4. Runbook 基础：传统 Runbook vs 自动化 Runbook、Runbook 生命周期

Runbook 是 SRE 团队应对已知故障或例行运维操作的标准操作文档。在可观测性体系下，Runbook 从“静态文档”进化为“自动化执行引擎”。本章从定义、对比和生命周期三个维度，建立 Runbook 的基础认知。

4.1 传统 Runbook 与自动化 Runbook 的对比

传统 Runbook 以人工执行为核心，自动化 Runbook 以事件驱动和工具编排为核心。下表从六个关键维度进行对比：

4.2 Runbook 生命周期模型

一个完整的 Runbook 生命周期包含五个阶段。下图展示了从设计到退役的闭环流程：

4.3 生命周期各阶段详解

4.3.1 设计阶段

设计阶段的核心产出是 Runbook 定义文档，包含以下要素：

• 触发事件：明确哪些 OpenTelemetry 事件（如 http.status_code = 500 持续 5 分钟）会激活该 Runbook。
• 前置条件：执行前必须满足的环境状态（如集群未处于维护模式）。
• 执行步骤：原子操作序列，每个步骤需定义成功/失败标准。
• 回滚计划：当执行失败或产生副作用时的恢复路径。

4.3.2 编码阶段

采用 Runbook as Code 原则，将 Runbook 编写为版本控制的代码文件。推荐使用 YAML 或 HCL 描述步骤，配合 Python/Go 实现具体逻辑。

# runbook_high_cpu.yaml 示例
apiVersion: runbook.io/v1
kind: Runbook
metadata:
  name: high-cpu-auto-remediation
spec:
  trigger:
    eventType: "otel.metric.host.cpu.utilization"
    condition: "value > 0.90 for 5m"
  steps:
    - name: "identify_top_process"
      action: "exec"
      command: "ps aux --sort=-%cpu | head -5"
      outputVar: "top_processes"
    - name: "restart_service"
      action: "k8s"
      resource: "deployment"
      operation: "rollout restart"
      selector: "app={{ top_processes.app_name }}"
  rollback:
    - name: "scale_up_replicas"
      action: "k8s"
      resource: "deployment"
      operation: "scale"
      replicas: 3

4.3.3 测试阶段

自动化 Runbook 必须经过严格测试才能投入生产。测试策略包括：

• 单元测试：验证每个步骤的输入输出逻辑。
• 集成测试：在沙箱环境中模拟事件触发，验证全流程执行。
• 混沌测试：注入故障（如网络延迟、节点宕机），验证 Runbook 的容错能力。

4.3.4 运行阶段

运行阶段是 Runbook 的核心价值体现。自动化引擎监听 OpenTelemetry Collector 发出的告警事件，匹配 Runbook 触发条件后自动执行。执行过程中的关键数据点：

4.3.5 退役阶段

当以下情况发生时，Runbook 应进入退役流程：

• 对应的故障模式已通过架构优化彻底消除（如服务已迁移至无状态架构）。
• 有更优的自动化方案替代现有 Runbook。
• Runbook 长期未触发且维护成本过高。

退役操作包括：从事件触发引擎中移除绑定、归档代码仓库、更新相关告警规则中的 Runbook 链接。

4.4 传统 vs 自动化：一个故障场景的对比

以“数据库连接池耗尽”为例，对比两种 Runbook 的执行路径：