📚 课程目录第3章 Runbook基础

3. Runbook 基础：定义、分类与标准化结构

Runbook（运维手册）是运维团队将可重复的操作过程文档化、标准化、可执行的操作指南。在告警自愈场景中，Runbook 是连接“告警触发”与“自动化恢复”的核心桥梁——它定义了“当某类故障发生时，系统应该执行哪些步骤来恢复服务”。没有标准化的 Runbook，告警自愈就只是一堆零散的脚本，无法形成可复用的自动化闭环。

3.1 Runbook 的定义

Runbook 是一份结构化的操作文档，它详细描述了在特定运维场景下（如故障处理、变更实施、日常巡检）需要执行的一系列步骤、检查点、回退方案和预期结果。在自动化体系中，Runbook 不仅是给人阅读的 SOP，更是可以被自动化引擎（如 Ansible、StackStorm、Rundeck）解析和执行的可编程工作流。

核心观点： 好的 Runbook 应该做到“三可”——可读（人看得懂）、可执行（机器能跑）、可度量（结果可验证）。告警自愈的 Runbook 尤其强调“可执行”与“可度量”。

3.2 Runbook 的分类

根据运维场景的不同，Runbook 通常分为三大类。在告警自愈流程设计中，故障类 Runbook 是核心，但变更类和巡检类 Runbook 也常作为前置或后置环节被串联调用。

分类	触发条件	核心目标	典型场景	自动化程度
故障类 Runbook	告警事件、监控指标异常	快速恢复服务，消除故障影响	进程挂掉、磁盘满、高延迟、证书过期	高（全自动或半自动）
变更类 Runbook	计划内变更、版本发布、配置修改	安全、可追溯地完成变更，降低人为失误	应用发布、数据库迁移、配置推送	中（审批+自动执行）
日常巡检类 Runbook	定时任务、周期性检查	提前发现隐患，验证系统健康度	磁盘使用率检查、日志错误扫描、证书有效期检查	高（全自动）

  分类要点： 故障类 Runbook 强调速度和幂等性（多次执行结果一致）；变更类 Runbook 强调审批流和回滚能力；巡检类 Runbook 强调数据采集和趋势分析。在告警自愈体系中，故障类 Runbook 是“第一响应人”，变更类 Runbook 是“修复工具”，巡检类 Runbook 是“预警哨兵”。

3.3 Runbook 的标准化结构

为了让 Runbook 能被自动化引擎统一调度，同时让不同团队的运维人员都能快速理解和使用，Runbook 必须遵循一套标准化的结构模板。以下是我们推荐的七段式 Runbook 结构：

元数据（Metadata）： Runbook 名称、ID、版本、分类、负责人、创建日期、标签。
触发条件（Trigger）： 什么告警或事件会启动这个 Runbook？匹配规则是什么？
前置检查（Pre-check）： 执行前必须满足的条件（如：目标主机可达、资源锁未占用、维护窗口内）。
执行步骤（Steps）： 核心操作序列，每一步需包含：操作命令/API、预期结果、超时时间、失败处理策略。
验证步骤（Validation）： 如何确认恢复成功？需要检查哪些指标或日志？
回滚方案（Rollback）： 如果执行失败或验证不通过，如何回退到安全状态？
输出与通知（Output & Notification）： 执行结果、日志、告警关闭/升级通知、工单更新。

3.4 故障类 Runbook 的典型结构示例

以“Nginx 进程挂掉”这个常见告警为例，展示一个标准化的故障类 Runbook 应该长什么样：

---
# Runbook 元数据
name: "nginx-process-restart"
id: "runbook-nginx-001"
version: "1.2.0"
category: "故障类"
owner: "sre-team"
tags: ["nginx", "process", "restart", "web"]

# 触发条件
trigger:
  alert_name: "NginxProcessDown"
  severity: "critical"
  match_labels:
    service: "nginx"
  cooldown: 300  # 5分钟内不重复触发

# 前置检查
pre_check:
  - host_reachable: true
  - lock_acquired: "nginx-restart-lock"
  - maintenance_window: false

# 执行步骤
steps:
  - step_id: "step-1-check-process"
    action: "command"
    command: "systemctl status nginx"
    timeout: 10
    on_failure: "continue"

  - step_id: "step-2-restart-nginx"
    action: "command"
    command: "systemctl restart nginx"
    timeout: 30
    retry: 2
    on_failure: "rollback"

  - step_id: "step-3-verify-port"
    action: "command"
    command: "ss -tlnp | grep :80"
    timeout: 10
    on_failure: "rollback"

# 验证步骤
validation:
  - check_type: "metric"
    metric_query: "nginx_up{instance='{{.host}}'}"
    expected_value: 1
    max_retries: 3
    interval: 10

# 回滚方案
rollback:
  - rollback_action: "restore_previous_config"
    rollback_command: "cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf && systemctl restart nginx"
    rollback_timeout: 30

# 输出与通知
output:
  format: "json"
  notify_channels: ["pagerduty", "slack"]
  ticket_update: true
  alert_resolve: true

常见误区： 很多团队在编写 Runbook 时只写了“执行步骤”，忽略了“前置检查”和“回滚方案”。在告警自愈场景中，没有前置检查的 Runbook 可能让系统雪上加霜（例如在磁盘已满时还去写日志）；没有回滚方案的 Runbook 是危险的——一旦修复失败，系统可能从“部分故障”变成“完全不可用”。

3.5 Runbook 在告警自愈中的角色定位

在完整的告警自愈流程中，Runbook 不是孤立存在的，它与告警系统、CMDB、自动化引擎、通知系统紧密协作。下图展示了 Runbook 在告警自愈闭环中的位置：

3.6 本章小结

Runbook 是告警自愈的“剧本”，定义了从告警触发到恢复验证的完整操作流程。
三大分类：故障类（核心）、变更类（辅助）、巡检类（预防），各有侧重。
标准化七段式结构：元数据 → 触发条件 → 前置检查 → 执行步骤 → 验证步骤 → 回滚方案 → 输出与通知，缺一不可。
关键原则：前置检查防止误操作，回滚方案兜底失败场景，验证步骤确保恢复有效。
自动化落地：Runbook 需要被自动化引擎解析执行，而非仅作为静态文档存在。