Menu
通过受控故障注入验证系统的容错能力。在验证节点宕机、网络分区、磁盘慢盘/坏盘、时钟漂移等故障路径时使用。当系统声称具备容错/高可用能力但缺乏故障路径证据时、上线前需要验证恢复流程时，或需要建立常态化混沌工程实践时使用。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
指导稳定的 RPC、存储协议和接口设计。在设计节点间 RPC、存储协议语义、模块边界或任何公共接口时使用。在定义 gRPC service、对象存储或文件系统语义、节点间的类型契约，或确立组件边界时使用。
自动化 CI/CD 流水线设置。在设置或修改构建和部署流水线时使用。当需要自动化质量门禁、在 CI 中配置测试运行器，或建立部署策略时使用。当需要处理 CI 上不稳定（flaky）的测试时使用。
进行多维度代码审查。在合并任何变更之前使用。在审查由你自己、另一个智能体或人类编写的代码时使用。当需要在代码进入主分支之前评估其跨多个维度的质量时使用。当需要评估变更的正确性、可读性、架构与性能，或审查 PR/diff 时使用。
为清晰性而简化代码。在重构代码以提高可读性而不改变行为时使用。当代码可以正常工作但比应有的更难阅读、维护或扩展时使用。在审查已积累不必要复杂性的代码时使用。当组件过度设计、过于炫技而难以维护时使用。当需要清理越来越难读懂的代码时使用。
验证系统的一致性与持久性承诺。在设计或修改复制协议、写路径、崩溃恢复逻辑时使用。当需要证明已确认的写入不丢失、副本间不发散、崩溃后能恢复到一致状态，或评审 fsync/校验和/事务语义时使用。
优化智能体上下文设置。在开始新会话、智能体输出质量下降、在不同任务之间切换，或需要为项目配置规则文件和上下文时使用。
| name | failure-injection-testing |
| description | 通过受控故障注入验证系统的容错能力。在验证节点宕机、网络分区、磁盘慢盘/坏盘、时钟漂移等故障路径时使用。当系统声称具备容错/高可用能力但缺乏故障路径证据时、上线前需要验证恢复流程时，或需要建立常态化混沌工程实践时使用。 |
分布式系统的正确性问题集中在故障路径上，而故障路径在 happy path 测试中永远不会被走到。故障注入是主动、受控地制造故障，用证据回答"系统在最坏情况下是否仍然守住承诺"——而不是等生产事故来回答。
核心纪律：一次只注入一种故障，先定义不变量再注入，爆炸半径永远受控。
不适用于：单元级逻辑验证（用 test-driven-development）、性能瓶颈定位（用 performance-optimization）、已知故障的根因排查（用 debugging-and-error-recovery）。
把"高可用"翻译成可证伪的不变量，每条都必须是可机器检查的断言：
- 已 ack 的写入在任意单节点故障后不丢失
- 网络分区期间，多数派侧继续服务，少数派侧拒绝写入（不脑裂）
- 单块慢盘不使集群 p99 超过基线的 2 倍
- 任意时刻 kill 进程，重启后能恢复到一致状态
没有不变量的故障注入只是制造混乱，不是测试。
注入前先测量正常状态下的关键指标（p99/p999 延迟、吞吐、副本滞后、错误率）。没有基线就无法判断注入后的偏移是故障影响还是注入工具本身的开销。
按系统架构枚举故障域，从最常见的开始：
| 故障类型 | 注入手段 | 典型验证目标 |
|---|---|---|
| 进程/节点宕机 | kill -9、停虚拟机 | 副本接管、重试路径、数据不丢 |
| 网络分区 | tc/iptables、Toxiproxy | 不脑裂、分区恢复后收敛 |
| 网络延迟/丢包 | tc qdisc add ... netem delay/loss | 超时与重试不失控、无重试风暴 |
| 慢盘 | dm-delay、限速 cgroup | 慢盘检测与隔离生效 |
| 坏盘/数据损坏 | dm-flakey、注入校验和错误 | 端到端校验和能发现静默损坏 |
| 磁盘写"说谎" | fault injection framework（fail_make_request） | fsync 语义被正确依赖 |
| 时钟漂移/跳变 | faketime、测试时钟 | lease 不重叠、单调钟假设成立 |
| 资源耗尽 | 打满磁盘、限制内存/句柄 | 优雅降级而非雪崩 |
kill point 的选择要有依据：在写路径的关键阶段（收到请求、写 WAL、刷盘、应用状态机、回复客户端）之间逐个注入，而不是随机杀。
| 借口 | 现实 |
|---|---|
| "我们有三副本，宕一台没事" | 三副本只证明你付了三份钱，不证明接管路径工作。未测试的故障转移等于没有 |
| "单元测试和集成测试都过了" | happy path 全绿对故障路径零覆盖。正确性问题恰恰住在故障路径上 |
| "随机关一下节点就算混沌工程了" | 没有不变量断言的随机破坏产生的是噪音，不是证据 |
| "测试环境测过了，生产肯定一样" | 测试集群通过了是准入证，不是终点——但生产注入必须审批、限速、有回退 |
| "这次先上线，故障测试后面补" | 故障路径的 bug 只在事故时暴露，那时的成本是数据丢失或停机 |
| "注入工具本身的干扰不用管" | netem/限速会改变被测系统的行为特征。不控制注入开销，结论无效 |
sleep 等待收敛而非轮询状态references/testing-patterns.md 的故障注入章节一致