系统总会在最意想不到的时候出故障：数据库主库宕机、网络分区、依赖服务超时、磁盘写满。很多团队平时不做演练，等故障真的发生，手忙脚乱，损失惨重。故障演练（Chaos Engineering / 混沌工程） 正是为了应对这一点：主动注入故障，验证系统的容错能力，在和平时期暴露问题。它不是"制造麻烦"，而是"提前发现麻烦"。本文将从理念、方法、实践到文化，系统探讨故障演练。
一、什么是故障演练
故障演练：主动在系统中注入故障（如杀进程、断网、延迟），观察系统行为，验证容错能力。
核心思想：在可控环境暴露问题，好过在生产环境被动应对。
类比：消防演习、军事演习——平时多流汗，战时少流血。
关键认知：故障演练不是"搞破坏"，而是"验证假设"——我们假设系统能容错，真的吗？
二、为什么需要故障演练
1. 故障不可避免
分布式系统中，网络、硬件、软件故障是常态。假设"不会出问题"是危险的。
2. 容错能力需要验证
代码里写了重试、熔断、降级，但它们真的有效吗？只有演练能验证。
3. 发现隐藏问题
很多问题平时不暴露，故障时才显现。演练提前暴露。
4. 提升应急能力
演练让团队熟悉故障处理流程，减少真实故障时的慌乱。
5. 建立信心
经过演练的系统，团队敢于发布、敢于应对。
三、故障演练的原则
1. 建立稳态假设
先定义"正常"是什么（如错误率 < 0.1%，延迟 P99 < 200ms），演练后对比。
2. 模拟真实故障
注入的故障应贴近真实（如网络延迟、节点宕机），而非臆想。
3. 在生产环境演练（谨慎）
生产环境最真实，但风险高。可从预发环境开始，逐步到生产。
4. 控制爆炸半径
从小范围开始，限制影响，可随时停止。
5. 自动化
手动演练难持续，自动化才能常态化。
6. 持续进行
一次演练不够，要持续、定期。
四、常见的故障类型
1. 资源故障
- CPU 打满
- 内存耗尽
- 磁盘写满
- 文件句柄耗尽
2. 网络故障
- 网络延迟
- 网络丢包
- 网络分区
- DNS 故障
3. 服务故障
- 服务宕机
- 服务超时
- 服务返回错误
- 依赖不可用
4. 数据故障
- 数据库主库宕机
- 数据不一致
- 缓存失效
5. 基础设施故障
- 节点宕机
- 可用区故障
- 容器被杀
从简单到复杂，逐步演练。
五、故障演练的流程
1. 定义稳态
明确系统正常时的指标：错误率、延迟、吞吐、业务指标。
2. 提出假设
"如果杀掉一个节点，系统应自动恢复，错误率不超过 X%。"
3. 设计实验
- 注入什么故障
- 影响范围
- 持续时间
- 观察指标
- 停止条件
4. 小范围执行
从预发或小流量开始，观察。
5. 观察结果
对比稳态，看是否符合假设。
6. 分析改进
- 符合假设：容错有效
- 不符合：找原因，修复
7. 扩大范围
逐步扩大，直至生产。
8. 复盘
记录发现的问题，改进系统。
六、故障演练的工具
1. Chaos Monkey
Netflix 开源，随机杀实例，验证系统容错。
2. Chaos Blade
阿里开源，支持多种故障注入。
3. Litmus
Kubernetes 原生混沌工程工具。
4. Gremlin
商业混沌工程平台。
5. 自研工具
按需自研，灵活可控。
工具是手段，理念是核心。
七、故障演练与可观测性
演练离不开可观测性：
- 监控：实时看指标变化
- 日志：分析故障细节
- 追踪：定位链路问题
- 告警：验证告警是否及时
没有可观测性，演练就是盲人摸象。
八、故障演练的文化
1. 不指责
演练暴露问题是好事，不追责。
2. 接受失败
演练失败是常态，从失败中学习。
3. 持续改进
每次演练后改进系统。
4. 全员参与
开发、运维、测试共同参与。
5. 常态化
演练不是一次性活动，而是日常。
6. 领导支持
领导重视，资源到位。
九、故障演练的误区
1. "演练就是搞破坏"
演练是验证，不是破坏。有目标、有控制。
2. "演练影响生产"
控制爆炸半径，小范围、可停止。
3. "一次演练就够了"
系统在变，需持续演练。
4. "演练是运维的事"
开发也要参与，理解系统容错。
5. "演练失败是坏事"
失败暴露问题，是好事。
6. "没有可观测性也能演练"
没有监控，演练无效。
7. "演练风险太大"
不演练的风险更大。
十、从小开始的实践
第一步：预发环境
在预发环境杀一个实例，看是否自动恢复。
第二步：小流量生产
生产环境小流量注入延迟，看熔断是否生效。
第三步：定期演练
每月一次，形成制度。
第四步：自动化
工具自动注入、自动观察、自动回滚。
第五步：GameDay
组织"故障日"，集中演练多个场景。
循序渐进，逐步深入。
十一、一个实践案例
场景：某电商系统，担心数据库主库故障。
演练：
- 预发环境：手动切换主从，验证切换流程
- 生产环境：低峰期，模拟主库延迟，观察读写分离、降级是否生效
发现：
- 切换脚本有 bug，切换失败
- 部分服务未配置降级，直接报错
改进：github.com/kevinedsam/qaq/issues/261
- 修复切换脚本
- 补充降级逻辑
- 定期演练
结果：真实主库故障时，系统自动切换，用户几乎无感。
对比：若不演练，真实故障时可能长时间不可用。
十二、故障演练的进阶
1. 混沌工程平台
自动化、常态化、可观测。
2. 生产环境演练
在可控前提下，生产环境演练最真实。
3. 故障注入即代码
故障场景代码化，可重复、可版本控制。
4. 与 SRE 结合
SLO、错误预算驱动演练。
5. 红蓝对抗
模拟攻击与防御，提升应急能力。
结语
故障演练是"在和平时期准备战争"。它主动暴露问题，验证容错能力，提升应急水平。
记住几个原则：
- 建立稳态假设，对比验证
- 模拟真实故障，贴近现实
- 控制爆炸半径，可随时停止
- 自动化、常态化
- 从小范围开始，逐步深入
- 离不开可观测性
- 不指责，持续改进
系统总会出故障，区别在于：是提前发现，还是被动应对。故障演练让团队在真实故障前做好准备，让系统在真实故障时从容应对。平时多演练，战时少损失——这是成熟团队的必修课。
