上周跟一个在大厂做运维的朋友吃饭，他说上周三凌晨被手机震醒的时候，第一反应是想把手机扔出窗外。
啥情况？大促前全链路压测，告警系统半小时蹦了1200多条推送，全是重复的、关联的、没有优先级区分的内容。他坐在床上翻了二十分钟告警列表，眼睛都花了，才找到真正触发流量异常的那个网关配置错误。那天他到公司的时候，眼睛里全是红血丝。
先搞懂降噪到底是在降什么
很多人第一次接触AIOps告警降噪，第一反应就是把那些天天弹、从来没出过事的告警全屏蔽了。省事。但麻烦在于，你今天觉得没用的告警，可能就是下次故障前唯一的预警信号。之前接触过一个团队，觉得磁盘使用率超过80%的告警太吵，直接在告警平台加了全量屏蔽规则，结果半个月后有个日志盘写满，直接堵死了整个交易链路的写入流程，翻历史监控的时候才发现，那几条被屏蔽的磁盘告警，在故障爆发前40分钟就已经弹过了。
说白了，真正的降噪从来不是硬关告警，是把同时间窗口、同关联范围的告警做聚合、收敛、优先级排序。比如同一个集群里所有节点都报CPU使用率超阈值，根本不需要给运维弹10条一模一样的告警，合并成一条”集群整体负载超阈值”的推送就够了。这里最容易踩的坑，就是规则写得太死。有人直接定死”5分钟内3条同类型告警就自动合并”，结果真遇到单节点硬件故障，关键告警被合到集群整体告警的条目里，反而把最核心的故障信号给盖住了。弹性阈值的动态调整，是降噪能力能不能真正用起来的核心。没有哪个规则能适配所有场景，你得跟着业务的波峰波谷、服务的架构变化不停调，不存在一写就用一年的规则。
根因定位从来不是排个时间序
很多厂商吹根因定位的时候，说的天花乱坠，好像系统能自动把所有故障的根源给你找出来。实际落地的时候，很多人对根因定位的理解，就是把所有告警按出现时间排个序，找最早冒出来的那条。扯。那跟运维自己手工翻列表有啥区别？
真实的故障链路里，告警的先后顺序根本不能代表根因。比如你最先看到的告警是数据库慢查询，往上翻一层是应用层接口超时，再往上是网关的流量突增，最后扒到底，根源是某个边缘缓存节点挂了，导致所有请求直接打穿到数据库。如果系统只是按时间排序告警，你可能盯着数据库的慢查询调半小时参数，越调越乱。
很多团队花了大价钱买的根因定位系统，最后用不起来，问题就出在这里。系统内置的服务拓扑是半年前静态导出来的，根本跟不上实际的迭代速度——这周刚把两个服务拆成三个，下周又换了个新的消息中间件，系统里的拓扑图还是老样子，关联出来的所谓”根因”自然全是错的。运维最后还是回到老路子，自己登服务器翻日志、查调用链。没有实时动态更新的服务拓扑，所有根因定位都是自说自话。
别信开箱即用的万能神话
我见过太多销售吹，说他们的AIOps系统开箱即用，上线第一天就能把告警量降80%，根因定位准确率到90%。纯扯淡。你家的系统架构跟别家的能一样？你家的告警阈值是根据自己的业务特性调了三四年的，换个通用模型上来，直接把有价值的告警当噪音滤了，到时候出了核心故障谁担责？
之前接触过一个做电商的团队，从开始搭AIOps告警降噪与根因定位能力，到真正能在真实故障场景里帮上忙，花了快8个月。前面三个月全在洗数据——把过去三年的告警记录、故障处理台账、变更记录全导出来，给模型做标注，哪些告警是真故障，哪些是测试环境误报，哪些是节假日的特殊流量波动。中间两个月在调规则，把之前硬屏蔽的告警一条条捞回来，按不同的业务场景设不同的合并阈值。后面三个月才是在真实的故障演练里跑，每次出问题就复盘，模型这次找的根因对不对，漏了哪些关联关系。
上次再跟那个运维朋友吃饭，他说现在系统调顺了。上周压测的时候，还是半小时1200多条原始告警，最后系统收敛成27条有效信息，还直接标了3条疑似根因。他顺着点进去，3分钟就找到了那个网关的配置错误。那天他在家补觉，手机安安静静的。
这事没那么玄。
也没那么简单。