智汇 IT
城启新篇

AIOps落地那些藏在指标之外的事

上个月跟南京本地某股份制城商行的运维负责人约在珠江路吃鸭血粉丝汤,他把汤勺往瓷碗边重重一磕。

钱花了。

人累了。

效果没见着。

说去年砸了小两百万采购的全套AIOps平台,现在全组12个运维还是习惯凌晨三点爬起来查告警,那平台除了每周自动生成一份没人仔细看的运维周报,半毛钱忙都没帮上。

被高估的告警降噪能力

当初vendor过来做演示的时候,拍着胸脯承诺,上线之后能把日均告警量压到原来的10%,值班人员的告警处置量直接降九成。结果真跑了三个月,团队差点因为这平台出生产事故。

原因说起来有点好笑。模型训练用的全是两年前的老故障样本,今年新上的核心清算系统的告警,模型根本没见过,甚至好几次把正常业务高峰触发的阈值告警给当成噪音过滤了。上次跨城清算的节点延迟告警,就被平台直接吞了,等值班的人发现的时候,已经有三笔跨城转账卡在了队列里,差点触发监管的考核扣分。

城商行核心交易系统AIOps告警面板界面
城商行核心交易系统AIOps告警面板界面

说真的,我当时差点把嘴里的鸭血粉丝喷出来。

太多团队对AIOps的期待从一开始就偏了。总觉得把历史日志、监控指标、告警记录一股脑丢给模型,它就能自动识别异常、定位根因,甚至自动修复故障。哪有这么理想的事。90%的中小团队根本凑不出足够量的带标注的故障样本——你总不能为了训练模型,故意在生产环境搞几次宕机演练吧?剩下的那点零散样本,还是三四年前的老系统故障,现在系统迭代了七八轮,连当初写核心代码的开发都跳去隔壁做AI创业了,模型学的那点东西,早就和现在的业务场景脱节了。

真正能落地的AIOps长什么样

之前跟做本地即时配送的团队技术负责人聊天,人家的AIOps建设,从一开始就没追什么”全栈智能运维”的噱头。

整个平台就盯着三个最具体的场景打磨:第一,把早高峰派单系统的CPU抖动和骑手定位接口的延迟做关联映射,以前要花20分钟跨多个系统排查的网络抖动问题,现在系统能在30秒内定位到是哪个机房的接入交换机出了问题;第二,自动把重复触发、没有处置价值的告警归并成一条消息,比如同一个服务连续100次的超时告警,不会凌晨连环炸企业微信群;第三,每天早上自动给值班人员生成当日的重点关注清单,哪个服务的磁盘使用率快到阈值了,哪个数据库的连接数快打满了,根本不用人挨个翻十几个监控面板找问题。

本地生活配送系统AIOps自动关联故障链路图
本地生活配送系统AIOps自动关联故障链路图

不过话说回来,你别觉得这东西技术含量低。

人家这套系统,根本没采购什么贵得离谱的大模型服务,就是把过去两年值班人员手动排查故障的操作路径,拆成了几十条清晰的关联规则,再搭了个轻量的时序预测模型,算下来整个平台的建设成本还不到当初那家城商行采购平台的十分之一,但上线之后,值班的人每周能少熬至少两个大夜。

我见过太多团队,一上来就对标头部互联网公司的AIOps建设标准,什么全链路可观测、根因自动定位、异常自动修复,PPT写得比谁都漂亮,真落地的时候才发现,自己团队连最基础的指标命名都不统一——有的团队把接口延迟叫latency,有的叫response_time,有的干脆内部俗称”那个慢的数”,模型连输入数据都读不明白,谈什么智能?

别一开始就想着做”全自动”

很多人对AIOps的误解,在于觉得它是来替代运维人员的。

真不是。

真正靠谱的落地路径,永远是先当”辅助”,再当”主角”。

刚开始落地的时候,你根本不用追求什么全自动修复,哪怕就让AI帮你把海量告警按优先级排个序,把每个告警关联的最近15分钟的监控曲线、相关日志片段提前拉出来整理好,推送到值班人员的消息框里,哪怕最终的故障判断还是人来做,只要能把单次故障的排查时间从30分钟压到5分钟,这钱就花得值。

之前碰到个做垂直类电商的技术负责人,他们团队去年上AIOps的时候,根本没找外部供应商,就是组里两个懂Python的运维,花了两周时间写了个轻量脚本,把所有触发的告警先跑一遍规则过滤,再把每个告警对应的关联上下文自动整理成个短文档,推送到值班人的企业微信上。就这么个简单到不能再简单的小工具,上线之后,值班的人平均每次处理告警的时间,从原来的8分钟降到了2分钟,算下来一年能省出至少一个全职运维的人力成本。

上周跟那个城商行的运维负责人通电话,他说已经把原来那个大而全的平台给停了,现在就留了两个最实用的功能:一个是自动磁盘清理提醒,一个是重复告警去重。上周三凌晨他睡了个整觉,说这才是AIOps该有的样子。

免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。如有侵权请联系删除。
文章名称:AIOps落地那些藏在指标之外的事
文章链接:https://m.itcdj.com/it/421.html