Appearance
混沌工程入门：用可控实验检查系统韧性
修订于 2026-10-12。本文是方法说明，不包含本站亲历事故或实测性能数据。
混沌工程通过有边界的实验，检查系统遭遇故障时是否仍能满足预期。它的起点是可验证的假设：例如“一个应用实例不可用时，请求仍能通过其他实例完成”。注入故障只是手段，观察和复盘才是目的。
先定义稳态
稳态要反映用户体验或业务结果。可选指标包括成功请求比例、关键流程完成率、端到端延迟和队列积压量。CPU 使用率可以辅助诊断，却通常不能单独代表用户是否还能完成任务。
实验前记录正常波动范围、观察窗口和数据来源。把“可接受”的阈值写入实验方案。具体阈值须由目标系统的服务目标和历史数据确定，不应照搬通用数字。
写出故障假设与边界
| 项目 | 示例写法 |
|---|---|
| 假设 | 单个无状态实例退出后，入口仍能将请求转发至健康实例 |
| 故障 | 停止一个指定实例 |
| 范围 | 仅测试环境或经过批准的少量生产流量 |
| 观察 | 成功率、延迟、重试量、实例健康状态 |
| 停止条件 | 关键流程异常或告警达到预设阈值 |
| 恢复 | 重新启动实例，确认流量与数据恢复 |
先在可控环境验证故障注入和监控，再逐步扩展范围。生产实验需要明确负责人、维护窗口和停止权限；涉及有状态组件时还要考虑数据一致性与恢复时间。
执行与复盘
- 记录实验前基线，确认告警与恢复手段可用。
- 只注入一种预先定义的故障，记录开始和结束时间。
- 比对稳态指标、调用链和日志；达到停止条件就立即结束。
- 撤销故障并确认恢复，不把“注入动作成功”误认为“系统具备韧性”。
- 把意外结果转化为改进项，安排再次验证。
云服务的故障实验功能通常提供目标范围和停止条件。以 AWS Fault Injection Service 为例，停止条件可由 CloudWatch 告警触发；该机制仍不能代替对数据和业务风险的事前评估。
常见误区
- 没有假设就随机停机，难以解释结果，还可能扩大影响。
- 只看基础设施指标，忽略关键业务流程。
- 未设置停止条件或未验证恢复过程。
- 用演练次数代表质量，而不追踪问题是否修复。