凌晨三点的告警，和那些开始“会思考”的机器

去年冬天，有一次半夜被电话吵醒。监控系统疯狂报错，核心业务接口超时，用户投诉量直线上升。我摸着黑爬起来，一边开电脑一边在心里骂那套运警规则——阈值设得太死，稍微抖一下就炸锅。折腾了两个多小时，最后发现是某个下游缓存节点内存泄漏，压根不是我们这边的问题。

那种无力感，做运维的人大概都经历过。

后来公司开始推智能运维，说要上AI。一开始我挺抵触的。觉得这东西不就是换了个皮的规则引擎吗？结果用了一段时间，发现它确实有点不一样。

以前我们怎么干活

传统运维其实很像守夜人。盯着一堆大盘，CPU、内存、磁盘、网络、接口延迟、错误率……阈值一超就告警。告警多了就麻木，少了又怕漏。出了问题，靠经验猜，靠日志翻，靠人肉排查。

经验这东西很吃老。新来的同学面对一堆告警，经常不知道从哪下手。老员工离职，很多隐性知识就跟着走了。而且人是有极限的。连续值几个夜班，眼睛都花了，误判和漏判几乎不可避免。

更麻烦的是故障关联。现在系统越来越复杂，微服务、容器、云原生，一个接口慢，可能是下游数据库、可能是网络抖动、可能是某个sidecar资源不够。靠人去画因果图，效率太低。

AI进来之后，变化是悄悄发生的

我们最初上的是异常检测。以前是固定阈值，现在是模型自己学“正常”长什么样。它会看历史数据的波动规律，节假日流量高、工作日早晚高峰、甚至某个业务活动期间的特殊模式，都能记下来。突然偏离了，才报警。

一开始误报还是不少。后来调了调特征，加了些业务维度，明显好很多。有一次晚上数据库连接数缓慢爬升，传统阈值还没触发，模型已经提前半小时给出了预警。我们排查下来，是某个定时任务写了有问题的SQL，连接池没及时释放。那次真的救了场。

根因分析这块，体感更明显。出故障时，系统会自动拉相关的指标、日志、调用链，然后给出几个可疑点，并按概率排序。以前我们要打开五六个工具来回切，现在至少有个起点。虽然它给的结论偶尔会跑偏，但方向大体对，能少走很多弯路。

还有预测。磁盘快满了、证书快过期了、某些容量指标即将触顶，这些以前靠人工巡检或者简单脚本。现在模型会根据增长趋势提前几天提醒。听起来不起眼，但积少成多，真能减少不少半夜被叫起来的次数。

落地没那么浪漫

说归说，真正用起来坑也不少。

数据是最大的门槛。模型再聪明，喂进去的是脏数据，出来的也是垃圾。我们花了好几个月清洗指标、统一命名、补齐缺失值。日志格式不统一、调用链采样率太低，都会让效果打折。

假阳性还是存在。模型有时候会把正常的业务波动当成异常。尤其是新业务上线、大促期间，历史数据不够，它就容易慌。这时候还是得靠人兜底，不能完全放手。

信任问题也很现实。出了故障，如果AI说“大概率是A服务的问题”，有人直接信，有人非要自己再验证一遍。验证多了效率下来，信多了又怕被带偏。我们现在的做法是把它当“高级助手”，建议可以听，但关键决策还是人说了算。

还有人的问题。有些老运维觉得这是在抢饭碗，心里不舒服。其实反过来看，重复的、机械的活被机器扛了，人才能腾出手去做更有价值的事——架构优化、容量规划、故障演练这些。但这个心态转变，需要时间。

成本也不能忽视。训练和维护模型要算力，要专门的人。中小团队如果数据量不大，强行上复杂模型，可能得不偿失。有时候简单的统计方法加上人工规则，性价比更高。

它到底改变了什么

用了一年多，最大的感受不是“AI有多厉害”，而是运维的工作重心在慢慢挪。

以前大量时间花在救火和重复劳动上。现在异常发现更早了，排查有了辅助，一些简单的自愈动作也能自动做。人开始有精力去想“怎么让系统更稳”，而不是“怎么让今天别再出事”。

智能运维不是取代人，而是把人从低效的重复中解放出来。真正难的、需要判断和取舍的地方，机器暂时还替代不了。比如业务优先级怎么排、故障影响面怎么评估、要不要做降级——这些还得靠经验和对业务的理解。

未来可能会走得更远。自动修复的范围会扩大，从简单的重启、扩容，到更复杂的配置调整甚至代码回滚。多模态可能把日志、指标、链路、甚至变更记录揉在一起分析。但前提是数据基础打牢，反馈闭环做好。模型给了建议，人执行后效果如何，得能回流，不然它永远学不会。

写在最后

有时候半夜还是会被叫醒。但次数少了，处理时间短了。打开电脑的时候，心里不再是纯粹的烦躁，而是先看一眼系统给的线索。

智能运维不是魔法，也不是银弹。它更像一个越来越靠谱的同事——有时候会说错话，但大多数时候能帮你少走弯路。关键还是自己得清楚它能做什么、不能做什么，别神话，也别排斥。

技术会继续往前走。我们要做的，大概就是保持一点好奇，再保持一点清醒。毕竟最终要对业务结果负责的，还是人。

（完）