2. 事件触发机制：监控告警体系基础、事件生命周期与分类优先级
事件触发是值班机器人联动 Runbook 的起点。没有可靠的事件触发机制，后续的告警、响应与恢复流程将失去依据。本章从监控告警体系的基础出发，梳理事件从产生到关闭的完整生命周期，并建立事件分类与优先级模型，为值班机器人提供明确的决策输入。
2.1 监控告警体系基础
监控告警体系是事件触发的数据源。一个完整的体系通常包含四个层次：
| 层次 | 职责 | 典型组件 |
|---|---|---|
| 数据采集层 | 从基础设施、应用、网络等源头收集指标、日志与链路数据 | Prometheus Node Exporter、Fluentd、OpenTelemetry Agent |
| 存储与计算层 | 时序存储、日志索引、聚合计算与异常检测 | Prometheus Server、Elasticsearch、Thanos |
| 告警规则层 | 定义触发条件、阈值、持续时间与聚合策略 | Prometheus Alerting Rules、Grafana Alerting |
| 通知路由层 | 将告警事件格式化、去重、抑制、分组后发送至值班机器人 | Alertmanager、PagerDuty、Opsgenie |
关键原则：告警事件必须携带足够的上下文标签（如 cluster、service、severity、region），值班机器人才能根据标签匹配对应的 Runbook。
2.2 事件生命周期
一个事件从产生到关闭，经历四个核心阶段：触发 → 告警 → 响应 → 恢复。每个阶段都有明确的输入、输出与状态转换。
阶段定义：“触发”是原始条件满足；“告警”是事件被通知到人；“响应”是有人认领并开始处理；“恢复”是系统状态回归正常且事件关闭。
事件在生命周期中的状态流转如下表所示：
| 阶段 | 事件状态 | 值班机器人动作 |
|---|---|---|
| 触发 | firing（未确认） | 接收事件，提取标签，匹配 Runbook ID |
| 告警 | alerting（已通知） | 发送告警卡片，附带 Runbook 链接与快捷认领按钮 |
| 响应 | acknowledged（已认领） | 锁定事件归属，推送 Runbook 步骤，启动诊断脚本 |
| 恢复 | resolved（已恢复） | 执行恢复验证，生成事件报告，解除值班人绑定 |
2.3 事件分类与优先级
不同事件对业务的影响差异巨大。值班机器人必须根据事件的分类与优先级决定响应策略：是立即触发 Runbook 自动恢复，还是仅通知值班人人工介入。
2.3.1 事件分类模型
按故障来源与影响范围，事件可分为以下五类：
- 基础设施类：主机宕机、磁盘满、网络分区、CPU 高负载。
- 应用服务类：接口 5xx 错误率飙升、P99 延迟超阈值、进程崩溃。
- 中间件/存储类：MySQL 主从延迟、Redis OOM、Kafka 消费堆积。
- 安全合规类：异常登录、敏感操作审计告警、DDoS 攻击。
- 业务指标类：订单成功率下降、支付超时、用户登录失败率升高。
2.3.2 优先级矩阵
优先级由 影响范围 与 紧急程度 两个维度共同决定：
| 影响范围 \ 紧急程度 | 高（持续恶化） | 中（稳定异常） | 低（偶发波动） |
|---|---|---|---|
| 全局（>50% 用户） | P0 立即响应 | P1 快速响应 | P2 正常响应 |
| 局部（10%-50% 用户） | P1 快速响应 | P2 正常响应 | P3 观察响应 |
| 单实例（<10% 用户） | P2 正常响应 | P3 观察响应 | P4 记录不告警 |
注意：P0 事件必须触发值班机器人 自动执行 Runbook，并在 1 分钟内无人认领时升级至第二值班人。P3/P4 事件仅记录日志或发送摘要，不触发即时通知。
2.3.3 事件分类与优先级在值班机器人中的映射
值班机器人通过事件标签中的 severity 和 class 字段自动决策：
# 事件示例（Prometheus Alertmanager 格式）
{
"labels": {
"alertname": "HighErrorRate",
"severity": "critical", # critical → P0, warning → P2, info → P4
"class": "application", # 映射到应用服务类 Runbook
"service": "order-api",
"region": "us-east-1"
},
"annotations": {
"summary": "Order API 5xx rate > 5% for 5 minutes",
"runbook_id": "rb-app-http-5xx"
}
}值班机器人接收到事件后，按以下逻辑处理：
- 解析
severity映射为优先级（critical→P0, warning→P2, info→P4）。 - 根据
class选择对应的 Runbook 分类目录。 - 根据
runbook_id加载具体的恢复步骤。 - 若优先级为 P0 且 Runbook 包含自动恢复步骤，则立即执行；否则仅推送通知。
2.4 事件触发与 Runbook 的绑定关系
事件触发后，值班机器人通过 标签匹配 与 规则引擎 找到对应的 Runbook。绑定关系在配置中心定义：
# 绑定规则示例（YAML 格式）
event_to_runbook_bindings:
- match_labels:
class: "infrastructure"
severity: "critical"
runbook_id: "rb-infra-host-down"
auto_execute: true
- match_labels:
class: "application"
severity: "warning"
runbook_id: "rb-app-latency"
auto_execute: false
- match_labels:
class: "security"
runbook_id: "rb-sec-anomaly"
auto_execute: false
notify_roles: ["security-team"]
最佳实践：每个 Runbook 在元数据中声明自己支持的事件分类与优先级范围。值班机器人在启动时加载所有绑定规则，构建内存中的匹配树，确保事件到达时 O(1) 级别找到对应 Runbook。
通过以上机制，事件触发不再是孤立的告警通知，而是与值班机器人、Runbook 联动恢复流程紧密耦合的自动化起点。下一层将深入值班机器人的内部架构与消息处理引擎。