混沌工程的十年：从流行概念到可靠性基石

一、从“爆红”到“平静”

如果你在 2016 年前后关注过云原生或 SRE 领域，大概率听过混沌工程（Chaos Engineering）这个概念。

这个概念诞生于 Netflix 的 Chaos Monkey 项目，主张“主动制造故障、验证系统可靠性”，当时被认为是可靠性工程的革命性突破。短短几年，它便迎来高光时刻：

• Netflix 发布完整的 Simian Army 实验工具链；

• Gremlin、ChaosIQ 等商用平台崛起；

• AWS、Azure、Google Cloud 等云厂商纷纷推出原生故障注入功能；

• ChaosMesh、Litmus、ChaosBlade、PowerfulSeal 等开源项目快速迭代。

2016 到 2020 年，是混沌工程的黄金时代。然而到了 2025 年，在大会议程、GitHub 趋势榜，乃至招聘 JD 里，几乎很少再看到它的身影。混沌工程真的不流行了吗？

二、混沌工程的本质与价值

混沌工程的核心思想：

在可控环境中主动制造异常，验证系统在不确定条件下的稳定性与恢复能力。

其核心价值在于将“故障”从威胁变为工具，用实验的方式让系统更稳定、团队更成熟、组织更有韧性，体现在如下四个方面：

1. 工程层面：从被动修复到主动验证，提高架构容错与稳定性设计质量

2. 组织层面：构建可靠性工程体系，让可靠性成为可度量的指标

3. 文化层面：让团队接受“不确定性”的常态，打造“抗脆弱”的工程文化

4. 业务层面：降低风险，提升客户信任与品牌可靠性

三、为什么混沌工程“不再流行”

1️⃣ 虚拟化削弱“杀实例”的必要性

过去：Chaos Monkey 随机杀掉 EC2 实例来测试系统弹性。

现在：Kubernetes、Auto Scaling Group、Pod disruption budget 等机制让节点失效能够被快速感知并自动修复。

结果：底层混沌实验的价值降低，因为系统天生具备恢复能力。

2️⃣ 流量治理和 Service Mesh 的普及

过去：Latency Monkey 通过在应用层或主机层模拟网络延迟和丢包来进行实验。

现在：Service Mesh（如 Istio、Linkerd）本身就支持流量注入、延迟控制等特性。

结果：原本需要 SRE 介入的网络层混沌实验，变成了平台的默认能力。

3️⃣ 稳定性验证部分前移到测试阶段

过去：混沌实验发生在生产环境，用于验证系统稳健性。

现在：通过“混沌测试左移”（shift-left chaos testing），如 Litmus、Gremlin、Chaos Mesh 等集成到 CI/CD 流水线。以 Chaos Mesh 为例，模拟 Pod 故障的 PodChaos，模拟网络故障的 NetworkChaos，模拟 DNS 故障的 DNSChaos，模拟 I/O 故障的 IOChaos，模拟时间跳动异常的 TimeChaos，模拟内核故障的 KernelChaos，模拟 HTTP 通信故障的 HTTPChaos，模拟 JVM 应用故障的 JVMChaos，均可在测试环境中通过单实例注入完成故障模拟。

                  （图 1-大部分场景其实都是可以在测试环境中通过单实例注入完成故障模拟）

结果：单实例的故障场景逐步迁移到测试阶段，进行常态化、自动化的验证。

4️⃣ 合规与风险限制使混沌实验的落地难度增加

合规问题：在金融、医疗等高合规行业，混沌实验涉及数据安全与系统稳定性，出于监管和合规要求，故障注入通常只能在测试或预生产环境中进行，以避免影响真实业务。

风险问题：在生产环境中开展混沌实验虽然能获得最真实的验证效果，但若缺乏完善的防护、观测与回滚机制，极易引发业务中断、数据损坏等问题。

结果：受合规与风险的双重约束，大量混沌实验被限制在测试或预生产环境中进行，验证效果大打折扣，也让混沌工程在企业中的落地变得更加困难。

总结

混沌工程之所以“不再流行”，并非理念错误，受制于合规和风险的双重约束，让混沌工程在生产环境中的落地难度陡增，进而转向和虚拟化、服务网格、自动化测试等领域进行融合，演变为现代基础设施的内生能力。

四、混沌工程落地的持续探索

1️⃣ 聚焦极端场景验证：断网演练

从 Netflix 的 Simian Army 也可以推测，Netflix 的混沌工程也遇到了相似的问题，因此其对故障注入场景不断进行丰富，从过去的杀节点变成了一个猴子军团，除去稳定性相关的场景外，还涉及到安全漏洞、实例健康度、配置合规和成本优化等领域。

还记得我们前面提到的，混沌工程的核心思想吗？在可控环境中主动制造异常，验证系统在不确定条件下的稳定性与恢复能力。那么查找闲置实例的 Janitor Monkey，你很难说它对可用性的直接贡献有多大。

参考业界对这一问题的思考和探索，我们可以看到，混沌工程在发展到一定阶段后，尤其是各方面的能力进行了一定积累和储备后，不再验证单个组件是否可用，而是验证整个系统在极端条件下是否仍能存活、降级或恢复，也就是所谓的极端场景验证。

常见的极端场景如断网演练，是近年来各大公司的主攻方向，除此之外，强弱依赖验证和全链路压测也是非常重要的。

2️⃣ 验证高危风险的应急处置能力

狭义的混沌工程，是必须有故障注入动作，但实际上任何可以帮助我们确信系统可以抵御突发事件的方法都可以归结为混沌工程。

因此，针对可能引发严重故障的风险点（参考公司历史故障和业界故障），开展混沌实验，提前暴露系统隐患并验证恢复能力也是混沌工程当前的重点方向。

3️⃣ 从场景全覆盖向决策智能化的演进

在混沌工程领域，有一句话很好地概括了智能化建设的意义：注入故障并不难，难的是弄清楚该在哪注入，以及为什么要注入。

提升场景覆盖率的时代已经过去。如今，各类开源故障注入工具大多进入维护期，而主流云厂商也推出标准化的托管实验平台，让团队能够以更低成本开展混沌实验，例如 AWS 的 Fault Injection Simulator、Azure 的 Chaos Studio、以及 GCP 的 DiRT（Disaster Recovery Testing）。这意味着，工具层的门槛正在降低，而决策层的挑战正在上升。

需要明确区分的是，注入的自动化与决策的智能化并非同一层次的能力。

所谓注入自动化，是指将人工执行的杀实例和加延迟等操作实现自动化并例行化执行，其核心目标是提效与标准化。

而决策智能化，则面向生产环境，通过智能分析系统运行状态、依赖拓扑与历史故障数据，自动识别潜在的风险与薄弱点，并生成相匹配的注入方案，从而实现更具针对性的验证。同时，智能化注入还具备较强的安全防护能力，能够在实验设计与执行过程中动态评估风险、控制影响范围，确保混沌实验既敢做，又可控。

五、小结

可以看到，混沌工程并未消失，而是在悄然演化。从最初的“杀实例”到如今的“智能决策”，它的形态在变，核心逻辑未变，依然是在可控的混乱中寻找确定性，让系统在不确定中保持稳定与韧性。

随着系统复杂度的上升以及混沌工程自身能力的持续完善，混沌工程的责任也在加重，逐渐承担起极端场景验证的使命：在断网演练等最坏条件下，确保业务依旧可用、系统能够自愈。

正因如此，混沌工程已不再是一时的流行概念，而是演化为现代可靠性体系的基石，支撑着企业在复杂、不确定的世界中保持秩序与稳定。