3. 告警触发链路总览：从告警产生到自愈动作执行

告警自愈触发链路是 Runbook 自动化体系的核心骨架。一条告警从产生到最终执行自愈动作，需要经过 采集 → 判定 → 路由 → 匹配 → 执行 → 反馈 六个阶段。本章从全局视角拆解完整链路，明确每个环节的职责边界与数据流转。

3.1 完整链路六阶段模型

下图展示了告警自愈触发链路的全貌，包含核心节点与阶段划分：

3.2 各环节职责划分

每个阶段都有明确的输入、处理逻辑和输出。下表详细拆解六阶段职责：

阶段	输入	核心处理	输出	典型组件
① 告警采集	监控指标 / 日志 / 事件	数据聚合、去重、格式化	标准化告警事件	Prometheus / Zabbix / 日志平台
② 告警判定	标准化告警事件	阈值判断、抑制、静默	有效告警 / 已抑制告警	Alertmanager / 告警规则引擎
③ 告警路由	有效告警	标签路由、租户隔离、优先级队列	路由后的告警上下文	事件总线 / 消息队列
④ Runbook 匹配	告警上下文	规则匹配、参数绑定、版本选择	可执行 Runbook 实例	Runbook 引擎 / 规则库
⑤ 自愈执行	Runbook 实例	脚本执行、API 调用、重试、回滚	执行结果 / 状态	Ansible / 自定义 Runner
⑥ 结果反馈	执行结果	成功确认 / 失败升级 / 告警关闭	反馈事件 / 升级工单	告警平台回调 / 工单系统

3.3 链路中的关键数据流

告警在链路中流转时，携带的上下文信息会逐步丰富。以下是各阶段传递的核心数据字段：

• 告警采集阶段：alert_name、severity、instance、metric_value、timestamp
• 告警判定阶段：追加 status（firing/resolved）、silenced_by、inhibited_by
• 告警路由阶段：追加 route_label、tenant_id、priority
• Runbook 匹配阶段：追加 runbook_id、params、timeout
• 自愈执行阶段：追加 execution_id、retry_count、log_url
• 结果反馈阶段：追加 result（success/failure）、recovery_alert_id、escalation_ticket

3.4 链路中的关键决策点

在完整链路中，有三个决策点直接影响自愈成功率与安全性：

1. 告警抑制决策（阶段②）：当同一故障引发多条关联告警时，抑制非根因告警，避免 Runbook 重复执行。
2. Runbook 匹配决策（阶段④）：支持精确匹配（告警名称 + 标签）和模糊匹配（正则 / 通配符），需定义匹配优先级。
3. 自愈执行决策（阶段⑤）：执行前检查“自愈锁”（如主机是否已被其他 Runbook 锁定），防止并发冲突。

3.5 链路超时与降级策略

为保证链路稳定性，每个阶段都应设置超时与降级兜底：

阶段	推荐超时	超时后行为	降级策略
告警采集	5s	丢弃该条告警，记录日志	降级为手动处理
告警判定	3s	默认通过（放行告警）	跳过抑制逻辑
告警路由	2s	投递到默认队列	使用 last-known 路由规则
Runbook 匹配	3s	不执行自愈，仅通知	匹配默认兜底 Runbook
自愈执行	按 Runbook 定义	标记失败，触发升级	执行回滚脚本
结果反馈	5s	重试 3 次，仍失败则写本地队列	异步补偿

3.6 链路可观测性设计

每条告警在链路中的流转都应可追踪。建议在以下节点埋点：

• 阶段入口埋点：记录告警 ID、进入时间、阶段名称
• 阶段出口埋点：记录离开时间、处理结果、耗时
• 异常埋点：记录超时、匹配失败、执行异常的具体原因

3.7 链路职责边界总结

下图以分层视角展示各环节的归属边界，帮助团队划分系统模块：

分层架构明确了各系统的职责边界：

• 监控与告警平台层：负责告警的采集、判定和路由，输出标准化告警事件。
• 事件总线层：解耦告警平台与 Runbook 引擎，提供削峰填谷和异步投递能力。
• Runbook 引擎层：负责 Runbook 匹配、自愈执行和结果反馈，是自动化动作的执行主体。