告警分级与告警疲劳治理：On-call 与 SRE 实践

告警系统的终极悖论是：告警太多 = 没有告警。当值班人员每小时收到几十条通知、其中九成无需处理时，大脑会习惯性忽略所有提醒——真正的事故发生时反而没人及时响应。Google 的 SRE 理念强调，On-call 的首要目标是"让每一次被叫醒都值得"。这需要从告警分级、通知降噪和值班机制三个层面同时下手。

告警分级：不是所有问题都值得被叫醒

先把"需要人行动"和"只需看一眼"分开。常见的四级模型：

级别	定义	通知方式	响应时限
P0	核心业务不可用，用户流失	电话 + 短信 + 邮件	立即
P1	主要功能受损，有变通方案	短信 + IM	15 分钟
P2	局部问题，无用户影响	IM + 邮件	工作时段
P3	告警、日志类，仅记录	看板/日报	无需即时

判断标准不是"指标是否异常"，而是**"如果不处理，用户会怎样"**。指标层面的噪音，应在告警规则层就过滤掉（见 Prometheus 告警规则设计），而不是把噪音全部推到值班人手机上。

一次"告警风暴"的真实代价

2025 年一家中型电商公司做过复盘：大促预热当天凌晨，支付网关因为上游银行接口超时，40 分钟内触发了 3200 条告警，值班群被刷屏，真正的根因告警被淹没，核心团队被全员拉进群却找不到负责人。事后分析发现：半数告警来自同一根因的重复实例，20% 是早已存在的基线噪音，真正需要人工处理的只有 8 条。如果当时配置了分组与升级，这 8 条会汇聚成一条，且只推送给支付组值班人。这个案例说明，告警治理的收益不是"少收几条消息"，而是事故发生时有人立刻行动。

通知降噪：分组、路由与升级

即使分级合理，偶发的大量告警仍会淹没关键信息。降噪三板斧：

分组与聚合：把同一根因的告警合并成一条（Alertmanager 的分组、抑制、静默都是为此而生）。
路由到正确的接收者：不同团队、不同严重级走不同渠道，让每个告警只打扰"该负责的人"。
升级策略：没人确认就自动升级——如 5 分钟未确认升一级、15 分钟未处理升级到上级，既保证兜底，又避免全员轰炸。

以 Prometheus + Alertmanager 为例，一份可落地的降噪配置大致长这样：

route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers: ['severity="page"']
      receiver: oncall-phone
    - matchers: ['severity="ticket"']
      receiver: ticket-queue
      continue: false

group_by 把同一根因的实例合并成一条；group_wait 防止短促抖动引发连发；repeat_interval 控制同一告警的重复频率，避免"每小时轰炸一次"。这套配置配合夜间值班，能让手机只在真正需要处理的时候响起。

On-call 值班机制：让被叫醒的人能处理

告警分级做得再好，如果值班人收到告警却不知如何应对，疲劳感依然存在。SRE 实践给值班设计了完整闭环：

值班日历与轮换：明确"谁值班、值班周期、如何交接"，避免同一人长期值守。
Runbook 手册：每个高频告警对应一份操作手册——先看哪个面板、跑什么命令、通常根因是什么，把"第一次处理"变成"照单操作"。
事后复盘：每次真事故做 postmortem，区分"人因"与"系统缺陷"，把可改进的流程沉淀成新的 runbook 或规则。

一份高质量 runbook 通常包含五个要素：影响范围、诊断步骤、处置命令、回滚方案，以及"何时该升级"。把这五点写清楚，往往能把平均恢复时间缩短一半以上。

用数据衡量值班健康度

告警治理的效果可以用几个指标持续观察：每班告警量（应持续下降）、页面率（真正需要即时响应的比例，目标 10%-20%）、误报率（处理后确认"无需行动"的告警占比）、以及 MTTA/MTTR（响应与恢复时间）。如果误报率长期偏高，说明告警规则需要收紧；如果页面率过低，说明很多"页面级"告警其实应该降级为工单级。每周花 30 分钟过一遍这些数据，比反复"感觉告警变少了"靠谱得多。

16IDC 观察

对小团队而言，On-call 不必像大厂那样重，但两个原则通用：一是告警必须有明确的下一步动作，没有动作的告警直接删除；二是让"值班"成为轮换制，哪怕只是三个人轮班，也能显著降低个体疲劳。值班范围与工具可参考监控报警指南与 Uptime Kuma 部署；事故复盘模板见事故复盘模板；告警是否与业务目标一致，用 SLO/SLI 与错误预算来校准；规则编写与看板搭建可参考 Prometheus 与 Grafana 入门。更多内容请查看监控报警分类。

参考：Google SRE 手册《Being On-Call》https://sre.google/sre-book/being-on-call/；《On-Call Rotations: How Best to Awaken Engineers》https://sre.google/sre-book/oncall/

告警分级与告警疲劳治理：On-call 与 SRE 实践