故障演练到底是"验证假设的实验室"还是"证明稳定的考试"？聊聊怎么做才不沦为走过场

先交代下背景，免得大家各说各话。

我在一个 20 人左右的后端团队做 SRE，服务跑在自建 K8s 1.28 上，核心链路是「网关 → 订单 → 库存 → 支付」。去年 Q4 开始，我们引入了故障演练：用 ChaosMesh 在 staging 环境周期性注入 Pod 杀、网络延迟、磁盘满，目标是"在事故前把坑挖出来"。

跑了两个季度后，我复盘发现一个挺扎心的现象——演练的价值在递减，形式在膨胀。具体表现：

1. 演练项目化：每次演练前要写方案、拉群、约时间，一个"杀一个 Pod"的动作能折腾半天，团队开始把它当成 KPI 而不是手段；
2. 结论模板化：报告里清一色"发现 N 个问题，已排期修复"，但三个月后回看，真正被修复的不超过一半，因为演练发现的"问题"大多没有优先级；
3. 演练与真实事故脱钩：去年 11 月一次真实的数据库主从切换，我们事先演练过"主库挂"，结果真出事时值班同学的第一反应还是"先看看是不是误报"——演练里我们练的是"注入→观察→恢复"，没练"值班同学在凌晨 3 点、没有上帝视角时怎么决策"。

这里有个我一直没想清楚的核心分歧，想抛给大家：

故障演练的定位，应该是"验证假设的实验室"还是"证明稳定的考试"？

这两种定位导向完全不同的做法：

• 实验室派：演练是工程活动，目标是"证伪"——我假设"主库挂了 30s 内能自动切换"，演练就是去看这个假设在什么条件下不成立。失败是常态，甚至失败越多说明演练越有效。结论是"哪些假设不成立"，不是"系统稳不稳"。
• 考试派：演练是质量门禁，目标是"证明"——上线前/季度末跑一遍，全绿了才能发布/对外承诺 SLA。失败是异常，需要追责和返工。结论是"能不能过"。

我的倾向是实验室派，理由有三：

1. 考试派会逼出"应试行为"：为了过演练，团队会去"记住"哪些场景会被考，而不是真的提升系统韧性。我见过一个团队把演练脚本里的故障模式硬编码进了启动参数，演练当然全绿，真实事故一来全崩。
2. 实验室派天然和"假设驱动"对齐：每次演练前明确写下"我假设 X，在 Y 条件下不成立"，演练后只回答"假设成立吗"，不回答"系统好不好"。这让结论可证伪、可追踪，也避免了"报告里写一堆但没优先级"的问题。
3. 实验室派对"失败"的容忍度更高：失败是数据，不是事故。这点对团队心理很重要——我见过太多团队因为演练"搞崩了 staging"被业务方投诉，最后演练被叫停。

但我也有几个没想清楚、想听大家经验的点：

1. 演练频率怎么定？每周一次"杀 Pod"还是每月一次"全链路注入"？小团队人手有限，怎么在"够用"和"过度"之间取平衡？
2. staging 和生产的差距：我们的 staging 是生产的 1/3 规模，网络拓扑也不同。在 staging 通过的演练，到了生产真的能复现吗？有没有团队直接在生产做"小剂量"演练（比如只对一个非核心服务注入延迟）？
3. 演练结论怎么变成 actionable item：我现在的做法是把每个"不成立的假设"转成一条 issue，打 chaos-found 标签进 backlog，但优先级还是靠人肉排。有没有更结构化的做法？
4. 怎么避免"演练疲劳"：当团队开始把演练当成"又一个要应付的事"，是不是说明定位错了？还是说应该降低频率、提高单次深度？

我特别想听两种场景下的做法：

• 5 人以下的小团队：没有专职 SRE，演练怎么做才不变成负担？
• 100 人以上的大团队：演练怎么避免"每个团队各搞一套、标准不统一"？

欢迎把你们踩过的坑、跑通的做法、甚至"我们试过但放弃了"的案例都贴出来。这种话题最怕全是"我觉得应该……"，我宁可听具体的命令、配置、数据。