需要把重复性运维任务固化为可复现 runbook 时…

适用于为值班/运维需要重复执行的任务创建或更新可复现的分步操作 runbook。

适用场景

解决思路

1. 若看到不熟悉的占位符或需要检查哪些工具已连接，查看 CONNECTORS.md。
2. 运行 `/runbook $ARGUMENTS`，并传入流程或任务名称来创建或更新 runbook。
3. 按 Markdown 模板输出 Runbook，并填写标题、Owner、Frequency、Last Updated、Last Run。
4. 写 Purpose 部分，说明该 runbook 达成什么目标以及适用触发条件。
5. 在 Prerequisites 中列出检查项：所需访问或权限、所需工具或系统、所需数据或输入。
6. 将 Procedure 按顺序拆成编号步骤，并为每步写 Step 名称。
7. 在每步中放入精确命令、动作或指令的代码块。
8. 在每步中写明 Expected result：应该发生什么。
9. 在每步中写明 If it fails：失败时该做什么。
10. 添加 Verification 检查清单，用于确认任务已成功完成以及需要检查什么。
11. 添加 Troubleshooting 表格，列为 Symptom、Likely Cause、Fix。
12. 添加 Rollback 部分，说明出错时如何撤销该操作。
13. 添加 Escalation 表格，列为 Situation、Contact、Method。
14. 添加 History 表格，列为 Date、Run By、Notes。
15. 如果连接了 knowledge base：搜索已有 runbook 以更新，而不是从头创建。
16. 如果连接了 knowledge base：将完成的 runbook 发布到 ops wiki。
17. 如果连接了 ITSM：将 runbook 关联到相关 incident types 和 change requests。
18. 如果连接了 ITSM：从 on-call schedules 自动填充 escalation contacts。
19. 要极度具体：不要写“Run the script”，而要写“从 ops server 运行 `python sync.py --prod --dry-run`”。
20. 包含失败模式：写出每步可能出什么问题以及如何处理。
21. 测试 runbook：让不熟悉该流程的人按它执行，并修复他们卡住的地方。

适用边界 · 注意事项

• 不适用于一次性、临时性的任务，或没有重复执行价值的操作。
• 不适用于流程尚未稳定、每步都依赖临场判断且无法固化为明确命令或动作的场景。
• 不要用 runbook 替代实时事故指挥或复杂根因分析，这些需要另行处理。