凌晨三点十七分。
手机震得床头柜上的玻璃杯都跟着晃。
我当时第一反应是伸手按掉，毕竟上周已经被这种半夜的告警折腾了三回，两次都是测试环境的服务器磁盘满了。
结果按掉没两秒，电话打过来了。是同组的运维值班的兄弟，声音哑得像砂纸磨：”别睡了，支付接口挂了二十分钟，之前告警太多大家都静音了，现在客诉已经堆了两百多条。”
那天我们折腾到早上六点，算下来直接损失快十二万。
被告警喂出来的值班条件反射
很多团队的值班机制，最后都慢慢变成了告警降噪的反向操作。刚开始大家看到告警弹窗就神经紧绷，生怕漏了什么影响业务的问题，可架不住每天几十上百条告警轮番弹：什么CPU使用率超60%要提醒，内存占了55%要提醒，日志文件超过1G要提醒，连个进程句柄数到了阈值都要弹个窗。时间长了所有人都学乖了，要么把告警通道全关静音，要么看到弹窗先划走，等着别人处理。
谁没经历过这种时刻？刚把哄睡的娃放下，刚把泡好的面端到桌上，刚在地铁上挤得脚不沾地，手机嗡一下弹个告警，爬起来处理十分钟，最后发现根本不影响任何用户。
大部分告警根本不配叫醒人
很多团队上监控的时候，思路从根上就错了。没有经过业务影响校验的告警，本质都是噪音。比如你采集了一台非核心的边缘节点服务器的CPU使用率，设的阈值是70%，但这台服务器就算CPU跑到100%，最多也就是影响几个偏远地区的用户打开首页慢两秒，根本到不了需要半夜叫醒值班人的程度。更别说很多团队根本不做告警收敛，同一个服务在10分钟内因为网络波动连续弹17条同类型的告警，刷得满屏都是，人看到了只会觉得烦，根本不会认真看内容。
还有一种常见的误区，就是把系统自动能处理的事，也放进实时告警流里。比如你的监控系统已经配置了自动扩容策略，当CPU使用率超过70%的时候，系统会自动加两台服务器，三分钟内就能把使用率拉回正常水平，这种事为什么要发告警给人？人收到告警除了知道系统做了个自动操作，什么也做不了，纯纯浪费注意力。告警的核心价值是减少人的注意力损耗，而不是追求指标覆盖率。很多团队给老板汇报的时候，总说自己监控覆盖率到了99%，覆盖了多少个指标，多少台服务器，从来不说自己的告警里，有多少比例是真的需要人介入的。
能落地的告警调整其实没那么复杂
很多人觉得告警体系改造是个大工程，要花几个月时间梳理所有指标，其实根本不用。你先花一个星期，把最近三个月收到的所有实时告警拉出来，按需要人介入的程度顺一遍就行。那种不立刻处理就会直接影响资金安全或者核心用户访问的，比如支付失败率暴涨、核心接口不可用，这种才配走最高优先级的告警通道，电话加短信，必须第一时间触达值班人。那种影响部分非核心功能、不会立刻造成损失的，比如评论区加载慢、个人中心头像显示异常，这种发个群消息就行，不用打电话催。那种根本不需要实时处理的，比如磁盘使用率到了80%、非核心节点网络波动，这种直接进每日汇总报表，上班的时候看一眼就行，根本不用实时推。
再加个最简单的收敛规则：同一个服务、同类型的告警，10分钟内触发的，合并成一条，不要反复弹。之前有个做SaaS的朋友，团队一开始每周要收到130多条实时告警，光梳理分类、加了个简单的收敛规则，两周之后每周的实时告警就降到了7条，值班的人再也不会把通知权限关了，因为知道每次手机响，都是真的需要花点时间处理的事。
别总觉得监控告警做的越细越好。
你想想，要是你家的烟雾报警器，每次炒菜油烟大一点就响，每次烤面包的热气飘上去就响，时间长了你肯定会把电池抠了。真着火的时候，报警器就算响破喉咙，你也不会当真。
监控告警也是一样的道理。