chaos-engineering

混沌工程

设计实验，找出生产系统的真实弱点，同时避免造成服务中断。大多数“混沌工程”尝试都会跳过稳态测量、不设定中止标准，也不限制影响范围。本技能会严格执行相关规范，确保混沌实验安全且有用。

适用场景

• 规划混沌实验（破坏什么、在哪里、何时进行、如何中止）
• 运行实验前计算影响范围
• 审查现有实验计划的安全性
• 选择混沌工具（Chaos Toolkit / Chaos Mesh / Litmus / Gremlin / AWS FIS）
• 编写混沌实验复盘报告
• 开展 Game Day 演练

不适用场景

• 一般事件响应（使用 incident-response）
• 威胁狩猎 / 红队演练（使用 red-team、threat-detection）
• 性能负载测试（目标不同——混沌工程关注故障模式，而非容量）
• 生产环境调试（混沌工程旨在提前发现弱点，而不是事后排查）

核心原则：没有中止标准的混沌实验就是一次服务中断

混沌工程的 4 项原则（Netflix，2016）：

1. 围绕稳态行为建立假设。 不要问“什么会坏？”，而要问“X 成立；在故障 Y 下还能成立吗？”
2. 模拟真实事件。 注入符合实际情况的故障：终止节点、降低网络速度、丢失缓存、限制依赖项。
3. 在生产环境中运行实验。 预发布环境永远无法呈现相同的故障模式。要从小规模开始。
4. 自动化实验并持续运行。 一次性混沌实验只是新闻稿；持续混沌才是工程实践。

再加上第五项：事先定义中止标准。 没有中止标准的混沌实验，换个名字仍是一次服务中断。

快速开始

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

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

# 2. Calculate blast radius
python "$SKILL/scripts/blast_radius_calculator.py" --traffic-share 0.05 --user-pop 1000000 --duration-min 15

# 3. Generate postmortem after the experiment
python "$SKILL/scripts/experiment_postmortem.py" --plan experiment.json --result-log results.txt

3 个 Python 工具

均仅使用标准库。使用 --help 运行。

experiment_designer.py

根据输入生成结构化实验计划。确保计划包含必需部分（假设、稳态指标、影响范围、中止标准、回滚）。

python scripts/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

计算计划中实验的影响范围。根据流量占比、用户群体和持续时间，计算预计受影响用户数、预计错误预算消耗量和风险评分。

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

GREEN = <1% 错误预算；YELLOW = 1-10%；RED = >10%。

experiment_postmortem.py

根据实验计划和结果生成结构化复盘报告。可发现常见的复盘问题：未记录经验教训、没有后续行动、措辞充满指责。

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

输出包含以下内容的 Markdown：摘要、假设（是否得到证实或被推翻？）、经验教训、意外发现、注明负责人的后续行动，以及下一个实验的链接。

7 种攻击类型（分类）

不同攻击会揭示不同的弱点。完整详情请参阅 references/attack_taxonomy.md。

攻击	测试内容	工具
延迟	超时、重试、断路器	tc、Chaos Mesh NetworkChaos
错误	错误处理、回退路径	Chaos Mesh HTTPChaos、Toxiproxy
资源（CPU、内存、磁盘）	饱和处理、自动扩缩容	Chaos Mesh StressChaos、stress-ng
网络分区	脑裂、共识、故障切换	Chaos Mesh NetworkChaos partition
依赖项故障	优雅降级、回退	服务网格故障注入
时间	时钟偏差、NTP 问题	libfaketime、Chaos Mesh TimeChaos
基础设施（终止实例）	自动恢复、故障切换	AWS FIS、Chaos Monkey

选择与假设相符的攻击。“如果 X 变慢会怎样？”→ 延迟。“如果 X 失去网络连接会怎样？”→ 分区。

工具选择指南

