蹲了三个月运维岗才懂的AIOps告警降噪与根因定位真相

上周帮一个做金融运维的朋友值了一次晚班。

凌晨两点十七分，监控面板跳出来127条告警。指尖刚碰到鼠标，又蹦出来40多条。群里已经有人在发”谁在改配置”的表情包。

朋友当时差点跳起来。去年他们花了大价钱上的AIOps系统，当时厂商拍胸脯说能把告警量降90%，结果呢？该炸的时候还是炸，甚至为了凑降噪率，把好几条核心链路的慢查询告警给压到”已归档”的分类里，上次核心交易卡顿，翻了半小时告警日志才找到问题源头。

所谓降噪，先得把无效告警拦在阈值外

很多人对AIOps告警降噪的认知从根上就错了。

上来就说用大模型做相似告警聚合，做告警收敛，听着高大上。实际上呢？你家监控里一半的告警，本来就是不该存在的噪音。

比如很多团队为了凑监控覆盖率，给所有服务器的磁盘设了80%的告警阈值。根本不管这台机器跑的是核心交易库，还是放了三年没人碰的冷备份。冷备份的磁盘用到90%都不会有任何影响，这种告警一年触发几百次，全是无效信息。你就算用最先进的算法把这些告警聚成一百组，组里的内容还是没用的噪音。

真的，别迷信算法先。先把监控阈值的家底清一遍，能砍掉30%的无效阈值告警，比啥复杂模型都管用。很多团队清完阈值才发现，之前每天上千条告警，有一半是因为阈值设的太敏感，或者监控对象根本就不需要告警。

降噪的第一步，从来不是用算法把告警藏起来，是先把那些根本不该发的告警给掐了。你要是把核心告警都给压下去，哪怕告警量降了99%，那也不叫降噪，叫埋雷。

根因定位的坎，从来不是找不出关联关系

每次跟厂商聊根因定位，对方都能拿出一套复杂的拓扑图，说能把所有微服务的依赖关系理的清清楚楚，故障出来自动定位根因。

实际用起来啥样？

上次跟一个做电商运维的老炮聊，他们家300多个微服务，全链路追踪埋点做的密不透风。每次小故障，翻链路图5分钟就能找到哪个节点报错。但真遇到大故障，告警炸的时候，整个链路图上飘满了红叉。哪个是因，哪个是果？

举个最常见的场景：数据库连接池满了，导致所有依赖数据库的服务都报接口超时，超时又触发了网关的熔断告警，熔断又触发了用户侧访问失败的告警，最后连客服系统的投诉量指标都触发了告警。这一串告警按时间顺序排，最先弹出来的是用户投诉告警，然后是网关熔断，然后是服务超时，最后才是数据库连接池满的告警。你要是顺着告警弹出的顺序往上找，找半小时都摸不到根因。

很多算法做根因定位，只看哪个指标的变化幅度最大。上次试点的时候，算法给的根因是”网关流量突增”。实际上网关流量突增是因为数据库慢，所有请求都堵在网关上排队。算法根本没考虑告警之间的因果传导顺序，只看了表象。

麻烦在于，因果关系从来不是靠算法凭空算出来的。你得先知道，哪个告警是能触发所有后续告警的最小源头。不是先发生的就是因，变化幅度大的就是因。是那个只要修好，所有其他告警都会自动消失的点。

真正能用的系统，从来不是给运维加活

很多团队上AIOps的路子从一开始就歪了。

上来就给运维派一堆活：先把所有告警的标签打全，把所有历史故障的根因标清楚，把所有依赖关系录进系统，给模型喂够数据才能跑起来。折腾三个月，运维本来值晚班就够累了，还要抽时间给模型当标注员。最后跑出来的结果，还不如老运维凭经验判断的准。图啥？

我见过落地最顺的一套AIOps告警降噪与根因定位系统，根本没搞什么复杂的大模型训练。就是把过去两年所有故障的告警串，按”根因告警-中间影响告警-结果告警”的顺序存成案例库。每次新告警出来，先跟案例库做相似度匹配，匹配到了直接把对应的根因和处置方案弹出来。准确率能到80%。

剩下20%匹配不上的，运维处理完故障，顺手把这次的告警串存进案例库就行。没有额外的标注任务，没有强制的流程要求，系统越用越准的前提是不额外增加运维工作量。

真的，别被那些概念忽悠了。什么因果图计算，什么大模型推理，听着厉害，落地的时候全是坑。你要搞清楚，AIOps是帮运维省时间的，不是给运维增加新的工作流程的。

上周那个金融运维的朋友跟我说，他们把之前买的AIOps系统退了一半的功能。现在就留了两个模块：一个是把同链路的告警按10分钟的时间窗口聚合，另一个是搭了个简单的历史故障案例库。现在值晚班的时候，一晚上收到的告警从200多条降到20多条，真遇到告警，翻案例库两分钟就能找到问题。

比之前那些花里胡哨的功能好用多了。