**云栖实录：重构可观测 - 打造大模型驱动的云监控 2.0 与 AIOps 新范式**
纵观技术发展，每一次技术范式的迁移，都会重塑一个领域。正如云原生时代，将“监控”演进为“可观测”；如今，大模型时代的到来，也正驱动着可观测走向下一轮颠覆式变革。我们看到，AI 正在重塑软件开发，催生了全新的 AI Coding 的编程模式。那么，用 AI 简化运维复杂度的智能运维，所谓 AI Operation（AIOps） 也必然是时代的趋势。
其实，AIOps 不是新概念。早在 2017 年，Gartner 就提出了这个愿景，希望实现运维领域的自动驾驶。然而，过去的 AIOps 普遍受限于三大瓶颈：僵化的规则引擎、严重的数据孤岛以及高昂的定制化成本，导致其长期难以大规模落地。但如今大模型的出现，为我们突破这些瓶颈带来了曙光，让 AIOps 真正走到了即将突破的临界点。
为什么我们会认为 AIOps 即将迎来临界点呢？这取决于三个关键因素的成熟，它们共同构成了这一次 AIOps 突破的基础：
首先，是高质量数据。这是 AIOps 的第一性原理。数据不仅要准确，而且要多维，有统一语义，互相关联，这样才能被 AI 有效理解和推理，否则就是“Garbage in, garbage out”。
其次，是弹性算力。无论是应对海量数据的实时处理，还是在定位问题时进行深度分析，都需要一个能按需伸缩的强大计算存储平台作为支撑，而这正是云时代带来的核心优势，也是目前我们解决得比较好的问题。
最后，也是最关键的，是大模型。大模型在通用知识与推理能力上的涌现，让它不再是过去那种需要大量标注和训练的“小模型”，而是真正具备了理解运维场景的通识能力。
在大模型时代，要真正满足这三个关键因素，我们必须首先解决两个棘手问题：
- 数据的驾驭问题：当可观测数据从 TB 迈向 PB 甚至 EB 级别时，我们该如何驾驭这片异构、实时的数据海洋，让数据能够为我们所用？
- 认知的对齐问题：我们该如何弥合大模型的通用智能与运维领域的专业知识之间的鸿沟，让 AI 真正“看懂”我们的系统？
数据的驾驭问题
当我们将 AIOps 应用于海量可观测数据时，海量、异构、实时的可观测数据会产生三个挑战：
- 异构系统的孤岛困境：企业内部往往有着各种监控系统，这些系统接口与权限各异，大模型很难进行有效的跨域分析，在分析排查时，就无法获得必需的完整上下文，就有如盲人摸象，局限在局部信息，根因定位很难成功。
- 数据洪流的承载瓶颈：可观测数据正经历爆炸性增长，给平台带来了巨大压力。这个压力，即包含数据接收的承载压力，也包含数据存储的成本压力，还包含计算时的资源压力。要么牺牲数据完整性（如采样丢弃），要么承担高昂成本。这个存不下、算不起的瓶颈，在问题分析时，就会极大地限制 AIOps 的使用。
- 海量数据的算力黑洞：我认为这是一个典型的技术路径错配问题。看到业界一些尝试是让大模型直接处理海量、价值密度不均的原始数据（例如：直接让模型去分析系统日志，这得多有钱），这不仅会疯狂消耗昂贵的 GPU 算力，而且分析效率极低，最终导致投入产出比完全失衡。
要解决数据难题，必须有一个强大的平台，一个能支撑好 AIOps 场景的统一可观测数据平台。这个平台，我们围绕日志服务 SLS 为核心引擎去构建，能够统一支持日志、指标、链路、事件、性能剖析等可观测数据。它彻底解决了数据难题：
- 采集侧，统一数据接入，以打破孤岛：我们提供了覆盖从移动端到基础设施，从传统应用到最新的 AI 应用框架等 200 多种组件的全栈、实时、无侵入的数据接入能力。无论是日志、指标还是链路，每天上报数百 PB 数据，都能被汇入一个平台，为后续 AI 分析提供了完整的全局上下文。
- 服务端，统一数据加工与存储，以应对洪流：SLS 具备全球可用的高弹性高可靠架构，能承载每日 EB 级的存储规模，秒级千亿行查询，数百亿行分析，百万时间线计算能力。通过丰富、灵活、强大的数据加工能力和存储冷热分层技术，在保障数据完整性的同时，将综合成本较自建方案降低 50% 以上。
而且，我们坚持秉承数据开源开放原则，所有数据都符合标准开源协议规范（指标符合 Prometheus 标准，链路符合 OpenTelemetry 标准，事件符合 CloudEvents 标准，使用表格模型均支持 SQL 查询），存储在客户租户下的 SLS Project 内，客户可以自行进行自定义分析或导出。另外，默认会采用三副本存储，在符合条件的地域，免费启用 3AZ 同城冗余，这是业界独一份的存储高可靠性。基于一个数据平台的持续建设，让我们的数据能够“存得下、存得好、存得起”。
有了统一的平台，我们如何解决“算力黑洞”的问题？
我们的核心理念是：计算下推。不要把海量原始数据喂给大模型，而是将模型的分析意图下推到底层数据引擎去执行。为此，我们沉淀了大量高效的 通用算子+可观测数据算子。可观测算子就像一把把锋利的手术刀，专门用于处理特定数据场景。例如指标数据，有丰富的异常检测、预测、聚类、维度下探算法；链路数据，有专门针对链路的异常分析、维度下钻，也有对多调用链构成的拓扑进行构造和对比分析的算子。由此一来，在实际工作中，大模型只需要扮演智能调度的中枢角色。它接到任务后，会调用这些强大的算子在数据源头进行预处理和关键特征提取。只有 高价值信息 才会被提交给大模型进行最终的推理和决策。
这种方式，将大模型的推理能力和平台强大的数据处理能力完美结合，将 Token 消耗降低 90% 以上，让 AIOps 真正变得高效且经济可行。
认知的对齐问题
解决了数据问题，我们再来看 AIOps 面临的第二个、也是更深层次的难题 - 认知。从本质上是如何弥合大模型的通用智能与运维领域的专业知识之间的鸿沟。具体来说，我们会面临三大挑战：
- 运维领域的语义鸿沟：当用户提问“服务有抖动没？数据库还健康吗？CPU 有没有毛刺？”，大模型听不懂什么是“抖动”，怎样算“健康”，多高算“毛刺”。这些运维“黑话”和指标之间的语义鸿沟，导致 AI 难以准确理解用户意图，结果自然差强人意。
- 系统拓扑的认知迷宫：现代 IT 系统依赖关系错综复杂。大模型缺乏对拓扑关系的认知，看到的一个个数据，都是孤立的，就没办法有效找到关联的其他数据和节点。
- 根因分析的逻辑断链：有效的根因分析依赖完整因果逻辑关系。而大模型面对离散数据容易产生推理幻觉，难以形成可靠的诊断结论。
如何解决这些认知挑战？我们的答案，不是无休止地训练运维大模型，而是为它构建一个更易于理解的“数字孪生”世界。UModel 统一模型，就是这个数字孪生的核心。它提供了一套观测实体、以及实体关系的定义，帮助我们构建 IT 系统的数字孪生世界，覆盖从用户体验、应用服务、容器到底层基础设施的每一层。有了这张动态拓扑，排查效率将发生质变。比如，当一个应用报错，我们就可以直接从应用下钻到引发问题的慢 SQL，再到具体的数据库实例；或者，我们可以跨域到它所在的 K8s Pod 和 Node 节点上。过去需要在多个系统间的手动跳转、关联的繁琐操作，现在都可以在一个统一的视图内轻松完成。
我们现在基于 UModel，已经覆盖了 6 大核心领域、创建了 1800 多个模型，并且这是完全开放可扩展的。我认为它真正的革命性在于，它重构了可观测世界的范式，将数据、知识、行动这三个核心要素绑定在了一起：
- 数据：它定义了“是什么”（实体）和“如何连接”（关系）。
- 知识：我们将运维领域的专业知识，如黄金指标、健康度、水位、运维手册等，都附着在实体上。这就填平了语义鸿沟，让 AI 能听懂“服务抖动”的真正含义。
- 行动：我们将可执行的操作，如回滚、重启、扩容等动作，也都附着在实体上。这就像赋予了 AI 一个工具箱，让它知道面对问题时能对这个实体做些什么。
通过这种方式，UModel 不再仅仅是一张简单的拓扑图，它可以为大模型提供完整的上下文，让大模型进化成一个能理解、会推理、可行动的“数字 SRE”，从而真正开启了AIOps 的新范式。我认为这是重构可观测的重要一步。
Demo：UModel 探索与全局实体拓扑
在 Demo 之前先补充一个核心概念：实体（Entity）。如果把 UModel 理解为面向对象编程中的 Class（类），那么实体就是被实例化后的 Instance（对象）——比如一台具体的 ECS、一个 RDS 数据库实例、一个运行中的应用。它是我们可观测世界里真实存在的基本单元。
接下来，看上面这个 Demo，它展示了基于 UModel 和 Entity 构建的三大核心拓扑视图：
- UModel 探索：这里是整个可观测世界的设计蓝图。它定义了“应用”、“K8s 集群”、“ECS 实例”是什么、它们和谁关联，以及它有哪些字段，会挂载哪些指标、日志和链路数据。这是 2.0 实现统一可观测的基石。
- 全局实体拓扑：它是一张全局视角的 IT 资产地图，将所有实体按类型聚合。当技术负责人需要快速盘点全局资源，掌控整个 IT 架构的可观测接入情况时，这就是最佳的视图。
- 应用实体拓扑：这是为业务架构师和应用 SRE 准备的“流量拓扑图”。它平铺每个应用实体，清晰展现所有应用的依赖关系和流量走向，让使用者在分析应用间影响、排查故障时，能够鸟瞰全局。
Demo：基于实体拓扑的问题排查
请至钉钉文档查看附件《apm_topo_trblsht.mp4》
上面这个 Demo 是一次非常典型的线上故障排查过程，全程都在云监控 2.0 的控制台上完成，我们来快速回顾一下整个破案过程：
一切始于一个告警——网关应用的接口耗时突然飙升。我们没有在海量日志或指标中排查问题，而是沿着云监控 2.0 自动构建的实体拓扑，开启了上帝视角的排查。排查路径非常清晰：从“网关应用”出发，顺着拓扑的调用关系追到“订单应用”，再到“数据库客户端”，最终跨越应用域的边界，来到“数据库服务端”。在这里，我们通过慢 SQL 日志，精准锁定了根本原因：一次应用发布引入了未经优化的 SQL 语句，导致索引失效，引发了数据库性能瓶颈（CPU 接近 100%）。在这里可以关注一个细节，数据库列出几百条慢 SQL 语句，我们通过日志聚类算法识别到事实只有三类慢 SQL，进一步简化了问题判断的难度。我们还需要回答“这个问题是什么时候、由哪个版本引入的”。再次回到拓扑图，利用强大的关联能力，从应用下钻到其运行的 K8s 环境，沿着“Deployment -> Namespace -> K8s 集群”的路径，顺利找到了对应的发布审计日志，定位到了引入问题的镜像版本。这是一个非常经典的业务故障案例。去年云栖大会我也录制了一个 Demo，演示过类似的场景，当时我的核心排查武器是调用链。调用链无疑是问题排查的首选工具，对于追踪由请求调用串联起来的问题，它非常有效。但它的局限也很明显——它主要工作在“流量”的世界里。当问题涉及到应用与底层基础设施（比如 K8s 发布）的关联时，就稍显力不从心了。
而现在 Demo 演示的核心能力，是由 UModel 生成的统一实体拓扑。它最大的价值是打破了不同技术领域之间的壁垒，将应用、中间件、数据库，打通到云 RDS 实例，甚至打通到底层 K8s 资源和 ECS 节点，这些都全部关联在了一张图上。我们的排查不再局限调用链，而是在一个全局的、立体的视角下进行自由穿梭和下钻。
Demo 背后的思考
最后，也想揭示出我们在这个 Demo 背后更深层的思考：Demo 上看到的控制台每一步点击、每一次下钻，其实都在模拟我们 AIOps 进行根因定位的推理过程。
我们对 AIOps 能做什么分析、排查什么问题，目标非常明确而且坚定：如果一个问题能够被工程师在我们的控制台上清晰地排查出来，那么在 UModel 和大模型的驱动下，它就 应当 能被大模型自动化、智能化地解决。这是我们坚守的目标。换句话说，云监控 2.0 的设计理念是什么？是让大模型能够看见我们所看见，能够操作我们所操作；重构产品，是要让用户和大模型能够在一个产品界面或者层次上，共同协作、互相理解。就像自动驾驶要经过漫长发展，人机共驾必不可少，AIOps 也肯定不能一步到位，还要打磨很长时间，辅助运维是必经形态。现在大模型的智能水平和对用户看到和操作的能力覆盖度，也远还没达到我说的这个阶段。但相信在这个理念的牵引下，复杂问题的思考过程能够变得简单、直观，大模型的能力能够一点点逼近到我们想要的位置。
智能运维助手
如果说 UModel 为可观测世界构建了骨架，那么我们全新升级的 AIOps Agent，就是驱动这一切的智能大脑。它的交互方式被彻底重塑。用户可以在云监控 2.0 的任意界面，通过自然语言随时召唤它。因为它具备全场景上下文感知，因此用户可以直接选中一个集群（“添加到上下文”）然后提问：“这个集群最近是否稳定？列出上面业务的错误率排名”，Agent 能立刻理解意图并展开分析，让交互精准而高效。更重要的是，它的内核与众不同。我们彻底抛弃了传统的、基于僵化规则或流程驱动的 AIOps。AIOps Agent 采用 Agentic 架构，它能够基于大模型进行自主规划、调用工具、执行、反思，从而能够解决更多开放和未知的运维难题。
这标志着，我们正从“人适应工具”的时代，迈向“工具适应人”的 AIOps 新范式。
AIOps Agent 的价值，不仅在于它的智能，更在于它重构了我们熟悉的 AIOps 核心场景。这里的关键词是“重构”——这是因为我们用大模型驱动和自然语言交互的全新形态，整合和升级了最核心的四大场景：
- 智能分析：Agent 变成可观测的数据分析伴侣，无论是复杂的调用链还是火焰图，无论是应用域的问题还是云产品域的问题，都可以直接向它提问，让它为解读数据，并给出优化建议。
- 智能告警：Agent 可以帮助配置告警、治理告警，通过调用算法对告警进行收敛降噪（即将升级到 Agent 模式）。
- 根因洞察：当故障发生时，Agent 能帮助进行根因分析，评估影响，并生成故障总结。
- 智能巡检：还可以让 Agent 定时对核心业务或集群进行巡检，从“被动救火”转向“主动预防” （即将发布）。
那么，AIOps Agent 是怎么实现这一切的呢？智能并非空中楼阁，也无法一蹴而就，需要逐级构建在一个坚实的能力分层金字塔之上：
- 基础查询：这是 Agent 的“语言能力”。对 LogStore 和 MetricStore 的自然语言翻译、智能取数。
- 拓扑感知：这是 Agent 的“认知能力”。基于 UModel，它不仅能查询数据，更能理解数据与实体之间的关联关系，实现关联分析和资源盘点。
- 深度洞察：这是 Agent 的“分析能力”。它能调用各种可观测算子，进行异常检测、趋势预测和模式分类，从海量数据中提炼关键信息。
- 辅助决策：这是 Agent 的“智慧能力”。它综合所有底层能力，进行复杂的根因定位和变更分析，并最终给出决策建议。
正是这个层层递进的能力栈，让 Agent 从一个简单的问答机器人，进化成能够进行复杂诊断的 AIOps 分析引擎。
这个能力分层在实际工作中是如何体现的。比如，你可以问：“这个 K8s 集群上部署的 APM 应用的错误率排名？”，也可以选中应用 xx，让 Agent 分析：“分析这个应用上周调用量并做后续三天趋势预测”。当然，最重要的是进行顶层的辅助决策，你可以直接下达任务：“对 K8s 集群的进行巡检，关注组件与资源水位”，或者在故障时直接求助：“这个应用这个小时有请求超时情况，帮我定位原因”。如你所见，这不再是固定死板的命令，而是与你的助手的真实对话。而且更多更复杂的对话能力，随着接入 UModel 的数据、知识和行动的增加，会逐步解锁。
请至钉钉文档查看附件《k8s_cluster_healthcheck2.mp4》
为了让大家更有体验感，Demo 展示的内容是 K8s 集群巡检，巡检如果发现异常，就顺带做根因定位，找到引入异常的变更事件。Demo 过程可以看到 Agent 的思考过程，一般简单任务会直接处理，复杂任务会先规划（Plan），再处理、再总结反思。这个 Demo 最后，发现了我们注入 OOM 故障和高 CPU 负载的 sidecar，并在追问下，对上层业务进行了影响面评估。
智能运维的能力开放
在和客户共同成长的道路上，我们深知，任何黑盒方案都无法长久。因此，我们将 AIOps 的核心能力，通过一个分层的可观测 MCP 工具集全面开放了出来。
我们之所以设计成三层，是为了管理 AI 的复杂性。因为当工具过多时，AI Agent 很容易在选择和调用时产生混乱。这种分层结构，提供了不同层面的对接方式，可以按需选择。
有没有看出这三层和前面的四层金字塔有一些对应关系？实际如此。让我们仔细对比看一下：
- 基础查询层：为数据专家提供了直接访问原始数据的 API，支持自然语言转 SQL/PromQL。
- UModel 工具层：对应拓扑感知和智能洞察，为具备自主规划、工具调用能力的大模型或 Agent 使用，也可以用于 Workflow 编排的 AI 应用场景。提供了基于拓扑和实体的结构化查询能力。此外，支持在将信息喂给大模型前进行预处理，大幅提升分析准确性并降低 Token 消耗。
- Agent 层：为所有用户提供了最易用的自然语言可观测接口，专注解决可观测数据分析和问题定位问题，可以与其他管控 MCP 一起集成实现完整的 AIOps 闭环。
- 我们相信客户需要的，不是一切推倒重来都搬到我们的平台上，而是在现有基础上进行渐进式能力增强。这套开放的 MCP 工具，允许企业将我们的可观测智能无缝集成到已有的平台和流程中，构建属于自己的智能运维大脑。
Demo：可观测 MCP 的 DevOps 场景集成
最后让我们来看一个激动人心的例子，看看基于云监控 2.0 的开放体系能创造怎样的可能性。在这个 Demo 中，我们做了两件关键的事：
- 扩展了 UModel：通过 UModel 的开放性，自定义了一系列 DevOps UModel，将“研发人员”、“代码仓库”、“代码发布”等实体也纳入了可观测世界。
- 集成了 AI Coding IDE：我们将可观测 MCP 工具集无缝集成到了阿里的 Qoder 中。由于 Qoder 已经是 Agentic IDE，背后有强大的大模型驱动，所以这个 MCP 集成只依赖了 UModel 工具层这一层，没有用 Agent 层。这个集成会形成非常有趣的化学反应。
设想一下开发者在用上述 Qoder IDE 编码时，发生的如下场景：
开发者：“刚才线上的问题是因为我刚才提交发布的代码引起的吗？”
Qoder：“是的，错误率上升跟你提交的 xxx 代码变更有关。”
开发者：“帮我立刻回滚回来，同时进行对应的代码优化，并提交新的 PR。”
Qoder：立即回滚变更，同时根据线上的可观测数据和错误定位情况，进行代码优化并提交修改。
请至钉钉文档查看附件《troubleshooting5.mp4》
Demo 第一部分：问题排查，还是之前那个根因定位的场景。Qoder 根据引起异常的应用找到了对应的镜像版本，确定了根因由发布引起。根据 UModel 定位到了代码发布记录。
Demo 第二部分：将前面问题排查的结论复制并作为这轮输入，让 Qoder 找到引起问题的具体代码并进行修复，提交 PR 到云效平台（通过云效 MCP）。
这个 Demo，展示了 AIOps 的完整闭环：它将 Ops 的能力无缝融入 Dev 的工作流，让开发者成为保障稳定的第一道防线。同时，这也揭示了 AIOps 往另一种形态发展的可能：既然有 Vibe Coding，为什么不能“Vibe Operation”（或者“VibeOps”）呢？既然用户能够通过 Vibe Coding 基于想法和意图来创造软件，那么他们同样不希望也大概率不具备能力去处理复杂的部署、监控、故障排查和性能优化等运维工作。
结语
文章的最后，放出云监控 2.0 全景这张图，就是我们对“重构可观测”这个命题，所交出的完整答卷。
云监控 2.0 历经一年半的演进，已经完成了 ARMS、容器监控（Prometheus）、企业云监控的大部分系统整合、存储迁移等工作，剩余的 SLS CloudLens、基础云监控等也在下半年逐步迁移规划中。统一接入、统一数据处理、统一算法引擎、统一告警、统一仪表盘，这些都不是一句空话，也都离不开可观测团队一直在持续进行的升级和迁移。阿里云大部分可观测客户已经可以无缝升级到云监控 2.0 体系。体验 UModel 拓扑、AIOps Agent 的升级，不需要额外多花钱。回顾我们的 2.0 旅程，借助云整体 All in AI 的浪潮，并没有在传统的技术体系上缝缝补补。而是从根本上重构了三个核心层：
- 最底层，我们做了统一接入、计算、存储的决定，解决了“数据”的承载与性能难题。
- 中间层，通过创新的 UModel 和算法引擎，我们为数据赋予了拓扑关联和领域知识，解决了“认知”的鸿沟问题。
- 最顶层，诞生了全新的 AIOps Agent 形态，以及丰富的智能探索场景，将运维带入了自然语言对话的新形态。
这就是我们所定义的大模型驱动的 AIOps 新范式。它不是一个个孤立的工具集合，而是一个从数据、到认知、再到决策的全链路整合。我们相信，这不仅是技术的变革，更是智能运维理念的进化。让我们共同期待基于大模型，可以重新探索和定义的智能运维的未来。