做了三年运维我才摸透AIOps的真正用法

上个月陪南京本地一家做生鲜电商的客户做双11前的压测，凌晨两点群里突然炸锅。

值班的小孩连着发了二十几条告警截图，说系统CPU使用率跳得跟过山车似的，按平时的阈值算早就触发P0故障了，结果他们去年花了二十多万上的所谓智能运维平台，硬是把这些告警全压成了”低优先级提示”。

为啥？

因为模型的基线还是按三个月前平峰期的流量算的，压测阶段本来流量就是平时的四倍，在它眼里这波波动完全在正常范围里。

你说这叫AIOps？

这叫花大价钱给传统告警系统套了个AI的壳子。

别拿AIOps当告警系统的豪华换皮

我见过太多团队踩这个坑了。上来就把原来的Zabbix、Prometheus的告警数据全导进所谓的智能平台，指望模型自动把几千条无效告警筛成几十条有用的，连最基本的指标校准、场景标签都没打对。比如门店POS机的离线告警，本来在每天打烊后是正常的，结果模型不分时段，每天晚上十一点准时报一次”核心节点离线异常”，报多了值班的人直接把告警通道关了——真出问题的时候，反而没人看得见。

很多销售在卖这类产品的时候，总喜欢吹”智能降噪能减少90%的无效告警”，却从来不会告诉你，降噪的前提是你得给模型喂足够准确的场景标签。不然它根本分不清哪些告警是该压的噪音，哪些是真的会炸的雷。

能省人力的AIOps，从来不是靠”预测”吃饭

之前帮那家生鲜电商调AIOps的时候，我们没上来就换更贵的大模型。

先拉着团队翻了过去一整年的故障复盘文档，数了下，70%的故障最后根因都能归到三类：CDN节点缓存命中率掉幅过大导致回源带宽打满、业务代码内存泄漏导致应用实例频繁重启、数据库慢查询堆积导致连接池耗尽。

这些故障有个共同的特点：从第一个异常指标出现，到最后影响用户下单，中间至少有15到20分钟的窗口期。原来的流程里，值班的人要盯着十几个面板来回切，等看到用户侧的支付超时告警时，往往已经过了最佳处置时间。

我们做的调整特别简单：把这三类故障的关联规则先喂给模型，只要CDN命中率掉幅超过20%，同时回源带宽每分钟涨速超过100Mbps，就直接把对应的链路事件打包推给值班同学，甚至自动触发预案——把非核心的营销页面流量切到备用节点，给回源通道留够带宽。

就这功能。

比那些吹得神乎其神的”全局故障预测”有用一百倍！

有次压测的时候，模型提前12分钟识别到了CDN的异常，值班同学刚切完流量，那边原来的链路就真的因为带宽打满卡了。整个过程没影响任何测试用户，连之前要花半小时查根因的流程，现在两分钟就走完了。

不过话说回来，这已经比大多数花了大价钱却只换了个告警界面的平台强太多了。说实话，很多人对AIOps的期待太高了，觉得它能像个资深运维专家一样，坐在系统里帮你盯所有的指标，提前预判所有可能的故障。实际上现在大多数场景下，AIOps能把原来跨好几个团队、要花几十分钟才能理清楚的因果链给理明白，就已经值回票价了。

别指望AIOps能替你兜住所有底

上个月跟一个做企业服务的创业公司CTO吃饭，他吐槽说他们上了AIOps之后，本来想砍两个运维编制，结果上个月出了一次大事故，差点把公司赔进去。

啥事故？

机房核心交换机的光模块老化，导致出口带宽突然掉了30%。模型按照过去三个月的流量波动算，觉得这个掉幅属于正常的业务波动，直接把告警压成了普通提示。等客服接到客户投诉说系统登不上的时候，已经断网40分钟了。

为啥会这样？

因为从来没人给模型喂过”交换机硬件老化导致带宽掉幅”的样本。总不能指望模型自己凭空知道哪个光模块快坏了对吧？

别不信，真踩过坑的人都懂。AIOps的能力边界其实特别清楚。它擅长处理的，是那些有大量历史数据积累、重复发生的常规故障——比如磁盘坏道、内存泄漏、常见的接口超时、证书过期。但是涉及到从来没发生过的、跨硬件跨网络的新型故障，它比有经验的运维人员靠谱不了多少。

我见过最离谱的团队，上了AIOps之后，直接把原来的故障预案文档全删了，说反正模型会自动处置。真遇到模型没见过的场景，全组人对着面板大眼瞪小眼，连个应急的流程都找不到。

说真的，如果你现在正打算给公司上AIOps，别急着签几十万的年付合同。

先拉着团队把过去一年的故障记录全拉出来，数一下有多少是重复发生的，有多少是每次查根因要花超过半小时的。先把这些最痛的点用最简单的规则跑通，再考虑上模型做关联分析。

别被销售PPT里的”全链路智能预测”忽悠了。

真的好用的AIOps，从来不是什么高大上的黑科技。就是帮你把那些每天重复做的、费眼睛的、容易漏的事，给提前兜住而已。