本文分享了阿里巴巴构建可观测Copilot的实践经验，该系统融合可观测数据和大模型能力，实现运维问题自动化归因定位。构建过程中面临数据异构、认知差异和执行障碍等挑战，通过统一数据建模、开发专用SPL查询语言、整合知识图谱等解决方案，实现跨云产品统一分析和智能故障排查，已在内部云监控2.0成功应用。

---

第27届 GOPS 全球运维大会暨研运数字化技术峰会 2025 · 上海站，阿里巴巴智能可观测团队后端算法研发工程师刘进步，带来《可观测场景 Copilot 构建实践与思考》的分享。内容亮点：

• 可观测 Copilot 的任务
• Copilot 构建中的问题
• 解决思路与尝试
• 应用场景与实践案例

一

可观测 Copilot 的任务

要构建可观测 Copilot，我们认为需要理解运维日常处理问题的流程。

1、运维工程师处理问题时的流程

运维处理问题的流程通常始于对各类数据的收集和清洗，在初步界定问题的边界后，转交给相关的负责人，而接手的同事会在其负责的领域，重复一遍这样的过程。

我们希望 Copilot 协助完成这个过程，这里的数据收集、清洗与可视化通过大模型已经处理的比较好了。另外，比如想找相关的同事找到问题的边界，只要将这一步拓展出去，我们就希望大模型能半自动的将这个过程完成。

2、可观测 Copilot 的必要能力

构建可观测 Copilot 涉及三个必要能力：

1. 数据获取与分析，主要涉及收集、清洗和可视化。
2. 系统探查与链路感知
3. 根因定位与故障传导链推理，给出可靠的问题传导链路。

3、可观测 Copilot

可观测 Copilot，是融合可观测数据和大模型能力的运维新范式，它更像一个智能运维的专家，基于给出的数据、专家知识最终实现自动化的归因定位能力。

主要涉及三个模块：

• 数据模块，提供全栈的可观测性。在大模型出来之前，我们已经提供端到端的全链路监控能力，将数据收集整理起来，供大模型消费使用。
• 推理能力与决策能力，这方面主要依赖大模型自身的能力。
• 在运维特定领域，由于内部的知识尚不完善，需要引入外部领域知识。为此，我们系统性提取了工单数据、用户手册，用于增强大模型的决策能力。

二

可观测 Copilot 构建中的难点

基于以上出发点，在实践过程中，主要遇到三类问题，即数据、模型认知与执行层面。

1. 数据问题

在数据层面，面临的首要挑战是可观测数据种类多样性，常见的 Metric、Log、Trace，Profiling 等数据形态异构。尽管已实现数据采集，但内部评估与用户反馈来看，不同数据源的联通性没有那么好。

取数上的困难集成到 Agent 会进一步带来：

• **上下文构造的困难。**构造上下文时通常需要繁琐的操作，将各种数据收集起来并过滤，这个对于模型其实也有一定的门槛。
• **可观测的数据量大。**这一方面受限于模型上下文长度的限制。
• 作为在线服务系统，可能有一些延迟上的要求。
• 作为可观测数据，它的信噪比可能会非常高，可能 99.9% 以上数据都是正常数据，让模型去找出异常数据比较困难，专业的运营人员需要大海捞针地将需要关注的异常数据找出来，其实都是有一些门槛的。

基于种种情况，寄希望于大模型还是有一定的难度。

2、认知差异

第二是认知差异。

• 运维领域的专业性和用户自然语言描述存在鸿沟。比如说客户提出“流量突然跌下去”或“服务延迟有抖动”等笼统表述，缺乏上下文信息。大模型主要基于通用文本训练，对特定领域的模糊问题理解还是有一定困难。
• 生产环境的系统是动态变化的。可能用户提问过程中，后端的微服务系统已经产生了新的变更。让模型要及时感知到变更信息其实也有一定门槛。
• 在根因定位过程中，我们希望基于真实的、可靠的、用户可以信任的根因链路结果，去做进一步的故障恢复处理。虽然现在有基于大模型的可解释性手段，但在之前更多认为它是一个黑盒的逻辑，给到的结果很难直接判断它是不是有一定的依据。

