2. Runbook 基础概念
2.1 什么是 Runbook
Runbook（运行手册）是一份可执行的、结构化的操作文档，它将运维人员从“凭经验操作”转变为“按标准流程执行”。在 SRE 体系中，Runbook 不仅是故障处理指南，更是自动化编排的原子单元。
核心定义：Runbook 是一组经过验证、可重复执行的步骤集合，用于完成特定的运维任务（如故障恢复、变更部署、容量扩缩容），并具备明确的输入、输出、判定条件和回滚路径。
一个标准 Runbook 应包含以下关键要素：
| 要素 | 说明 | 示例 |
|---|---|---|
| 触发条件 | 启动 Runbook 的事件或阈值 | CPU 使用率 > 90% 持续 5 分钟 |
| 前置检查 | 执行前必须满足的状态 | 确认备用节点健康、确认数据库主从同步正常 |
| 操作步骤 | 原子化的执行指令 | 执行 kubectl cordon → 迁移 Pod → 重启服务 |
| 验证条件 | 判断步骤是否成功的指标 | HTTP 200 响应、延迟 < 200ms |
| 回滚方案 | 步骤失败时的恢复路径 | 回退到上一版本、重启旧 Pod |
| 输出记录 | 执行结果的持久化 | 日志、告警关闭、工单更新 |
实践建议：Runbook 的粒度应控制在“一个人 15 分钟内可手动完成”的范围内。过大的 Runbook 应拆分为多个子 Runbook，通过编排引擎串联执行。
2.2 Runbook 的典型生命周期
Runbook 不是一次性编写的静态文档，它需要经历从设计、编写、测试、发布到持续优化的完整生命周期。SRE 团队应将 Runbook 视为“代码”进行管理。
Runbook 生命周期包含以下 6 个阶段：
- 设计（Design）：分析故障场景，确定触发条件、输入输出和依赖关系，绘制流程图。
- 编写（Author）：使用标准模板或 DSL（领域特定语言）编写步骤，嵌入自动化脚本。
- 测试（Test）：在沙箱环境执行，验证每个步骤的预期结果和回滚路径。
- 发布（Release）：通过 CI/CD 管道合并到生产 Runbook 仓库，关联告警规则。
- 执行（Execute）：由 on-call 工程师手动触发或自动化引擎自动触发，记录执行日志。
- 审计（Audit）：定期审查执行记录，收集反馈，更新步骤或阈值。
常见陷阱：很多团队只完成了“编写”阶段，忽略了测试和审计。未经测试的 Runbook 在故障时可能造成二次事故；缺乏审计的 Runbook 会随着系统演进逐渐失效。
2.3 Runbook 在 SRE 中的价值
Runbook 是 SRE 实践的核心载体，它将“可观测性”与“自动化执行”连接起来。没有 Runbook，告警只是噪音；有了 Runbook，告警才能转化为可执行的行动。
Runbook 在 SRE 中的四大核心价值：
| 价值维度 | 具体表现 | 量化指标 |
|---|---|---|
| 缩短 MTTR | 标准化流程消除“思考时间”，on-call 工程师按步骤执行即可恢复 | MTTR 降低 40%~60% |
| 减少人为失误 | 避免遗漏步骤、输错命令、误判状态等人为因素 | 故障恢复成功率提升至 95%+ |
| 知识沉淀 | 将资深工程师的经验转化为可复用的文档和脚本 | 新员工上手时间缩短 70% |
| 自动化基石 | Runbook 是自动化编排的最小单元，可被 ChatOps、告警引擎调用 | 自动化覆盖率提升至 80%+ |
关键认知：Runbook 的价值不在于“写得多好”，而在于“是否被执行”。一个被频繁执行并持续优化的 Runbook，远胜于一个完美但从未被使用的 Runbook。SRE 团队应优先为 P0/P1 级故障场景编写 Runbook。
在自动化与 on-call 阈值策略融合的实践中，Runbook 扮演着“执行层”的角色：
- 告警触发 → Runbook 匹配：当监控指标超过阈值时，告警系统根据标签（如
severity=critical、service=api-gateway）自动匹配对应的 Runbook。 - Runbook 执行 → 状态反馈：Runbook 执行过程中产生的中间状态（如“节点已隔离”、“流量已切换”）会实时更新到告警上下文，避免 on-call 工程师重复确认。
- 执行结果 → 阈值调优：Runbook 执行失败或超时的记录，可作为调整告警阈值或优化 Runbook 步骤的依据。
融合实践示例：某电商平台为“数据库连接池耗尽”场景配置了 Runbook。当连接数阈值达到 80% 时，自动触发 Runbook 执行“临时扩容连接池”步骤；若 5 分钟内未恢复，则升级为 P1 告警并通知 on-call 工程师手动执行“重启数据库代理”Runbook。该实践将 MTTR 从 25 分钟降至 6 分钟。