什么是告警疲劳？如何治理？
简化版
告警疲劳是大量低价值、重复或不可行动的通知消耗值班注意力，最终让真正事故被忽略。治理核心是只让需要立即人工动作且影响用户的信号叫醒人，其余进入工单、看板或自动化处理。
详细版
盘点每条告警的 owner、用户影响、动作、准确率和历史处置，删除无 owner/无动作告警；按根因或服务聚合，设置抑制、去重、维护窗口和恢复通知。优先使用 SLO 多窗口燃烧率，而非瞬时资源阈值。
衡量 pages/shift、唯一事故数、确认时间、误报率、无动作率和重复率；每次事故后更新阈值与 Runbook。不能通过无限延长窗口掩盖故障，也不能让告警依赖本身单点失效。
完整版教学
一、疲劳如何伤害可靠性
值班者每晚收到 100 条通知，其中 95 条无需操作，会形成条件反射式静音。真正严重告警到来时，响应时间反而更长；因此告警数量不是覆盖度，注意力才是稀缺资源。
记忆钩子：每一条 Page 都必须回答“谁现在要做什么，不做会怎样”。
二、告警分级
| 等级 | 条件 | 通道 |
|---|---|---|
| Page | 正在影响用户、需立即动作 | 电话/值班 |
| Ticket | 可延后但需处理 | 工单 |
| Info | 趋势与上下文 | 看板/日报 |
| Automation | 有确定修复 | 自动执行+审计 |
CPU 80% 若没有用户影响和动作，通常不应直接 Page。
三、SLO 燃烧率
burn_rate = observed_error_rate / allowed_error_rate99.9% SLO 的允许错误率为 0.1%；观察到 1% 错误时燃烧率为 10。短窗口高燃烧抓急性事故，长窗口持续燃烧抓慢性问题，两者组合降低噪声。
四、去重、分组与抑制
同一数据库故障可能让 50 个服务报警，应按依赖与时间聚合，优先通知根告警，并抑制已知下游症状。抑制必须有时限，防止根告警恢复后症状仍被永久隐藏。
告警指纹使用稳定服务、规则和故障域，不把 podId 等易变值纳入，否则无法聚合。
五、阈值与窗口
瞬时尖峰可通过持续时间、样本量和基线过滤；周期业务适合同比或动态阈值。但动态算法同样要解释，不能把模型异常当成绝对事实。
维护窗口来自变更系统自动创建并到期，只屏蔽预期信号；安全和数据丢失类告警不应随意静音。
六、闭环指标
记录告警是否对应真实事故、是否采取动作、耗时和最终根因。若一条规则 30 天触发 40 次却从未行动，应删除、降级或重写。
Runbook 必须包含验证、止血、升级和回滚；值班复盘关注系统设计，不以惩罚个人为目的。
轮值设计要限制连续夜间负担并提供交接，长期睡眠中断本身会降低判断质量，不能只靠个人硬扛。
通知平台故障应有独立心跳与备用通道，否则“没有告警”可能只是告警系统不可用。
规则变更先在静默评估模式回放历史数据，比较预期触发与真实事故后再启用 Page。
七、常见误区与追问
- 误区：告警越多覆盖越全面。 噪声会降低真正事故响应率。
- 误区：提高阈值即可消除疲劳。 可能同时增加漏报。
- 误区：所有异常都应电话通知。 不需要立即动作的应分流。
- 误区：有 Runbook 就代表可行动。 内容必须验证且与权限匹配。
- 追问：如何量化误报？ 记录是否存在用户影响和是否采取有效动作。
- 追问：依赖故障如何防告警风暴？ 根因分组、拓扑抑制和事件关联。
- 追问：谁负责删除告警？ 规则 owner 定期评审，平台提供数据与治理门禁。
八、加强记忆
告警治理按“用户影响—立即动作—唯一 owner—聚合抑制—SLO 窗口—事后反馈”闭环。Page 保护人的注意力，Ticket 承接可延后工作，Info 留趋势；用真实事故与处置数据持续淘汰无价值规则，而不是简单调高阈值。