混沌工程与故障演练

本文讲清混沌工程为什么不是"随机搞破坏"：如何定义稳态、控制爆炸半径、设计可复盘的实验，以及如何把它接进日常研发流程。

为什么需要混沌工程

分布式系统的故障是必然的：网络会抖、磁盘会满、依赖会超时、节点会挂。靠代码评审和单元测试，很难覆盖"多个故障叠加"的真实场景。

混沌工程的做法是：主动注入受控故障，在真实或接近真实的环境里验证系统的容错能力。它的目标不是制造事故，而是在事故真正发生前，把问题暴露出来。

四条基本原则

1. 建立稳态假设：先定义"系统正常"的可观测指标，比如错误率低于 0.1%、P99 延迟低于 300ms。
2. 模拟真实故障：延迟、超时、异常、资源耗尽、网络分区、进程退出，都要贴近生产可能发生的样子。
3. 在生产环境做实验：预发环境往往缺少真实流量和依赖拓扑，结论有限；但必须严格控制爆炸半径。
4. 自动持续运行：一次性演练价值有限，纳入流水线、定期执行才能持续发现退化。

常见故障类型

工具生态

• Chaos Mesh：Kubernetes 原生，CRD 定义实验，支持网络、Pod、IO、压力等。
• LitmusChaos：CNCF 项目，实验库丰富，适合 K8s。
• ChaosBlade：阿里开源，覆盖主机、容器、应用层。
• Toxiproxy：在测试环境模拟网络故障，适合集成测试。
• AWS Fault Injection Simulator / 各云厂商故障注入服务：托管方案。

一个 Chaos Mesh 实验

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: order-to-payment-delay
  namespace: chaos
spec:
  action: delay
  mode: one
  selector:
    namespaces: [orders]
    labelSelectors:
      app: order-service
  delay:
    latency: "500ms"
    jitter: "100ms"
  direction: to
  target:
    mode: all
    selector:
      namespaces: [payments]
      labelSelectors:
        app: payment-service
  duration: "5m"
  scheduler:
    cron: "@every 24h"

这段配置的意思是：每天给订单服务到支付服务的调用注入 500ms 延迟，持续 5 分钟，观察超时与熔断是否符合预期。

实验流程

1. 明确假设：例如"支付服务延迟 500ms 时，订单服务应在 1 秒内触发熔断并返回降级结果，错误率不超过 1%"。
2. 限定范围：选择单个命名空间、少量副本、低峰时段。
3. 准备回滚：随时能停止实验，预案和联系人就位。
4. 注入并观测：盯住错误率、延迟、日志、告警。
5. 记录结论：假设成立还是不成立，暴露了哪些配置问题。
6. 修复并回归：改完配置或代码，再跑一次同样的实验。

爆炸半径控制

这是混沌工程最容易出事的地方。控制手段：

• 按比例注入，不要一次打全部实例（Chaos Mesh 的 mode: one / fixed-percent）。
• 限定命名空间和标签，别误伤核心链路。
• 设置实验时长和自动终止。
• 低峰期执行，并提前通知值班同学。
• 核心支付、登录等链路先做演练审批。
• 准备 kill switch，出问题立刻停止实验。

和 SLO / 告警结合

混沌工程不是孤立活动，最好挂在 SLO 体系上：每次实验都对照 SLO 判断"这点故障是否突破了用户体验底线"。如果注入 200ms 延迟就导致 SLO 违约，说明系统余量不足，需要优化。

告警也要验证：故障注入时，告警是否按预期触发、是否指向正确的根因。很多团队发现，故障来了但告警没响，或者响了一堆噪音——这正是混沌工程的价值。

成熟度分级

不要跳级。先测试环境、再预发、最后生产，每一步都要有回滚能力。

最佳实践

1. 从"最可能发生、影响最大"的故障开始，比如依赖超时和网络抖动。
2. 每次只注入一个变量，便于归因。
3. 假设要可量化，结论要可验证。
4. 把实验配置代码化、版本化，纳入仓库。
5. 演练后必须复盘并修复，否则只是表演。
6. 建立故障库，沉淀"注入方式 + 预期 + 实际"。
7. 新人入职可以做一次故障演练，比看文档有效。

总结

混沌工程的核心不是工具，而是"用实验验证假设"的工程习惯。系统对故障的韧性，只能通过真实注入来证明，不能靠感觉。