工具	最适合	定价	技术栈
Chaos Toolkit	轻量、与语言无关、使用 JSON 实验	OSS	任意
Chaos Mesh	Kubernetes 原生、CRD 丰富、集群内运行	OSS	Kubernetes
Litmus	Kubernetes、与 Argo 集成、库丰富	OSS + Enterprise	Kubernetes
Gremlin	企业级 SaaS、多云、审计	付费	任意
AWS FIS	AWS 原生、与 IAM 集成，适用于 EC2/ECS/EKS	付费（AWS）	AWS
Custom	特定需求、单云、预算有限	无	任意

决策规则：

• 仅使用 k8s 的技术栈 + OSS → Chaos Mesh 或 Litmus（Litmus 的实验库更大）
• 多云 + OSS → Chaos Toolkit
• 以 AWS 为主 + 需求简单 → AWS FIS
• 企业级 + 审计/合规 → Gremlin

权衡取舍请参见 references/tooling_landscape.md。

工作流

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

1. State a hypothesis: "When [fault], steady-state metric X stays within Y."
2. Identify the steady-state metric — must be measurable BEFORE the experiment.
3. Run blast_radius_calculator.py — confirm GREEN before proceeding.
4. Run experiment_designer.py to produce the plan.
5. Get a peer review of the plan; confirm abort criteria are concrete.
6. Notify the on-call team in #incidents (or whatever channel).
7. Run the experiment with monitoring open.
8. If abort criteria are hit, abort immediately; record what happened.
9. Run experiment_postmortem.py to capture learnings.
10. File follow-up actions; link to next experiment.

工作流 2：Game Day 演练

1. Pick a scenario (e.g., "primary database fails over").
2. Identify all dependent services that should keep working.
3. Build a multi-experiment plan covering each layer.
4. Schedule with stakeholders; on-call coverage required.
5. Run with a facilitator who manages the scenario.
6. Capture observations in a shared doc as they happen.
7. Single combined postmortem covering all observations.
8. Track follow-up actions in a board with owners.

工作流 3：持续混沌工程（从 Game Day 到每日演练）

1. Start: weekly Game Day in staging.
2. Move to: weekly Game Day in production with limited blast radius.
3. Mature to: continuous chaos via scheduled experiments (Litmus chaos schedule, Gremlin scenarios).
4. Wire to deployment: every prod deploy triggers a baseline chaos sweep.
5. Track: experiments per week, weaknesses discovered, MTTR trend.

与其他技能的组合

此技能明确与此库中的另外两项技能组合使用：

技能	组合方式
feature-flags-architect	在该技能中定义的 Kill Switch 是此处的中止触发条件
kubernetes-operator	Operator 是常见的混沌测试对象（在故障条件下测试 reconcile）
incident-response	升级为事件的混沌实验将成为事件

反模式

• 没有假设 — “我们来搞点破坏”是蓄意破坏，不是工程实践
• 没有稳态指标 — 没有基线，就无法判断 X 是否发生故障
• 没有限定爆炸半径 — 不设限的全生产环境实验 = 服务中断
• 没有中止标准 — 参见上文；这是强制要求
• 没有值班覆盖 — 没有监控的混沌测试，就是无人监控生产环境
• 只在预发布环境进行混沌测试 — 预发布环境永远不会出现生产环境的故障模式
• 在开发环境进行混沌测试 — 毫无用处；开发环境和生产环境的故障模式不同
• 一次性混沌测试 — 单次实验只是新闻稿；要从中学习就必须反复进行
• 充满指责的事后复盘 — 记录原因，而非追究责任；否则团队就会停止混沌测试

参考资料

• 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% 的混沌实验都有书面假设、中止标准和爆炸半径计算
• 任一实验的爆炸半径始终不超过错误预算的 10%
• 混沌实验的平均间隔 <14 天（持续进行，而非一次性）
• 每项实验至少产生 1 项后续行动，并最终完成发布
• 过去 90 天内，没有混沌实验升级为影响客户的事件