故障演练的常态化：从年度大戏到每周小考

故障防治系列新篇。前面聊了舱壁隔离、依赖度量——都是「建设防线」，这篇聊「验证防线」：故障演练。大多数团队对演练的认知停在「年度容灾大演习」——声势浩大、准备三月、演完散场。真正有效的演练是反过来的：小、频、常态化。

为什么年度大戏式演练失效

1. 剧本化：准备充分到每个人都知道自己该干嘛——真实故障恰恰是没人知道该干嘛
2. 样本量太小：一年一两次演练，覆盖不了故障模式的零头
3. 心理状态失真：演练时知道是假的，决策从容；真实故障的恐慌和压力才是执行的真正敌人（预案写得再好，慌了就忘）

常态化的形态：混沌工程的小步走

核心思想借自混沌工程：在受控条件下主动注入故障，验证系统和服务人员的真实响应。常态化的节奏设计：

• 每周一次微演练（30 分钟）：注入一个小故障（杀一个实例、断一个依赖、延迟注入），值班轮值响应。不预告——这是微演练的灵魂
• 每月一次中演练（2 小时）：复合场景（依赖故障+发布中），跨团队协作响应
• 每季一次专项（半天）：演练新预案（配合预案库的时效刷新）+ 复盘演练本身

从哪里开始：爆炸半径控制

常态化的头号顾虑是「演练变事故」。控制手段：

1. 爆炸半径分级：新手期只演练「可自愈目标」——杀实例（调度器自动拉起）、清缓存（会回源重建）。这些操作的副作用天然有界
2. 一键熔断：演练环境准备「停止开关」——演练失控立即终止注入，值班手册第一条就是它
3. 非高峰窗口：微演练固定在业务低峰（不是没人用的时候，是错了影响很小的时候——注意这个区别）
4. 演练目标白名单：核心支付链路这类区域，初期不进演练池，成熟后再纳入

演练的产出：两类资产

每次演练的复盘产出两样东西：

1. 系统改进项：暴露出的架构问题（实例被杀后 40 秒才有流量切走——熔断阈值要调）——进整改跟踪流程
2. 预案修订：预案写的步骤实际走不通的（第三步的命令报错）——当场修订预案库

度量的三个数

• 演练覆盖率：核心故障模式中被演练过的比例（目标：季度 30%+）
• 响应达标率：演练中止血时间/通知链路达标的比例
• 改进转化率：演练发现的改进项按期完成的比例（低于 50% 说明演练在空转——发现的问题没人修，下次演练还是它）

人的问题：让演练不被讨厌

演练非常容易招人烦（谁愿意每周被突袭一次）。三个软化设计：

1. 不评分：演练结果不进绩效——一旦评分，大家开始「为演而演」，真实性归零
2. 值班轮值制：全员轮流当「被演练者」，公平分摊
3. 把功劳给发现：演练暴露的问题被修复，修复的功劳算演练团队的——演练从「找麻烦」变成「攒贡献」

一个起步计划（四周）

• 第 1 周：选 3 个低风险故障模式（实例重启/缓存清空/单依赖延迟），写好熔断预案
• 第 2 周：第一次微演练（预告时间但不预告内容），演练后复盘 30 分钟
• 第 3~4 周：不预告演练 ×2，第 4 周末做一次月度小结：暴露了什么、修了什么

一个月后回头看：演练清单长了、预案库实了、值班的人对「突然挂一个实例」脱敏了——脱敏本身就是价值，从容是练出来的，不是招来的。

（服务端系列：舱壁隔离 → 依赖度量 → 本文：故障演练 → 计划中：告警自愈的边界）