谈谈运维稳定性_关于平台稳定性运维，2024年最新2024最新大厂高频微服务面试总结

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

在此模型中，他从SRE的视角出发，将稳定性建设也分了7层。

1. 他认为稳定性建设最基础是监控(Monitoring)。没有监控，一个服务是否稳定无从谈起。我们首先得知道服务运行情况，当系统哪里出了故障，我们需要及时发现(告警)。

2. 当获知系统出故障后，SRE们需要作出一些应急响应(Incident Response)，包括24小时on-call机制，系统降级预案，协同相关方进行进一步分析，定位最终原因并修复上线。

3. 事后，还需要组织进行深度复盘和根因分析(Postmortem/Root Cause Analysis)。我们需要做到从失败中学习，并尽量保证未来不会掉进同样的坑。

4. 前三步都是在做一些防御工事，我们应该尽量在测试阶段就发现问题，并通过科学的发布过程来保证不会轻易引入新的线上问题(Testing+Release procedures)。

5. SRE们还需要关注容量需求的变化情况(Capacity Planning)。系统是动态的，我们需要尽力做到让资源在适当的时机，能够灵活的调配到真正需要他的地方。

6. 以上做好之后，还需要关注一些研发的工作(Development)。这部分包括原先的系统实现是否合理，从问题反推，是否可以有更合理的设计，并推动优化。当然还有一些必要的工具也需要开发。

7. 稳定性最终极要关注的是产品本身(Product)。从用户角度，稳定性意味着什么？哪些是他们核心关注的？我们应该努力通过产品和流程设计等减少用户对系统故障的感知，甚至做到无感。

有了上面介绍，从运维的角度去分析，是需要把上面金三角的地基打好。

就是基础监控以及故障响应、复盘文档做好。

而基础监控因公司架构而异：

有的公司是全云架构，这种监控做起来会比较轻松，因为部分base监控可以使用云自带的，一些中间件再自己使用开源的即可，例如普罗+grafana即可，再加上各种export收集中间件的数据。

而如果有自己idc机房，有大量物理机器和交换机设备需要监控的时候，需要考虑的指标就多起来了，例如硬件设备的老化、线的老化、网卡的老化等等，每一项的替换都是成本的支出，而往往企业都是对成本看得很紧，这下就见仁见智了。

在降本的情况下，在维持稳定性上面，故障响应以及自动治愈，这就显得十分重要了。

存在很多历史问题无法解决时，如果你的服务上无法做到自动治愈，需要人工手动恢复，故障时长将无法得到保证。分分钟面临的都是客户的投诉。影响面会非常广，大到公司在前面销售的同事没有信心去售卖自家公司的产品等。

复盘故障：每一次可以复盘故障的机会都难能可贵，都是技术的一次积累，防止重复跳坑。

应用发布：devops基本每家公司都在做，一个好的发布平台是可以减少很多业务故障的。因为每一次发布都需要经过一层层的review才可以发布，可以很好降低一些不必要的人工干扰的bug。

最后是业务接口的监控：

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**