混沌工程

chaos-engineering
分类编程
作者Alireza Rezvani
许可MIT
评分4.80/5
使用11.9K

混沌工程 (Chaos Engineering)

设计能够揭示生产系统真实弱点且不会演变成大规模停机的实验。大多数“混沌工程”尝试往往忽略了稳态测量，未定义中止标准，且缺乏爆炸半径限制。本技能旨在强制执行一套使混沌实验安全且有效的规范。

适用场景

  • 规划混沌实验（破坏什么、在哪里、何时破坏、如何中止）
  • 在运行实验前计算爆炸半径
  • 审查现有实验计划的安全性
  • 选择混沌工具（Chaos Toolkit / Chaos Mesh / Litmus / Gremlin / AWS FIS）
  • 编写混沌实验的事后分析报告 (Postmortem)
  • 执行游戏日 (Game Day) 演习

不适用场景

  • 通用的事故响应（请使用 incident-response）
  • 威胁猎寻 / 红队测试（请使用 red-team、threat-detection）
  • 性能压力测试（目标不同——混沌工程关注的是故障模式而非容量）
  • 生产环境调试（混沌工程旨在预先发现弱点，而非事后排查）

核心原则：没有中止标准的混沌就是一次停机

混沌工程的四大原则 (Netflix, 2016)：

1. 围绕稳态行为建立假设。 不是问“什么会坏？”，而是问“X 状态目前成立；在故障 Y 发生时，它是否依然成立？”
2. 模拟真实世界的事件。 注入真实的故障：杀死节点、网络延迟、缓存丢失、依赖项限流。
3. 在生产环境中运行实验。 测试环境永远无法完全模拟生产环境的故障模式。从小规模开始。
4. 将实验自动化以持续运行。 一次性的混沌实验只是公关稿；持续的混沌实验才是工程。

补充第五点：预先定义中止标准。 没有中止标准的混沌实验，本质上就是一次换了名字的停机事故。

快速上手

bash
SKILL=engineering/chaos-engineering/skills/chaos-engineering

1. 设计实验

python "$SKILL/scripts/experiment_designer.py" --target "checkout-svc" --hypothesis "p99 latency stays <500ms" --attack latency --duration-min 15

2. 计算爆炸半径

python "$SKILL/scripts/blast_radius_calculator.py" --traffic-share 0.05 --user-pop 1000000 --duration-min 15

3. 实验后生成事后分析报告

python "$SKILL/scripts/experiment_postmortem.py" --plan experiment.json --result-log results.txt

3 个 Python 工具

全部仅使用标准库。运行 --help 查看详情。

experiment_designer.py

根据输入生成结构化的实验计划。强制要求包含必要章节（假设、稳态指标、爆炸半径、中止标准、回滚方案）。

bash
python scripts/
bash
experiment_designer.py \
  --target "checkout-svc" \
  --hypothesis "p99 latency stays <500ms when payment-svc is slow" \
  --attack latency \
  --magnitude "+200ms" \
  --duration-min 15 \
  --blast-radius "5% of US traffic" \
  --abort-if "p99 > 1000ms OR error_rate > baseline + 1pp"

输出一份包含以下内容的 Markdown 计划：假设、稳态、攻击方式、幅度、持续时间、爆炸半径、中止标准、回滚流程、监控仪表盘以及学习问题。

blast_radius_calculator.py

计算计划实验的爆炸半径。根据流量份额 + 用户群体 + 持续时间，计算预计受影响用户数、预计错误预算消耗量以及风险评分。

bash
python scripts/blast_radius_calculator.py \
  --traffic-share 0.05 \
  --user-pop 1000000 \
  --duration-min 15 \
  --baseline-availability 0.999 \
  --expected-impact-availability 0.95

输出内容：

  • 预计受影响用户数

  • 消耗的错误预算（以错误预算分钟数计）

  • 风险评分：绿色 (GREEN) / 黄色 (YELLOW) / 红色 (RED)

  • 建议：继续 (PROCEED) / 缩减 (REDUCE) / 中止 (ABORT)

绿色 = 错误预算 <1%；黄色 = 1-10%；红色 = >10%。

experiment_postmortem.py

根据实验计划 + 结果生成结构化的事后分析报告。旨在解决常见的事后分析失败模式：未记录学习心得、无后续行动、语言带有指责色彩。

bash
python scripts/experiment_postmortem.py --plan experiment.json --result-log results.txt

输出包含以下内容的 Markdown：摘要、假设（是否被证实/反驳？）、学习心得、意外发现、带有责任人的后续行动，以及指向下一次实验的链接。

7 种攻击类型（分类法）

不同的攻击方式揭示不同的弱点。详见 references/attack_taxonomy.md。

| 攻击类型 | 测试目标 | 工具 |
|---|---|---|
| 延迟 (Latency) | 超时、重试、熔断器 | tc, Chaos Mesh NetworkChaos |
| 错误 (Error) | 错误处理、回退路径 | Chaos Mesh HTTPChaos, Toxiproxy |
| 资源 (Resource) (CPU, 内存, 磁盘) | 饱和度处理、自动扩缩容 | Chaos Mesh StressChaos, stress-ng |
| 网络分区 (Network partition) | 脑裂、共识、故障转移 | Chaos Mesh NetworkChaos partition |
| 依赖故障 (Dependency failure) | 优雅降级、回退 | 服务网格故障注入 |
| 时间 (Time) | 时钟偏移、NTP 问题 | libfaketime, Chaos Mesh TimeChaos |
| 基础设施 (Infrastructure) (杀死实例) | 自动恢复、故障转移 | AWS FIS, Chaos Monkey |

