分级解决什么
告警分级把通知强度和响应时效对应起来：级别越高，打扰越强、要求响应越快。它的目的是让值班同学的注意力与故障的实际影响匹配，避免所有告警都用同一种方式通知，最后导致所有告警都被忽略。
级别由用户影响决定
级别应由用户影响决定，而不是由技术原因决定：影响全站交易或资金链路的属于最高级，影响个别非核心功能的属于低级别，纯粹的观察项不进值班通道。按原因分级会把大量技术噪音推到最高级，反而掩盖真实故障。
分级要落到通道
分级只有在通知通路上体现才有意义：不同级别对应不同的通知渠道与升级策略，并且要在告警规则里把级别写成标签，由接收方按标签分流。如果所有级别都走同一个通道，分级就只是文档里的装饰。
基本信息
| 级别数量 | 通常三到四级，从最高到最低 |
|---|---|
| 承载方式 | 写在告警标签里，供路由与分组使用 |
| 响应要求 | 每级规定确认时限与处置时限 |
| 升级策略 | 超时未确认时逐级提升通知强度 |
| 划分依据 | 用户影响范围与业务重要性 |
典型使用场景
- 全站不可用：所有用户受影响，需要立即人工介入
- 核心功能受损：部分用户无法完成关键操作，需要快速响应
- 局部或非核心影响：影响有限，可以按计划处理
- 容量与趋势预警：尚未影响用户，但需要安排处理时间
- 观察项：只记录留痕，不进值班通道
- 演练与维护：按流程静默或走低优先级通道
用标签承载级别并分流
用标签承载级别并分流
# 告警规则里打上级别标签
labels:
severity: critical
# 接收端按级别分流
routes:
- matchers: [ 'severity="critical"' ]
receiver: page-oncall # 电话与短信
- matchers: [ 'severity="warning"' ]
receiver: ticket-queue # 工单或群消息分级参考
| 级别 | 判据 | 通知方式 | 响应时效 |
|---|---|---|---|
| 最高级 | 全站不可用或资金链路受损 | 电话加短信 | 立即确认 |
| 次高级 | 核心功能大范围受损 | 电话加即时消息 | 十五分钟内 |
| 一般级 | 非核心或局部影响 | 即时消息加工单 | 四小时内 |
| 观察级 | 趋势与观察项 | 日报或邮件 | 次工作日 |
分级要素
| 要素 | 作用 | 注意 |
|---|---|---|
| 判据 | 明确什么情况属于该级别 | 越具体越不容易自行发挥 |
| 通知方式 | 电话、即时消息、工单或日报 | 必须与判据一一对应 |
| 响应时效 | 确认与处置的时限 | 写进值班制度并定期复盘 |
| 升级策略 | 超时之后的处理 | 避免告警被长期搁置 |
分级落地的约定
- 级别越高，规则数量应越少，才能保住注意力
- 同一故障只产生一条最高级别的通知
- 定期复盘分级是否合理，剔除长期无人处理的项
- 级别调整走评审，避免被随手调高
分级是运维与研发之间的约定：只有双方都认可判据与时效，值班响应才可能稳定，否则每次故障都要重新争论该不该半夜叫人。
所有告警都走电话等于没有分级：低级别噪音挤占注意力，真正紧急的告警反而被忽略。
定期复查的内容
- 过去一个月有哪些级别被频繁触发，判据是否需要收紧
- 是否存在长期无人处理的高级别告警，说明判据或处置流程有问题
- 升级策略是否被真正执行，超时未确认的告警去向是否明确