前端可观测性建好了，告警却没人信：告警降噪与响应闭环怎么设计？

背景

社区里前端可观测性已经聊了很多层：#28 讲错误监控从「白屏没人知道」到 5 分钟定位，#121 聊采样还是全量，#431 聊稳定性投入的最低水位，#750 聊 RUM 还是合成拨测。但我发现一个被反复绕过去的问题——指标采上来了、面板也画了，可真出故障时，告警要么淹没在群里没人理，要么半夜把人叫起来发现是误报。

我团队去年统计过：一个月前端告警 300+ 条，真正需要人动手的不到 10 条，剩下 90% 被当成「噪音」划掉。这个比例我自己都觉得离谱，而且最坏的不是「漏报」，而是「狼来了」——真正 P0 来的时候，大家第一反应是「又是误报吧」。

常见分歧 / 几种做法

1. 激进派：默认全量告警 + 人工值班，「宁可误报不可漏报」。代价是告警疲劳，最后所有人都把通知静音了，等于没告警。
2. 保守派：只保留少数核心告警（白屏率、JS 错误率、LCP 超阈值），其他进面板不告警。代价是漏掉长尾问题，等用户投诉才知道。
3. 分级派：按「影响面 = 用户数 × 时长」自动分级，P0 打电话、P1 群通知、P2 进日报，再叠一层「相似告警合并」做降噪。

我的倾向与理由

我偏向分级派，但关键不是「分级」本身，而是给每条告警一个明确的 owner 和响应 SLA。我们试过纯规则分级，结果是规则越加越多、越加越脆，最后没人敢动、也没人信。后来改成「告警必须挂在某个页面的 SLO 上，SLO 被烧穿才升级」，规则量降了一半，误报也降了——因为大家开始为「这个 SLO 到底要不要保」做取舍，而不是为「这条规则要不要存在」做取舍。前者有业务含义，后者只是堆配置。

想听大家

• 你们在什么场景下选哪种？C 端高流量 H5 还是 B 端后台？流量量级大概多少，告警量一个月多少条？
• 你们怎么定义「前端该不该对某个指标负责」？告警响了第一响应人是谁、多久要 ack、谁来判定误报、误报要不要回流改规则？
• 「相似告警合并」你们踩过坑吗？我见过同一个错误在多个页面触发被合并成一条，结果真出事时被吞掉——你们怎么防这种情况？