告警疲劳怎么破：炬鲸 OBSERVE 的分级告警、抑制与值班轮转

告警为什么让人疲劳

告警系统最常见的失败，不是不响，而是响得太多。CPU 瞬时抖动、一条能自动恢复的网络超时，都可能触发告警，把人从睡梦中叫醒。久而久之，值班的人开始对告警麻木，先静音通知，再静音整个系统，真正的事故反而被淹没在海量通知里。

要解决告警疲劳，关键是让每一条告警都「可行动」：收到它，值班的人知道该做什么，而不是猜它是不是误报。

分级：把告警分成三个等级

炬鲸 OBSERVE 内置三级告警：

• P0 严重：直接影响可用性，例如错误率超过 5%、核心接口 P99 延迟翻倍。P0 走电话 + 短信 + 企业微信全渠道。
• P1 警告：有劣化趋势，例如磁盘使用率超过 85%。走企业微信 + 邮件。
• P2 提示：信息类，例如一次夜间定时任务的慢日志。只进控制台，不主动打扰。

阈值告警的配置示例：

alert:
  name: order-service-error-rate
  level: P0
  metric: http_error_rate
  condition: '> 0.05'
  duration: 5m
  notify: [phone, sms, wecom]

duration: 5m 很关键：指标要连续 5 分钟超标才触发，避免瞬时抖动误报。

举一个真实例子：某电商团队给下单接口配了 P0、阈值 5%、持续 5 分钟。凌晨两点一波支付回调重试让错误率瞬时冲到 6%，但 3 分钟后回落，duration: 5m 让这次波动没有触发告警；真正触发的是第二天上午错误率稳定在 8% 的那次，值班同事第一时间介入，避免了白天演变成客诉。

抑制与静默：让噪音闭嘴

两个机制能挡掉大部分噪音：

1. 告警抑制：当一个服务宕机时，它下游依赖的几十条告警都会被抑制，只保留根因那一条。避免「一个故障、一百条通知」。
2. 静默窗口：为计划内的维护、发版设置静默时段。窗口内的告警自动降级为 P2，一次发布不该把全组人都叫醒。

值班轮转与升级

• 排班：按周排班、自动轮转，值班表对全员可见。
• 升级：P0 告警 10 分钟内无人确认，自动升级给二级负责人，避免漏接。
• 回执：值班人确认或解决后告警关闭，形成闭环。

从告警到恢复的闭环

一条合格的告警，不只是「响」，还要能带着人走到恢复。炬鲸 OBSERVE 把告警和上下文绑在一起：每条告警都带上触发时的指标曲线、关联的错误日志、以及同时间段的 trace 列表。值班人点开告警，不用再切三个页面找线索。

配合告警确认、转派、评论和解决状态，一次故障从发现到关闭全程留痕。复盘时可以直接按告警维度回看：这次事故总共触发了几条告警、每条多久被响应、最终根因是什么。

落地建议

1. 先给核心服务配置 P0，跑一周，观察误报率。
2. 把告警数量本身当成指标监控：健康团队的告警/故障比通常在 5:1 到 10:1，过高说明规则太敏感。
3. 定期复盘告警，把「没人处理的告警」要么删掉、要么降级。

告警的目标不是「每条都响」，而是「响的每条都值得看」。