4. Runbook 核心概念：定义、生命周期与剧本关系
Runbook 是运维自动化的“操作手册”，在变更冻结闸口与故障恢复流程中扮演核心执行引擎的角色。本节从定义、生命周期和与剧本的关系三个维度，系统梳理 Runbook 的核心概念。
4.1 Runbook 定义
Runbook（运行手册）是一份可执行的、结构化的操作文档，它将运维人员的经验、标准和流程转化为可重复、可审计、可自动化的步骤序列。在 SRE 实践中，Runbook 不仅是文档，更是自动化流程的载体。
| 维度 | 说明 | 示例 |
|---|---|---|
| 文档属性 | 记录操作步骤、前置条件、预期结果、回退方案 | “数据库主从切换 Runbook”包含 12 个步骤 |
| 可执行属性 | 步骤可被自动化引擎（如 Ansible、StackStorm）直接调用 | “重启服务”步骤对应一个 Ansible Playbook 任务 |
| 审计属性 | 每次执行记录时间、操作人、输入输出、结果状态 | 执行日志写入 Elasticsearch，保留 180 天 |
| 版本属性 | 随系统架构变更持续迭代，有版本号和变更记录 | v2.1.0 新增“自动回滚”分支 |
关键原则：好的 Runbook 应让“初级工程师也能按步骤完成复杂恢复操作”，且每一步都有明确的成功/失败判断标准。
4.2 Runbook 生命周期
Runbook 从创建到废弃经历完整的生命周期管理，每个阶段都有对应的质量门禁和自动化检查点。
生命周期各阶段的关键活动与质量门禁：
- 设计阶段：明确故障场景、恢复目标（RTO/RPO）、操作边界；输出步骤流程图和参数定义表。
- 开发阶段：将步骤转化为可执行脚本或 API 调用；使用版本控制（Git）管理 Runbook 代码。
- 测试阶段：在沙箱环境执行全流程验证，包括正常路径、异常路径、超时处理；通过后标记“测试通过”。
- 发布阶段：合并到主分支，打版本标签，部署到生产自动化引擎；触发变更通知。
- 执行阶段：由告警或人工触发，记录执行上下文、每一步的输入输出、耗时和结果。
- 审计阶段：定期回顾执行记录，识别失败步骤、耗时瓶颈、人工干预点；生成改进建议。
- 废弃阶段：当系统架构变更导致 Runbook 不再适用时，标记为废弃并归档，避免误用。
常见陷阱：跳过测试阶段直接发布 Runbook，或在生产环境直接编辑 Runbook 内容。这两种行为都会破坏 Runbook 的可审计性和可靠性，在变更冻结期间尤其危险。
4.3 Runbook 与剧本的关系
在运维自动化领域，“Runbook”和“剧本（Playbook）”经常被混用，但两者在抽象层级、作用范围和执行方式上存在明确差异。
| 对比维度 | Runbook（运行手册） | 剧本（Playbook） |
|---|---|---|
| 抽象层级 | 业务/场景级：描述“做什么”和“为什么做” | 任务/技术级：描述“怎么做”的具体命令 |
| 作用范围 | 端到端恢复流程，可能跨多个系统、多个团队 | 单系统或单组件的操作序列 |
| 执行方式 | 可人工执行、半自动或全自动 | 通常由自动化引擎全自动执行 |
| 包含关系 | 一个 Runbook 可调用多个剧本 | 一个剧本可被多个 Runbook 引用 |
| 示例 | “数据库故障恢复 Runbook” | “MySQL 主从切换 Playbook” |
| 变更频率 | 随业务架构变化，低频变更 | 随组件版本升级，高频变更 |
在变更冻结闸口自动化场景中，两者的协作关系如下：
最佳实践：在变更冻结闸口自动化中，建议将 Runbook 作为“流程编排层”，负责决策逻辑、条件分支、人工审批节点；将剧本作为“原子操作层”，负责具体的系统命令执行。这种分层设计使得 Runbook 变更时无需修改底层剧本，反之亦然，大幅降低变更风险。
4.4 三者关系总结
Runbook、剧本与变更冻结闸口的关系可以概括为：
- 变更冻结闸口是管控策略，定义“什么条件下允许变更”。
- Runbook是执行载体，承载“如何执行恢复操作”的完整流程。
- 剧本是技术实现，提供“具体操作命令”的可复用组件。
在故障恢复场景中，闸口触发 Runbook，Runbook 按步骤调用剧本，剧本执行具体的系统操作，执行结果反馈回 Runbook 进行下一步决策。三者形成“策略→流程→执行”的完整闭环。