打开你手机上的 Slack，找到那个叫 #alerts 的频道，看看上面有几条未读消息。

300+？500+？还是你早就把它 mute 了，连红点都懒得看？

别不好意思承认——我见过的团队里，十个有九个是这样的。告警频道变成了一个自言自语的机器人聊天室，每天兢兢业业地往里面倒垃圾，而人类早就跑光了。

直到有一天凌晨三点，线上真挂了。那条真正要命的告警，安安静静地躺在 499 条”CPU 使用率超过 70%”和”磁盘空间低于 30%”中间。没人看到它。

告警太多，等于没有告警。

这不是一个技术问题，这是一个人性问题。

你的监控不是太少，是太多

很多团队有一个根深蒂固的直觉：告警嘛，宁可多发不可漏发，宁可错杀不可放过。听起来很负责任对吧？

但你想想烟雾报警器的故事。你家装了一个灵敏度极高的烟雾报警器，炒个菜它响，烧个水它响，点个蚊香它也响。一开始你还紧张地跑去检查，第三次之后你开始骂它，第十次之后你直接拆了电池。

然后某天半夜，厨房真着火了。

你猜怎么着？没人听到。

你的监控系统就是那个每次炒菜都响的烟雾报警器。而你的团队，就是那个已经把电池拆了的住户。

这个现象有个正式名字，叫告警疲劳（Alert Fatigue）。Google SRE 团队有一条硬杠杠：如果你的告警没有 80% 以上需要人工干预，说明你的告警阈值设错了。换句话说，你发出去的告警里，大部分应该是”这事必须有人管”，而不是”通知你一下，系统打了个喷嚏”。

PagerDuty 还做过一个统计，结论挺扎心的：告警数量翻一倍，工程师的响应速度平均慢三倍。不是慢一倍，是慢三倍。因为工程师收到告警后的第一反应不再是”出事了”，而是”又来了，先看看是不是假的”。

判断一条告警是不是假的，比处理一条真告警还耗精力。

90% 的告警，其实都是废话

你可以现在就做一个实验：把过去一个月的告警记录导出来，按”最终处理结果”分个类。你大概率会发现：

  • 一部分告警，触发后系统自己恢复了，没人需要做任何事
  • 一部分告警，有人看了一眼说”哦，正常波动”，然后关掉
  • 一部分告警，已经连续几个月每天都在报，所有人都知道”这个不用管”
  • 只有很少一部分，有人看了之后真的去做了什么操作

如果你发现最后一类不到 20%，恭喜你，你的监控系统已经成功训练出了一支”对告警完全免疫”的团队。

这不是工程师的错。这是人脑的出厂设置。

你不信？住在铁轨旁边的人，一个月之后就听不见火车声了——大脑会把反复出现又没有后果的刺激自动归为背景噪音。心理学管这叫”习惯化”，但你不需要记这个术语，你只需要知道：你的告警频道就是那条铁轨，而你的团队已经”听不见火车了”。

告警降噪三步法

好消息是，这事有解。而且不需要换监控工具，不需要重写系统，只需要你花一个下午做三件事。

第一步：分级——不是所有告警都配打电话

把你现有的所有告警规则拿出来，一条一条过，按这个标准分三档：

P0：房子着火了。 5 分钟内必须有人响应，否则业务受损。通知方式：打电话 + 短信。一天不超过 2-3 条。如果你的 P0 每天超过 5 条，要么你的系统真的每天着火五次——那该修的不是告警——要么你的分级标准有问题。

P1：水龙头没关紧。 30 分钟内有人看就行，暂时不会炸。通知方式：Slack 高优频道，但这个频道只放 P1。工程师看到这个频道有消息，知道”有事但不急”。

P2：隔壁装修有点吵。 下个工作日处理就行。通知方式：每天一封汇总邮件，把所有 P2 打包发送。或者干脆做成一个 dashboard，有空的时候扫一眼。

关键来了：你现有的告警里，大概有 70-80% 应该被归到 P2。 也就是说，它们根本不该出现在你的 Slack 里。

分级的本质不是给告警贴标签，而是给你自己的注意力做预算。你的注意力是有限的，别让 P2 把 P0 的额度吃光了。

第二步：聚合——同一个问题只说一遍

假设你有 50 台机器，其中 30 台在同一时间 CPU 飙高了。你是希望收到 30 条告警呢，还是收到一条写着”30/50 台机器 CPU 超过阈值”的告警？

答案很明显，但大部分监控系统的默认配置是前者。

设一个聚合窗口，比如 5 分钟。5 分钟内同类告警只发一条摘要。摘要里写清楚：影响了多少台机器、什么指标、当前值多少、持续了多久。一条顶三十条，而且信息量更大。

好的告警像急诊分诊台，坏的告警像菜市场大喇叭。

第三步：定期清理——每月杀一批告警规则

这是最容易被忽略、但最有用的一步。

每个月花半小时，拉出所有告警规则，问一个问题：过去 30 天，这条规则触发后，有没有人做了任何操作？

如果答案是”没有”——删掉它，或者把阈值调高到不会轻易触发。

没有人做操作，只有两种可能：要么这个告警对应的问题不需要人管（那它就不应该发），要么这个告警已经被所有人忽略了（那它发了也没用）。不管是哪种，留着它只会增加噪音。

敢删，才是真正的运维自信。

那个凌晨丢了四小时数据的团队

我之前待过的一个团队，告警频道每天 200+ 条消息。On-call 的同学有个不成文的规矩：轮到值班那周，先把 #alerts mute 掉，然后每两小时集中看一次。

后来有一天半夜数据库主从切换失败了。告警发了，但值班的同学在睡觉（毕竟他已经 mute 了那个频道），等到早上起来看到的时候，已经丢了四个小时的数据。

复盘的时候，所有人都说同一句话：”我以为那些告警都是假的。”

后来这个团队花了两天时间做了一次告警大扫除：从 147 条告警规则砍到 23 条，P0 只留了 5 条。告警频道从每天 200+ 条变成了每天不到 10 条。

效果呢？三个月后，on-call 的响应时间从平均 47 分钟降到了 4 分钟。不是因为工程师变勤快了，而是因为每一条告警都值得认真对待了。

频道里的消息从 200 条变成 10 条，但每条消息的重量增加了 20 倍。

把 #alerts 从 mute 里捞出来

现在你可以回到文章开头那个问题了：你上次点进 #alerts 频道是什么时候？

如果答案让你有点心虚，不用焦虑。你的问题不是”不够重视监控”，而是”监控在用错误的方式消耗你的注意力”。

把 50 条告警降到 5 条，然后把那个频道的 mute 解除掉。

好的监控不是让你知道”系统还活着”。好的监控是一个靠谱的哨兵——它平时安安静静什么都不说，但它开口的时候，你知道必须立刻放下手里的事。

别让你的哨兵变成那个喊”狼来了”的小孩。