在团队里兼职做稳定性保障相关的工作，有一二年了吧，有一点经验和思考，做些总结和输出吧，欢迎指正。

首先要明确对系统的稳定性保障，并非是完全不能出现问题。越是复杂庞大的系统，就越有可能出现问题。参考云厂商在提供服务的时候，会有服务等级协议 SLA ，一般承诺可用性不低于 99.9%，但不会是 100%。所以在做稳定性保障之前，要先容忍不稳定的问题的发生。

其次要知道对系统做稳定性建设，是一件螺旋向上和持续优化的事情，而非一步到位就万事大吉了。这个月的问题数量比上个月少，这周告警认领率比上周高，这次故障影响面比上次小等等，都可以算作稳定性建设的成果。

回到主题。限流降级确实重要，但当做这些措施的时候，问题已经发生了。有没有一种方式，可以完全避免问题的发生呢，举个例子：当一个危险变更上线的时候，在多重审核机制下，被其他同事识别风险并阻断流程，能不能减少一次线上故障呢。

鸟瞰稳定性保障这件事，从时间维度可以分为事前->事中->事后三个节点，事前尽可能预防，事中及时高效处理，事后再做积极复盘。

在事前的预防阶段，首先要做的就是明确核心业务的核心链路，隔离故障影响面的带来直接效果会是最好的。要为其定制高可用的保障方案，例如历史代码的技术债务清理、应用独立集群和高规格部署、流量高峰期的弹性伸缩配置、避免与非核心业务共享存储资源、设计一套保障 VIP 用户体验的灾备通道流程等等。最具价值的业务流程自然是我们保障工作的重点。当然还有研发规范、变更管控、风险巡检、压测演练等这些日常需要经常执行的事情，甚至可以定期举办一些带奖品的简单考试，使稳定性的风险意识人人具备。

在事中的处理阶段，大部分人都存在一个误区：处理线上问题的时候，定位根因永远不是第一优先级，快速恢复业务才是。举个例子：在杭州自来水异味的事件中，排查臭味来源不是第一优先级，快速恢复居民正常供水才是，毕竟没有人会想喝一周时间的藻类降解物的自来水。为了使业务快速恢复正常，变更回滚、扩容升配、应急预案、必要的熔断限流降级等等，该用的措施就该及时用上，不熟悉业务的值班人员也该紧急联系业务老手才是。

另外，与问题没有被高效处置来说，更令人可怕的是问题没有被及时发现，毕竟没有人会想经历一次毫不知情的屎到淋头的感觉。监控和告警是大型应用系统不可或缺的一部分，除了机器水位指标，关键业务指标才是更加需要被关注的。核心指标的异常波动需要结合 IM 或者电话等能力，做到第一时间触达至正确的人，并且要搭配合理的升级机制，非核心指标的短暂波动要尽可能地减少干扰，让有限的精力始终保持在核心的业务上。

还有，对问题的处理效率是减少业务影响面的关键因素，可以按照问题发现->处置->恢复分为三个阶段，给每个阶段定一个耗时指标 MTTR ，例如五分钟发现、五分钟处置、十分钟恢复，每次问题处理过程中记录这些耗时，存在几次未达成是可以接受的，但要保持整体趋势往这个方向前行。

在事后的复盘阶段，需要注意避免定级定责带来的撕逼甩锅，要从做好保障和避免再次发生的角度来推进。每次复盘的知识库要沉淀，改进项要及时跟踪，避免这次复盘的问题根因，又再次出现。

最后再说，稳定性建设是一个高维度跨团队的事情，需要从上而下地和各方协作，才能最终执行到位。虽然说了很多方法论，但都是高屋建瓴的话语，我深知稳定性保障的难做，希望对楼主有所帮助吧。