4、故障演练的流程与阶段：规划、设计、执行、分析、改进
故障演练不是拍脑袋搞破坏。很多团队一上来就“炸个网络试试”，结果炸完啥也没学到，反而把生产搞崩了。我见过太多这样的案例。说白了，演练是一个闭环工程——规划、设计、执行、分析、改进，五个阶段缺一不可。今天我就把这套流程掰开揉碎给你讲清楚。
4.1 规划阶段：先想清楚再动手
规划是地基。地基不稳，后面全白搭。我个人习惯把规划拆成三步：
- 定范围：这次演练覆盖哪些服务？是核心下单链路，还是日志上报通道？范围越小越容易控制爆炸半径。
- 定目标：想验证什么？可用性指标（比如99.9%的请求成功率）、延迟阈值（P99不超过200ms）、还是数据一致性？目标得可量化。
- 定风险预案：万一真搞砸了怎么办？回滚脚本、停止按钮、监控告警阈值，这些必须在演练前就位。
我记得有一次在电商大促前做演练规划，团队只说了句“模拟Redis宕机”。我问他们：宕机后降级策略是什么？缓存穿透打到数据库怎么办？没人能马上答上来。那次之后，我就要求规划文档必须包含“场景→预期行为→止损步骤”三栏表格。
4.2 设计阶段：把场景拆成可控单元
设计阶段就是画“爆炸图”。我不建议上来就用ChaosMesh一键注入，先把场景写清楚再说。设计阶段的核心产出是一张故障场景卡片，包含以下要素：
| 要素 | 说明 | 示例 |
|---|---|---|
| 故障类型 | CPU、内存、网络、磁盘、进程、依赖 | 网络延迟 |
| 注入对象 | 具体容器、Pod、或主机标签 | app=order, version=v2 |
| 注入参数 | 延迟时长、丢包率、CPU占比 | 延迟200ms, 丢包率10% |
| 持续时间 | 从注入到自动恢复的时间 | 5分钟 |
| 观察指标 | 通过哪些监控项观测影响 | 请求延迟、错误率、QPS |
| 成功标准 | 演练通过的条件 | P99延迟<500ms, 错误率<1% |
你想想看，如果连成功标准都没写，演练完了你拿什么判断系统"扛住了"还是"没扛住"？
4.3 执行阶段：像手术一样精细
执行不是一键爆破，而是分步推进。我建议严格按“灰度→小范围→全量”的节奏来：
- 第一步：在预发/压测环境执行。确认工具正常、监控数据能打到看板。
- 第二步：生产环境随机一台机器注入。观察5分钟，确认没有连锁故障。
- 第三步：逐步扩大范围。10% → 30% → 50% → 100%，每步观察并评估。
- 第四步：恢复。执行恢复脚本，确认指标回落基线。
# 举个简单的执行命令例子（使用chaosblade）
# 注入CPU满载30秒，目标为order-service的Pod
blade create cpu load --cpu-percent 80 --timeout 30s --target order-service-pod-xxx
# 执行后立即检查告警：
# 1. 告警平台是否收到CPU告警？
# 2. 下游库存服务调用是否超时？
# 3. 自动扩容是否触发？4.4 分析阶段：别只看指标，要看日志和调用链
很多团队分析时只盯着P99延迟和错误率。这远远不够。我习惯在看板基础上，再拉三个维度的数据：
- 日志模式：服务在故障期间报了什么WARN/ERROR？是否有大量重试Log？
- 调用链追踪：哪个环节超时？熔断是否触发？降级后的数据是不是脏数据？
- 业务反馈：对用户来说，故障表现为“页面白屏”、“提交失败”还是完全无感？
举个例子，有一次演练时QPS下降10%，但P99没怎么涨。团队觉得没问题。我多看了一眼调用链，发现Gateway层做了静默降级——把某些数据返回成了空数组。业务表现就是首页一半模块不显示，用户感知很强烈。这就是只看指标的坑。
4.5 改进阶段：把发现转化成代码和流程
改进是最容易被跳过的一环。演练完了，写个报告，群里发一下，然后……就没有然后了。这种演练毫无意义。我改进了多少次？嗯，做得比较狠的一次，团队每月演练生成的Action Item必须在下个月演练前全部关闭，否则不能开始新一轮。
改进通常分三类：
- 代码修复：比如发现重试机制有问题，直接改代码提PR。
- 配置优化：超时时间设短了、熔断阈值设高了，调整配置并做回归。
- 流程补丁：比如监控告警漏配、值班响应流程不清晰，更新SOP文档。
完整的五阶段闭环
这五个阶段不是线性走一遍就完事，而是一个螺旋上升的闭环。每次演练后，改进的结果会融入下一次的规划与设计。下面这张图你保存好，以后每次做演练都可以拿来对照：
图里箭头是闭环的——从规划出发，经过设计、执行、分析，然后改进，改进的结果又回到下一轮规划。你看，这不是一次性动作，而是一个不断淬炼系统韧性的过程。