上周三凌晨两点，我被手机震得从床上弹起来。是南京河西某电商客户的值班电话。他们团队的监控告警炸了——一晚上弹了1200多条提醒，其中80%是同一个商品查询接口的超时波动，值班的小伙子盯着满屏的通知坐了俩小时，愣是没找着真正出问题的支付链路。等他顺着日志翻到支付模块的时候，已经有三百多个用户付不了款，客服的投诉消息堆了半屏。
说实话，这种场景我这几年见得太多了。
大部分团队的告警，从一开始就配错了
很多团队刚上监控系统的时候，总觉得把所有能埋点的指标都接上、所有能设置的阈值都拉到最严，就是把监控做扎实了。CPU到70%就喊，接口响应超100ms就弹，磁盘用了30%就发邮件，恨不得把服务器的每一次内存波动都推到值班群里。
谁没经历过？早上打开电脑，邮箱里躺着几十条告警通知，全是昨天半夜服务器闲得慌触发的无效提醒。时间长了，大家对这些弹来弹去的消息早就麻木了，群消息设置成免打扰，告警电话直接静音——直到真的出了影响用户的事故，才反应过来刚才的提醒里早就有线索。
真正有用的告警，从来不是报指标异常，而是提示风险即将影响真实用户。我之前接触过一个做在线教育的团队，最开始不分场景乱配规则，一周要接300多条告警，大家都疲了。上次直播课因为推流节点故障大面积卡顿，值班的同学以为又是普通的网络抖动，没当回事，等客服接到家长投诉的时候，已经过了20分钟，好几十个家长直接申请了退课。
后来他们咬着牙把所有告警规则重新梳理了一遍，按影响程度分成三级：一级是直接影响用户付钱、看课的核心问题，比如支付接口报错率超1%，直播流中断，这种直接打值班电话，响到接为止；二级是核心链路有隐患，比如数据库慢查询涨了3倍，磁盘使用率到80%，这种发企业微信提醒，10分钟内响应就行；三级是优化类的问题，比如某个非核心的运营活动页面加载慢200ms，这种攒到周一的复盘会统一讨论就行。改完规则的第一个月，他们的无效告警直接砍了80%。
别让告警变成单向的通知喇叭
很多团队的告警系统，本质上就是个单向发消息的工具。消息弹出去，就没人管后续了：这条告警有没有人看到，有没有被处理，处理的结果是什么，根因有没有找出来，全靠值班的人自己记。
之前和雨花台区一个做企业服务的技术负责人聊天，他说他们之前的告警系统，每个月弹的消息里有60%是重复的。比如同一个服务器磁盘满的问题，因为没人定期清理日志，连续弹了三天，每天8次提醒，最后值班的同学直接把告警群的消息屏蔽了。等系统因为磁盘满宕机的时候，没人第一时间看到告警，硬扛了两个小时才被用户发现。
无效告警多了，比没有告警的危害还大。他们后来改了规则，同一个问题1小时内的重复告警直接自动聚合，只弹第一次提醒，后面的都攒着等问题处理完了统一展示；每条告警弹出来的时候，后面跟着三个按钮：”认领””误报””已解决”。点”误报”的话，系统会自动记录这个规则的误报次数，攒够3次就自动把规则拉出来，让配置的人重新调整阈值，不会一直瞎弹。要是告警弹出来10分钟没人认领，系统会自动把消息推给上一级的负责人。
就这么几个简单的改动，他们当月的无效告警直接降到了之前的30%，值班的人再也不用对着满屏的消息发呆了。
那些花大价钱买的监控工具，最后为啥成了摆设
我见过太多团队，刚上监控的时候选最贵的企业版，大几十万砸下去，最后用了俩月就没人看了。
为啥？因为配置规则的人根本不结合自己的业务实际。同样是接口响应慢，做外卖的和做内部OA的，阈值能一样吗？外卖的骑手接单接口，响应超500ms可能就会影响骑手抢单效率，是一级告警；OA的请假审批接口，响应超2s其实也没人在意，攒着慢慢优化就行。很多人不管这些，直接拿工具自带的默认规则往上套，最后出来的告警全是隔靴搔痒的废话。
还有那些花里胡哨的监控大屏，搞的跟城市指挥中心似的，实时数据跳来跳去，装在公司进门的大厅里，客户来了就指着大屏吹半天。真出问题的时候，没人会盯着那个大屏看。我之前碰到过一个客户，他们的大屏上显示支付成功率100%，实时在线人数蹭蹭涨，实际上后台已经挂了三个支付渠道，用户根本付不了钱。为啥？因为大屏的数据源接错了，取的是测试环境的指标数。
不过话说回来，那种花几十万做的超大屏，用来接客户参观确实有面子，真要用来排障，还不如值班同学手里那个能直接弹告警的企业微信小程序好用。
上周那个河西的电商客户，回去照着这套思路改了告警规则，这周给我发消息，说现在一晚上的告警从1200条降到了17条，值班的小伙子终于能睡个整觉了。说白了，监控告警从来不是越全越好，越严越好，是要让看到告警的人，清楚什么时候该马上爬起来处理，什么时候可以等上班了再说。