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

某团队在生产环境做了第一次混沌实验：kubectl delete pod checkout-xxx。Pod 被删除后，一个新的 Pod 在 15 秒内被 K8s 调度器重建——服务自动恢复。团队欢呼：我们的系统是高可用的！

但没人注意到：在这 15 秒内，checkout 服务的可用率从 99.95% 降到了 99.1%，消耗了整整两周的错误预算。而告警一条都没响——因为延迟 SLO 的 PromQL 写得有问题（用的是 p50 而不是 p99）。这个实验确实证明了系统”自愈了”，但它真正暴露的问题是可观测性盲区——你的告警体系完全没意识到一个 SLO 级别的故障正在发生。

这就是混沌工程的真正价值：不是找代码 bug，是找可观测性的盲区。

一、混沌工程五步法

1. 定义稳态。用 Metrics 描述”系统正常”——例如”p99 latency < 200ms AND success rate > 99.9% AND QPS 在 800-1200 之间”。这是实验的对照组。
2. 提出假设。“如果杀掉 checkout 服务的一个 Pod，K8s 应该在 30 秒内重建，期间 p99 latency 不应该超过 300ms，且告警应该在 2 分钟内触发。”
3. 设计实验。选择故障类型（Pod Kill / 网络延迟 / CPU Stress / DNS 不可用 / AZ 宕机）、爆炸半径（单 Pod / 单 Deployment / 单 AZ）、恢复条件。
4. 执行 + 观测。注入故障 → 观察 SLO Dashboard → 确认告警是否触发 → 确认自动恢复是否生效 → 测量恢复时间。
5. 分析结果。实验预期 vs 实际。如果告警没触发——发现了一个可观测性盲区。如果恢复比预期慢——发现了一个架构弱点。

二、三大开源工具

ChaosBlade（阿里开源）：CLI 简单直接，blade create network delay --time 3000 --interface eth0 一条命令注入网络延迟。支持 JVM/HTTP/DNS/Docker/K8s 等多种故障类型。中文文档好。适合国内团队快速上手。

Chaos Mesh（PingCAP 开源，CNCF 孵化）：K8s 原生，故障类型定义为 CRD。支持 PodKill、NetworkChaos、IOChaos、StressChaos、DNSChaos、TimeChaos。Workflow 功能支持编排”先注入 CPU 压力 → 等 5 分钟 → 再注入网络延迟”的多步组合实验。Dashboard + 可视化。适合 K8s 环境下的系统化混沌实验。

LitmusChaos（CNCF 孵化）：Hub 模式——预定义的实验模板（ChaosHub），类似于”混沌实验的 Helm Chart”。GitOps 集成——实验定义存储在 Git 中，由 ArgoCD/Flux 触发。商业版 Harness CE 提供企业级支持。适合需要标准化实验流程的企业。

三、爆炸半径控制

爆炸半径不是”能不做就不做”的免责声明——它是在做的前提下如何控制风险的工程策略。

半径递进：单 Pod → 单 Deployment → 单 AZ → 整集群。第一步在 staging 做，第二步在 prod 用最小半径（单 Pod），第三步逐步放大。

紧急停止（Kill Switch）：ChaosBlade 的 blade destroy UID、Chaos Mesh 的 kubectl delete chaos-experiment。在实验脚本中显式设置超时（timeout 300）——5 分钟后自动停止，不管实验完成与否。

生产准入条件：实验已经过 staging 验证 + 有即时 rollback/stop 手段 + 有 on-call 人员现场值守 + 有监控 Dashboard 实时观察 SLO 变化。

四、混沌实验驱动可观测性改进

三个经典案例：

网络延迟暴露告警盲区。注入 200ms 网络延迟 → p99 飙升但无告警 → 发现 latency SLO 的 PromQL 写了 p50 而不是 p99 → 修复告警规则。

Kafka broker 宕机暴露 Trace 断裂。杀掉一个 Kafka broker → 服务降级但 Trace 链路断裂 → 发现 Kafka client 没有传播 trace context → 修复 producer/consumer 的 propagation 配置。

DNS 超时暴露日志缺失。注入 DNS 超时 → 服务挂了但日志里没有任何关于 DNS 的信息 → 发现 gRPC 的 DNS resolver 错误被默认吞掉了 → 增加 error-level 日志 + Span event。

每次混沌实验的输出不应该是”通过了 / 没通过”这么简单——应该是”增加了 N 条可观测性改进项到 Reliability Backlog 中”。

五、工程坑点

生产环境直接跑第一个混沌实验。没经过 staging 验证——这是实验伦理问题，不是技术问题。

实验脚本没有超时机制。CPU stress 一直跑到手动 kill——节点实际上废了——造成了真实事故。

只做自动化混沌测试不做 Game Day。自动化测试跑在 CI 中只能覆盖”已知的故障模式”。Game Day（人工参与的全链路演练）才能暴露”没有人想到过的故障组合”。

六、关键概念回顾

• 混沌工程五步法：定义稳态 → 提出假设 → 设计实验 → 控制半径执行 → 分析结果。
• 核心价值：验证可观测性能不能发现故障——不是证明系统可靠。
• 爆炸半径递进：单 Pod → 单 Deployment → 单 AZ → 整集群。
• 紧急停止：超时机制 + Kill Switch。任何混沌实验都必须有自动和手动的紧急停止手段。

七、下一步

混沌工程是治理层的最后一篇。从下一篇开始，我们进入系列的最后一部分——中国落地与决策。下一篇 中国可观测性厂商对比。

上一篇：多租户与安全：数据隔离、标签治理、PII 清洗

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

参考资料

1. Netflix, Chaos Monkey, https://netflix.github.io/chaosmonkey/
2. Chaos Mesh, Documentation, https://chaos-mesh.org/docs/
3. ChaosBlade, Documentation, https://chaosblade.io/docs/
4. LitmusChaos, Documentation, https://litmuschaos.io/docs/