混沌测试（Chaos Testing/Chaos Engineering）

混沌测试（Chaos Testing/Chaos Engineering），简单说就是：故意在系统里制造可控的故障，验证系统会不会崩、能不能自愈，提前找出架构弱点，提升分布式系统的韧性（弹性 / 容错能力）。

一、核心概念

• 起源：2008 年 Netflix 提出，代表作 Chaos Monkey（混沌猴）：生产环境随机杀实例，倒逼架构容忍单点故障。
• 本质：主动注入故障 → 观察系统反应 → 暴露弱点 → 加固系统。
• 适用场景：微服务、云原生、分布式系统（节点多、依赖复杂、故障不可预测）。

二、为什么需要混沌测试

传统测试（功能 / 性能 / 接口）是 “验证正常流程”；混沌测试是 “主动搞破坏，验证异常下的韧性”。

• 提前发现单点故障、雪崩效应、隐藏依赖、配置错误。
• 验证熔断、降级、限流、重试、容灾、自动恢复是否生效。
• 提升生产事故信心：小故障常态化，大故障不慌。

三、常见故障场景（注入什么）

• 资源类：CPU 飙高、内存溢出、磁盘满、IO 打满。
• 网络类：延迟、丢包、分区、DNS 故障、连接断开。
• 服务类：杀进程、实例宕机、接口超时、依赖服务不可用。
• 数据类：数据库挂掉、连接池耗尽、缓存失效、数据错乱。

四、实施步骤（怎么做）

1. 定义稳态：明确正常指标（成功率≥99.9%、延迟 < 200ms、无报错）。
2. 设计假设：如 “支付服务挂掉，订单服务应降级并可重试”。
3. 选环境与工具：先灰度 / 测试，再生产；工具如 Chaos Monkey、Chaos Mesh、Gremlin、ChaosBlade。
4. 注入故障 + 监控：小范围、可控、可回滚；实时看指标、日志、告警。
5. 分析 + 改进：找出弱点，优化架构 / 策略，闭环验证。

五、关键原则（安全第一）

• 最小影响：从10% 流量、单实例、非核心链路开始。
• 快速回滚：必须有自动停止 / 恢复机制，避免扩大故障。
• 不搞 “大破坏”：目标是学习，不是搞崩系统。

六、和传统测试的区别

• 传统测试：验证 “正常行不行”；场景已知、预期明确；找功能 / 性能 bug。
• 混沌测试：验证 “异常下扛不扛得住”；场景随机、未知；找架构弱点、韧性问题。

七、一句话总结

混沌测试 = 可控的 “搞破坏”，用小混乱换大稳定，让系统在意外面前更能扛。