相信大家在实践时，也会发现大模型会给出这种看似比较合理的答案。同一个问题正向的问与反向的问都会给出一些解释。这对于比较严肃的运维场景来说，不是特别好。在实际落地中如果有这样的问题，其实很难去真实用起来。

3、运行障碍

最后是大模型和环境交互时面临的问题。

1. 历史沉淀的运维工具多以脚本形式沉淀（代码风格不统一），内部现有工具往往功能集成度高，命令行参数复杂。模型一般比较擅长使用功能聚焦、语义明确的工具，这对于大模型也不是很友好。
2. **任务规划缺少可以触达的完整环境。**阿里内部各产品通常有独属运维团队。一旦一个系统出问题，这个功能可能涉及不同的团队，在定位、模型做决策的时候，很难去触达其他团队的业务领域。这方面没有打通的情况下，做任务规划的归因定位是一件比较困难的事情。
3. **脚本在执行时，需要确保安全可靠（不希望造成什么线上事件）的沙箱环境容纳各种云产品。**既要保证覆盖广又要保证绝对安全，另外也不希望模型带来的幻觉影响线上的服务。
4. 人机协同。其实主要涉及到模型的输出对于运维来说是不是可以理解的，是不是可靠的？对于运维给出的反馈模型是不是也能很好的接收到。

三

解决思路与尝试

针对以上几个问题，在构建可观测性时，做了感知、认知、执行方面的尝试。

1、五官：感知层

在数据组织层，我们希望将不同云产品中涉及的概念做统一化处理。

今年，我们的核心精力聚焦于数据建模与数据打通工作。我们定义了一些可以被认为是知识图谱的概念，然后在数据采集上加上 ID，保证将这些数据都串联起来。

在可观测领域，借助 UModel 的核心建模能力，将日志（Log）、指标（Metric）、链路（Trace）、事件、变更等多源可观测数据，自动抽取成实体（Entitiy）及其关系网络。以及数据存储的具体 Storage、可视化方式 Explore、处理实体和实体之间的 EntitySetLink、实体和数据之间的 DataLink，数据存储的 StorageLink，绘制了一张精准的且动态更新的“全局地图”。整体上，尽量做到比较简单接入类似 OT 的协议，方便进一步扩展。

2. 五官：感知层（故障排查）

借助统一建模，问题定位不再需要切换多个平台，可以沿着拓扑链路一跳一跳地自助化进行探索，加速故障闭环，模型也可以通过一个低成本的方式探索进去，不断地监控服务并发现服务的异常。

3、五官：感知层（产品形态）

上图是目前大概的产品形态，是一个最终呈现的结果。这个在现在的产品和官网中其实也有介绍，大家也可以去体验试用一下。

4、双手：执行层（取数逻辑）

完成数据统一建模后，后边要处理的问题就是如何高效、便捷获取数据。我们希望构建一种对大模型友好的。在可观测领域，传统查询数据的方式是通过 SQL 或 PromSQL，在现实中没有采取 SQL 这种方式，主要有几个考虑：

1. 有些可观测数据的存储介质可能不太适合 SQL 引擎，这是一个比较硬性的限制。
2. 可观测数据本身业务化程度较高，并非单纯的表格数据，这种对 SQL 也不是很方便，在拿到 SQL 结果之后还要做很多后处理。
3. 在数据科学领域，不管大家在用 Numpy、Pandas、Notebook 等 Python 数据管理工具，其编程方式是一种渐进式、增量式的，一步步将数据分析的流程做出来。我觉得这种方式比较适合人去理解，也比较适合大模型的增量式处理分析。

为了打通跨域分析的最后一公里，专门实现了一套针对数据可观测的 DSL（内部定义为 SPL）。我们最终将 SPL 作为获取底层数据的基础手段，所有的 Model 定义的数据都通过 SPL 访问，其中涉及的鉴权、数据存储位置都通过 SPL 里面的算子统一处理。

5、双手：执行层（联合查询）

上面是 SPL 执行的一些效果，这幅图主要介绍通过 SPL 拿到实体相关联的可观测数据，在表格中也能查到可观测数据的保存位置、Meta 信息。

下面的图表主要是展示实体，就是在 UModel 上做游走时涉及到的算子。

