凌晨三点的电话不是勋章
凌晨两点十七分，手机响了。不是微信，是电话。我盯着屏幕，心里骂了一句。又是那个订单服务的告警。这已经是今晚第三次。
值班群里弹出一串红色。CPU 使用率超过 80%。三分钟后又自己下去了。电话却已经把人吵醒。说实话，这种告警最折磨人。它不致命，但它让你睡不回去。
很多团队把告警数量当作战绩。谁处理的告警多，谁就是救火英雄。可问题是，火从哪来的？如果每天都有火，那说明系统在持续冒烟。救火队员再猛，也扛不住天天熬夜。
监控告警的本质不是通知。它是信号系统。信号太多，等于没有信号。人脑对重复刺激会脱敏，这跟狼来了一个道理。第一周你还紧张，第二周你开始扫一眼，第三周你直接静音。
告警风暴的根子往往不在监控工具
有人一上来就换工具。Prometheus 换掉，Zabbix 换掉，接入 PagerDuty。钱花了，值班表重排了。风暴还在。
为什么？因为告警规则是照着指标清单抄的。CPU、内存、磁盘、网络，每个都配一条。阈值拍脑袋定。80% 就告警。可 CPU 80% 在有些业务里是常态。它不代表用户受影响。
这里要提一个词，SLO。服务等级目标。说白了，就是你对用户承诺的可用性或者延迟底线。比如 99.9% 的请求在 300 毫秒内返回。告警应该围着这个承诺转，而不是围着机器转。
黄金指标那套东西，延迟、流量、错误、饱和度，听起来老生常谈。但真落到规则里，很多团队只配了饱和度和错误总数。错误总数还按分钟聚合。结果一个偶发 500 就触发电话。偶发，意味着用户可能刷新一下就好了。你却被叫醒。
更隐蔽的是告警依赖。数据库连接池满了，上游应用疯狂报错，网关也跟着报错，前端埋点也报错。一条根因，炸出三十条告警。值班的人看到的是三十条，不是一条。他得在三十条里找那一条。这哪是值班，这是破案。
分级不是贴颜色标签
P0、P1、P2、P3。很多团队分了。分完以后，P0 也打电话，P1 也打电话，P2 发群，P3 发邮件。可实际跑起来，P0 和 P1 的边界全靠感觉。业务说这个很重要，技术说这个没影响。吵到最后，全按 P0 处理。
分级要挂后果，不是挂情绪。用户不能下单，P0。用户能下单但慢，P1。后台任务延迟，但两小时内能追平，P2。内部报表晚十分钟，P3。写清楚，谁也别拍桌子。
还有抑制和静默。这两个词听起来像运维黑话。抑制的意思是，如果根因告警已经触发，就别再发衍生告警。比如数据库挂了，就别再发应用连接超时。静默的意思是，计划内维护期间，先把告警闭嘴。但静默必须有到期时间。永久静默等于把烟雾报警器拆了。
把告警当成产品来运营
我见过一个不错的做法。每周五下午，花二十分钟过一遍本周告警。不是复盘故障，是复盘告警本身。哪些告警没人处理？哪些告警重复？哪些告警一响，大家第一反应是关掉？
列个表。告警名称、触发次数、处理动作、是否有效。有效告警留下。无效告警删掉或者改阈值。有动作但可以自动化的，写 Runbook。Runbook 不是什么高级东西，就是操作手册。第一步看什么，第二步查什么，第三步找谁。
别小看这个动作。一个季度下来，告警量能降一半。值班的人开始认真看告警了。因为他知道，响起来的每一条都值得看。这个信任感，比多买几套监控贵得多。
工具层面，Alertmanager 的分组、抑制、静默够用了。Grafana 的看板也够用了。缺的往往是规则治理。谁都能加规则，没人删规则。最后规则比代码还多。
行动清单从删掉一条开始
如果你现在正被告警淹没，别急着搞大平台。先做几件小事。
第一，把过去一周的告警导出来。按触发次数排序。只看前十。问三个问题：它代表用户受影响吗？有处理动作吗？能自动化吗？三个都是否，删掉。有一个是，留下改造。
第二，给每个 P0 和 P1 写一句话后果。不要写“服务异常”。写“用户无法支付”或者“订单积压超过一千单”。后果越具体，分级越不会吵架。
第三，设置告警抑制。至少把数据库、缓存、消息队列的根因告警和应用层衍生告警隔开。别让一根网线抖动，引发全站电话。
第四，值班轮换要合理。一个人连续值一周夜班，判断力会崩。这不是意志力问题，是生理问题。可以缩短到三天，或者白天补休。别把值班当奉献。
第五，每月删掉至少一条告警。对，必须删。只加不删的监控体系，迟早变成噪音垃圾场。
监控告警不是越灵敏越好。它像家里的烟雾报警器。炒菜冒烟就响，你会把电池抠了。真着火的时候，它反而不响。调到一个合适的灵敏度，然后定期换电池。剩下的，交给流程和信任。