监控大盘「安静」到底是不是 KPI：一周 0 告警是团队赢了，还是监控在说谎？

【背景】 我做了 3 年 SRE，手上管着 40 来个服务的告警。去年 Q4 我们团队把「每周 3am 被叫醒次数」立成了硬指标：从平均 6 次压到 0，庆功会上老板说这就是「稳定性的胜利」。 但今年 Q1 复盘一起 P2 事故时我发现一个尴尬的事实：出事前的 3 天里，大盘一片安静，0 告警。事后拉数据，有 3 条本该响的告警，其中 2 条是被「降噪」规则静默掉的——当初降噪的理由，恰好就是「这规则最近一周响了 4 次，太吵了」。 一句话：我们把「安静」当成了目标，结果安静成了掩盖问题的被子。

【常见分歧，我见过三种做法】

1. 「零告警派」：告警必须每条都值得 3am 爬起来，做不到 0 就是告警设计不合格。降噪手段：合并、提级、白名单。极端情况下有人直接把「本周 0 paging」写进 OKR。
2. 「宁可吵派」：告警宁错杀不放过，值班靠肉筛。代价是狼来了效应——我们测过，一个月被叫醒 20 多次之后，值班看到告警的第一反应是「先等等看」，MTTR 反而变长了。
3. 「分级派」：Page / Ticket / 看板三级，Page 只留真故障。听起来最对，但落地时「什么算真故障」全凭值班同学当下心情，口径飘。

【我的倾向与理由】 我站分级派，但补一个我认为缺的环节——告警要有「预算」，而且预算要花在「被静默的告警」上，不是花在「响了的告警」上。 具体我们后来改成三步：

1. 每条告警规则建台账，字段就 4 个：规则名、近 90 天触发次数、每次触发后 24h 内有没有人真的动手处理、动手后的动作。
2. 触发 10 次以上、0 次处理的规则，不允许直接删——要么改阈值，要么降级成看板指标，要么写一句「这条为什么不该响」。删规则必须留痕。
3. 每周看一个反向指标：「静默掉的告警里，事后被证明是真实故障的有几条」。这个数才是「安静」的含金量。 跑了一个季度，paging 从 6/周降到 1.5/周，没到 0——但事故复盘时发现漏报率从 3/10 降到 1/10。我认为这才是真赢。

【想听大家】

• 你的团队「安静」的判定标准是什么？0 告警，还是 0 误报，还是 0 漏报？
• 有没有人做过「静默告警回放」——把降噪/静默掉的告警翻出来，对着真实故障逐条比对？漏了几条？
• 分级（Page/Ticket/看板）的边界，你们是写死在文档里，还是让值班同学现场判？哪种更靠谱？
• 极端问题：如果老板的 OKR 就是「0 告警」，你怎么在不撒谎的前提下交差？

欢迎带数字来吵，我准备了一季度的台账数据可以贴出来对照。