背景
做运维 3 年，我接手过 4 套生产系统，每套的告警策略都不一样，但有一个共同点：告警发出去的那一刻，团队是响的；告警发到第 30 天的时候，团队是聋的。
最典型的一次：凌晨 3 点被一条"磁盘使用率 85%"的告警叫醒，爬起来一看，那块盘是日志盘，前一天刚做了扩容，阈值没跟着改。后来我翻了那个系统的告警列表——217 条告警规则，其中 63 条是"历史遗留"，没有人记得当初为什么加的。
从那之后我开始认真想一个问题：告警分级到底应该由谁定、按什么标准定？
常见分歧（我观察到的 3 种流派）
流派一：按"影响面"分级 P0 = 用户直接感知（页面 502、核心交易不可用）；P1 = 性能劣化（P99 翻倍、队列堆积）；P2 = 资源预警（磁盘 85%、连接池水位 90%）。 → 听起来很合理，但"用户直接感知"这条线谁来划？一个只影响 5% 用户的支付接口 502，算 P0 还是 P1？
流派二：按"是否需要立即人工介入"分级 P0 = 必须 5 分钟内有人响应；P1 = 30 分钟内响应；P2 = 工作时间处理。 → 这个标准更可执行，但"5 分钟"本身就是一个拍脑袋的数字。我见过团队把 P0 响应时间从 5 分钟改成 1 分钟，结果就是——所有人 24 小时不敢睡觉。
流派三：按"MTTR 倒推"分级 先定 SLA（比如核心接口可用性 99.95%），再倒推：如果这个指标偏离了，还有多少时间窗口可以恢复？用这个窗口来定响应时限和升级路径。 → 理论上最严谨，但前提是你得先有一个靠谱的 SLA 定义，以及你确实能监控到那个指标。很多团队的 SLA 是写在 PPT 里的，监控面板上根本没有对应曲线。
我的倾向与踩坑经验
我最终倾向于流派一 + 流派二的混合，但加了一条铁律：任何一条告警规则上线前，必须回答三个问题——
- 这条告警触发后，值班人做的第一个动作是什么？ 如果答案是"看一眼、确认没问题、关掉"，那这条告警就不该发，它应该是一条日志或者一个 dashboard 面板。
- 这条告警过去 30 天触发了几次？其中几次是真实问题？ 如果 30 天触发了 47 次、只有 2 次是真实问题，那阈值或者检测逻辑就是错的。
- 如果这条告警被静音了（比如正在做变更），最坏后果是什么？ 如果答案是"其实没什么"，那它就不该是 P0/P1。
我建过一张"告警体检表"，每月跑一次：把最近 30 天所有告警按"触发次数 × 实际有效次数"排序，有效次数 < 触发次数 10% 的规则直接降级或下线。第一次跑的时候，217 条规则里砍掉了 71 条，团队反而觉得告警"更准了"。
想听大家聊的
- 你们团队的 P0 告警，响应 SLA 到底是多少？是 5 分钟、15 分钟、还是"看到就处理"？ 这个数字是怎么定出来的，拍脑袋还是推演过？
- 告警分级是 SRE/运维定，还是业务开发定，还是共同定？ 我见过最离谱的一次是开发说"这个接口挂了不算 P0，因为用户可以用另一个入口"，结果那个"另一个入口"依赖的就是这个接口。
- 你们怎么处理"变更窗口内告警静音"这件事？ 我见过两种极端：一种是变更期间全静音（结果真出了问题没人知道）；另一种是不静音（结果变更触发的抖动告警把真正的问题淹没了）。
- 如果只能留 3 条告警，你们留哪 3 条？ 这个问题我逼每个新入职的运维都答过，答案差异大到让我怀疑我们是不是在同一个行业。
欢迎贴你们团队的告警分级标准、体检方法、或者被"狼来了"坑过的故事。越具体越好，最好带数据。