上周三凌晨两点十七分，我被手机震得差点从床上滚下去。摸过来按亮屏幕，是企业微信的告警推送——支付成功率下降0.2%。我盯着屏幕愣了三分钟，爬起来翻监控，最后发现是某个用户端的弱网触发的统计抖动，根本没影响实际交易。
挺烦的。
翻完回去躺到四点才睡着，第二天早会整个人飘着，旁边坐的运维兄弟说他昨晚一共收了127条告警，其中120条是无意义的阈值提醒。他说现在手机只要一震，心脏就跟着抽一下，生怕又是什么需要爬起来处理的破事。
大部分团队的告警，从一开始就建歪了
很多团队刚搭监控系统的时候，思路简单得可笑。把所有能拉到的指标全挂上阈值，CPU超过70%告警，内存超过60%告警，接口响应超过200ms告警，恨不得把服务器上每一个进程的状态都做成实时提醒。总觉得告警覆盖的指标越多，系统就越安全。
根本不是那么回事。
之前接触过一个做电商的团队，大促前一周把所有接口的告警阈值压得比平时低30%，结果活动当天光告警就刷了三千多条，值班的同学根本看不过来，最后真的出现库存超卖的时候，告警被刷到了消息队列最下面，晚了二十分钟才发现，平白损失了十几万。
我见过太多团队把告警的逻辑搞反了。告警的核心价值从来不是覆盖所有指标，而是筛掉所有不需要人介入的噪音。如果一条告警发出去，值班的人看了一眼，发现根本不需要动手处理，甚至连多看一眼的价值都没有，那这条告警从配置的那天起，就已经是垃圾了。
那些被忽略的告警优化细节
说个最容易被忽略的点：告警的触发条件，一定要和真实的业务影响绑定，而不是盯着技术指标死调阈值。
同样是支付接口的响应时间，要是支付渠道那边的响应慢了100ms，但是整体支付成功率没掉，用户也没反馈，那根本没必要告警。反过来，要是支付成功率掉了哪怕0.1%，哪怕所有技术指标看起来都正常，也必须立刻弹最高级别的提醒。
很多人做告警优化的时候，总想着要上多么复杂的算法，要做什么智能异常检测，要花大价钱买高级功能。其实完全没必要。先把最基础的事做好——把所有过去三个月里，触发了之后没人处理、最后自动恢复的告警全部拉出来，要么把阈值调松，要么直接关掉，光这一步就能砍掉至少60%的无效告警。
剩下的告警，一定要做清晰的分级。第一级是必须5分钟内响应的，比如核心交易链路断了，用户付不了钱，这种直接打值班同学的电话，连打三次没人接就打备用联系人；第二级是30分钟内处理的，比如非核心模块的接口报错率涨了，这种发企业微信群就行，不用打电话；第三级是日报里汇总的，比如某个边缘节点的CPU偶尔飙到80%，根本不用实时推，攒着每周复盘的时候看一眼就行。
我还见过一个很离谱的操作：告警发出去之后，根本没人跟进闭环。比如上次有个告警说某个接口连续报错，推到群里之后，大家看了一眼，没人处理，过了半小时告警自动消失了，就当这事没发生。结果一周之后这个接口因为内存泄漏整个崩了，影响了整整一下午的用户访问。
别把告警当成甩锅的工具
说起来你可能不信，很多团队的告警乱成一团，根本不是技术问题，是协作的问题。
开发搭完服务，随便拉个监控就甩给运维，说“这个服务的告警我配好了，以后有问题你们盯着”，结果根本不管告警的阈值合不合理。最后出了问题，双方对着甩锅：开发说我告警都配了，运维没及时处理；运维说你那告警阈值设得跟闹着玩似的，十分钟弹一次，谁能盯得过来。
之前在软件大道那家做生鲜电商的团队，他们的做法就很有意思。所有服务的告警配置，必须由服务的开发owner签字确认，要是因为告警配置不合理导致漏了故障，责任算在开发owner头上；要是告警触发了之后运维没及时响应，责任算在运维头上。刚开始推行的时候大家都吐槽麻烦，结果推行了三个月之后，整个团队的无效告警直接降了70%，因为开发自己知道哪些指标是真的有影响的，不会随便拉个阈值就完事。
还有个小细节，现在很多团队喜欢把告警推到几百人的大群里，结果真的有紧急告警的时候，大家早就被平时的无效消息刷得麻木了，根本注意不到。不如给每一级的告警建独立的群，第一级的告警群就拉对应的值班同学和业务负责人，平时根本不会有别的消息，只要群里弹消息，所有人都知道是真的有问题，不会漏。
前几天碰到之前做运维的老同事，他说现在他们团队每天的告警量从最开始的几百条，降到了每天平均不到10条。上次大促的时候，整个值班过程顺得离谱，没有凌晨的骚扰电话，没有刷屏的消息，出了问题大家都能第一时间看到，处理完接着回去睡觉。
说真的，做监控告警这么久，从来没觉得什么“智能运维”“全链路观测”是多么高大上的东西。
本质上不就是让系统该说话的时候说话，不该说话的时候别吵人嘛。
对吧？