5.5 混沌工程与稳定性验证

5.5 混沌工程与稳定性验证

本节摘要：稳定性不是纸面上说"我们很稳"，而是要证明给系统看——故意往生产里制造故障，观察它在故障下是不是真扛得住。这就是混沌工程。本节讲混沌工程的原则（爆炸半径、先验证后放火、可回滚），用一个"断网混沌实验"的完整走场，展示怎么设计爆破半径、观察指标、回滚预案，并给出从演练到常态化混沌平台的落地建议。

为什么坐着不稳，得放火烧一下才知道

最贵的教训永远来自"第一次遇到"的网络抖动、节点宕机。平时系统看着稳，是因为故障还没发生；你不知道它在故障下的表现，就只能赌。混沌工程换个思路：与其等故障找上门，不如我主动放一把可控的火，看看熔断、降级、重试这些保护机制有没有真的发挥作用。

一句话：稳定性的证明方式是经过验证，而不是因为没出过事。混沌工程就是把"假设很稳"变成"被证明很稳"。

四条铁律：爆破半径、先验证、可回滚、自动化前先手动

新手最容易一上来就往全站放火,那是事故不是实验。混沌工程有铁律护体：

第一，爆破半径要可控。第一把火永远只烧一个小范围——一个实例、一个节点、一个可用区，别一上来全网。先把系统在小范围的故障下是不是扛得住验证一遍,再考虑放大。

第二，先观测后放火。放火前，先把"什么指标是基线"记下来，放火中记录变化，放火后对比——没有基线你根本看不出火烧了有没有影响。

第三，必须有回滚预案。每场混沌实验都要预先想好"一旦系统没扛住，我半分钟内怎么恢复"。没有退出按钮的混沌实验就是纸面赌命。

第四，从手动到自动化。第一轮混沌先手动执行、人肉观察，跑顺了以后再做成可配置的自动化平台,定期自动演练。

一场断网混沌实验，完整走场

我们设计一场最经典的："断开一个可用区的网络连接"，看系统能不能优雅降级到其它可用区。目标假设:"多可用区部署能扛住单可用区断网"。

第一步，定爆炸半径：只烧 A 可用区的入网流量,不碰 B、C 区,更不碰数据库主节点。范围就锁定在一个象限。

第二步，记基线：放火前先记录核心指标半小时:支付 QPS、综合错误率、P95 延迟、跨区调用成功率。这些是"火烧"的对照组。

第三步，放火：在 A 区网关层切断入网流量,模拟该区网络中断。持续 15 分钟。

第四步，观察：记录放火期间的指标变化。视觉上,我们看"跨区调用成功率"——如果 B、C 区接管后成功率仍接近 100%,说明降级生效;如果掉到 80% 以下且 P95 涨到几秒,说明这个可用区是某些请求的必经通道,降级预案不成立。

第五步，回滚：15 分钟后恢复 A 区网络,观察指标回落穿越基线。

第六步，结论与改进：本次假设成立——B/C 区成功接管,成功率 98.7%,P95 略涨但可控。本次实验暴露的问题是:切换期间有几类请求触发了大量重试,日志刷屏。改进：给这些请求的熔断阈值调低一档再观察。于是混沌实验从"验证了"直接产出"改进项"。

混沌指标怎么看，看什么

混沌实验的观测指标要有讲究,不是什么都看,建议聚焦"用户可感知"的:

• 错误率与成功率:用户是不是报错了。
• P95/P99 延迟:用户是不是变慢了。
• 跨区/降级后的关键链路:预制的降级有没有真把流量接住。
• 熔断/重试计数:保护机制有没有被触发、有没有误伤。

收锤时判断就一条:故障范围内用户没有明显受损 = 实验通过。受损了就能刻录下"我们还没准备好"，回滚后再写改进。要特别提醒:实验通过不等于系统完美,它只说明"在这一次注入下扛得住",换个故障类型、换一个更大的爆炸半径,结论可能完全不同——所以混沌不是一次性的资格认证,而是需要持续重新验证的练习。

一场实验的时间轴画出来，爆炸半径、基线与回滚的位置一目了然——四个阶段环环相扣，任何一步缺腿，实验就从"验证"退化成"赌命"。

整个循环看得越清楚，就越该把"回滚预案"焊在放火之前——没有退出按钮的实验，算不得实验。

什么时候上混沌平台

刚开始别搞重武器,先用一台实验网关手动跑（如上例）。当你想常态化演练——比如"每月一场全栈故障演练"——再引入混沌平台,让它自动化编排:随机挑选目标、在低峰期自动触发、自动对指标判定、自动出报告。但平台也有它的代价:编排规则本身会老化,平台自己也可能成为故障源,所以上平台前先问一句"我的假设+验证+改进循环转起来没有"——如果还没转起来,平台只会把没想清楚的动作自动化放大。平台的本质是把探索流程固化,它不是混沌工程本身,真正的价值在"假设验证"这套循环有没有转起来。

让混沌实验"养"出改进清单

混沌工程很容易出现"实验通过=完事"的错觉。我见过最好的团队,每次混沌实验结束,不只看"通过没有",而是单独产出一张改进清单,像上面那场实验就把"某类请求切换期重试过多"记进了改造项。混沌的最高价值,不是验证"我们扛得住",而是连续产出"我们还有哪里脆弱、该怎么补"。如果一场实验结束只是打个勾,那是把验证当成了终点——正确做法是让混沌成为持续暴露问题的探针,每次实验都给后续的监控、熔断、降级策略喂一个可落地的改进项。这也是混沌工程和普通故障演练最本质的区别:演练是"过了就完",混沌是"过了还要留下下一桩能补的弱项"。每周一次小实验,每月一次中实验,其实不难,但能帮你把防御网越织越密。一开始哪怕只测一条最关心的链路,也是开始,重要的是让"主动验证"这件事成为团队的肌肉记忆,而不是等出事才想起要看一眼系统到底抗不抗造。

本节要点回顾

• 稳定性要证明不要假设：没出过事不等于扛得住。
• 四条铁律：爆炸半径可控、先记录基线、有回滚预案、手动先再自动化。
• 第一把火最小化：只烧一个节点或可用区,别全站。
• 无基线不观测：放火前先记录对照数据。
• 判断标准：故障范围内用户没明显受损 = 通过。
• 失败也是产出：暴露了熔断/重试/logging 的问题,就是实验的价值。
• 从手动到平台：跑顺了再上自动化,平台只是固化流程。

至此,可观测性与高级分析的五块拼图齐了:链路、APM、AIOps、SIEM、混沌。最后一章我们把所有能力落地成选型——第六章给值班室配齐那套家伙。