告警是写给未来某个倒霉蛋的信
我在上一家公司维护过一套大约三千条告警规则的监控系统，最后一条被静默的规则，是我离职前亲手加的注释——"此告警已无意义，但下游依赖方要求保留，勿动"。这个注释就像恐龙博物馆里的标签，说明这里曾经有过某种巨大的生物，如今只剩下化石。其实，大部分告警都不是为了发现故障而生的，它们是为了证明某个系统存在过，或者证明某个团队曾经思考过风险。有多少告警规则，是去年某个凌晨为了应付事故复盘，加上了就再也没人敢删的？你可以去看看你身边的监控大盘，随便点开一条告警规则，看看它的创建时间和最后修改时间。如果这条规则超过一年没人动过，它大概率已经变成了噪音的一部分。这不是监控工具的问题，是人性——我们宁愿被确定性的事物折磨，也不愿面对"删掉它万一出事怎么办"的不确定性焦虑。所以告警系统最终变成了一座数字垃圾场，里面堆满了过期的恐惧和被遗忘的承诺。
而真正有趣的部分在于，告警是写给未来某个倒霉蛋的信，只是写信的人从来没想过收信人能不能读懂。我接手过一个老旧的支付系统，里面有一条告警写着"数据库连接池数量超过80%"，触发之后只发邮件，不加群。我花了三周才搞明白这个系统根本不用连接池，它用的是自研的裸连接。那条告警的规则是五年前一个已经离职的架构师留下的，他当时设计的方案后来被推翻重写，但告警规则像幽灵一样留了下来。每次触发，邮件系统会安静地把这个错误发送给一个已经不存在的邮箱地址。这种荒诞的场面每天都在不同公司上演。告警不应该只是触发条件与通知通道的集合，它更是一种组织记忆的载体。如果一条告警无法讲清楚"它为什么存在"，那它就和写在水面上的字一样，只剩下仪式感。
你痛苦的不是告警多，而是不知道谁该醒着
我观察过不少团队处理告警的方式，最荒唐的一种是不管什么级别，先拉一个全员群。半夜两点，数据库主从延迟告警触发，于是运维、后端、前端、QA、产品经理，甚至偶尔包括运营，都在群里被叮咚声吵醒。然后真正能处理问题的人，可能还在翻日志找线索，而其余二十个人在群里发出各种表情包排队问"怎么了"。这种场景本质上不是技术问题，而是组织缺乏"响应责任边界"的体现。告警的物理通道是监控系统负责的，但告警的心理学通道——谁该焦虑、谁该行动、谁可以安心睡去——却是团队文化决定的。一个成熟的告警体系，衡量标准不是MTTA和MTTR降了多少，而是值班的人是否在夜间被叫醒时，心里清楚地知道自己就是那个被选中的倒霉蛋，并且毫无怨言。
告警疲劳的核心诱因，从来不是告警数量本身，而是大量"你知道了也做不了什么"的无效信息。我见过一个团队把磁盘使用率85%的告警设置成了电话通知，理由是"防止磁盘写满"。结果就是值班的人每周被叫醒两三次，然后起来登进服务器看一眼，做个扩容操作，再躺回去。三个月后，所有人都开始静音这个通知，然后有一天磁盘真的写满了。这个案例烂俗但真实。对比之下，另一个团队处理同样的场景就高明得多：他们做了一个磁盘增长预测脚本，只有当剩余可用空间按照当前增速不足以支撑未来12小时时才会触发告警。同样一件事，前者传递的是"现状让你看看"，后者传递的是"你该做决定了"。告警应该是决策触发器，而不只是状态通报器。很多系统设计了严重级别、升级策略、值班日历，却忘了设计最关键的一个东西：告警到底是要求接收者做什么决定。没有决策负担的告警，本质上是精神污染。
维护系统的人，比系统本身更需要被理解
我逐渐形成了一种偏见：看一个监控系统设计得如何，不要看它功能多齐全，要看值班工程师在凌晨三点被叫醒后，第一句话说的是什么。是"靠，又是这条"，还是"这个报错之前没注意过"。如果大多数情况是第一句，那这个监控系统已经和那只不断报假的狼重复咬人的故事没什么区别了。但如果大多数情况是第二句，恭喜，这说明这个团队的监控系统还保持着和现实的某种对话感。监控告警的本质，是帮人类缩小注意力范围，而不是帮机器刷存在感。这套逻辑放到人与人之间也一样——一个真正关心你的朋友，不会每天跟你说八百遍"注意身体"，而是在你真正快要倒下的时候，适时地递给你一杯温水。好的监控系统应该像那种有分寸感的朋友。
不过在我的经验里，能做到这种境界的团队实在不多。更多时候，监控系统变成了团队内部甩锅的证据库。开发说"没有收到告警"，运维说"告警发了两遍"，最后打开历史记录一看，告警确实发了，但级别设置成了"提示"，而值班的人只盯着"严重"级别的通知。这种对话我见过太多次了。问题的根源在于，很多公司把告警当成责任的最后一道防线，而不是问题发现的第一条线索。于是大家花大量精力去争论告警是否送达、是否升级、是否被认领，却很少有人讨论为什么一个级别为"提示"的告警，实际上预示着一个严重的故障。告警的级别设定，往往反映的是事件发生时的"尴尬程度"，而不是它对用户或业务的实际影响。这导致了一种系统性的集体虚伪：所有人在防火，却没人在排查助燃物。
告警的终局可能是把自己给告没了
说点让我自己都觉得不安的观察。监控和告警这个行当，未来二十年可能会发生非常根本性的变化。传统的告警是基于规则的，规则是人写的，而人写规则的习惯是——只写自己经历过的事。但系统的故障形态是进化的，它永远比你经历过的更狡猾。这就好比，你按照历史地震记录来设计抗震建筑，但下一次地震有着完全不同的波形。而基于机器学习的告警分析开始介入之后，我身边不少同行都在焦虑一个更哲学的问题：如果告警系统能够自动判断故障并触发自愈脚本，那告警消息的接收者，还是人吗？当系统能自我诊断、自我修复、自我复盘的时候，告警不再是"通知人来做决定"，而只是"记录系统替人做过的决定"。到那个时候，告警的终点是沉默，而不是铃声。你可能觉得这遥不可及，但其实我们现在已经有监控系统在部分场景下做到了——比如K8s的HPA自动扩容，比如基于流量特征的限流降级，比如集群脑裂时的自动选举。这些动作发生时，你并不会收到一条"我要扩容了"的告警。你会发现，最优秀的处理，是无声的。
所以我想说的是，监控告警的长远目标，不是让团队响应更快，而是让团队无事可响应。这是一个有点自毁倾向的结论——我们这些做监控的人，最终追求的是把自己的存在变得多余。但在这个目标达成之前，我依然每天睁大眼睛盯着各种布满图表的大屏，认真对待每一条可能预示着未知的告警。因为我知道，每一个告警的背后，可能藏着一个还没被讲述的故障故事，而读懂这些故事，是工程师的本分。也是在这个意义上，我比任何时候都相信：告警的价值不在于它被收到了，而在于它被某个清醒的人真正理解了。