混沌工程实验设计

解决什么具体问题

多数团队尝试混沌工程时，容易把它做成一次“生产事故预演”。常见问题是：实验前没有稳定的稳态指标（steady-state），实验中不定义明确的中止条件（abort criteria），也不计算爆炸半径（blast radius）。结果就是故障注入变成了真实故障。

这个技能的价值在于把混沌实验拉回工程纪律：没有中止条件的混沌实验，本质上就是一次故障。它要求每次实验都围绕稳态假设设计，先定义“什么情况下必须立刻停止”，再决定注入什么故障、影响多大范围。

技能如何工作

技能的工作流可以拆成四个关键步骤：

• 基于稳态构建假设：不是问“什么会坏”，而是问“系统在稳态下满足 X，注入故障 Y 后 X 是否仍然成立”。这是 Netflix 提出的四条原则的核心，也是有效实验的起点。

• 先算爆炸半径再动手：通过 blast_radius_calculator.py 输入流量占比、用户规模和持续时间，得到预期受影响用户数、消耗的错误预算（error budget）和风险等级（GREEN / YELLOW / RED），再决定是继续、缩减还是取消。

• 匹配故障类型与工具：技能内置了七种攻击类型的分类体系（latency、error、resource、partition、dependency、time、infrastructure），并给出每种类型的适用工具建议，例如 Chaos Mesh 的 NetworkChaos 用于网络分区、TimeChaos 用于时钟偏移。工具选型上也覆盖了 Chaos Toolkit、Chaos Mesh、Litmus、Gremlin 和 AWS FIS 的适用场景。

• 结构化复盘并沉淀：experiment_postmortem.py 会把实验计划和结果整理成标准复盘文档，强制记录假设是否成立、什么出乎意料、后续行动项和负责人。避免复盘变成“没有结论的会议”。

适用边界与注意点

这个技能不适合用来做通用的应急响应、威胁狩猎或性能压测。这些场景的目标和混沌工程不同——混沌工程关注的是故障模式下的系统行为，而不是容量上限或事后排查。

几个必须避免的反模式：

• 只在 staging 或 dev 跑混沌：这些环境没有生产环境的真实故障模式，测了也不等于生产安全。
• 没有 on-call 覆盖就动手：没有监控和人在场的混沌实验等于在无人看管的生产环境里搞破坏。
• 一次性实验：跑一次就收工的混沌工程只是发一篇新闻稿，真正有价值的是周期性、持续化的实验节奏。