告警路由分级基础：什么是告警路由、为什么需要分级
在 On-Call 场景中，告警并非孤立事件，而是需要被准确传递到正确处理者的信息流。告警路由（Alert Routing）正是这一信息流的调度中枢。它根据预定义的规则，将告警事件从产生源定向到对应的处理团队、个人或自动化流程，并决定告警的呈现方式、通知渠道与响应优先级。
2.1 什么是告警路由
告警路由本质上是一套条件 → 动作的映射规则。当监控系统产生一条告警时，路由引擎会提取告警中的关键属性（如服务名、严重级别、标签、告警名称），与路由表中的规则进行匹配，最终执行对应的路由动作。
核心路由动作包括：
- 分配：将告警指派给特定的 On-Call 轮转组或个人。
- 通知：通过 PagerDuty、钉钉、Slack、短信等渠道发送告警。
- 升级：若在规定时间内未确认，自动升级到更高层级。
- 抑制/降噪：对重复或已知的告警进行聚合、静默或丢弃。
- 触发自动化：调用 Webhook 执行自愈脚本或创建 Jira 工单。
一个典型的告警路由流程如下图所示：
2.2 为什么需要分级
在未分级的扁平化路由模式下，所有告警被一视同仁地发送给所有 On-Call 人员，导致以下典型问题：
| 问题 | 表现 | 后果 |
|---|---|---|
| 告警风暴 | 单次故障触发数百条关联告警，全部涌入通知渠道 | 关键告警被淹没，响应延迟 |
| 认知过载 | On-Call 人员同时收到不同级别的告警，无法区分优先级 | 决策疲劳，误判或忽略真正紧急的事件 |
| 资源错配 | 低级告警占用高级 SRE 的注意力 | 人力浪费，高级工程师无法聚焦架构级问题 |
| 通知疲劳 | 频繁的低价值通知导致“告警麻木” | 重要告警被习惯性忽略或延迟确认 |
告警路由分级正是为了解决上述问题而设计的架构模式。它将告警按照严重程度、影响范围、业务重要性等维度划分为多个等级，并为每个等级定义差异化的路由策略。
2.3 分级路由的核心价值
分级路由的四大收益：
- 精准触达：P0 告警直达值班组长手机，P3 告警仅写入工单系统。
- 降噪聚合：同类告警合并为一条事件，减少重复通知。
- 自动升级：超时未响应的告警自动提升等级，确保不遗漏。
- 成本优化：高成本通知渠道（短信、电话）仅用于最高优先级。
下图展示了分级路由与扁平路由的对比效果：
2.4 分级路由的典型层级模型
业界通用的告警分级模型通常包含 4～5 个等级，每个等级对应不同的响应 SLA 和路由策略：
| 等级 | 定义 | 响应 SLA | 通知方式 | 路由目标 |
|---|---|---|---|---|
| P0 | 核心服务完全不可用，影响全部用户 | 5 分钟确认，15 分钟恢复 | 电话 + 短信 + PagerDuty | 值班组长 → Tech Lead |
| P1 | 核心功能受损，影响部分用户 | 15 分钟确认，1 小时恢复 | PagerDuty + 钉钉 | On-Call SRE |
| P2 | 非核心功能异常，有临时规避方案 | 1 小时确认，4 小时恢复 | 钉钉 + 邮件 | 对应服务开发团队 |
| P3 | 轻微异常，不影响用户体验 | 24 小时内处理 | 邮件 + 工单 | 工单系统 / 技术债务池 |
| P4 | 信息性告警，无需人工介入 | 无 SLA | 仅记录日志 | 自动归档 / 趋势分析 |
⚠️ 常见误区：不要将所有告警都定义为 P0 或 P1。过度提升告警等级会导致“狼来了”效应，反而降低真正紧急事件的响应效率。建议遵循“能降则降，能合则合”的原则，让 P0/P1 告警数量控制在总告警量的 5% 以内。
2.5 分级路由的决策要素
设计分级路由时，需要综合考虑以下要素：
- 业务影响度：该告警影响的用户量、交易量、收入损失。
- 故障传播速度：是瞬时故障还是缓慢恶化。
- 可恢复性：是否有自动化自愈能力，是否需要人工介入。
- 时间敏感度：是否在业务高峰期，是否影响合规审计。
- 依赖链：该告警是否由上游故障引发，是否需要先处理根因。