告警的「最小必要集」到底怎么定：「只告出过事的指标」vs「宁可多告一个也别漏」，你的团队线上走的是哪条路？

【背景】

做了 10 年网络与后端稳定性，最近帮两个团队做告警治理，感受特别强烈：

• 团队 A：Prometheus 里配了 200+ 条 alert rule，值班同学说「大部分告警我闭着眼都知道怎么关」，真正出事故时反而被淹没在噪音里，MTTR 从 8 分钟涨到 35 分钟。
• 团队 B：只有 5 条告警（CPU、内存、磁盘、进程存活、HTTP 5xx），某次 DNS 解析抖动导致下游超时，没告警，靠用户投诉才发现，拖了 6 小时。

两个极端我都见过，但「到底该告几个、告哪些」这件事，我还没见过一个能说服所有人的定论。

【常见分歧 / 几种做法】

1. 事后驱动（Incident-driven）：只给「出过事的指标」加告警，没出过事的不告。好处是零噪音；坏处是第一次出事永远是「无预警」，而且你不可能把每个历史事故都记住再逐条配。
2. 全面覆盖（Comprehensive）：能采的指标都采、都配阈值，宁可多告。好处是「不会漏」；坏处是告警疲劳，on-call 开始习惯性忽略，真正该响的也滑过去了。
3. SLO 烧录率（Burn-rate）：不告单个指标，只告「错误预算消耗速度超阈值」。Google SRE 推荐的路子，理论优雅，但前提是你得先有靠谱的 SLO 定义——现实中很多团队的 SLO 是拍脑袋定的。
4. 金丝雀 + 症状（Canary + Symptom）：只告用户可感知的症状（P99、5xx、错误率），再加 2~3 个「先行指标」（如连接池 pending、队列深度），其他一律不告。
5. 分层告警：P0 只留 3~5 条「必须 5 分钟内响应」的，P1 可以多一些但走 IM 不打电话，P2 只写日报不推送。本质上是用「响应成本」做分层过滤。

【我的倾向与理由】

我偏向 方案 4 + 方案 5 的混合，核心原则一句话：每一条告警必须能回答「响了之后我第一步做什么」，回答不了就不该存在。

具体做法：

• 症状层（P0，打电话）：用户可感知的 3~5 条，比如核心接口 P99 > SLO 阈值持续 2 分钟、5xx 比率 > 1%。这些是「果」，不是「因」。
• 先行层（P1，IM 推送）：2~4 个能比症状早 5~15 分钟出现的指标，比如连接池 active/maximum > 80%、消息队列 lag > 阈值、下游 RT P99 突增 3 倍。这些是「因」的代理。
• 观察层（P2，日报/周报）：资源水位、容量趋势，不推送、不打电话，只进周报。

关键不是「告几条」，而是每条告警背后有一个 runbook 入口。没有 runbook 的告警，要么补上 runbook，要么降级到 P2，要么删掉。

成本上，这个方案的落地成本大概 1~2 周：梳理现有告警 → 按三层分类 → 给 P0/P1 补 runbook → 跑 2 周观察噪音 → 删掉误报率 > 50% 的。不需要引入新工具，Prometheus + Alertmanager + 一个 IM webhook 就够。

【想听大家聊的】

1. 你们线上 P0 告警有几条？是「越加越多」还是「越砍越少」？砍的依据是什么？
2. 「只告出过事的指标」这个策略，你们有没有遇到过「第一次出事就是最严重的一次」的情况？
3. SLO 烧录率告警你们落地过吗？最大的坑是什么——SLO 定不准、还是窗口/短窗长窗配不好？
4. 有没有人试过「告警预算制」：每月给 on-call 最多 N 条电话告警，超了就要合并/降级？效果怎么样？
5. 跨团队场景：A 团队的告警响了，根因在 B 团队的服务，这种「告警跨边界」你们怎么处理的？

欢迎带具体数字来聊——你的 P0 有几条、MTTR 多少、误报率多少，比「我们也在做」有参考价值得多。