2. Runbook 基础概念
Runbook 是运维领域将“人脑经验”转化为“机器可执行剧本”的核心载体。在告警自愈场景中，Runbook 定义了从告警触发到恢复动作完成的全链路操作规范。理解其定义、组成要素与常见类型，是设计自愈触发链路的前提。
2.1 Runbook 的定义
Runbook（运行手册）是一份结构化的操作文档或可执行剧本，它详细描述了在特定运维事件（如告警、故障、变更）发生时，运维人员或自动化系统应遵循的步骤、判断逻辑与恢复动作。在 SRE 实践中，Runbook 不仅是知识沉淀的载体，更是告警自愈链路的“大脑”——它决定了“收到告警后，系统该做什么”。
核心定位： Runbook = 标准化操作流程 + 可编程决策逻辑 + 可执行动作脚本。它消除了运维人员对“个人经验”的依赖，使故障处理可重复、可审计、可自动化。
2.2 Runbook 的组成要素
一个完整的 Runbook 通常包含以下 7 个核心要素，它们共同构成了告警自愈触发链路的“剧本骨架”：
| 要素 | 说明 | 告警自愈场景示例 |
|---|---|---|
| 触发条件 | 定义 Runbook 被调用的前置条件，通常与告警规则绑定 | CPU 使用率 > 90% 持续 5 分钟 |
| 输入参数 | 从告警事件中提取的上下文变量，供后续步骤使用 | ${host_ip}, ${alert_severity}, ${metric_value} |
| 决策逻辑 | 条件判断、分支选择、循环控制等流程控制语句 | IF severity == 'critical' THEN 执行重启 ELSE 执行扩容 |
| 操作步骤 | 有序的动作列表，可以是手动指令或自动化脚本 | Step1: SSH 登录 → Step2: 执行诊断脚本 → Step3: 重启服务 |
| 验证检查 | 执行操作后，确认故障是否恢复的检查点 | 检查 CPU 是否降至 70% 以下，且服务端口正常 |
| 回滚策略 | 当操作失败或引发副作用时的恢复方案 | 重启失败则触发告警升级，通知 SRE 人工介入 |
| 输出记录 | 执行日志、状态变更、指标快照等审计信息 | 记录执行时间、操作人（或系统）、执行结果、变更的配置项 |
设计要点： 在告警自愈场景中，输入参数和验证检查是容易被忽略但至关重要的要素。缺少参数传递会导致脚本无法适配不同主机；缺少验证检查会导致“假恢复”——操作执行了但故障未解决。
2.3 Runbook 的常见类型
根据自动化程度和执行方式，Runbook 可分为以下三种常见类型。在告警自愈触发链路设计中，通常需要混合使用多种类型来覆盖不同场景。
- 手动 Runbook（Manual Runbook）：以文档形式存在，供运维人员按步骤手动执行。适用于高危操作（如数据库主从切换）或无法完全自动化的场景。在自愈链路中通常作为“兜底方案”或“人工审批节点”。
- 半自动化 Runbook（Semi-automated Runbook）：部分步骤由系统自动执行，关键决策点需要人工确认。例如：系统自动诊断并生成修复建议，由运维人员点击“确认”后执行。适用于需要人工判断风险的场景。
- 全自动化 Runbook（Fully-automated Runbook）：从触发到恢复完全由系统自动完成，无需人工干预。这是告警自愈链路的理想形态，适用于确定性高、风险可控的故障场景（如进程重启、缓存清理、自动扩容）。
避坑提示： 不要盲目追求全自动化。对于变更类操作（如修改配置、重启数据库），建议先以“半自动化”形式运行一段时间，积累足够的执行日志和成功率数据后，再逐步过渡到全自动化。直接上线全自动化 Runbook 可能导致“雪崩式误操作”。
2.4 小结
Runbook 是告警自愈触发链路的“剧本核心”。理解其定义（标准化操作流程 + 可执行剧本）、7 大组成要素（触发条件、输入参数、决策逻辑、操作步骤、验证检查、回滚策略、输出记录）以及三种常见类型（手动、半自动化、全自动化），是后续设计自愈链路的基础。在实际落地中，建议从半自动化 Runbook 起步，逐步积累信心与数据，再向全自动化演进。