混沌工程：ChaosBlade、Chaos Mesh 与可观测性闭环

某团队在生产做第一次「混沌」：kubectl delete pod checkout-xxx。Pod 15 秒内重建，服务恢复。团队欢呼系统高可用。

但 15 秒内 checkout 可用率从 99.95% 降到 99.1%，消耗两周错误预算；告警一条未响——延迟 SLO 的 PromQL 用了 p50 而非 p99。实验证明了自愈，更证明了可观测性盲区。

混沌工程的价值：不是找代码 bug，是找「告警与 SLO 能否发现这类故障」。稳态用 SLO 工程 度量；告警是否触发用 告警体系 验证；全链路排障见 事故复盘剧本。

一、混沌工程的原则

1.1 起源

Netflix Chaos Monkey（2011）随机终止生产实例，验证容错。原则被归纳进 Principles of Chaos Engineering。

1.2 五步循环

1.3 与测试的区别

二、三大开源工具对比

2.1 总览

2.2 ChaosBlade

# 网络延迟（主机）
blade create network delay --time 3000 --interface eth0 --offset 100

# K8s Pod CPU 满载
blade create k8s pod-cpu fullload --namespace checkout --names checkout-xxx --cpu-percent 80

# 销毁实验
blade destroy <UID>

中文文档完善，适合国内团队第一个实验。

2.3 Chaos Mesh

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: delay-checkout
  namespace: chaos-testing
spec:
  action: delay
  mode: one
  selector:
    namespaces: [checkout]
    labelSelectors:
      app: checkout
  delay:
    latency: "200ms"
  duration: "5m"

Workflow 可编排多步实验；Dashboard 可视化。

2.4 LitmusChaos

ChaosHub 提供预置实验模板；与 ArgoCD 集成做 GitOps 混沌。

三、稳态假设与 SLO 判定

3.1 稳态指标示例

• 可用性：\[\text{SLI}_{avail} \geq 99.9\%\]（5m 窗口）
• 延迟：p99 < 200ms
• 吞吐：QPS 在预期区间

3.2 实验假设模板

若对 checkout 单 Pod 注入 200ms 网络延迟 5 分钟，则 p99 延迟 SLO Burn Rate 告警应在 2 分钟内触发，且错误预算消耗 < 1%。

3.3 判定表

四、实验工程设计（四阶段）

4.1 Fault Injection

CPU、内存、网络延迟/丢包、DNS、磁盘 I/O、Pod 删除、AZ 故障。

4.2 Observability

并行观察：SLO Dashboard、告警、Logs trace_id、Traces 采样率是否够。

4.3 Recovery

记录 RTO；是否需人工 kubectl rollout undo。

4.4 Analysis

写入 Reliability Backlog：每条 gap 对应 owner 与 due date。

sequenceDiagram
  participant E as 实验编排
  participant F as 故障注入
  participant S as SLI 采集
  participant A as Alertmanager
  participant O as On-call
  E->>F: 注入延迟
  F->>S: 扰动流量
  S->>A: Burn Rate 计算
  alt 告警触发
    A->>O: Page
  else 漏报
    O->>O: 记录盲区
  end

五、爆炸半径控制

5.1 递进策略

单 Pod → 单 Deployment → 单 AZ → Region（极少）。

5.2 Kill Switch

• ChaosBlade: blade destroy
• Chaos Mesh: kubectl delete networkchaos --all -n chaos-testing
• 脚本: timeout 300

5.3 生产准入

1. staging 同模板通过
2. on-call 值守
3. 变更窗口审批
4. 回滚/停止演练过一遍

六、驱动可观测性改进的案例

6.1 网络延迟 → 告警盲区

注入 200ms → p99 升无告警 → PromQL 用 p50 → 改为 p99 + Burn Rate。

6.2 Kafka broker → Trace 断裂

杀 broker → 降级无完整 trace → Kafka client 未传播 traceparent → 修 OTel 配置。

6.3 DNS 超时 → 日志缺失

gRPC DNS 错误未打日志 → 补 error log + span event。

七、工程坑点

1. 未 staging 验证就上生产——违背实验伦理。
2. 无超时——CPU stress 打满节点。
3. 不监控实验本身——注入是否成功未知。
4. 只做自动化不做 Game Day——组合故障只有人才能发现。
5. 实验未关联 SLO——无法量化用户影响。

八、落地清单

• 稳态 Dashboard 与 SLO 对齐
• 实验库 Git 版本化
• 爆炸半径 policy 文档
• 每季度 Game Day
• 实验结果 → Backlog 闭环

九、关键概念回顾

• 混沌输出 = 可观测性盲区清单
• 稳态必须 可度量（SLO）
• 半径 递进 + Kill Switch

十、常见误解

十一、下一步

治理层收束。下一篇 中国可观测性厂商对比。

附录 A：实验目录模板

参考资料

1. Principles of Chaos Engineering, https://principlesofchaos.org/
2. Netflix Chaos Monkey, https://netflix.github.io/chaosmonkey/
3. Chaos Mesh Documentation, https://chaos-mesh.org/docs/
4. ChaosBlade Documentation, https://chaosblade.io/docs/
5. LitmusChaos Documentation, https://litmuschaos.io/docs/
6. Google SRE Workbook, Alerting on SLOs
7. 本站 SLO 工程
8. 本站 告警体系
9. 本站 事故复盘剧本
10. 本站 Events 与变更关联

上一篇：多租户与安全

下一篇：中国可观测性厂商对比