HarmonyOS7 落地了 3 年 AIOps，我发现真正难的不是算法，是这 5 项工程能力

文章目录AIOps 不是算法问题那次翻车让我想明白了一件事真正决定 AIOps 生死的 5 项工程能力1. 可观测性数据治理地基里的地基2. 告警事件化从消息到事件3. 知识资产沉淀让 AI 有东西可答4. 编排与闭环从分析到处置5. 反馈机制让系统越用越准中小团队该怎么切入写在最后前几天参加一个行业交流会主持人问了句挺扎心的话AIOps 概念这么火为什么真正跑通闭环的团队还是不多我坐在下面想了一会儿。过去三年我陆续在几家公司参与过 AIOps 项目落地有大厂、也有中小厂。方案文档写过一摞架构图画了几十版PPT 演示也做得挺漂亮。但说实话真正让一线值班同学愿意用、并且用下来的没几个。问题不是模型不够强也不是数据不够多。真正卡住的地方永远是工程能力。AIOps 不是算法问题这是过去三年我看到的最大误解。一提 AIOps很多人第一反应是得用什么模型大模型能不能替代传统的规则引擎根因分析要不要上图神经网络这些问题当然重要但都不是决定项目死活的问题。决定死活的是你有没有一套稳定、干净、可复用的工程底座。我见过一个金融行业的团队请了顶级的算法团队做告警关联指标堆得满满当当。上线三个月后被值班同学集体投诉——模型给的建议大部分对不上因为底层的 CMDB 数据本身就是错的服务和实例的映射关系有 20% 以上的偏差。算法没错模型没错全垮在了数据源头。这种事在 AIOps 项目里太常见了。那次翻车让我想明白了一件事印象最深的一次翻车是在一家电商公司。老板批了预算专门给运维团队做智能故障定位。三个月冲刺做了一套挺完整的故障自动分析平台从告警接入、指标关联、拓扑分析、日志聚合到大模型生成诊断结论端到端跑得挺流畅。上线之前 Demo 演了好几场效果都不错。上线之后第一周就翻车了。值班同学跟我说了一句很扎心的话“平台给的结论不是不对是没用。”我一开始不服气。后来蹲了几个夜班才明白他们说的没用是什么意思平台说某服务响应异常——他们早就看到了不需要 AI 再告诉一遍。平台说疑似上游 XX 服务导致——上游有 6 个服务没说清是哪个。平台说建议重启 Pod——但没说这个建议的依据是什么也没说重启的影响面。值班的人是要在 5 分钟内做决定的。他们要的不是看起来智能的输出而是能直接指导下一步动作的答案。这个差距靠模型是补不上的。真正决定 AIOps 生死的 5 项工程能力下面这几项是我认为绕不开的硬功夫。顺序不是按重要性排的是按如果缺了后面基本白搞的依赖关系排的。能力一句话解释缺了会怎样可观测性数据治理让指标、日志、Trace、变更能被统一引用模型再强也只是在垃圾数据上做拟合告警事件化把碎片告警变成一个可操作的事件对象值班同学永远在信息海里游泳知识资产沉淀把 SOP、经验、复盘变成机器可召回的内容大模型只能靠通识回答答不到点上编排与闭环把诊断、通知、处置串成一条可执行链路结论再准也停留在看看而已反馈机制让每一次使用都能反过来优化系统上线即巅峰之后一路下滑一个个说。1. 可观测性数据治理地基里的地基这一步没做好后面所有事都是空中楼阁。很多团队的可观测性数据是这样的Prometheus 一套、ELK 一套、Skywalking 一套、CMDB 又一套。命名规则不统一服务标识不统一甚至同一个服务在不同系统里叫不同的名字。模型拿到这种数据光实体对齐就要花掉一半的算力。这件事的核心不是接入更多数据而是让不同系统的数据能被同一个身份关联起来。具体怎么做至少四个方向要拉齐。服务身份要统一service.name全链路一致别一会儿驼峰一会儿下划线。环境标签要统一env、region、cluster三件套是最小集。变更事件也要可观测——发布、配置修改、扩缩容都要有对应的事件流。时间戳统一到毫秒级 UTC别再让人对 8 小时时差。我带过一个团队光统一service.name就花了两周因为不同团队的技术栈选型差异太大。但这一步不做后面上什么算法都是浪费钱。2. 告警事件化从消息到事件这一步就是01.md里聊过的告警治理的正解。原始告警是消息一条一条发出来讲不清故事。值班同学需要的是事件——一个有起因、有影响、有推进状态的对象。举个例子。旧模式下群里刷出 36 条红色消息12 条超时、8 条重启、5 条网关抖动、11 条数据库慢查询看着就头大。新模式下这些应该被聚合成一条事件卡片事件 IDINC-20260708-014首个异常13:02:17payment-gateway响应时间 P99 突破 800ms影响面4 条业务链路预估影响 8% 订单优先级P1当前状态处置中负责人 张三关联告警36 条已聚合能做到这一步一线的排查节奏立刻就不一样了。工程上难在哪难在你要有一套告警聚合、去重、关联和降级的机制还要有一套事件生命周期管理。这是纯工程活儿跟大模型基本没关系。3. 知识资产沉淀让 AI 有东西可答这两年大家都在聊 RAG、向量库、Agent。但很多团队没意识到一件事你的知识库里根本没有值得召回的东西。我见过好几个团队兴冲冲搭了向量库把 Confluence 上几千篇文档全灌进去。结果一问就翻车——文档大部分是过时的写得像备忘录而不是操作指南甚至有一半是重复的旧版本。知识资产沉淀不是把文档拷进向量库就完了。SOP 要模板化每类常见故障都要有可执行的处置步骤不是根据经验判断。故障案例要结构化现象、根因、处置、影响、教训五要素缺一不可。每个核心服务都要有一份技术档案包括依赖关系、SLA、常见故障模式。变更日志也要可追溯——谁改了什么、什么时候改的、为什么改。这些东西整理好了大模型才有底气生成靠谱的建议。否则就是让一个再聪明的实习生去回答一堆他从来没听过的业务问题。4. 编排与闭环从分析到处置大部分 AIOps 平台的天花板都卡在这一步。分析做得再好最后落到界面上还是一段文字值班同学看完还得自己去操作。坦白讲这个体验和看 Grafana 大屏没本质区别。真正好用的 AIOps 平台应该能把诊断结论直接串到处置动作。判断出是慢查询导致的就一键生成慢 SQL 报告并 DBA。判断出是发布引起的就一键调用发布系统回滚。判断出是流量突增就一键触发限流预案。这里的核心工程能力叫编排Orchestration。你需要一套稳定的工作流引擎把监控、告警、诊断、通知、处置、复盘等环节串成一条链路。而且——重要的事说三遍——每一个自动动作都必须有人审批的兜底开关。别自动化搞得自己都不敢用那是真出过事的。5. 反馈机制让系统越用越准这是最容易被忽略的一项但也是决定长期效果的一项。AIOps 不是一次交付的项目是一个持续迭代的产品。没有反馈机制你根本不知道模型在真实场景里表现如何——是漏报了误报了建议不对还是建议对了但没人采纳我推荐的最小反馈闭环长这样每一条诊断结论旁边都有有用 / 没用 / 部分有用的按钮每一次自动处置结束后值班人可以补一条实际根因每周汇总一次反馈报告重点看建议采纳率和平均处置时间变化每月做一次数据回流把标注过的高质量样本喂回模型。这一步做不好AIOps 项目的宿命就是上线即巅峰。第一个月靠新鲜感和推广力度用户还愿意用。三个月后建议开始不准六个月后没人再点开平台。等一年 KPI 复盘时只剩一张漂亮的 PPT。中小团队该怎么切入前面这 5 项能力听起来挺重很多中小团队会问我们没那么多人力是不是就没法做 AIOps 了我的建议是——别一上来就做平台先做事件。头一两个月先把告警事件化跑通。不用做算法先做工程。把现有告警按业务链路做聚合输出结构化的事件对象。哪怕聚合逻辑一开始就是简单规则也比一堆碎片消息强。接下来三到六个月把 SOP 和故障案例沉淀成结构化数据。不用先上大模型。先让人写清楚 SOP 模板把最近半年的故障案例按五要素拆解。这一步能不能坚持下去直接决定后面做不做得成。六个月之后再引入 AI 能力。到这一步你的数据、事件、知识都是干净的无论上大模型做诊断助手还是上根因分析算法都会有明显效果。这个顺序反过来就是我看过的大部分 AIOps 项目翻车的原因。写在最后行业里聊 AIOps容易被新技术带偏。大模型、多模态、Agent、图神经网络……确实都是好东西但它们只是工具。工具用不用得好取决于底下有没有一套扎实的工程底座。三年下来我最大的体会是AIOps 本质上是一个工程问题不是一个算法问题。模型能做的事有上限工程能做的事没上限。谁把工程做扎实了谁的 AIOps 才真正跑得起来。哪怕最后你用的是最朴素的规则引擎只要数据干净、事件清晰、知识可用、编排跑得通、反馈闭环转起来了这套系统给一线带来的价值就已经胜过 90% 挂着 AI 名头的花架子。反过来讲如果这 5 项工程能力不到位就算你把 GPT-5 接进来它也帮不了你。它可能只是让你的错误结论生成得更快一点罢了。如果你想系统学习 AIOps推荐这个课程51CTO 明星讲师授课崔皓前惠普中国系统架构师、20年IT经验 韩先超K8s架构师、50万学员课程内容AI 大模型开启智能运维新时代AI 智能解析慢查询自动诊断 SQL 并给出优化方案自动化巡检实战Dify Prometheus DeepSeekAIOps 闭环实践基于大模型的对话式运维OpenClaw 微信 JenkinsDeepSeek RAG构建 K8s 智能故障分析平台企业级 AI 助手实时分析 EFK 错误日志智能运维新范式AI 故障预测与决策辅助零基础也能入门用 AI 智能体实现运维智能化点击链接快速直达 https://edu.51cto.com/surlVdSLK4