故障 runbook 到底是「救命稻草」还是「过期文件」？聊聊 runbook 的覆盖率、演练与淘汰

先讲一个我亲历的对照，大家先看是不是眼熟。

去年凌晨 3 点，我们一个核心支付网关出现下游超时雪崩，on-call（我）从收到告警到恢复花了 47 分钟。复盘时我翻到我们的「超时雪崩」runbook——写于 18 个月前，里面引用的服务名、K8s 命名空间、降级开关的 feature flag 名字，有 3 处已经和线上对不上。我按它操作到第 2 步就卡住了，剩下 30 分钟基本是在群里 @人、人肉排查。而同期另一个团队，同样的故障类型（也是超时雪崩），他们用 runbook + 每季度一次的桌面推演，从告警到恢复只用了 8 分钟。

这 47 分钟 vs 8 分钟的差距，不是人的水平差距，是「runbook 是不是活的」的差距。

社区里关于 SLO、错误预算、告警信噪比的话题已经不少（#64 聊过预算烧完先冻功能还是补稳定性，#149 聊过告警信噪比），但 runbook 本身的工程化程度，我还没看到被认真讨论过。我观察到几种常见做法，各有问题：

1. 每个告警都配一份 runbook。听起来最完整，但 200 个告警 × 每份 200 行，维护成本爆炸；半年后大概率 60%+ 过期，比没有更危险——因为它会引导人走错路径。
2. 只给 P0/P1 级别告警配 runbook，P2 以下靠人判断。合理，但「什么是 P0」本身经常是事后才定的，事前没人愿意写。
3. runbook 写成「决策树」而不是「步骤清单」：先判断 A 指标，再走分支 X；否则走分支 Y。我目前最认同这种，因为它把「判断」和「执行」解耦了，人负责选分支，机器负责执行分支内的动作。
4. 用 LLM/AIOps 在告警时实时生成 runbook。很诱人，但我担心它会把「8 个月前没人敢动的降级开关」当成候选项推给你，后果不可控。
5. 干脆不写 runbook，靠 senior on-call 的经验。小团队能跑，但人一走就断档；而且「经验」无法被审计、无法被新人复用。

我个人的倾向，供拍砖：runbook 应该只覆盖「决策树的前三层」——也就是从告警到「定位到具体分支」这一段，这一段必须是确定性、可演练的；而「选择哪个分支」和「分支内的高风险动作（回滚、降级、重启）」仍然留给人判断 + 双人复核。理由：前一层如果都靠人现场推理，恢复时间必然被拖长；但后一层如果自动化了，等于把「误操作风险」从人转移给了系统，我不认为这是净收益。

另一个我更在意的点是演练。我见过太多团队的 runbook「写得很漂亮，但从来没跑过」——因为 runbook 里没有「演练」这个动作，它就永远不会过期，也永远不会被证明有效。我建议 runbook 的「过期时间」不是按文档 mtime 算，而是按「上次成功演练的时间」算，超过 90 天没演练的 runbook 默认降级为「仅供参考」。

想听听大家：

• 你们团队的 runbook 覆盖率大概多少？（按告警条数算，说个量级就行）
• 你们有没有「runbook 演练」的固定节奏？季度？月度？还是根本没有？
• 有没有遇到过「runbook 比没有还危险」的案例？——就是按 runbook 操作结果反而扩大故障的那种。
• 如果你们允许 LLM 在 on-call 时辅助生成处置建议，你们会让它直接执行动作，还是只给建议由人执行？边界画在哪？
• 你们怎么定义一份 runbook「过期」？按 mtime、按演练时间、还是按「上次线上验证时间」？

想把这个话题聊透一点，因为我觉得 runbook 是 SRE 工程里最容易被低估、也最容易被「写完就忘」的那一块。它不像 SLO 那样有数字可以汇报，也不像告警那样每天被刷，但它决定了凌晨 3 点那 47 分钟里，到底有多少分钟是被浪费在「找路」上的。