Runbook 是什么
Runbook 是挂在告警旁边的一页处置说明：症状是什么、先看哪个数据、有哪些缓解动作、什么条件下升级。判据很简单——值班人半夜被叫醒，打开链接后知道下一步做什么。它和事故预案不同：预案面向组织级响应，runbook 面向单条告警的具体动作，一份只服务一个告警，因此要短、要具体、要带能直接执行的查询与链接。
基本信息
| 适用平台 | 任何告警体系都适用，与 Alertmanager 或云监控无关 |
|---|---|
| 挂载位置 | 告警规则的 annotations 里放文档链接 |
| 建议篇幅 | 一屏可读完，超过两屏说明该拆成多份 |
| 维护节奏 | 每次真实排障后顺带修订，季度巡检核对链接 |
典型使用场景
- 高危告警配处置：错误率、延迟、容量类告警各配一份
- 新人值班：把隐性经验写成显性步骤，缩短上手时间
- 处置动作标准化：同一告警不同人处理，结果差异变小
- 复盘沉淀：事故中的有效动作回写进 runbook，下次直接复用
- 演练脚本：把 runbook 当作演练检查单逐条执行
runbook 结构示例
runbook 结构示例
# 告警名：HighErrorRate（service=order-svc）
## 症状与影响
- 订单接口错误率高于 5%，用户下单失败
## 确认步骤（两步内看到关键数据）
1. 打开看板：订单服务总览
2. 查询：按状态码分组的错误速率
## 缓解动作（按优先顺序）
- 回滚最近一次发布 / 切流到备用集群 / 扩容实例
## 升级条件
- 15 分钟未缓解：联系订单域架构组并宣布事故
## 相关链接
- 发布记录、变更窗口、历史同类事件复盘必备要素
| 要素 | 写什么 | 反例 |
|---|---|---|
| 症状 | 用户可感知的现象 | 只写指标名不写影响 |
| 确认步骤 | 能直接执行的查询或链接 | 让你自己判断一下 |
| 缓解动作 | 按优先级排序的具体操作 | 联系相关负责人 |
| 升级条件 | 时间与判据，明确联系人 | 视情况升级 |
| 相关链接 | 看板、发布记录、历史复盘 | 无 |
runbook 要由一线写、用真实排障迭代：从别处抄来的通用文档通常缺少本环境的命令与链接，值班时用不上。
把链接放进告警规则的注解里，让通知正文直接可点；文档与告警分离存放时，改名或迁移很容易造成链接失效。