3. 触发机制基础：触发机制的定义、触发源类型与触发条件模型

触发机制是 Runbook 自动化执行的“起搏器”。没有明确的触发定义，变更窗口的 Runbook 要么永远不执行，要么在错误的时间点被错误地调用。本章从定义、触发源分类和条件模型三个层次，建立触发机制的理论基础。

3.1 触发机制的定义

在事故响应与变更管理体系中，触发机制是指一个可被观测的事件或条件组合，它启动 Runbook 执行流程的入口动作。触发机制包含三个核心要素：

3.2 触发源类型

根据信号产生的方式，触发源分为三大类：手动触发、自动触发和事件驱动触发。三类触发源在变更窗口 Runbook 中各有适用场景。

3.2.1 手动触发

由运维人员或审批者通过 UI 界面、命令行或 API 调用显式启动 Runbook。适用于需要人工判断的变更场景，如紧急回滚决策。

• UI 按钮触发：变更窗口控制台中的“执行回滚”、“开始灰度”等操作按钮。
• CLI 命令触发：通过 runbook-cli execute --id rollback-v1.2 等命令启动。
• API 调用触发：第三方系统通过 REST/gRPC 接口调用 Runbook 执行端点。

3.2.2 自动触发

由系统内部定时器或状态机自动发起，无需人工介入。适用于计划性变更和周期性健康检查。

• 定时触发：基于 Cron 表达式或固定时间窗口启动，如“每周二凌晨 2:00 执行数据库索引重建”。
• 状态触发：当系统进入特定状态（如“部署完成”、“金丝雀通过”）时自动启动后续 Runbook。

3.2.3 事件驱动触发

由外部系统或基础设施产生的事件流触发，是事故响应中最常见的触发源类型。

• 监控告警事件：Prometheus Alertmanager、Datadog 等发出的告警通知。
• 日志事件：特定错误日志模式匹配（如 OOM、panic）。
• Webhook 事件：Git 提交、CI/CD 流水线完成、PagerDuty 确认等外部回调。
• 消息队列事件：Kafka/RabbitMQ 中的特定主题消息。

3.3 触发条件模型

触发条件模型定义了“什么情况下触发源信号才真正启动 Runbook”。一个健壮的触发条件模型可以大幅减少误触发和漏触发。常见的触发条件模型包括以下四种：

3.3.1 阈值模型

当监控指标超过或低于某个数值阈值时触发。适用于资源类指标（CPU、内存、错误率）。

# 阈值模型示例：错误率触发回滚
trigger:
  source: prometheus
  condition:
    metric: http_requests_error_rate
    operator: ">"
    threshold: 5.0
    duration: 120s        # 持续 2 分钟
  action: runbook_rollback

3.3.2 复合条件模型

多个条件通过逻辑运算符（AND/OR/NOT）组合，提高触发准确性。

# 复合条件模型：错误率升高且流量异常
trigger:
  source: event_bus
  condition:
    and:
      - metric: error_rate
        operator: ">"
        threshold: 3.0
      - metric: request_latency_p99
        operator: ">"
        threshold: 2000
  action: runbook_auto_recovery

3.3.3 时间窗口模型

仅在特定时间窗口内评估触发条件，避免非工作时段误触发。

• 变更窗口内触发：仅在变更窗口开启期间（如 22:00-06:00）允许自动回滚触发。
• 冷却期：同一 Runbook 触发后，在冷却期内（如 5 分钟）不再响应相同事件。

3.3.4 状态依赖模型

触发条件依赖系统当前状态或 Runbook 执行上下文。

• 阶段依赖：仅在“灰度阶段”或“全量发布阶段”允许特定触发。
• 锁依赖：当变更窗口持有分布式锁时，才允许触发回滚 Runbook。

3.4 触发机制设计要点总结