告警疲劳是什么
告警疲劳是长期信噪比恶化后的组织表现：值班人对通知麻木、静默变成日常操作、故障由用户先发现而不是监控先发现。代价是实打实的——发现时间被拉长，关键告警混在噪声里被忽略。治理顺序很关键：先删无效告警，再修阈值与观察窗口，最后才谈分组与抑制；只优化通知样式而数量不减，疲劳很快会回到原样。
基本信息
| 归属 | 告警治理与值班体验 |
|---|---|
| 典型信号 | 静默频率上升、值班换班增多、用户先发现故障 |
| 治理顺序 | 删除无效、修阈值与窗口、再做分组与抑制 |
| 度量口径 | 收到但未动手的比例、每班告警条数 |
| 权限要求 | 规则与值班配置的修改权限 |
疲劳自查信号
- 近一月「收到但没有动手」的告警占比超过两成
- 手动静默每周都会出现，且集中在固定几条规则上
- 值班换班与代班请求明显增多
- 出现过故障由用户反馈先发现、监控后知后觉
- 复盘会上反复讨论某条告警要不要留，却始终没有结论
治理顺序
- 第一步删：没有对应动作、没有预案可写的规则直接下线或降级
- 第二步修：阈值贴边的调整窗口与 for 时长，减少抖动误报
- 第三步合：同一根因的多条告警用分组与抑制合并
- 第四步评：把「值班页面的准入标准」写进团队规范并定期评审
- 第五步量：持续记录每班告警条数与确认率，用数据验证治理效果
疲劳自查
疲劳自查
[ ] 近一月「收到但没动手」的告警占比 > 20%
[ ] 手动静默每周出现，且集中在少数规则
[ ] 值班换班或代班请求增多
[ ] 有过故障由用户反馈先发现
# 取样方法：导出近 90 天触发次数排行，逐条问「触发时该做什么」
# 答不上来的规则，就是候选删除对象手段与误区
| 手段 | 直接效果 | 常见误区 |
|---|---|---|
| 删除无效告警 | 数量下降最明显 | 只看触发次数，误删保命规则 |
| 修阈值与窗口 | 减少抖动误报 | 阈值一味放宽，漏掉真实故障 |
| 分组与抑制 | 合并同根因告警 | 抑制范围过宽造成盲区 |
| 优化通知样式 | 可读性提升 | 数量不减，疲劳很快回来 |
疲劳的本质是信噪比问题：长期不治理会直接抬高发现时间，最终表现为用户比监控更早发现故障。