Runbook 缺口补全

手册为什么跟不上现场

故障处置时，值班同学常常照着 runbook 走到一半，发现手册里根本没有这一步，只能临时问人、翻聊天记录、靠记忆补。等故障过去了，runbook 还是原样，下一次同样的坑还要再踩一遍。更麻烦的是手册写了 A 步骤、现场实际执行的是 B——两者都存在，却没人知道它们已经不一致。

它做什么

输入是两样东西：现有 runbook 全文或相关章节，以及一次真实故障的时间线（或演练记录）。技能把时间线上的每个关键动作逐条映射回手册：

• 手册有且步骤一致 → 通过
• 手册有但与实操冲突 → 记入冲突表
• 手册没有 → 记入缺口表，并附故障中的证据摘录

最终输出四份内容：

1. 缺口表——手册未覆盖、但故障中实际用到的动作或判断
2. 冲突表——手册与实操不一致之处
3. 建议补丁——可直接粘贴进手册的步骤段落草案
4. 待确认——缺权限、监控名、命令参数时留占位，不编造

补丁用「可粘贴」的步骤语气写；拿不准的命令一律写成 待确认命令，而不是猜一个出来。输出格式遵循 references/gap-template.md。

边界与注意点

它是文档改进参谋，不是执行工具：不做故障事中通报，不登录机器，不自动 SSH、改配置或切流量。补丁只是文本建议，是否合入由人工审阅决定，命令在真实环境能否跑通也不在保证范围内。

缺少 runbook 或故障经过任意一项时会先追问补齐。只有手册、没有故障经过时，可做一轮「常见场景覆盖自检」，但会明确标注无实证，优先级低于对照真实故障。

如果需求是写给业务的进度短讯、事故根因与改进项复盘，或制度条款与现场执行的差距核对，应选择 incident-status-update、postmortem-lite、sop-gap-check——本技能只管值班手册这一层。