6、双手：执行层（范式规约）

除了给 Copilot 提供底层算子，还有一些基于算子包装、抽象程度更高的算子，SPL 不像 SQL 是通用的语法，模型再次生成 SQL 来说比较简单，对于复杂场景，生成的 SPL 准确率没有那么高。

对于一些高频、实现起来复杂的，可能通过一些工具包装暴露出来；而对于简单的字段提取、数据过滤，大模型生成的 SPL 就能有效处理。处理完工具并调用 Agent 部分，我感觉大部分时间是在处理上下文工程。目前提供给大模型的上下文，主要包括历史信息，就是在 plan 之前的步骤及之前步骤的处理结果、当前待解决的问题和供使用的工具及数据模型 & 数据样例。

这里面临的问题就是可观测数据量非常大，是直接给到大模型还是有其他的手段去处理？这里其实可以看一下之前的统计。

7、双手：执行层（上下文压缩）

时序数据在分词之后大概会有 4, 000 多个 Token，一个 Trace 的 Span 可能会消耗 800 多 Token。一次分析过程中可能会消耗掉的 Token 数量非常大（可能几十万），一般常见的大模型上下文应该是 128 K 左右，如果将现场数据全部放进去是不切实际的。一方面是延时会非常高，另一方面数据越长，产生幻觉的概率越大。

目前处理方式沿用了之前积累的运维算子，对于时序我们会做一些变点检测和分区间，并做一些异常检测及时序预测，我们将常见的算子所产生的时序处理结果进行包装，这一过程可以被认为是对于需要关注的时序的压缩。对于日志，我们沿用日志模板提取的方式提取关键日志，再基于模板做一些日志的异常处理，提取出来可能会是是模型需要关注的日志；Trace 的话也是 Trace 聚类的操作。

通过各种传统机器学习算子的压缩之后，我们希望能将可观测的数据量整体上有几个级别的收敛。

8、大脑：认知层（知识+反思提升）

有了执行层，如何将大模型能力深入认识运维问题。我们沿用比较常见的 DeepResearch 结构，即感知-规划-行动-反思，后边重点介绍如何落地这些环节。

9、大脑：认知层（知识抽取）

这部分主要是想结合运维领域专家知识来来完善流程，让流程更加可靠。主要来源于这几方面的数据：

1. 官网手册及团队帮助文档
2. 工单数据及故障报告

如何将这些数据与前面提到的 UModel 数据进行整合呢？我们主要是依赖于 NER 技术，或者依赖于这种事件提取的技术。

我们将目前相关事件抽为几个部分：核心摘要、根因分析、关键信息提取、后续行动项。目前只是针对常见的云产品做了这方面的集成。

10、大脑：认知层（实体图谱+知识图谱）

UModel 告诉我们服务在哪里、去哪里取数及它的拓扑链路，上面的示例图谱是告诉我们为什么发生事故，发生了事故要采取什么样的措施？基于示例图谱，我们定义了几个概念：

• 事件
• 事件的表现
• 它的可能根因
• 基于事件应该采取的措施。也定义了概念之间的关联关系

基于上述的 UModel 配置，我们会将故障&用户手册涉及到 UModel 的概念与外部进行关联。这样模型在拿上下文时，不仅能拿到实体，还可以拿到实体相关联的以往故障、之前故障的排查流程。

四

应用场景与实践案例

UModel 不仅实现了数据的标准化和统一建模，还支持算法和大模型对数据的高效应用，UModel 目前已集成到内部云监控 2.0。

1、案例分享：K8s 查询分析

这是目前的一个形态，可以看到之前介绍的 UModel 的定义，这是展示 K8s 的环境，可以看到 K8s 集群的信息，关联了哪些节点，这些节点目前运行的 Pod。

这是目前在样例系统里演示的监控服务（定义的实体），我们从服务出发，查看有哪些关联的上下游节点，关联了哪些应用和接口。这是拓扑结构，帮助模型沿着拓扑结构在系统里不断地游走。

相较于之前，UModel 将之前散落在阿里云各云产品的数据做了统一的整理和管理，提供了集中性的分析。这种数据关联在构造 Copilot 时提供很多便利性。我们可以选择将某些服务加到 Copilot 上下文里，从上下文出发，可以尝试去问 Copilot 很多问题。

