ChatGPT 视角：故障频发背后的反思，重新理解稳定性

一、稳定性是一项复杂的系统工程

木桶原理：在一个复杂的系统中，如果一个组件的故障概率非常高，那么无论其他组件的稳定性有多高，整个系统的稳定性都会受到这个组件的影响。

二、稳定性保障高度依赖于经验积累

实践类学科：这类学科对人的经验有较强依赖。以医学为例，虽然医学理论是基础，但医生的诊疗技能往往需要通过实践来培养。每个病人的病情都有其独特性，医生需要根据自己的经验来进行判断和处理。虽然经验在实践类学科中扮演着重要的角色，许多实践类学科也在不断努力提高理论化水平，从而减少对经验的依赖，进而提高实践活动的效率和可靠性。

三、稳定性治理是百里行而九十在半途

低垂的果实 ：在很多领域，搞定『低垂的果实』就是大功一箭。以成本优化为例，目标是成本降低 1000 万，只要能达成目标即可，不是说一定要对最核心、最重要的服务进行成本优化，达成目标、风险可控是王道。

硬骨头：在稳定性治理领域，套用『低垂果实』这个逻辑，就会出大问题。以限流为例，我把十万个不重要接口的限流都加好了，就剩下 100 个服务（核心服务不敢动怕出事情），那治理的完成率超过了 99.99%，算完成了吗？但最容易出问题就是这 100 个服务，虽然前面做了很多，但其实又好像什么都没做。

这个问题上，是需要管理层在认知上拉齐的。按照做『低垂果实』项目的思路来要求『硬骨头』项目，大概率有人会通过玩文字游戏来搏一把，没做完肯定会暴雷，但不一定会立即暴雷。

烂梗：少一笔都不行

四、平台能力是决定稳定性的关键因素

基础架构：K8S 的出现，让稳定性保障的难度降低了几个数量级。现在有很多的稳定性保障能力都是基于 K8S 之上，如弹性伸缩、蓝绿发布、资源隔离、故障转移、服务发现、快速回滚，这些能力大幅降低了稳定性保障的门槛和成本，极大提升了运维效率，同时，很多的标准规范，也是内置于系统才能确保这些规范的持续有效。

事不过三：如果一个事情靠人执行且多次重复，就需要通过系统化的方式来解决。这里面的误区在于系统的价值并非是降低人力成本，而是提升了系统的自动化程度，避免人工介入可能导致的各种风险。

五、稳定性的动态平衡依赖于持续投入

变化：业务的快速迭代、用户规模的快速扩张以及系统功能的不断增加都会导致系统复杂度的增加，因此必须持续投入资源维护系统稳定性以实现稳定性的动态平衡。这点不论是成长期还是成熟期的公司都是适用的。（还有一种说法是叫熵增）

六、稳定性度量是区分运气和能力的关键

度量评价：建立稳定性整体的度量评价体系，涵盖从开发、部署、变更、加固、发现和止损恢复的全流程，从而能够完整全面识别稳定性建设的真实情况。避免单一指标如故障数量所造成的片面性。

七、蓝军是检验稳定性的重要手段

第三方评价：蓝军作为模拟真实威胁和提供客观评估的角色，在检验系统、网络和流程的稳定性方面发挥着重要作用。通过与蓝军的对抗和演练，组织能够不断提升自身的防御能力、应急处置能力和团队协作能力，从而确保在实际面临威胁时能够保持高度的稳定性。同时，也在一定程度上解决了基于故障评价体系一考定终身的很多弊端。

AZ 逃生：蓝军最关键的故障模拟场景其实是 AZ 逃生，通过整机房断网演练，来确保公司能够应对极端风险，并持续提升应急处置能力。

八、稳定性文化和意识至关重要

平衡业务迭代和稳定性： 在业务追求快速迭代的同时，也需要保证其产品或服务的稳定性。如果公司有清晰的稳定性文化宣贯，那么在设计新产品或服务，或者在进行变更时，员工会自然地考虑到稳定性的影响，从而在业务迭代与稳定性之间找到平衡。

减少长期成本： 如果公司有清晰的稳定性文化，那么员工在开发新产品或服务时，会更加注重质量和稳定性，这可以减少产品上线后出现问题，需要进行修复的频率，从而降低长期的运维成本。

降低风险：单纯依赖平台强制卡点和管控措施是不足够的，这种方法可能会在未被平台覆盖的领域中留下显著的风险敞口。因此，我们需要通过积极推广稳定性文化和意识，来增强员工对稳定性问题的辨识和判断能力。这样，员工能够主动规避高风险操作，从而降低潜在风险。结合平台的卡点管控措施，形成一种双保险机制，有效地确保系统的稳定性。

九、稳定性的终极目标不是 100%可用

预防为主：尽量避免严重故障的发生

快速恢复：在 SLA 要求的时效内快速恢复

微信公众号：智能运维

可以关注作者的微信公众号『智能运维』，及时查看最新文章，并进行实时交流。