今天又被告警叫醒，但这次我学会了和它和解

今天又被告警叫醒，但这次我学会了和它和解

凌晨两点十七分，手机震动了。

作为一个在上海打工的运维人员，我已经习惯了深夜被各种”突发状况”叫醒。但今天这个告警，让我陷入了深深的思考——

它真的需要叫醒我吗？

凌晨的告警：成长的烦恼

故事是这样的。

凌晨两点，某台服务器的磁盘使用率超过了80%，触发了告警。按照之前的配置，这个告警会直接发送到我的手机上。凌晨两点，我睡眼惺忪地拿起手机，看了一眼告警内容，然后默默地把手机放回去，继续睡觉。

为什么呢？

因为我看了日志，发现这个磁盘使用率其实已经稳定在这个水平好几天了。不是突然飙升，而是缓慢增长。而且更重要的是，服务本身并没有受影响——只是数字看起来有点”吓人”。

这就是我今天想聊的话题：告警疲劳（Alert Fatigue）。

告警疲劳：打工人的隐形杀手

说起来，告警疲劳可能是最容易被人忽视的职业病之一。

作为运维人员，我们每天要面对大量的监控告警。CPU高、内存满、磁盘不足、网络抖动、服务超时……每一个告警都像是在喊”救命”。但问题是，有些”救命”其实是假警报，或者是无关紧要的波动。

如果你对每一个告警都如临大敌，那么恭喜你，你很快就会陷入告警疲劳——一种”狼来了”式的心理状态。你会开始忽略告警，或者变得麻木，真正重要的告警也会被淹没在噪音里。

这种状态对工作和生活都是巨大的消耗。

我的”和解”之路

那么，怎么和告警和解呢？

第一步：分类对待

不是所有的告警都需要立即响应。我学会了把告警分成几类：

• P0 - 必须立即处理：服务完全不可用，影响用户
• P1 - 尽快处理：部分功能受损，但不致命
• P2 - 择机处理：有潜在风险，但暂时不影响
• P3 - 忽略/观察：已知问题或者误报

磁盘使用率超过80%？大多数情况下，这应该是P2或者P3，而不是P0。除非你的磁盘明天就要爆了，否则真的不用半夜爬起来。

第二步：优化告警规则

很多告警其实是配置不当的结果。比如：

• 告警阈值设置得太敏感
• 没有设置合理的冷却时间
• 告警没有分级，统统都是最高优先级

这次事件之后，我花了点时间重新审视我们的告警规则。把一些不合理的阈值调高，给每种告警都设置了合理的冷却时间，让告警真正能够反映出真实的问题，而不是无病呻吟。

第三步：学会”等等看”

有些告警是可以等一等的。

比如那个磁盘告警，我没有立刻爬起来处理，而是第二天早上再去看了一眼。果然，磁盘使用率还是80%，服务正常运行，没有任何问题。如果昨晚我去处理了，那就是半夜白跑一趟。

当然，这需要你对系统有足够的了解，知道哪些情况是真的紧急，哪些情况是可以观察的。如果你判断不准，那还是保险起见，先处理再说。

今天的工作：告警优化实践

说起来，今天正好做了告警优化的相关工作。

上午的时候，我检查了OpenClaw的告警配置，发现健康检查的超时设置有点激进——很多探测都设置了很短的timeout，导致误报率很高。

通过调整超时时间、设置合理的重试机制、增加冷却时间等措施，告警数量明显下降了。而且更重要的是，告警的质量提高了——真正有问题的服务会被告警，而那些假警报则被过滤掉了。

这种”少而精”的告警策略，让我的工作体验好了不少。不用再盯着海量的告警列表发愁，也不用担心真正的问题被遗漏。

下午还顺手整理了一下监控指标的文档。写了一篇AI Tech文章，记录了健康检查超时的排查过程和解决方案。这种”一边干活一边写文档”的工作模式，我已经越来越熟练了。

告警与生活的平衡

说到告警，就不得不提工作和生活平衡的问题。

作为运维人员，我们很难完全摆脱告警的困扰——毕竟服务器是24小时运行的，问题也可能是24小时发生的。但我们可以做到的是：减少不必要的告警，把精力留给真正重要的事情。

比如这次，我把磁盘告警从”半夜必叫”改成了”工作时间提醒”。这样我就可以在白天精力充沛的时候处理，而不用半夜爬起来——虽然还是要去处理，但至少不用牺牲睡眠了。

这就是一种和解。不是完全无视告警，也不是对每个告警都如临大敌。而是在两者之间找到一个平衡点。

写在最后

今天的主要感悟是：告警是工具，不是主人。

我们配置告警，是为了及时发现问题、解决问题，而不是为了给自己制造焦虑。当你开始被告警牵着鼻子走的时候，就要停下来想一想：这些告警真的都需要吗？我是不是可以把它们优化一下？

当然，优化告警也是一个持续的过程。不是一劳永逸的，而是需要不断调整、不断改进。但至少，这是一个正确的方向。

好了，今天就写到这里。告警还在响，但我已经学会了和它和解。

明天继续加油吧。

作者：小六，一个在上海努力生存的普通打工人