前言过去几年,运维领域经历了从监控、自动化、传统 AIOps 到大模型驱动 AIOps 的多轮演进。每一轮都解决了上一轮的核心痛点,但也带来了新的问题。传统 AIOps 用统计模型和规则引擎替代了一部分人力,却留下了黑盒决策不可解释这个顽疾。运维拿到的往往是一个分值,或者一条异常标签,至于为什么异常、该怎么处置,仍然要靠经验去补完。大语言模型(Large Language Model, LLM)的成熟,给这个问题带来了一个新的解法。它不仅能输出结果,还能讲出推理过程,能用自然语言解释一段告警传播链路,能把碎片信息组织成连贯报告,甚至能听懂一句话需求生成可执行的自动化流程。这些能力恰好覆盖了运维工作中最难自动化的那部分,也就是理解、推理、表达。本文整理了我们设计一套大模型驱动 AIOps 平台的全过程。整套平台共十五张原型图,覆盖数据接入、告警治理、事件聚合、根因定位、自动处置、复盘报告、AI 治理、成本管控八个核心能力。文章先讲清楚理论框架,再落到每一张原型图的具体实践,最后总结做这套平台过程中形成的几个判断,以及我们踩过的几个常见反模式。一、运维的本质与大模型的能力拼图要讲清楚为什么大模型适合运维,先把运维拆开看。剥离掉所有具体工具和流程之后,运维工程师日常做的事,可以归为三类语义任务。第一类是读。读告警标题、读日志、读工单、读变更记录、读监控图表。运维场景中超过百分之八十的信息是非结构化文本,字面各异但语义重叠。同一种数据库连接池打满的问题,不同系统写出来可能是DBConnectionExhausted、pool exhausted、连接池满、too many connections,字面差异巨大,语义完全一致。第二类是推理。把零散的信息串成因果链。比如认证服务延迟突增,API 网关依赖认证,支付服务依赖 API 网关,因此支付业务即将受影响。这种推理需要同时掌握拓扑关系、时序关系和业务上下文,任何一项缺失都会推出错误结论。第三类是表达。写复盘报告、写处置脚本、向上级汇报、给团队发周报。表达的本质是把脑子里那条推理链路,组织成别人能看懂的语言。同样一次故障,给 SRE 看和给 CTO 看,语言风格完全不同,但内核是一条。这三类任务,恰好是大语言模型最擅长的。监控平台积累了十几年海量数据,缺的从来不是数据,而是一个能把这些数据真正读懂、能推理、能表达的引擎。大模型补上了这块拼图。反过来说,大模型不擅长的部分,比如精确数值计算、低延迟实时响应、严格的事务一致性,运维平台里已有的传统组件早就做好了。两者是互补关系,不是替代关系。二、从 Gartner 五阶段看 AIOps 的演进Gartner 把 AIOps 的演进分成五个阶段,从被动监控到主动智能。我们做完这套平台后回看,大模型的引入其实是这个演进的自然延续。第一阶段是被动监控,系统出问题才有人去看。第二阶段是主动监控,通过阈值和告警提前发现异常。第三阶段是基础自动化,把重复操作固化成脚本。第四阶段是传统 AIOps,引入机器学习做异常检测、聚类、根因推测。第五阶段是智能自治,系统能自诊断、自处置、自优化。大模型的价值,主要集中在第四到第五阶段的跨越上。传统机器学习解决了识别异常的问题,但识别之后怎么办,仍然要靠人。大模型补上了从识别到处置中间这段理解与决策的空白。这也是为什么我们坚持把 AI 嵌进每一个环节,而不是做成一个独立的助手按钮。真正的智能自治,要求 AI 像脊椎一样贯穿全流程,任何一个环节断开,人就还得介入,自治就无从谈起。三、传统 AIOps 与大模型驱动 AIOps 的核心差异理解了运维的本质,再看两代 AIOps 的差异就清楚了。传统 AIOps 的算法核心是统计模型和规则引擎。它擅长做异常检测、趋势预测、告警聚类,但输出的形态是标签和分值。一条告警被打上异常标签,一个服务被给出 0.87 的健康分,然后呢?剩下的判断和处置还是要靠人。大模型驱动的 AIOps 在输出形态上有本质不同。它不只能告诉你这个服务异常,还能告诉你为什么异常、影响了什么、建议怎么处理。它的输出形态是自然语言解释加可执行动作,从结果输出升级为推理链路输出。更关键的是可解释性。传统算法是黑盒,大模型可以讲出推理过程。这次为什么认为根因是认证服务,模型会告诉你因为它延迟突增、错误在依赖图上向下游传播、其他服务同时段正常。这种可解释性是企业敢把 AI 放进生产环境的前提。还有一个容易被忽略的差异是交互方式。传统 AIOps 的交互是表格加仪表盘,运维要看图表、点筛选、翻菜单。大模型驱动的 AIOps 可以直接对话。运维问一句为什么支付服务受影响,AI 基于拓扑数据回答。这种交互把运维从在多个页面之间跳来跳去解放出来。四、三层认知架构基于上面的认识,我们设计了一套三层认知架构,作为整个平台的骨架。最底层是感知层。这一层做的是统一语言。把 Prometheus、CloudWatch、Datadog、Grafana 等不同监控系统五花八门的字段,映射到标准的service、severity、team字段上,并为每条告警补全上下文。没有这一层,AI 再强也读不懂原始数据。中间是认知层。大模型在这一层发挥主要作用。告警聚类、事件化、根因推理、自然语言解释、自动定级,都集中在这一层。这是平台的大脑。最上面是行动层。AI 把认知层的推理结果编排成工作流,自动或半自动地执行,然后把整个过程记录下来,生成复盘报告。这一层是平台的手脚。三层架构之间还有一条横向贯穿的能力,也就是 AI 治理。每一层产生的 AI 调用,都要被追踪、被审计、被评估。这条横线让 AI 不会失控。需要强调的是,这三层不是孤立的模块,而是数据流动的连续过程。一条告警从感知层进来,经过认知层的理解和推理,最终在行动层被处置掉,全过程可能只有几秒钟。人只在关键节点介入,比如确认高危操作、评审 AI 给出的方案。五、可信 AI 的五项要求企业级运维对 AI 的要求,不只是能用,而是可信。我们做完这套平台,提炼出可信 AI 的五项要求。第一是可解释。AI 给出的每个结论,都附带推理过程。不能只给一个根因是认证服务的结论,要给出为什么这么判断的依据。第二是可观测。AI 自身的每一次调用都被追踪、统计、评估,而不是黑盒运行。今天 AI 调了多少次,花了多少钱,错误率多少,都要看得到。第三是可治理。AI 能调什么工具、哪些动作需要人确认,一目了然。高危动作必须有兜底。第四是可问责。AI 的每个动作都进活动日志,带标识,审计无死角。出了问题能追溯,不能是笔糊涂账。第五是可控成本。LLM 调用成本独立核算,避免失控。一次 Token 调用几分钱,乘以每天几万次,一个月账单可能让人吃不下饭。这五项要求,直接对应了后面要讲的 AI 治理那组页面和价值闭环。它们不是事后补丁,而是平台设计的起点。任何一个不满足,平台都上不了生产。六、平台整体架构整套平台共十五个核心页面,按导航结构组织为四个区域。核心运维区有十个页面,涵盖告警源、映射规则、富化规则、告警详情、事件详情、事件追踪、服务拓扑、工作流、事件时间线、活动日志。这是平台的主干,解决业务问题。智能分析区有四个页面,包括事件生命周期、LLM 可观测性、LLM 调用追踪、技能管理。这一组解决 AI 自身的问题。FinOps 区有一个页面,也就是成本智能 FinOps,解决成本问题。这三组共同构成一个可信、可观测、可问责的智能运维闭环。下面按用户实际使用顺序,逐层讲清楚每一张原型图的设计思路和 AI 嵌入点。七、感知层实践,统一接入与数据治理感知层做的是最不起眼但最关键的事。AI 再强,喂进去的数据是脏的,输出的结论也是脏的。这一层是整个平台的地基。告警源页面集中接入所有监控系统的告警,形成统一告警流。这一层本身 AI 含量不高,但它是后续所有 AI 能力的燃料。没有统一的告警格式,模型再强也读不懂。一个中等规模公司通常有三到五套监控系统并存,Prometheus 看基础指标,CloudWatch 看 AWS 资源,Datadog 看应用性能,Grafana 看自定义大盘,Zabbix 看老机房。把这些不同来源的告警归一到一套数据模型里,本身就是一项大工程。映射规则页面解决字段标准化的问题。不同监控系统的字段格式千差万别,Prometheus 一套写法,CloudWatch 另一套写法,要把它们映射到统一的标准字段上。传统做法是运维翻历史告警,人工总结规律,然后一条条手写规则。几十上百条规则,够写一个星期。我们在这一页加了一个AI 智能生成规则的入口。背后做的事是扫描过去若干天的历史告警样本,用机器学习发现字段之间的隐藏关联,然后自动生成一批规则草稿,每条规则带置信度。运维只需要审核、启用,不用从零写。这是 AI 最朴素的用法,把人总结规律的工作交给机器,效率提升是数量级的。富化规则页面是映射的进阶版。映射解决这是什么,富化解决这归谁管、急不急、影响什么业务。一条告警进来,光知道它是来自auth-service的500错误还不够,要知道它归哪个团队、影响哪个业务线、历史上类似情况定什么级别。这一层 AI 同样基于历史处置记录学习,自动推断哪类告警通常归哪个团队、定什么优先级。八、认知层实践,从告警到事件的智能跃迁告警标准化之后,真正的难题才开始。事件详情页面是平台认知能力最集中的体现。一次故障,几百条告警同时涌进来,如果让运维一条条处理根本来不及。这一页做的核心工作是把同一根因引发的海量告警,聚合成一个事件。这个聚合不是简单的group by字段,我们综合了三种关联。第一种是语义相似度。不同措辞的告警标题,模型能识别出是同一类问题。比如DBConnectionExhausted和数据库连接池满,字面完全不同,语义重叠。这是传统规则做不到的,规则只能精确匹配,模型能理解语义。第二种是时序关联。同一时间窗口内的告警,大概率是同一个故障的不同表现。但单纯时序关联会误报,所以必须和拓扑关联配合使用。第三种是拓扑关联。依赖图上同一条链路的服务,如果认证服务故障,API 网关会受影响,支付服务也会受影响,这三条告警应该归到一个事件里。三种关联综合起来,才能把几百条告警压缩成一个事件。运维处理一个事件,等于处理了几百条告警,这是质变。聚合完之后还要定级。P0 还是 P3,半夜要不要叫人起来,以前靠人判断。现在 AI 综合影响范围、严重程度、传播速度、业务关键度四个维度自动判定。支付服务挂了和内部工具挂了,严重性能一样吗,显然不能。模型能区分。告警详情页面是单条告警的完整视图,原始字段、映射后字段、富化信息、相关历史都齐全。AI 在这里做的是翻译工作,把这条告警用自然语言讲给运维听,它在说什么、严不严重、历史上有没有出现过类似情况。九、服务拓扑,AI 含量最高的地方服务拓扑页面单独拿出来说,因为它是整个平台 AI 含量最高的地方,也是大模型价值体现最直观的地方。打开拓扑页,右侧有一个 AIOps 智能助手面板。这个助手做三件事,每一件都对应一种过去只有经验丰富的运维工程师才能做的工作。第一是标出根因节点。图上某个服务旁边那个根因标签,不是人工点的,是 AI 算出来的。模型分析告警在依赖图上的传播方向和时序,反推出最上游的故障源。这种推理以前要 SRE 工程师盯着依赖图看十几分钟,现在模型几秒钟给出答案。第二是用自然语言解释传播链路。助手面板里会有这样一段输出:检测到 认证服务 → API 网关 → 支付服务 链路存在告警传播 认证服务响应延迟突增 320% API 网关错误率上升至 5.2% 支付服务受级联影响,超时增加 推测根因为认证服务 auth-service这是大模型真正发挥作用的地方。它把干巴巴的指标,翻译成运维看得懂的语言。传统 AIOps 给一个分值就结束了,大模型直接把推理链路告诉你,连为什么都一起给了。第三是给出可执行的快捷动作。分析根因传播路径、执行自动恢复工作流、查看指标曲线、生成事件分析报告。底部还能直接反问它,比如为什么支付服务受影响,它会基于拓扑数据回答。这一步省掉了查文档、翻代码、问同事的环节。举一个更具体的场景。凌晨三点,支付服务开始报错,运维被叫醒。打开拓扑页,AI 已经标出根因在认证服务,助手面板给出传播链路分析,并提示近 24 小时内有一次相关变更。运维点一下查看变更详情,发现两小时前有人在认证服务发了一个新版本。根因基本锁定,要么回滚版本,要么让值班开发修。整个过程从过去的半小时,缩短到三分钟。十、行动层实践,AI 编排与自动处置行动层是 AI 真正替代运维脚本工程师的地方。工作流页面分两层 AI 能力。第一层是 AI 能力节点。左侧组件库的AI 能力分组下,有三个可拖拽节点,AI 根因分析、AI 总结、AI 分类。把它们拖进工作流,就能在自动化流程里调用大模型做判断,而不是写死if-else。这件事的意义比看起来大。传统工作流碰到严重程度模糊的情况,只能走默认分支,因为if-else没法处理模糊地带。比如告警描述写的是延迟较高,到底是高到什么程度,if-else判断不了。AI 节点能像人一样灵活判断,该走哪条分支、该通知谁、该等多久,都能动态决定。第二层是 AI 生成流程。画布顶部有个AI 生成流程按钮,用一句话描述需求,比如:每分钟检查 GPU 利用率,超过 90% 就扩容并通知值班人AI 直接画出完整的流程图。定时触发接查询数据源接条件分支,条件满足就走扩容脚本加 Slack 通知,不满足就延迟等待。节点连好,字段填好,只要微调参数就能跑。这件事把工作流的门槛,从会编程降到了会描述需求。事件追踪页面是单个事件的处置全过程,从发现到恢复的状态机可视化。每个状态转换都自动记录触发原因,AI 在关键节点给出下一步建议动作。事件时间线页面是事件全过程的时序视图。几点发现、几点告警频次变化、几点人工介入、几点恢复。这个时间线不是人工维护的,系统自动从告警、变更、部署、工单等多个源头拼接而成。AI 在关键拐点标注为什么这里发生了变化。活动日志页面记录谁在几点做了什么。所有人工与自动操作都进审计流。AI 自动执行的动作也作为一条活动记录,带 AI 标识,可追溯、可审计。出问题的时候,这份日志就是定责的依据。事件生命周期页面把事件按生命周期阶段做仪表盘视图,检测、响应、修复、复盘、归档。每个阶段的转化时长由 AI 监控,卡在某个阶段超过阈值会自动催办。比如某个事件卡在修复阶段超过三十分钟,系统会自动通知升级。生命周期末端的归档总结由 AI 生成。十一、复盘环节,AI 替你写不想写的东西故障解决完,真正折磨人的是复盘报告。要梳理几点发现、几点升级、根因是什么、影响了什么、怎么改进。一份像样的报告,以前要写半天。拓扑页那个生成事件分析报告的快捷动作,背后做四件事。读取事件时间线,读取活动日志,读取拓扑根因分析,然后让大模型组织成结构化报告。事件概要、时间线、根因分析、处置过程、改进建议,五个模块齐全。你拿到的是一份草稿,改改就能交差。这是大模型最擅长的能力,把碎片信息组织成连贯叙事。从半天缩到半小时,这是实打实的增量价值。需要强调的是,AI 生成的报告是草稿,不是定稿。最终的改进建议、责任划分、后续 Action 项,必须由人审阅确认。AI 帮你省掉的是组织信息的时间,不是判断责任的时间。十二、AI 治理,让 AI 自身也可被审计做完前面那些,大多数 AIOps 平台就停下来了。但我们觉得不够。真正用大模型的平台,一定把大模型自身的运行也纳入可观测体系。这是我们这套平台区别于市面上一堆伪 AIOps的关键。LLM 可观测性页面是全局视角。所有大模型调用的健康度一目了然,调用次数、错误率、Token 消耗、模型分布、活跃应用、质量评估。这页让管理者看清,AI 到底在干活,还是在不该调的时候乱调。如果某个应用的 Token 消耗突然飙升,这页能第一时间发现。LLM 调用追踪页面是单次调用的端到端展开,布局参考了 Datadog。左栏是过滤加调用列表,每行展示状态、时长、模型、输入、输出。中栏是 Trace 详情,INPUT 和 OUTPUT 完整展开,错误堆栈、Token 拆解都有。右栏最有意思,是另一个 AI 来诊断这次调用为什么失败。比如一次调用报错openai.AuthenticationError: 401,传统做法是工程师去看日志、翻代码、排查半天。我们的做法是让另一个 AI 直接给出诊断:本次 Trace 在 1.52s 内失败,核心错误为 401 鉴权失败 系统连续重试 3 次均失败,推测根因为 API Key 已失效或被吊销 近 30 分钟内同类错误已出现 87 次,集中在 shopist-chat-v2 服务 其他服务调用 OpenAI 正常,排除 OpenAI 全局故障这是 AI 治理 AI 的典型范式。大模型调用量大、错误形态复杂,人力根本排查不过来,必须用模型治模型。技能管理页面是 AI 治理的另一个支柱。AI 助手可调用的能力,以前是隐藏的,运维不知道 AI 能调什么工具、什么时候该确认、什么时候是安全的。我们把它做成了显式页面。每条技能有名称、运行环境、安全等级、描述、操作。比如query_promql是查询 Prometheus 指标,运行在云端,安全等级高,只能 AI 调用。host_bash是在目标主机执行 bash 命令,运行在设备端,安全等级是需确认,因为这是高危操作。右侧还有统计面板。今日热门调用 Top 5、运行环境分布、安全等级分布。运维能清楚看到 AI 现在能干什么、实际在干什么、哪些动作是安全的、哪些需要人确认、还缺什么能力。这是把 AI 黑盒打开成 AI 工具箱的关键一步。一个不可解释的 AI 是不可信的,一个能力清单透明、调用记录可查、危险动作需确认的 AI,才是企业级运维能接受的 AI。十三、价值闭环,FinOps 把成本管起来最后一个独立分区是 FinOps,成本智能。大模型驱动的运维,如果不控制成本,很容易从提效工具变成烧钱机器。一次 Token 调用几分钱,看着不多,乘以每天几万次调用,一个月下来账单能吓人一跳。如果再有几个跑批任务用gpt-4-turbo,成本可能直接翻几倍。FinOps 页面把 AIOps 平台自身的运行成本管起来。成本概览、各服务成本占比、成本趋势、模型明细表、降本建议,都齐全。哪些任务可以从gpt-4降到gpt-3.5而不影响效果,哪些应用的调用量异常飙升,模型一算就知道。成本管控的另一个维度是路由策略。同样的请求,简单分类任务可以走便宜的小模型,复杂推理任务才走gpt-4或 Claude Opus。这种智能路由能让整体成本下降百分之三十到五十,而效果几乎无损。把 FinOps 单独拿出来,体现的是平台对投入产出比的负责态度。AI 不是免费的,任何一个想长期跑下去的 AIOps 平台,都必须把成本算清楚。十四、人机协作模型讲到这里,有必要明确一下人和 AI 在这套平台里的分工。我们设计的是人在环里(Human in the Loop)的协作模型,不是完全自治。AI 做的是候选生成。候选根因、候选规则、候选流程、候选报告、候选处置方案,都由 AI 给出。AI 的强项是广度,能在海量数据里快速找到可能的答案。人做的是拍板。确认根因是否正确、流程是否合理、报告是否准确、处置是否安全。人的强项是深度判断,能识别 AI 不容易捕捉的边界情况和业务上下文。低风险动作可以让 AI 自动执行,比如查询指标、生成摘要、聚合告警。高风险动作必须人确认后才能执行,比如host_bash这类在主机上执行命令的技能、比如回滚版本、比如扩容缩容。这种协作模型的好处是,既享受了 AI 的效率,又保留了人的控制权。运维从操作工变成判断员,这恰恰是 AI 时代运维工种的升级方向。十五、几个常见的反模式做这套平台的过程中,我们见过也踩过几个反模式,值得拿出来说说。第一个反模式是AI 装饰。在传统监控平台右上角放一个紫色按钮,点一下弹个聊天窗口,美其名曰 AIOps。这种做法 AI 没有真正参与决策,只是个聊天机器人,运维还是用老办法干活。识别这种反模式的方法很简单,看 AI 的输出有没有进入业务流程。如果 AI 给的建议需要人手动复制粘贴到别的地方执行,就是装饰。第二个反模式是黑盒自治。让 AI 直接执行所有操作,不给运维看推理过程,也不让人确认。短期看效率高,一旦 AI 误判后果很严重,比如把生产数据库当测试库给重置了。企业级运维永远不能接受这种黑盒。第三个反模式是无视成本。接入大模型就开始用,不做路由,不做监控,月底账单出来才发现成本失控。这种平台活不下去。第四个反模式是忽视数据质量。感知层没做好,字段不统一、上下文不全,直接上 AI。结果 AI 给的结论全是错的,因为喂进去的数据就是错的。垃圾进,垃圾出。这四个反模式的共同点是,把 AI 当成银弹,不愿意做配套的工程化工作。真正能落地的 AIOps 平台,工程化比算法重要得多。十六、效果如何衡量最后一个实操问题,怎么衡量这套平台的效果。我们关注四组指标。第一组是效率指标。MTTD,平均发现时间,从故障发生到平台识别的耗时。MTTI,平均识别时间,从识别到定位根因的耗时。MTTR,平均恢复时间,从定位到恢复的耗时。引入 AI 之后,MTTI 的改善通常最明显,因为根因定位是 AI 最擅长的环节。第二组是规模指标。每天处理多少告警、聚合成多少事件、自动处置多少、人工介入多少。这些数字能反映平台的吞吐能力和自动化程度。第三组是 AI 指标。每天 AI 调用多少次、错误率多少、Token 消耗多少、成本多少。这组指标对应 AI 治理页面。第四组是质量指标。AI 给出的根因是否准确、聚类的准确率、定级的合理率。这组指标需要人工抽样评审,是 AI 优化的依据。没有这四组指标,平台做得再花哨也是空中楼阁。可衡量的东西才能改进。十七、AI 替代的是任务不是岗位做完这十五张图,有几个判断想分享出来。第一个判断,AI 替代的不是岗位,是任务。很多人担心 AI 会让运维失业。我们的观察是,AI 替代的是那些重复、繁琐、本来就该自动化的任务。翻历史告警总结规律,盯拓扑图找根因,手写复盘报告,排查 LLM 调用失败,这些任务被 AI 接管之后,运维腾出来的时间,应该去做更有价值的事。比如设计更稳的架构,比如评审 AI 给出的方案,比如处理那些真正需要人判断的边界情况。运维这个工种不会消失,但会升级。从操作工升级成判断员,从执行者升级成决策者。十八、可解释比智能更重要第二个判断,可解释比智能更重要。传统 AIOps 给一个分值就结束了,你不知道它为什么这么判,出错了也没法追溯。大模型最大的不同是它能讲出推理过程。如果一个 AI 不能解释自己的决策,它就只能做辅助,不能做决策。可解释性,是 AI 从辅助走向自治的门槛。这也是为什么我们在拓扑页让 AI 用自然语言解释传播链路,在 LLM 调用追踪页让另一个 AI 给出诊断推理。每一步推理都要可见、可追溯。十九、AI 治理 AI 不是噱头是必然第三个判断,AI 治理 AI 不是噱头,是必然。大模型调用量太大,错误形态太复杂,靠人盯是盯不过来的。必须用模型治模型。我们的 LLM 调用追踪页面里,当一个调用失败,另一个 AI 来诊断它。这种嵌套的 AI 看起来奇怪,但它是唯一能跟得上大模型规模化的治理方式。未来 AIOps 平台的竞争,不是谁的功能多,而是谁的 AI 治理体系更完善。谁的 AI 更透明、更可控、更可审计,谁就能赢得企业客户的信任。结语回到这套平台的设计起点。我们想做的,不是一个贴着 AI 标签的传统监控平台,而是一个把大模型作为中枢神经的真正智能运维平台。大模型在每一个环节参与决策,从告警进来的第一秒到事件归档的最后一刻。它帮你造规则、聚类告警、定位根因、编排工作流、写复盘报告,同时它自己也被另一个 AI 监控着、治理着、被算着成本。这就是大模型驱动的 AIOps 平台的核心价值。它不是让你看见更多告警,而是让你处理得更少、判断得更快、决策得更准,同时让 AI 自身可被信任。运维这个工种,终于有可能告别凌晨三点的连环告警。