告警降噪 vs 别漏报：狼来了 90% 之后，你们是压误报，还是赌那一次 P0 不丢？

【背景】 我 10 年 SRE，值班排班表上最真实的一行数据：我们一套核心链路，Prometheus 告警规则 480 条，一周告警 1200+ 条，其中「真需要人看」的不到 100 条。也就是说值班同学每天要翻过 100 多条狼，才能抓到 1–2 条真狼。

去年一次 P1，根因是块存储慢盘（IO 延迟从 2ms 爬到 80ms），但那条慢盘告警被淹在 30 条 GC 告警和 12 条连接池 pending 告警之间，值班同学当「老毛病」直接 ack 了——复盘时这句话最扎心：不是没报，是报了也没人信。

从那之后我一直在纠结一个问题：告警降噪，到底是在「降噪」，还是在「埋雷」？

【常见分歧 / 三种做法】 我见过三种流派：

1. 降噪派：误报率必须压到 <5%，能关的规则全关，能用 error-based 的绝不用阈值。口号是「告警必须 100% 可行动」。代价：他们曾漏过一次 P0，因为那条告警「理论上不该发」。
2. 保漏派：宁可误报到值班同学麻木，也不能漏一次 P0。核心路径 60 多条「宁滥勿缺」的告警。代价：狼来了 100 次之后，第 101 次真狼没人信。
3. 分级派：P0 走电话 + 值班群，P1 走 IM，P2 只进大盘，把「该不该叫醒人」和「该不该记录」分开。

【我的倾向与理由】 我站分级派，但有一条硬原则：SLO / error-based 告警优先，阈值告警只做兜底。理由三条：

• 阈值告警（CPU>80%、RT>500ms）本质是「相关性告警」，它说「系统不舒服」，但不说「用户受伤了」。而 error budget 烧速告警（「过去 5 分钟错误预算消耗达到正常速率的 30%」）直接对应用户体验，这种告警响一次就值得接电话。
• 降噪不是「关掉告警」，而是「把告警和明确行动绑定」。一条告警如果触发不了一个 runbook / 动作，它就不该存在，只配是大盘上的一个数字。
• 但分级不是万能的：前提是 SLO 定义得对，而多数团队（包括我们）的 SLO 是拍脑袋定的。所以顺序不能反——先补 SLO，再谈降噪。

【想听大家怎么选】

• 你们团队的告警，「真需要人看的」占比大概多少？这个数字你们量过吗，还是拍脑袋？
• 降噪时，你们敢不敢把一条「跑了三年从没误报、但也没人信」的老告警直接下线？
• SLO error-based 告警落地了吗？还是因为「算预算太麻烦」最后又退回了阈值？
• 最扎心的一条：你上一次「因为太吵所以把某条告警静音」，结果后来它真的响了——有吗，后果多大？

期待大家带真实数字来对线，别空谈「要降噪」。