告别告警疲劳：从「收到告警」到「定位根因」的产品设计

告警疲劳的本质

告警疲劳不是「告警太多」这么简单，而是告警与可行动信息脱节：一条「CPU 使用率超过 80%」既不知道影响哪个业务、也不告诉你怎么处理，值班同学收到后第一反应是「又是这个」，时间久了自然麻木。

炬鲸 OBSERVE 把告警设计的目标定成一句话：每条告警要么能自动恢复，要么能直接跳到根因。下面拆解四个能力。

一、多维聚合与去重

同一个故障会触发几十条告警。我们的做法是按故障维度聚合，而不是按告警规则聚合：

• 聚合维度可配置：按 集群 + 服务、可用区 + 应用 等组合。
• 同维度窗口内的事件合并成一条，展示「影响面」（多少个实例、多少个服务）而非一长串。
• 聚合窗口默认 5 分钟，窗口内新事件只更新计数、不新开告警。

效果：一次机房网络抖动，从 200 条告警压成 3 条聚合告警，每条说清影响面。

二、静默与抑制

• 静默（Silence）：计划内的变更、已知故障维护窗口，手动或按时间表静默，避免已知问题刷屏。
• 抑制（Inhibition）：基于拓扑的自动压制。节点宕机必然触发该节点上所有服务的告警，配一条「主机 Down 抑制其上所有服务告警」，只保留根因告警。

抑制规则是降低噪声最有效的一招，但配置成本也最高——建议从「主机级 → 容器级 → 服务级」的层次开始配，一层层加。

三、告警携带证据

这是告别疲劳的关键一跳：告警本身带上证据链接。

每条告警详情里自动附带：

1. Trace 查询：该服务该时间窗的慢链路 / 错误链路 Top 列表链接。
2. 日志查询：按 service + level=ERROR + 时间窗 预生成的日志搜索链接。
3. 变更关联：最近 30 分钟该服务的部署、配置变更记录。

值班同学点开告警，第一屏看到的就是「发生了什么变更 + 哪里有慢链路 + 哪里有报错」，而不是一张孤零零的曲线图。

四、升级与排班联动

• 多级升级：告警 N 分钟未确认，自动升级到上级或电话通知；不同 severity 走不同升级链。
• 排班（On-Call）：告警直接路由到当前值班人，支持轮转、分时区、节假日覆盖。
• 确认即记录：谁确认、什么时候确认、怎么处理的，全部留痕，形成可审计的值班记录。

落地建议

• 先把告警分级做对：P1 要人命、P2 要处理、P3 只是信息，别把所有规则都设成 P1。
• 每条告警规则发布前问一句：「收到这条告警的人，知道下一步做什么吗？」答不上来的规则，先加证据链接再加告警。
• 每周复盘「被静默的告警」和「被忽略的告警」，这两类是最该优化或删除的。

把「可行动」作为告警的第一验收标准，告警疲劳会随着证据链的补齐而自然消退。