2. Runbook 基础概念
Runbook 是运维领域的核心文档化工具，它把运维人员从“凭经验救火”推向“按剧本执行”。在告警自愈场景中，Runbook 既是故障处理的标准操作流程，也是自动化引擎的指令集。理解 Runbook 的定义、演进路径和组成要素，是构建模板化自愈体系的第一步。
2.1 Runbook 的定义
Runbook（运行手册）是一份结构化的操作文档，它详细描述了在特定运维事件（如告警触发、服务异常、变更部署）发生时，运维人员或自动化系统应当执行的步骤、命令、检查点和回退策略。
核心定位：Runbook 将隐性知识（运维人员的个人经验）转化为显性知识（可重复、可审计、可自动化的操作流程）。
一个完整的 Runbook 通常回答以下三个问题：
- 何时执行：触发条件是什么？（例如：CPU 使用率 > 90% 持续 5 分钟）
- 执行什么：具体操作步骤是什么？（例如：重启进程、扩容节点、回滚版本）
- 如何验证：操作成功的标准是什么？（例如：服务健康检查返回 200，延迟 < 100ms）
2.2 传统 Runbook vs 自动化 Runbook
随着运维体系从人工操作向自动化演进，Runbook 的形态和用途发生了根本性变化。下表从多个维度对比两种模式：
| 对比维度 | 传统 Runbook（人工执行） | 自动化 Runbook（自愈引擎） |
|---|---|---|
| 载体形式 | Wiki 页面、PDF 文档、共享文件夹 | YAML/JSON 配置文件、代码仓库、编排引擎 |
| 执行主体 | 值班运维工程师（On-Call） | 自动化平台（如 Ansible、StackStorm、Kubernetes Operator） |
| 触发方式 | 告警通知 → 人工登录 → 查阅文档 | Webhook 回调 → 自动匹配剧本 → 触发执行 |
| 执行速度 | 分钟级到小时级（依赖人员响应） | 秒级到分钟级（机器即时响应） |
| 一致性 | 依赖人员技能水平，容易遗漏步骤 | 严格按剧本执行，结果可复现 |
| 审计追溯 | 人工日志、聊天记录，难以聚合 | 自动记录执行日志、输入输出、决策路径 |
| 维护成本 | 文档容易过时，版本混乱 | 代码化版本管理（Git），变更可审查 |
关键转变：自动化 Runbook 不是简单地把文档里的“复制粘贴命令”写成脚本，而是将决策逻辑、条件分支、重试机制、回滚策略都编码为可执行的剧本。
2.3 Runbook 的组成要素
一个标准化的 Runbook 无论采用何种载体，都应包含以下核心要素。这些要素构成了 Runbook 的“骨架”，也是后续模板化的基础。
2.3.1 元数据（Metadata）
用于标识、分类和检索 Runbook 的信息，是自动化引擎匹配剧本的关键依据。
- 名称与 ID：唯一标识，如
runbook_nginx_restart_v2 - 版本号：遵循语义化版本，如
1.2.0 - 标签/分类：按服务、环境、告警类型打标，如
service:nginx, env:prod, alert:high_cpu - 维护人：负责更新和审核的团队或个人
- 创建/更新时间：用于追踪时效性
2.3.2 触发条件（Trigger）
定义 Runbook 在什么情况下被激活。在自动化场景中，触发条件通常与监控告警规则绑定。
- 告警规则匹配：如 Prometheus Alertmanager 的
alertname和labels - 条件表达式：如
cpu_usage > 90 AND duration > 5m - 环境/服务限定：如
env == "production" && service == "api-gateway"
2.3.3 执行步骤（Steps）
Runbook 的核心操作序列。每个步骤应具备原子性、可观测性和可回滚性。
| 步骤属性 | 说明 | 示例 |
|---|---|---|
| 步骤名称 | 清晰描述该步骤的目的 | “检查 Nginx 进程状态” |
| 操作类型 | 命令执行、API 调用、脚本运行、人工确认 | shell: systemctl status nginx |
| 预期结果 | 步骤成功的判断标准 | 返回码 0，输出包含 “active (running)” |
| 超时时间 | 防止步骤卡死 | timeout: 30s |
| 重试策略 | 失败后的重试次数和间隔 | retry: 3, interval: 5s |
| 回滚操作 | 步骤失败后的恢复动作 | “恢复备份配置文件并 reload” |
2.3.4 决策逻辑（Decision Logic）
Runbook 不是线性的死板脚本，它需要根据执行过程中的状态做出分支判断。
- 条件分支：如
if 步骤3成功 then 执行步骤4 else 执行回滚步骤 - 并行执行：如同时检查多个节点的健康状态
- 循环/遍历：如对集群中所有异常 Pod 执行重启操作
2.3.5 输出与通知（Output & Notification）
Runbook 执行完毕后，需要将结果反馈给相关人员或系统。
- 执行日志：记录每一步的输入、输出、耗时和状态
- 告警关闭/升级：成功则自动关闭告警，失败则升级到高级别 On-Call
- 通知渠道：Slack、钉钉、邮件、PagerDuty 等
- 审计报告：用于事后分析和合规要求
常见误区：很多团队把 Runbook 写成“操作手册”，只罗列命令，缺少触发条件和决策逻辑。这样的 Runbook 无法直接用于自动化自愈，因为引擎不知道“什么时候执行”以及“执行失败后怎么办”。