【背景】 3 年运维，从「全靠群里喊」到「runbook 满天飞」再到「runbook 没人看」，绕了一圈。最近新同事接手一个 20 节点 K8s 集群（1.28 + containerd），第一次 P99 告警我扔给他我们那份 runbook，他看完 40 分钟没动手——因为文档里全是「检查 X、看 Y 指标、如果 Z 就执行 W」，但没说「先判断哪个是根因」。最后我远程接过去 5 分钟定位：是下游 MySQL 主从延迟，不是我们服务的问题。
这件事让我重新想：runbook 到底是「操作手册」还是「决策树」？这两者的写法、维护成本、新人上手速度，完全不是一个量级。
【几种常见做法】
- 口口相传派：靠老同学带，群置顶 + 聊天记录。优点是快，缺点是人一走全没了，我见过一个团队核心 SRE 离职后 3 个月没人敢动生产。
- 症状-动作派：一张表，「看到 A 报错 → 执行 B 命令」。简单，但遇到组合故障（A 报错其实是 C 引起的）就失灵，新同学容易机械执行。
- 完整 runbook 派：每个故障场景一个 md，含现象、根因、指标、处置步骤、回滚、复盘链接。写起来 2-3 天一个，维护成本高，我见过最夸张的一份 4000 行，最后没人敢改。
- 可执行脚本派：runbook 就是几个 shell / kubectl 脚本 + grafana 面板链接，一键执行。适合流程固定的场景（重启、扩容、切流），但需要「判断」的场景写不出来。
- AI 辅助派：把日志 + 指标喂给 LLM，让它现场推。我们试过，准确率 60% 上下，敢用的人不多，卡点主要是「它给出的命令我不敢在生产敲」。
【我的倾向】 写「决策树」而不是「步骤手册」，具体几条：
- 每个节点只回答一个问题（「是 P99 抖还是 QPS 掉？」「是本服务还是下游？」），配一个可观察指标（grafana 面板链接，不是截图）
- 每个叶子节点只有一个动作（重启 / 回滚 / 扩容 / 找人），带一条回滚命令和一条「执行前必看」的确认指标
- 每个场景控制在 5 层以内，超过 5 层说明拆得不对，应该拆成两个场景
- 维护规则写死：每次事故复盘后 48h 内必须更新，PR 走 review，owner 写在文件头（不是「运维组」这种空 owner）
- 新人 onboarding 用「考 runbook」而不是「读 runbook」：随机抽 3 个场景让他 10 分钟内给出第一动作，比读完 20 篇 md 有效
理由：runbook 的价值不是「记住步骤」，而是「在压力下还能做对判断」。决策树把判断显式化，比步骤更抗遗忘，也更抗「组合故障」。
【想听大家】
- 你们团队的 runbook 现在长什么样？多少场景、多少行、谁维护？
- 触发「重写」的事件是什么？事故？换人？还是季度 review？我见过太多 runbook 写完 3 个月就和真实环境对不上了（比如 K8s 版本升了、告警阈值改了）。
- 小团队（<5 人）要不要搞？ 我见过 3 人团队硬写 30 个 runbook，最后全过期，反而不如不写。你们的临界点在哪？
- 有没有把 runbook 变成「可执行 + 可审计」的形态？比如 Terraform / ArgoCD / 内部 CLI，执行有审计日志、可回滚？
- AI 辅助排查你们线上敢用吗？卡在哪一步？是权限、是审计、还是「不敢敲它给的命令」？
欢迎拍砖，尤其想听「runbook 写完没人看」的破局思路——是不是我们根本不该写 runbook，而是该写「故障演练 + 决策树 + 可执行脚本」三件套？
0赞
0收藏
0楼层