从不触发的告警算不算缺陷：「3 天没响」该删还是该留——你们的告警治理有统一口径吗？

【背景】 做了 10 年网络工程，管过跨机房的 BGP 路由、专线冗余和一批 7×24 的网关集群。去年做告警治理时，我把 200 多条告警按「过去 90 天触发次数」排了个序，发现一半以上 90 天里一次没响。团队内直接吵起来了：

• 一组人主张：不响 = 没价值，直接删。理由是人被响过的告警训练出了肌肉记忆，不响的告警没人记得它存在，真出事时大家会习惯性忽略，等于没有。
• 另一组人反对：「3 天没响」和「3 天没出事」是两回事。磁盘水位 85%、证书还有 60 天到期、BFD 邻居 flapping 阈值——这些是安全网，删了等于把「出事才报警」改成「出事了才发现」。
• 还有人提出：应该按严重度分层，warning 允许不响，critical 不响就是配置错。

【常见的几种做法】

1. 时间窗硬规则：N 天没响自动降级或进 review 清单（Prometheus 的 alertmanager 社区、Google SRE Book 里都提过告警卫生）。
2. 演练验证：game day / 故障注入，定期验证告警链路真能响（从规则触发 → 路由 → 值班人收到）。
3. 分级管理：只考核 critical 的「静默率」，warning 允许长期不响。
4. 按 SLO 反向推导：告警只锚定「错误预算燃烧率」（burn rate），不锚定具体指标值。

【我的倾向与理由】 我倾向「分级 + 演练」组合：

• critical 告警 90 天不响 = 必须 review，要么改阈值（说明阈值太保守）、要么删（说明这个风险点已被上层 SLO 覆盖）、要么保留但必须补一条演练记录。
• warning 不考核静默率，但每季度跑一次故障注入，验证端到端链路（规则 → 路由 → 通知 → 值班响应）没断。
• 理由：告警的价值不在「响」，而在「响的时候有人信」。一个团队被狼来了训练过的值班，和没被训练过的，事故恢复时间差一个量级——这是我复盘 4 次建连失败类事故后的体感。

想听大家聊：

• 你们团队对「不响的告警」有统一口径吗？是按时间窗、按分级、还是没人管？
• 故障注入演练你们是怎么落地的？是手工改配置触发，还是有自动化的混沌平台？
• 如果 critical 告警 90 天不响，你们的第一反应是「删」还是「改阈值」？
• 有没有遇到「删了之后真出事」的案例？