一次线上事故，理解混沌工程为什么存在
很多团队第一次接触混沌工程，是因为线上出过一次大事故。某个核心服务依赖的 Redis 集群抖动了几百毫秒，结果整个调用链都跟着超时，最后丢了一堆订单消息。事后复盘时大家发现，系统里其实有不少保护机制——超时重试、熔断、降级配置——但从来没有一个场景真正验证过它们在故障叠加时是否还能发挥预期作用。这类问题，用常规的单元测试、集成测试很难暴露出来，因为测试环境里一切正常，故障不会自己排好队来找你。
混沌工程的本质不是“搞故障”
混沌工程的思路其实很简单：在生产或者贴近生产的环境中，主动注入可控的故障，观察系统是否还能维持稳态。这里的“稳态”不是不报错，而是业务指标仍然在可接受范围内。比如请求成功率保持在 99.9% 以上、P99 延迟不超过 500ms、消息不积压等等。如果故障注入后这些指标没有明显劣化，说明系统的容错设计是有效的；如果指标跌穿阈值，你就找到了一条未被验证的脆弱链路。
所以混沌工程真正要回答的问题是：当依赖的组件不像文档里描述得那么可靠时，我们的系统还能不能继续提供服务？这个问题靠代码评审和架构图回答不了。
为什么选择 Chaos Mesh
Chaos Mesh 是云原生计算基金会（CNCF）下的开源混沌工程平台，专门为 Kubernetes 设计。它用 CRD（自定义资源定义）来描述混沌实验，你只需要 apply 一个 YAML，就可以让集群中的某个服务经历网络延迟、丢包、Pod 被杀、磁盘 IO 错误、CPU 占满等异常。相比自己在业务代码里写故障注入逻辑，Chaos Mesh 的优势在于和基础设施层面工作，对应用无侵入。
更重要的是，它提供了实验定义、执行、编排、状态反馈一套完整机制，适合团队把混沌实验纳入常态化稳定性建设，而不是偶尔手动搞一次。下面这个对比可以帮助你快速建立判断：
| 维度 | Chaos Mesh | Litmus | 自研故障注入 |
|---|---|---|---|
| 故障注入范围 | Pod、网络、磁盘、压力、时间等 | Pod、网络、Chaos 实验库丰富 | 取决于实现，通常覆盖特定场景 |
| 部署与维护 | Operator，Helm 即可安装 | Operator，支持多集群 | 需要自己开发和维护 |
| 实验管理 | CRD + Dashboard，支持工作流 | CRD + Portal，支持编排 | 通常较弱 |
| 可观测性 | 对接 Prometheus，有实验指标 | 指标需要自行集成 | 从零搭建 |
| 适用团队 | 以 Kubernetes 为核心平台 | 多环境、多集群且有中台能力 | 有特殊故障类型约束 |
一个最简单的延迟注入实验
我们用一个最常用的场景来感受一下：模拟对某个支付服务的网络延迟注入，持续 5 分钟。定义文件如下：
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
name: delay-payment-service
spec:
action: delay
mode: one
selector:
apps:
- payment-service
delay:
latency: "500ms"
jitter: "100ms"
duration: "5m"这个实验的含义是：从支付服务实例中随机挑一个 Pod，对它的入口流量增加 500ms 延迟，并附带 100ms 抖动，持续 5 分钟。执行时只需要 kubectl apply -f delay.yaml，之后去观察监控面板上支付链路的成功率、耗时和依赖服务状态。实验结束后，Chaos Mesh 会自动恢复。
设计一场混沌实验的关键步骤
如果只要求跑通一次实验，其实很简单。但真正的难点在于设计一场有效的实验。我建议按照下面的顺序来准备：
- 定义稳态假设：先想清楚你要保住的核心指标是什么，例如“下单成功率不低于 99.9%”、“支付 P99 低于 1s”。没有稳态假设，实验就没有裁判。
- 缩小爆炸半径：从低风险服务开始，比如内部存储的备份链路、非核心的异步通知，而不是直接砍掉数据库主节点。逐步扩大，养成肌肉记忆。
- 选择故障类型：根据系统已知的薄弱点注入，而不是随机破坏。例如上游依赖的 Redis 曾经抖动，那网络延迟就是一个很好的候选。
- 观察与记录：注入前、注入中、注入后的指标都要保留。注意看告警是否及时触发，降级是否真的生效。
- 恢复与复盘：实验结束后，对照稳态假设得出结论，并把发现的问题列入整改清单。
这里最容易忽略的是“缩小爆炸半径”。我见过一个团队在预发环境做网络分区实验，结果整个配置中心的服务发现缓存失效，所有下游都在重试，预发环境几乎瘫痪。表面上看是实验引发了故障，但回头看，问题其实出在基础组件对故障的感知和恢复能力上。混沌实验的价值就在这里：它逼着你把系统看作一张网，而不是一个个独立的服务。
常见误区：验证系统稳定性的三种偏差
这几年混沌工程逐渐普及，我观察到团队最容易踩的坑有三个。
第一个是把混沌工程做成了“故障演练”。两者形式上很像，但混沌工程更强调假设验证和持续学习，而不是按时交一份演练报告。如果实验是为了应付安全检查，那它很难发现深层问题，反而会让团队产生虚假的安全感。
第二个是忽略监控能力就直接开测。稳态假设必须依赖可观测性，否则故障注入后你看不到变化，实验就成了盲人摸象。我建议至少先完善链路追踪、核心指标监控和告警通知，再开始写第一个 Chaos Mesh 实验文件。
第三个是认为故障注入越多越好。实际上，在高峰期对核心链路做没有保护的全链路破坏，可能会把可控的实验变成真实的生产事故。混沌实验的递进节奏非常重要，从小故障到大故障，从单实例到多实例，每一步都需要有明确的预期和回滚方案。
落地路径：从测试环境到生产环境的节奏
对于刚开始接触混沌工程的团队，我的建议是从两条线同时推进。一条线是技术建设：先补齐链路追踪和核心指标监控，安装好 Chaos Mesh，准备一个隔离的测试环境；另一条线是组织规范：和运维、业务负责人约定好可接受的爆炸范围，明确每次实验需要审批，并有回滚预案。
当团队具备一定经验后，再逐步把实验推向生产环境。此时可以选择流量低峰期，对部分实例进行小范围注入，并借助 Kubernetes 的副本机制保障整体容量。比如某个服务有 10 个副本，先对其中 1 个副本注入故障，观察现象后再决定是否扩大范围。这个思路比一次性破坏多个副本要安全得多。
长期来看，混沌工程应该和 CI/CD 流程结合起来。比如在每次版本发布前，自动跑一组基础混沌用例，确保新增依赖没有破坏已有容错能力。这样的投入比事后救火小得多。
记住，混沌工程的目标不是“搞坏系统”，而是建立系统能恢复的确定性。如果实验后你没有办法很快恢复，说明你还没有准备好实验，而不是实验本身有问题。
最后的判断：工具很重要，但不是全部
回到最开始那个 Redis 抖动的事故。如果团队在事故之前就已经用 Chaos Mesh 做过类似的延迟注入，那么降级配置是否生效、缓存重建是否需要保护，这些问题都会提前暴露在测试报告里，而不必成为一次凌晨三点的紧急通知。混沌工程不会消除所有故障，但它能让团队在故障真正来临时，多一份从容。
原创文章，作者：fudengji，如若转载，请注明出处：https://fudengji.cn/article/748/