📚 课程目录第3章 Runbook核心原理

3. Runbook 核心原理：自动化剧本的定义、触发方式与生命周期

Runbook（自动化剧本）是云原生运维中“可执行的文档”。它将标准操作流程（SOP）转化为机器可读、可触发、可审计的自动化步骤。在《Policy Check 多环境规则与 Runbook 联动部署》体系中，Runbook 是策略的最终执行者——当 Policy Check 判定某环境违规时，Runbook 负责自动修复、回滚或通知。

3.1 什么是 Runbook：从文档到代码的演进

传统 Runbook 是运维人员手边的操作手册，记录“如何重启服务”“如何扩容”等步骤。现代 Runbook 则是一段可执行的代码或工作流，具备以下核心特征：

维度	传统 Runbook（文档）	现代 Runbook（代码/工作流）
载体	Wiki、PDF、Confluence 页面	YAML、Python、Go、Terraform、Ansible Playbook
执行方式	人工阅读、手动敲命令	自动触发、CI/CD Pipeline、ChatOps
可测试性	无	单元测试、集成测试、Dry-Run 模式
版本控制	无或手动	Git 仓库、PR 审查、标签发布
审计追溯	依赖人工日志	结构化日志、执行记录、回放能力

  关键认知： 在 Policy Check 联动场景中，Runbook 是“策略的响应者”。例如：policy: 禁止公网暴露 3306 端口 → runbook: 自动移除安全组规则 + 发送告警到 Slack。

3.2 Runbook 的触发方式

Runbook 的触发方式决定了自动化响应的时效性与覆盖范围。根据触发源的不同，可分为以下四类：

事件驱动（Event-Driven）：监听云平台事件、监控告警、Webhook 回调。例如：AWS CloudWatch Alarm 触发 Lambda 执行 Runbook。
策略驱动（Policy-Driven）：Policy Check 引擎在扫描到违规后，直接调用 Runbook API。这是本课程的核心联动模式。
定时驱动（Schedule-Driven）：Cron 表达式或周期任务，用于定期巡检、数据清理、证书续期。
人工驱动（Manual-Driven）：通过 ChatOps 命令（/runbook restart-service）或运维平台按钮触发，保留人工审批环节。

最佳实践： 生产环境建议采用“策略驱动 + 人工审批”的混合模式。Policy Check 自动触发 Runbook 执行 Dry-Run，生成变更预览，等待 SRE 确认后执行实际变更。

3.3 Runbook 的生命周期

一个 Runbook 从创建到退役，经历完整的生命周期管理。每个阶段都与 Policy Check 规则库有明确的交互点：

阶段	关键活动	与 Policy Check 联动点
1. 设计	定义触发条件、执行步骤、回滚策略	确定 Runbook 对应的 Policy ID 与违规等级
2. 开发	编写代码、配置 YAML、单元测试	在 Runbook 中嵌入 Policy Check 的 API 调用
3. 测试	Dry-Run 模式、沙箱环境验证	使用 Policy Check 的模拟违规数据触发 Runbook
4. 发布	Git Tag、CI/CD 部署到生产环境	同步更新 Policy Check 的 Runbook 绑定表
5. 运行	监听触发、执行步骤、记录日志	实时接收 Policy Check 的违规事件流
6. 审计	执行记录查询、失败分析、合规报告	将执行结果回写 Policy Check 的审计数据库
7. 退役	废弃旧 Runbook、迁移到新版本	从 Policy Check 的绑定表中移除关联

常见陷阱： Runbook 的“测试阶段”容易被跳过。没有经过 Dry-Run 验证的 Runbook 在生产环境中可能造成配置漂移或服务中断。建议在 Policy Check 规则中增加一条：runbook_version >= 1.2.0 且 test_status == passed 才允许自动执行。

3.4 Runbook 的典型结构

一个标准化的 Runbook 通常包含以下字段。以下是一个与 Policy Check 联动的 Runbook 示例：

# runbook-restrict-public-3306.yaml
apiVersion: runbook.ops/v1
kind: Runbook
metadata:
  name: restrict-public-3306
  version: 1.2.0
spec:
  # 绑定 Policy Check 规则
  policyBinding:
    policyId: "POLICY-NET-001"
    severity: critical
    environment: ["prod", "staging"]

  # 触发条件
  trigger:
    type: policy-driven
    webhook: "https://policy-check.internal/v1/events"

  # 执行步骤
  steps:
    - name: validate_current_state
      action: api_call
      endpoint: "https://cloud-api/describe-security-groups"
      timeout: 10s

    - name: remove_public_rule
      action: api_call
      endpoint: "https://cloud-api/revoke-ingress"
      params:
        port: 3306
        protocol: tcp
        cidr: "0.0.0.0/0"
      dryRun: true

    - name: notify_sre
      action: slack_message
      channel: "#ops-alerts"
      message: "已移除公网 3306 规则，变更 ID: {{ .ChangeID }}"

  # 回滚策略
  rollback:
    enabled: true
    action: restore_security_group
    timeout: 30s

  # 审计配置
  audit:
    logDriver: elasticsearch
    retentionDays: 90

3.5 Runbook 与 Policy Check 的联动契约

为了实现可靠的自动化联动，Runbook 与 Policy Check 之间需要定义清晰的接口契约：

输入契约：Policy Check 向 Runbook 传递的上下文，包括违规资源 ID、违规详情、环境标签、时间戳。
输出契约：Runbook 执行完成后返回的状态码、变更摘要、回滚标识。
幂等性：同一个违规事件多次触发 Runbook，执行结果必须一致，不会产生副作用。
超时与熔断：Runbook 执行超过阈值时，Policy Check 应触发熔断并升级告警。

  实战要点： 在 Runbook 的 spec.policyBinding 中，建议使用 severity 字段控制自动执行的范围。例如：critical 级别自动执行，warning 级别仅通知，info 级别仅记录日志。这可以避免低风险违规触发不必要的变更。