选择与假设相匹配的攻击方式。“如果 X 变慢会怎样？” $\rightarrow$ 延迟。“如果 X 失去网络会怎样？” $\rightarrow$ 分区。

工具选择指南

| 工具 | 最适用场景 | 价格 | 技术栈 |
|---|---|---|---|
| Chaos Toolkit | 轻量级、语言无关、JSON 实验 | 开源 | 任意 |
| Chaos Mesh | Kubernetes 原生、丰富的 CRD、集群内运行 | 开源 | Kubernetes |
| Litmus | Kubernetes, Argo 集成, 庞大的库 | 开源 + 企业版 | Kubernetes |
| Gremlin | 企业级 SaaS, 多云, 审计 | 付费 | 任意 |
| AWS FIS | AWS 原生, IAM 集成, EC2/ECS/EKS | 付费 (AWS) | AWS |
| 自定义 (Custom) | 小众需求, 单云, 低预算 | 无 | 任意 |

决策规则：

  • 仅 k8s 栈 + 开源 $\rightarrow$ Chaos Mesh 或 Litmus（Litmus 的实验库更丰富）

  • 多云 + 开源 $\rightarrow$ Chaos Toolkit

  • 深度依赖 AWS + 简单需求 $\rightarrow$ AWS FIS

  • 企业级 + 审计/合规 $\rightarrow$ Gremlin

权衡分析详见 references/tooling_landscape.md。

工作流

工作流 1：设计并运行单个实验

code
1. 陈述假设：“当 [故障] 发生时，稳态指标 X 仍...
tays 处于 Y 范围内。" 2. 确定稳态指标 —— 必须在实验开始前可衡量。 3. 运行 blast_radius_calculator.py —— 确认显示为 GREEN 后再继续。 4. 运行 experiment_designer.py 生成方案。 5. 进行方案同行评审；确认中止标准具体明确。 6. 在 #incidents（或相关频道）通知值班团队。 7. 在开启监控的情况下运行实验。 8. 如果触发中止标准，立即中止并记录情况。 9. 运行 experiment_postmortem.py 总结经验。 10. 提交后续行动项；链接至下一次实验。
code
### 工作流 2：Game Day 演习
1. 选择场景（例如：“主数据库故障转移”）。 2. 识别所有应保持运行的依赖服务。 3. 构建覆盖每个层级的多实验计划。 4. 与利益相关者预约时间；必须有值班人员覆盖。 5. 由一名管理场景的引导者主持运行。 6. 在共享文档中实时记录观察结果。 7. 编写一份涵盖所有观察结果的统一复盘报告。 8. 在看板中跟踪后续行动项并指定负责人。
code
### 工作流 3：持续混沌（从 Game Day $\rightarrow$ 日常化）
1. 起步：在 Staging 环境进行每周 Game Day。 2. 迁移：在生产环境进行每周 Game Day，但限制爆炸半径。 3. 成熟：通过定时实验实现持续混沌（如 Litmus 混沌调度、Gremlin 场景）。 4. 关联部署：每次生产部署触发一次基准混沌扫描。 5. 跟踪：每周实验次数、发现的弱点、MTTR 趋势。 ``

与其他技能的组合

本技能与本库中的另外两项技能明确组合：

| 技能 | 组合方式 |
|---|---|
| feature-flags-architect | 其中定义的 Kill switches 是此处的中止触发器 |
| kubernetes-operator | Operator 是常见的混沌目标（测试故障下的调谐能力） |
| incident-response | 升级为事故的混沌实验将转入事故响应流程 |

反模式

  • 无假设 —— “随便搞坏点东西”是破坏而非工程
  • 无稳态指标 —— 没有基准线，你无法判断 X 是否损坏
  • 无爆炸半径限制 —— 无限制的全量生产实验 = 停机事故
  • 无中止标准 —— 见上文；这是强制要求的
  • 无值班覆盖 —— 没有监控的混沌就是对生产环境的盲目操作
  • 仅在 Staging 运行 —— Staging 永远无法完全模拟生产环境的故障模式
  • 在 Dev 环境运行 —— 毫无意义；Dev 的故障模式与生产环境不同
  • 一次性混沌 —— 单次实验像是一次公关稿；学习需要重复进行
  • 带有责备色彩的复盘 —— 记录原因而非责备，否则团队会停止运行混沌实验

参考资料

  • references/chaos_principles.md —— 4 大原则、历史、启动时机
  • references/experiment_design.md —— 假设结构、稳态指标、中止标准
  • references/attack_taxonomy.md —— 7 种攻击类型及其示例和工具
  • references/tooling_landscape.md —— Chaos Toolkit / Mesh / Litmus / Gremlin / FIS / DIY

斜杠命令

/chaos-experiment —— 交互式实验设计向导，可运行所有 3 个工具。

资产模板

  • assets/experiment_template.md —— 方案填写模板
  • assets/postmortem_template.md` —— 结构化复盘模板

可验证的成功标准

使用本技能的团队应实现：

  • 100% 的混沌实验拥有书面假设、中止标准和爆炸半径计算
  • 任何单次实验的爆炸半径不超过错误预算 (Error Budget) 的 10%
  • 混沌实验的平均间隔时间 < 14 天（持续进行，而非一次性）
  • 每项实验
  • 产生 $\ge 1$ 项已交付的后续行动
  • 在过去 90 天内，没有混沌实验升级为影响客户的事故