findscripter 何时使用
在生产系统中主动注入故障、提前暴露真实弱点而又不演变成事故时使用本技能。多数「混沌工程」尝试失败在于：跳过稳态测量、没有中止条件、没有爆炸半径上限。本技能强制这三项纪律。
适用：
- 设计混沌实验（破坏什么、在哪、何时、如何中止）
- 实验前计算爆炸半径
- 评审已有实验计划的安全性
- 选型混沌工具（Chaos Toolkit / Chaos Mesh / Litmus / Gremlin / AWS FIS）
- 撰写混沌实验复盘
- 组织 Game Day 演练
不该用（负边界）：
- 通用事故响应 → 用 incident-response 类技能
- 威胁狩猎 / 红队攻防 → 用安全类技能
- 性能 / 容量压测 → 目标不同，混沌关注故障模式而非容量
- 生产事后排障 → 混沌是提前发现弱点，不是事后救火
核心原则：没有中止条件的混沌就是一次事故。 在 Netflix 混沌工程四原则（2016）之上，本技能强制加上第五条——预先定义中止条件（abort criteria）。
混沌工程四原则：1) 围绕稳态行为建立假设（不是「什么会坏」，而是「X 成立；在故障 Y 下还成立吗」）；2) 注入贴近真实的事件（杀节点、降网速、丢缓存、限流依赖）；3) 在生产环境运行（预发永远没有相同的故障模式，从小开始）；4) 自动化持续运行（一次性混沌只是新闻稿，持续混沌才是工程）。
步骤
工作流一：设计并运行单次实验
- 陈述假设：「当发生 [故障] 时，稳态指标 X 保持在 Y 内」。
- 确定稳态指标——必须在实验之前可测量。
- 跑 blast_radius_calculator.py，确认风险评分为 GREEN 才继续。
- 跑 experiment_designer.py 产出计划。
- 请同行评审计划，确认中止条件是具体可判定的。
- 在值班 / 事故频道通知 on-call 团队。
- 打开监控大盘后运行实验。
- 一旦触发中止条件，立即中止并记录现象。
- 跑 experiment_postmortem.py 沉淀经验。
- 登记后续行动项，链接到下一个实验。
工作流二：Game Day 演练
选定场景（如「主库故障切换」）→ 梳理所有应继续工作的依赖服务 → 构建覆盖各层的多实验计划 → 与干系人排期且必须有 on-call 覆盖 → 由主持人管理场景推进 → 在共享文档实时记录观察 → 单份合并复盘 → 在看板按责任人跟踪行动项。
工作流三：持续混沌（从 Game Day 到日常）
预发周度 Game Day → 生产限爆炸半径周度 Game Day → 调度化持续混沌（Litmus 调度、Gremlin 场景）→ 接入发布流水线（每次生产发布触发基线混沌扫描）→ 跟踪指标：每周实验数、发现的弱点数、MTTR 趋势。
指令
三个工具均为纯标准库 Python，均支持 --help。
设置路径：
SKILL=engineering/chaos-engineering/skills/chaos-engineering
experiment_designer.py——从输入生成结构化实验计划，强制要求假设、稳态指标、爆炸半径、中止条件、回滚等小节：
python "$SKILL/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"
blast_radius_calculator.py——给定流量占比、用户规模、时长，计算受影响用户、错误预算消耗与风险评分：
python "$SKILL/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 "$SKILL/scripts/experiment_postmortem.py" --plan experiment.json --result-log results.txt
斜杠命令：/chaos-experiment——交互式实验设计向导，串起以上三个工具。
资产模板：assets/experiment_template.md（计划模板）、assets/postmortem_template.md（复盘模板）。
示例
7 种攻击类型（taxonomy）——不同攻击暴露不同弱点，按假设选攻击：
| 攻击 | 测试什么 | 工具 |
|---|---|---|
| 延迟 Latency | 超时、重试、熔断器 | tc、Chaos Mesh NetworkChaos |
| 错误 Error | 错误处理、降级路径 | Chaos Mesh HTTPChaos、Toxiproxy |
| 资源 Resource（CPU/内存/磁盘） | 饱和处理、自动扩容 | Chaos Mesh StressChaos、stress-ng |
| 网络分区 Partition | 脑裂、共识、故障切换 | Chaos Mesh NetworkChaos partition |
| 依赖失败 Dependency | 优雅降级、回退 | 服务网格故障注入 |
| 时间 Time | 时钟偏移、NTP 问题 | libfaketime、Chaos Mesh TimeChaos |
| 基础设施 Infrastructure（杀实例） | 自愈、故障切换 | AWS FIS、Chaos Monkey |
选攻击的判断：「X 慢了会怎样？」→ 延迟；「X 断网会怎样？」→ 分区。
工具选型：
- k8s 单栈 + 开源 → Chaos Mesh 或 Litmus（Litmus 实验库更大）
- 多云 + 开源 → Chaos Toolkit
- 重度 AWS + 需求简单 → AWS FIS
- 企业级 + 审计合规 → Gremlin（付费 SaaS）
注意事项
可验证成功标准：
- 100% 的混沌实验都有书面假设、中止条件、爆炸半径计算
- 任一单次实验的爆炸半径不超过错误预算的 10%
- 实验间隔均值 <14 天（持续而非一次性）
- 每个实验至少产出 1 个被落地交付的后续行动项
- 滚动 90 天内无混沌实验升级为影响客户的事故
反模式（务必规避）：
- 无假设——「随便搞坏点东西」是破坏不是工程
- 无稳态指标——没有基线就无法判断 X 是否坏了
- 无爆炸半径上限——无限制的全量生产实验 = 事故
- 无中止条件——强制项，缺失即事故
- 无 on-call 覆盖——无监控的混沌等于无监控的生产
- 只在预发 / 只在 dev 跑——故障模式与生产不同，无意义
- 一次性混沌——单次实验只是新闻稿，学习需要复现
- 含追责的复盘——记录原因而非追责，否则团队会停止做混沌
互见
本技能可与以下技能组合：
- 特性开关 / feature-flags-architect：那里定义的 kill switch 正是这里的中止触发器
- kubernetes-operator：Operator 是常见的混沌目标（验证故障下的 reconcile）
- 事故响应 / incident-response：升级了的混沌实验会转为事故
参考资料（源技能附带）：references/chaos_principles.md（四原则与起步时机）、references/experiment_design.md（假设结构、稳态指标、中止条件）、references/attack_taxonomy.md（7 种攻击详例）、references/tooling_landscape.md（各工具权衡）。
采编自 alirezarezvani/claude-skills（MIT 许可）。