监控告警里藏着的团队真相

上周三凌晨两点十七分，我手机在床头柜上震得快飞出去。

不是快递通知，是之前在雨花软件园做运维的朋友发的60秒长语音，带着哭腔——他们团队的告警系统又抽风了，一晚上弹了四百多条消息，等爬起来排查的时候，核心的下单接口已经超时了八分钟。

真的。

我见过太多团队把监控告警当成了上线即完成的任务，从买了系统那天起，就再也没调整过规则，任由没用的消息把真正的问题淹没。

被告警淹没的人，早就麻了

刚入行做运维的那两年，我也踩过一模一样的坑。刚接手监控系统的时候，恨不得把服务器上每一个能采集到的指标都设上告警：CPU占比超过60%就弹，磁盘使用率超过50%就发，哪怕是某个nginx进程重启了一次，都要在群里@所有人。

结果呢？

上线第一周，整个值班群每天能收到三百多条告警消息。大家一开始还认真看，后来看的多了，直接把群消息设成了免打扰。直到那次大促，支付通道的响应时间飙到了3秒，系统按规则发了告警，但是没人看到——等客服接到用户投诉反馈问题的时候，已经有近三百个用户因为付不了款走了。

90%的无效告警，本质上都是在消耗团队对真正问题的敏感度。

说句不好听的，当你一天要接两百条告警的时候，你根本不会在意哪条是真的会出事故的问题。就像你每天听楼下的汽车警报响十次，哪怕哪天警报真的是因为车被砸了，你也不会往窗外看一眼。

那些设错阈值的坑，踩过一次记三年

很多人觉得监控告警的阈值，就是找个参考值填进去就完事了。

太天真了。

之前有个做本地生活的团队，把接口响应时间的告警阈值统一设成了200ms——不管是凌晨三点整个园区都没人用系统的低峰期，还是工作日午间用户挤着点外卖的高峰期，全用同一个数值。结果一到午高峰，告警就跟连珠炮似的弹，运维刚爬起来打开监控面板，告警自己就消了。反复熬了三次大夜之后，整个团队看到告警消息都条件反射性地反胃。

后来他们花了整整一个下午，把所有阈值拆成了三个时段：凌晨低峰期，接口响应超过500ms才触发告警；工作日日常时段，超过300ms告警；大促流量高峰的时候，直接把临时阈值放宽到1s，但是真正触发告警的时候，不再只发群消息，而是直接打值班人的电话。

调整完的第一周，整个系统的告警量从每天217条降到了19条。

没有谁再因为半夜弹出来的无效消息惊醒，值班的人终于能把手机放离枕头半米远的地方睡个整觉。

我始终觉得，好的告警规则从来不是追求”零漏报”，而是要让每一条发出来的消息，都值得人从被窝里爬起来处理。

告警从来不是给运维一个人看的

之前跟一个做教育产品的团队聊，他们有个挂了快半年的告警：课程详情页的跳出率超过80%。

这个告警一直发在运维群里，运维每次看到都要查半天网络延迟、服务器负载，找来找去都没找到根本原因，最后只能把告警的接收阈值调高，眼不见为净。直到有次产品经理偶然刷群看到这条消息，点进页面才发现——上个月前端发版的时候，把课程播放按钮的路由路径写错了，用户点进详情页根本找不到按钮，当然转身就走。

就这么一个五分钟就能修好的问题，因为告警发错了人，硬生生耗了半年。

告警的价值，从来不是把问题”报出来”，而是要让能解决问题的人第一时间看到。

后来他们调整了告警的接收规则：纯服务器性能类的告警，发给运维团队；业务逻辑类的告警，直接抄送给对应的开发和产品负责人；涉及资金类的告警，同时抄送值班主管和业务线负责人。每一条告警后面，都直接标注了第一处理人、需要反馈的时限，再也没有出现过”大家都看到了告警，但大家都觉得不是自己的事”的尴尬。

上个月跟那个之前熬大夜的运维朋友吃饭，他说现在值班的时候终于不用把铃声开到最大睡觉了。上周系统出了个小问题，告警直接打到他的手机上，10分钟就定位到了故障点，等用户反馈的时候，问题早就修完了。

其实哪有什么复杂的监控技巧啊。

说白了就是别让没用的消息打扰人，别把该解决问题的人挡在消息外面。

毕竟装监控系统的初衷，从来不是为了证明团队有多重视稳定性。

是为了让大家少熬点没必要的夜。