Runbook 写了 20 篇、事故里真正翻开的不到 3 篇：你们团队的 runbook 到底是"操作手册"还是"考古化石"？

【背景】 15 年 SRE，换过 4 家公司。每家的 runbook 目录里都有十几篇甚至几十篇操作手册：MySQL 主从切换、Kafka 分区 rebalance、Pod OOM 应急扩内存、TLS 证书续签、连接池打满紧急扩容……

但真正在凌晨 3 点的 P0 里，被 on-call 工程师翻出来、照着执行的，我数过——不超过 3 篇。大多数 runbook 写完那天之后，再也没被打开过。

我见过两种极端：

• 一家公司 runbook 写得极其详尽（带截图、每条命令的预期输出、回滚步骤），但最后更新停留在 2 年前，架构已经换了 3 轮。事故里工程师打开一看，命令里的端口号、服务名都不对了，最后还是靠口口相传的"老张的经验"救的。
• 另一家公司 runbook 只有一行："重启。"但每次事故响应反而最快——因为工程师知道该找谁、该按什么顺序操作，runbook 只是"心理安慰"和"合规留痕"。

【常见分歧 / 几种做法】

1. runbook = 操作手册：写清楚每一步命令、预期输出、回滚步骤。适合"新人 on-call"和"跨团队协作"场景。
2. runbook = 决策树：只写"看到什么现象 → 判断什么 → 做什么动作"，不写具体命令。适合团队内熟练度高、人员流动小的场景。
3. runbook = 自动化的过渡态：runbook 本质上是"人脑 runbook → 脚本 runbook"的中间产物，最终目标是把操作脚本化，runbook 只留"异常处理分支"和"人工决策点"。
4. runbook 不重要：真正重要的不是文档，而是团队的"肌肉记忆"和"on-call 培训"。文档只是备份，是合规需要，不是工程需要。

【我的倾向与理由】 我偏向第 3 种，但有一个前提：runbook 的生命周期必须和代码一样管理——有 owner、有 review、有过期机制。

具体做法（我团队实际在用的，效果一般但比"不管"好）：

• 每篇 runbook 头部有一个 last_verified 字段，超过 90 天未验证的自动标黄（Confluence 宏实现的，不复杂）。
• 每次 P0/P1 事故后 48h 内，复盘会的第一项议程不是"根因分析"，而是"runbook 里有没有覆盖这个场景？没有就当场补，有就照着跑一遍，把偏差写进去"。
• 每季度做一次"runbook 盲演"：随机抽 2 篇，让 on-call 工程师在没有提示的情况下照着执行（非生产环境）。执行不了的，当场改。这一步最容易被砍，因为"没时间"。

但我也承认一个矛盾：如果 runbook 最终都变成了脚本，那"人"的角色就只剩"判断该跑哪个脚本"和"处理脚本没覆盖的异常"。这时候 runbook 的价值是不是已经退化成"一个 if-else 列表"？而 if-else 列表放在代码里不是更合理吗？

【想听大家在什么场景下怎么选】

• 你们团队的 runbook 是"活文档"还是"考古化石"？最后更新是什么时候？
• 有没有过"runbook 写得很详细但事故里根本没用上"的经历？当时是怎么救的？救完之后有没有回头改 runbook？
• 你们把 runbook 脚本化的比例大概是多少？剩下没脚本化的部分，是"不值得"还是"来不及"？
• 一个新 on-call 工程师接手值班，你给他看 runbook 还是给他看"历史事故复盘文档"？为什么？
• 你觉得 runbook 的"保质期"应该是多久？谁来负责续命？