在设计 Copilot 其实希望输出结果对于运维人员来说友好，也能用来评价它是否可靠。我们将中间所有环节及 Meta 信息进行了输出，方便做校验。

五

总 结

以上是本次整体分享的内容，整体上在构建可观测 Copilot 很长时间都是在实践数据的关联关系，还有数据的清洗后处理。

另外在构建 Copilot 过程中，快速迭代还是非常有必要的，没必要一开始瞄准非常复杂的框架或非常高端的技术，我们可能就从 Prompt 开始，从上下文工程开始一步步去搭，让流程真正可控，才方便去做后边的验证。

最后是系统的搭建过程中要考虑测试，否则很难发现搭建的系统在实际过落地过程中的效果是怎样的。最终会陷入到无尽地去调 Prompt 或上下文工程。谢谢大家。

​最后

我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。

我整理出这套 AI 大模型突围资料包：

• ✅AI大模型学习路线图
• ✅Agent行业报告
• ✅100集大模型视频教程
• ✅大模型书籍PDF
• ✅DeepSeek教程
• ✅AI产品经理入门资料

完整的大模型学习和面试资料已经上传带到CSDN的官方了，有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇
​​

为什么说现在普通人就业/升职加薪的首选是AI大模型？

人工智能技术的爆发式增长，正以不可逆转之势重塑就业市场版图。从DeepSeek等国产大模型引发的科技圈热议，到全国两会关于AI产业发展的政策聚焦，再到招聘会上排起的长队，AI的热度已从技术领域渗透到就业市场的每一个角落。

智联招聘的最新数据给出了最直观的印证：2025年2月，AI领域求职人数同比增幅突破200% ，远超其他行业平均水平；整个人工智能行业的求职增速达到33.4%，位居各行业榜首，其中人工智能工程师岗位的求职热度更是飙升69.6%。

AI产业的快速扩张，也让人才供需矛盾愈发突出。麦肯锡报告明确预测，到2030年中国AI专业人才需求将达600万人，人才缺口可能高达400万人，这一缺口不仅存在于核心技术领域，更蔓延至产业应用的各个环节。

​​

资料包有什么？

①从入门到精通的全套视频教程⑤⑥

包含提示词工程、RAG、Agent等技术点

② AI大模型学习路线图（还有视频解说）

全过程AI大模型学习路线

③学习电子书籍和技术文档

市面上的大模型书籍确实太多了，这些是我精选出来的

④各大厂大模型面试题目详解

⑤ 这些资料真的有用吗?

这份资料由我和鲁为民博士共同整理，鲁为民博士先后获得了北京清华大学学士和美国加州理工学院博士学位，在包括IEEE Transactions等学术期刊和诸多国际会议上发表了超过50篇学术论文、取得了多项美国和中国发明专利，同时还斩获了吴文俊人工智能科学技术奖。目前我正在和鲁博士共同进行人工智能的研究。

所有的视频教程由智泊AI老师录制，且资料与智泊AI共享，相互补充。这份学习大礼包应该算是现在最全面的大模型学习资料了。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

智泊AI始终秉持着“让每个人平等享受到优质教育资源”的育人理念‌，通过动态追踪大模型开发、数据标注伦理等前沿技术趋势‌，构建起"前沿课程+智能实训+精准就业"的高效培养体系。

课堂上不光教理论，还带着学员做了十多个真实项目。学员要亲自上手搞数据清洗、模型调优这些硬核操作，把课本知识变成真本事‌！

​​​​

如果说你是以下人群中的其中一类，都可以来智泊AI学习人工智能，找到高薪工作，一次小小的“投资”换来的是终身受益！

应届毕业生‌：无工作经验但想要系统学习AI大模型技术，期待通过实战项目掌握核心技术。

零基础转型‌：非技术背景但关注AI应用场景，计划通过低代码工具实现“AI+行业”跨界‌。

业务赋能 ‌突破瓶颈：传统开发者（Java/前端等）学习Transformer架构与LangChain框架，向AI全栈工程师转型‌。

👉获取方式：

😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓**

​