混沌测试（Chaos Testing/Chaos Engineering） ，简单说就是：故意在系统里制造可控的故障，验证系统会不会崩、能不能自愈，提前找出架构弱点，提升分布式系统的韧性（弹性 / 容错能力）。
一、核心概念
- 起源 ：2008 年 Netflix 提出，代表作 Chaos Monkey（混沌猴）：生产环境随机杀实例，倒逼架构容忍单点故障。
- 本质 ：主动注入故障 → 观察系统反应 → 暴露弱点 → 加固系统。
- 适用场景 ：微服务、云原生、分布式系统（节点多、依赖复杂、故障不可预测）。
二、为什么需要混沌测试
传统测试（功能 / 性能 / 接口）是 "验证正常流程 "；混沌测试是 "主动搞破坏，验证异常下的韧性"。
- 提前发现单点故障、雪崩效应、隐藏依赖、配置错误。
- 验证熔断、降级、限流、重试、容灾、自动恢复是否生效。
- 提升生产事故信心：小故障常态化，大故障不慌。
三、常见故障场景（注入什么）
- 资源类：CPU 飙高、内存溢出、磁盘满、IO 打满。
- 网络类：延迟、丢包、分区、DNS 故障、连接断开。
- 服务类：杀进程、实例宕机、接口超时、依赖服务不可用。
- 数据类：数据库挂掉、连接池耗尽、缓存失效、数据错乱。
四、实施步骤（怎么做）
- 定义稳态：明确正常指标（成功率≥99.9%、延迟 < 200ms、无报错）。
- 设计假设：如 "支付服务挂掉，订单服务应降级并可重试"。
- 选环境与工具 ：先灰度 / 测试，再生产；工具如 Chaos Monkey、Chaos Mesh、Gremlin、ChaosBlade。
- 注入故障 + 监控：小范围、可控、可回滚；实时看指标、日志、告警。
- 分析 + 改进：找出弱点，优化架构 / 策略，闭环验证。
五、关键原则（安全第一）
- 最小影响 ：从10% 流量、单实例、非核心链路开始。
- 快速回滚 ：必须有自动停止 / 恢复机制，避免扩大故障。
- 不搞 "大破坏" ：目标是学习，不是搞崩系统。
六、和传统测试的区别
- 传统测试 ：验证 "正常行不行 "；场景已知、预期明确 ；找功能 / 性能 bug。
- 混沌测试 ：验证 "异常下扛不扛得住 "；场景随机、未知 ；找架构弱点、韧性问题。
七、一句话总结
混沌测试 = 可控的 "搞破坏"，用小混乱换大稳定，让系统在意外面前更能扛。