凌晨两点，手机震了。值班群里三十多条告警，什么CPU高、接口超时、数据库连接池满。结果呢？核心交易没挂，用户只是慢了两秒。人先被吓醒了。
这就是很多团队上AIOps之前的日常。不是缺工具，是缺一条从“信号”到“动作”的路。
不少团队一听说AIOps，第一反应是买平台。买完发现，告警还是那么多，根因还是靠猜。问题出在哪？不是算法不行，是前面几块砖没铺好。
先说清楚 AIOps 不负责背锅
AIOps 这词听着玄。拆开看，AI 是手段，Ops 才是本体。它干的事无非几类：异常检测、告警收敛、根因定位、容量预测、自动修复。注意，自动修复排最后。为啥？因为修复动作越自动，风险越大。你让模型直接重启生产数据库？疯了吧。
我见过最离谱的落地，是把旧监控换个皮，大屏上加个“智能”两个字。然后汇报说 AIOps 上线了。说实话，这跟把闹钟改名叫管家没区别。闹钟还是闹钟，该响还是响。
第一个坑 数据没通就想喂模型
很多团队一上来就问，用啥算法，LSTM还是孤立森林？停。你先看看自己手里有啥数据。指标、日志、链路、变更、配置、工单。这些东西在不在一个时间轴上？能不能按服务、按实例、按版本串起来？
如果答案是不能，那算法只能学出一堆废话。比如 CPU 高了就告警，这玩意阈值也能干。AIOps 的价值在于关联。比如某个服务超时，同时段有发布变更，调用链里只有下游某个实例异常，日志里还出现连接池耗尽。把这些拼起来，才叫根因线索。
但现实是，指标在 Prometheus，日志在 ELK，链路在 SkyWalking，变更在 Jenkins，工单在 Jira。每个系统都挺努力，就是互相不认识。你让 AI 去破案，它连卷宗都没凑齐。
所以第一步不是买算法平台，是搞数据治理。至少把服务名、实例 IP、版本号、变更单号对齐。这事很土。但省不掉。
第二个坑 把告警收敛做成静音
告警收敛是 AIOps 最能快速见效的场景，没有之一。但很多团队做着做着，变成了“把烦人的告警关掉”。这就跑偏了。
收敛不是静音。收敛是分组、降噪、定级、找根因。比如一场数据库抖动，可能引发几十个服务超时。传统做法是每个服务都报。AIOps 应该识别出这是同一个根因事件，只留一条主告警，挂上受影响的服务列表。
这里有个关键细节：得有拓扑。没有服务依赖拓扑，算法只能靠时间窗口硬猜。猜着猜着就把不相干的事捆一起了。所以拓扑数据得准。别拿三个月前的架构图糊弄。架构早变了。
我之前跟一个团队聊，他们告警量从每天八千降到四百。怎么做的？不是换了多牛的模型。就是把告警按服务、按机房、按变更窗口聚合，再叠加上最近变更记录。简单吧？但有效。
第三个坑 指望 AI 直接给答案
这可能是最要命的期待。老板说，上 AIOps，以后故障自动定位。工程师听完心里一凉。因为故障定位从来不是纯技术问题，它跟业务、架构、人员操作都有关。
AIOps 能做的是缩小范围。比如从一百个实例缩到三个，从二十个可能原因缩到两个。剩下的判断，还得人来做。这不是 AI 不行，是生产系统太脏了。
那自动修复呢？可以做，但得分级。低风险动作，比如扩容、重启无状态服务、切流量，可以自动化。高风险动作，比如改数据库参数、回滚核心交易，必须人工确认。别为了酷，把刹车拆了。
还有个边界：AIOps 对突发未知故障往往不如对周期性、重复性故障好使。新问题来了，历史数据里没有相似模式，模型也懵。这时候靠的是可观测性基础和人的经验。
真要在团队里推 先干这三件事
第一，选一个窄场景。别一上来全链路。就选告警收敛，或者数据库慢查询根因。范围越小，越容易看到效果。效果出来了，团队才信。
第二，把变更事件接进来。很多故障根因就是变更。把发布、配置修改、扩缩容记录统一打标，和告警时间轴对齐。这一步做好，根因定位能快一半。
第三，定好人和自动化的边界。哪些自动执行，哪些只给建议，哪些必须人工。写成清单，别含糊。不然出了事，背锅的还是值班同学。
对了，还有一点。别忽略值班同学的反馈。模型准不准，他们最清楚。让他们能标记误报、漏报、正确根因。这些标注数据，比买现成数据集值钱多了。
收个尾 别把手段当目标
AIOps 不是大屏，不是算法比赛，更不是裁员工具。它是一套让运维从被动救火变成主动治理的方法。工具重要，但数据、流程、人更重要。
如果现在让我给建议，我会说：先别急着买平台。把告警理一遍，把拓扑画准，把变更记录接上。然后用一个最小的算法，解决一个最烦的问题。跑三个月，再看要不要扩大。
慢就是快。这话在运维里，真不是鸡汤。