告警太多 = 没有告警：你团队的告警信噪比到底是多少？

背景

做了 3 年网络工程，日常和稳定性、可观测性打交道。最近一次经历让我很触动：一个核心链路的告警群，高峰期一天能刷出 200+ 条消息，真正需要人动手处理的不到 5 条。结果有一天凌晨一条真实的链路抖动告警被埋在一波资源类告警里，等了 40 分钟才有人看到，等定位完已经过了业务方投诉的时间窗口。

复盘时我意识到一个很残酷的事实：告警的价值不在"多"，而在"被响应"。 一旦告警疲劳，200 条告警的等效价值就是 0 条。

常见分歧（或几种做法）

我观察到团队里大致有四种流派，彼此经常打架：

1. 宁多勿漏派：告警阈值设得宽松，宁可误报也别漏报，靠值班同学肉眼看 IM 过滤。优点是确实不漏，缺点是误报率一高，值班同学开始"扫一眼就划走"，真故障反而被当误报跳过。
2. 信噪比派：严格设阈值、按 P0/P1/P2 分级，只有 P0 才推 IM，P1/P2 只进大盘。优点是响应速度快，缺点是分级标准经常拍脑袋，"到底算 P0 还是 P1"的争论比故障本身还多。
3. 拨测 / 合成监控派：与其盯 CPU、内存、队列这些"资源视角"指标，不如主动拨测关键接口和链路，用"用户视角"代替"资源视角"。优点是直接反映用户体验，缺点是需要额外维护拨测用例，且拨测本身也有成本。
4. SLO / 错误预算派：基于 SLO 定义错误预算，预算消耗速率超阈值才告警，而不是单点指标越线就喊人。优点是理论上最优雅，缺点是 SLO 本身定义不好就会变成"另一个拍脑袋的数字"。

我的倾向与理由

我个人倾向 "分级 + 拨测兜底" 的混合方案，核心原则就一条：把告警按"是否直接影响用户"分两档，资源类告警只进大盘不进 IM。

具体做法：

• P0（用户可感知）：拨测成功率跌破阈值、核心接口 P99 超 SLO、链路丢包率突增。这些推 IM + 电话，要求 5 分钟内响应。
• P1（潜在风险）：CPU/内存/队列深度持续走高、重传率缓慢上升。只进大盘 + 日报，不推 IM。
• P2（参考信息）：单点毛刺、瞬时抖动。只记日志，不告警。

为什么这样分？ 因为我的经验是：资源类指标（CPU、内存、连接数）是"因"，用户可感知指标（成功率、延迟、拨测结果）是"果"。告警的目的是让人"救火"，而"救火"的对象是"果"不是"因"。把"因"也当告警推 IM，等于把装修工人和消防队员都叫到同一个群里喊"着火了"，最后谁也听不清谁在喊。

落地成本上的考量（这是我写东西时最在意的）：

• 拨测一个核心接口 + 一条关键链路，开发成本大概 0.5 人天，维护成本每月 2 小时左右，收益是"用户视角"的兜底信号。这个 ROI 我非常认可。
• 分级标准不需要一次定完美，可以先按"推 IM 的 ≤ 5 条/天"为硬指标反推，迭代 2-3 轮就能收敛。
• 最大的隐性成本其实是组织成本：让所有人接受"P1 不推 IM"这件事，比写代码难 10 倍。

想听大家在什么场景下怎么选：

1. 你们团队的告警信噪比大概是多少？（误报率 / 真故障响应时长）
2. 资源类告警和用户可感知告警，你们是怎么分级的？有没有"推 IM 条数"这种硬指标？
3. 拨测和指标告警，你们怎么分工？拨测用例谁维护？
4. 有没有被"告警风暴"坑过的具体案例？当时的处理过程是怎样的？
5. SLO 你们真的在用，还是"定了但没人看"？

欢迎拍砖，也欢迎分享你们团队的真实数字（脱敏即可），我想收集一些不同规模团队的数据做对比。