目标
代码库里每个超时与熔断器，都是对“某种可能从未发生过的故障下的行为”的声明。按计划在类生产环境注入那种故障，把声明变成已验证的事实——或者揭穿它。从未触发过的机制是信心与现实分歧最大的地方，定期重注入则能抓住悄悄腐烂的韧性。
步骤要点
- 盘点韧性机制：列出每个超时、重试策略、熔断器、舱壁与兜底，标明位置与所应对的故障。
- 一机制一故障实验：为每个机制设计应触发它的注入——超过超时的延迟、超过熔断阈值的错误率、依赖全黑触发兜底。
- 类生产条件下注入：在真实依赖与真实负载形态的环境运行，从指标而不只是日志观察机制是否触发。
- 验证用户可见行为：注入期间核对用户体验——降级但可用、正确的错误呈现、无静默数据丢失。
- 定期重验并对衰减告警：按计划重复实验，机制对故障不再响应时给 owner 开工单。
排错提示
配置了两年的超时注入后根本没生效是最常见的发现，机制要接在被测的真实调用路径上才作数；重构后熔断悄悄失效是韧性腐烂的常态，定期重注入就像备份要演练恢复；只看日志说熔断开了不算数，指标曲线与兜底流量占比才是证据。
适用边界
故障注入在共享环境有外溢风险，实验要配自动停止条件与爆炸半径声明；生产直接注入需要更严格的审批与值守，预生产拓扑等价是前提。
代码示例
mechanism inventory -> experiment:
payments timeout 800ms
fault: inject 2s latency on payments calls
expect: p99 <= 900ms, timeout errors < 1%
observed: p99 3.1s FAIL (timeout not wired!)
search breaker (50% err threshold)
fault: inject 60% errors for 60s
expect: breaker opens ~10s, fallback served
observed: opened at 11s, fallbacks 100% PASS
catalog fallback (static cache)
fault: full blackout 5 min
expect: static catalog served, no 5xx
observed: static served, 0 errors PASS
schedule: monthly; decay alert on missed fire