上周跟南京某互联网公司的运维组吃夜宵，刚坐下来半小时，组长的手机连震了七次。他苦笑着把屏幕扣在桌上，说这还算少的——大促前预演的时候，一晚上能弹四百多条告警，一半是关联触发的无效通知，剩下的一半里，能真的影响用户体验的，两只手数得过来。
先把堆在告警通道里的“噪音”清出去
很多团队最早碰告警泛滥的问题，第一反应是上规则引擎做简单合并。同个服务十分钟内弹的告警归成一条，同个机房的网络抖动通知打包成一条，折腾两三个月，看着告警量从每天上千条压到两三百条，正准备松口气，往往就会踩坑。之前有个运维组，上线这套合并规则的第一周，就漏了个核心数据库的慢查询告警——规则里把所有数据库类的告警，只要和CPU利用率告警同时间触发，就全归成关联告警合并了，偏偏那次慢查询是磁盘IO突增带的CPU抖动，根本不是同一个故障源。
真正有效的降噪从来不是“砍量”，是给每条告警标清楚“和谁有关、优先级多高、值不值得立刻看”。不是让告警越少越好，是让弹到值班人员手机上的每一条，都有明确的处理价值。
很多人对降噪的误解，就是把数量压下去就算赢。
错的。
你压下去的每一条告警，本质都是在给后续的故障排查埋雷。说白了，降噪的核心是做“信息提纯”——不是不让告警响，是不让无意义的重复通知，把真正需要人盯的关键信号给盖过去。
我见过不少团队做降噪，上来就追求“智能”，拿大模型去语义匹配所有告警内容，折腾半天，准确率还不如之前写的几条基础规则。原因也简单——之前攒了好几年的告警数据，本身就没有统一的标签体系，模型连哪条告警对应哪个业务模块都分不清，怎么可能准确判断哪些是噪音。
根因定位不是算命，是顺着告警链找源头
之前碰到个团队的技术负责人，吐槽他们花了大价钱上的AIOps平台，每次出故障，根因模块就给列十几个可能的原因，从网络抖动到应用内存泄漏到数据库连接池满，全列一遍，跟没说一样。值班的人盯着这堆选项，还是得挨个登机器查日志，跟没有这个模块的时候，效率差不了多少。
这事没那么玄。
现在真正好用的根因定位，根本不是靠大模型瞎猜，是先把整个系统的调用关系、依赖拓扑给理清楚——哪个服务调哪个数据库，哪个中间件挂了会带垮上面的哪几个应用，哪条链路的告警和哪条链路的告警是有因果关联的。根因定位的第一性原理，从来不是猜哪个指标异常，是顺着告警的因果依赖关系，找到整条链上第一个出现异常的那个节点。
很多团队做不好根因定位，根本不是算法不行，是之前攒了三四年的监控数据，标签全是乱的——有的告警标了服务名，有的只标了机器IP，有的连所属业务线都没写，你拿这种脏数据喂给模型，它能给你算出准确根因才怪。
对吧？你自己都理不清哪个告警对应哪个模块，指望AI给你理清楚，本来就是本末倒置。
我见过最离谱的一个场景，某个团队的AIOps平台定位某电商结算故障的根因，绕了三圈指到了办公区的打印机服务上——原因是打印机的监控告警和结算系统的告警，刚好在同一个机器IP上，因为标签没标清楚，模型就把两者关联到了一起。
别把AIOps当万能补丁，先把基础的监控账算明白
现在行业里总有一种浮躁的风气，好像不上大模型，不搞全自动的故障修复，就不算跟上了AIOps的潮流。但实际跑在一线的人都知道，很多团队的监控基础，还停留在“能看到指标就行”的阶段。
边缘节点的网络丢包没监控，缓存集群的命中率波动没采集，跨机房的专线带宽利用率连阈值都没设。这种情况下，别说AIOps了，就是把SRE团队24小时轮班盯屏幕，也未必能第一时间发现问题。之前有个做电商的团队，去年大促的时候出了个故障，用户点结算页面一直转圈，查了两个小时才发现是跨可用区的专线被运营商挖断了，他们之前根本没把专线的监控接入统一告警平台，AIOps工具连这个链路的指标都拿不到，怎么可能帮着定位根因。
其实做AIOps告警降噪与根因定位，最忌讳的就是一步到位的心态。
先把所有监控数据的标签统一了，把各个系统的依赖拓扑梳理清楚，再去谈用算法做关联分析，做降噪规则，做根因推导。别上来就买最贵的工具，搭最复杂的模型，最后连最基础的数据采集都没做全，钱花了，问题还是没解决。
上周跟之前那个运维组长再通电话，他们现在把告警量压到了原来的五分之一，半夜被叫醒的次数从每周三四次，降到了一两次。他说最爽的不是少加班，是现在告警弹出来的时候，他不用再花半小时翻关联日志，系统直接把可能的根因、关联的历史故障、需要排查的操作路径都列出来，他只要顺着点进去确认就行。
哦对，他们也没上什么特别复杂的大模型，就是把之前乱成一团的监控标签全理了一遍，搭了个简单的因果关联规则而已。
就这么简单。