作者：元乙
从可观测再出发
回顾数十年可观测的演进历程，本质上反映了我们对复杂系统认知方式的变化。
最初，我们面向单一数据类型构建监控体系——CPU、内存、磁盘，一个个孤立的指标告诉我们“什么地方出了问题”。随着系统复杂度提升，我们开始收集多类数据——日志、指标、链路并行发展，试图从不同维度观察同一个系统。
进一步，我们意识到这些数据间存在“关联性”，开始尝试将 Logs、Metrics、Traces 关联分析，这就是所谓的“三大支柱”。但这种关联往往停留在时间维度、资源维度、调用链维度上的简单拼接，缺乏深层的语义联系。
然而，这些演进路径都基于一个隐含假设：先收集数据，再从数据中推理出系统的真实状态。这种“由数据到世界”的认知路径，在面对日益复杂的分布式系统时，逐渐暴露出根本性局限。
这里核心困境在于：从海量、异构、动态变化的数据中准确推理出真实世界的状态，本质上是一个极其困难的逆向工程问题。数据只是现象，而现象与本质之间往往存在巨大的认知鸿沟。
如果从第一性原则重新审视这个问题，一个更有效的路径是：先建模真实/IT世界，再针对性地获取数据。这意味着我们需要从“数据驱动”转向“模型驱动”，从面向现象的观测转向面向本质的建模。
AI 时代的建模必要性
大模型的出现给了我们强大的工具，但实践中我们发现，当把这些“大脑”直接接入到“原始”的可观测数据流中时，却发现效果有限，往往还出现反作用。AI 缺乏对特定领域的结构化理解，面对没有上下文、没有关系的原始数据，几乎不可能做出精准判断。而这一现象在可观测领域更为明显。
基于在可观测领域尤其是 AIOps 的多年经验，阿里云可观测团队在 19 年开始了可观测数据建模的过程，并逐渐迭代和优化。这里我们经历了几个提升过程：
- 数据标准化：解决数据格式混乱问题，借助 OpenTelemetry 开放标准，定义各类可观测数据的互操作。
- 实体与关联：引入 EntitySet 概念描述 IT 世界的核心对象，通过 Link 建立实体间的调用、依赖、归属等关系，构建起 IT 系统的拓扑图谱。
- 知识表达：沉淀领域专家经验，通过 Semantic 的 Set 表达“知识”，让系统不仅有数据，还有相关背景和分析数据的方法。
- 行动能力：支持操作能力建模，将“如何响应”的行动知识也纳入体系，实现从观测到分析到行动的闭环。
这些阶段本身也是我们在做 AIOps 逐渐试错和优化的过程，面对 AI 逐渐从理论、落地到改变世界的迅速推进，我们推出的 UModel 这一结构化的运维世界模型，将数据、逻辑和行动串联起来，为 AI 提供了可推理、可交互的知识图谱。
UModel：可泛化的运维数字化本体
UModel 是从可观测领域出发，基于本体论思想构建的 IT 世界统一建模框架。它不仅仅是数据的抽象，更是一个融合数据、知识、行动三位一体的完整体系。
这一建模过程和业界领先的 Palantir 类似，Palantir 从国防安全领域出发逐渐做到通用 AI 应用领域的领先，其股价也坐火箭式上升。仔细分析 Palantir 的成功，其核心价值不在于 AI 算法本身，而在于底层的“本体”（Ontology）的落地。
上图和 Palantir 的介绍类似，旨在描述运维数字化领域，以 UModel 为核心的可观测运维数字化平台的能力。
借鉴 Palantir 的设计理念，UModel 通过图模型将 IT 世界的三大要素统一：
- 数据层：涵盖全域实体和观测数据，尤其包括各类关联关系。
- 知识层：沉淀领域专业知识，运维知识、分析模板、领域模型等。
- 行动层：支撑自动化决策执行的各类操作定义。
为什么 UModel 是可落地的、可持续的
建模这个概念并不新鲜，任何企业都可以提出“统一数据模型”的愿景。但真正在企业落地且持续发挥作用，很容易走到技术至上论、项目化思维、数据湖即数据能力、重分析轻行动等认知误区，最终导致“数据孤岛与认知隔阂”、“洞察与行动脱节”、“智能化技术与业务割裂”等问题。
UModel 之所以能够真正落地，在于我们系统性地解决了从理念到实践的完整链路问题：
- 面向业务价值的系统设计：阿里云可观测团队服务数十万家客户，且可观测领域碎片化极其严重，UModel 从一开始就面向可观测业务场景的核心痛点设计。不是为了建模而建模，而是为了解决实际的运维效率、故障定位、系统优化等具体业务问题。
- 构建持续进化的生态系统：本身 UModel 不是一个“一次性交付”的项目，我们的目标是构建一个具备进化能力的生态系统，上述的几个发展阶段本身也是进化的结果。通过元模型架构，新的实体类型、数据类型、关系类型都可以在不影响现有系统的前提下平滑扩展。
- 客户价值与平台能力的双飞轮效应：我们一直致力于构建一个不仅能够让客户实现数据获取、价值提取、决策、执行到验证的客户价值闭环。同时在打造背后可观测平台能力提升的闭环，包括 UModel、Agent、领域模型等，最终形成双飞轮效应。
UModel 概述：用 Set 和 Link 构建 IT 世界
UModel 的设计与信息学“本体论”一致：用图来描述对象与关系，用 Field 约束语义与质量。
核心 Set 类型
类型 |
说明 |
关键点 |
EntitySet |
可观测实体集合定义，一类实体资源的主键、属性、状态 |
唯一标识实体，支撑实体级分析 |
TelemetryDataSet |
可观测数据通用表示，最基础字段为 time |
日志/指标/链路/事件的共同基 |
LogSet |
日志集合定义，需关联至少一个 EntitySet |
将日志与对象语义绑定 |
MetricSet |
指标集合定义，一个 MetricSet 下包含多个 Metric |
指标与实体的结构化绑定 |
TraceSet |
链路集合定义，较日志增加 TraceID、SpanID |
调用语义、上下游关系 |
Storage |
目标存储抽象（SLS、Prometheus、MySQL…） |
解耦模型与存储实现 |
Runbook |
运维操作手册抽象 |
定义实体的操作手册、分析模板、领域知识等 |
核心 Link 类型
类型 |
说明 |
典型关系 |
EntitySetLink |
实体间关联关系 |
服务于 / 调用 / 包含 / 属于 / 运行在 / 相同 |
DataLink |
数据与实体的关联关系 |
实体-日志/指标/链路/事件的绑定 |
StorageLink |
抽象与具体存储的关联 |
Entity/Telemetry 映射到 SLS/Prom 等 |
RunbookLink |
操作手册与实体的关联 |
实体与操作手册的绑定 |
典型例子：应用调用数据库
- 定义 Service 与 DB 两类 EntitySet，并建立 Service -> DB 的 Calls 关系。
- 定义 ServiceLogs、ServiceMetrics、Traces 等 TelemetryDataSet，描述自身数据与调用产生的数据。
- 建立 TelemetryDataSet 与 EntitySet 的 DataLink。
- 定义具体实例及其 Storage 与 StorageLink。
- 定义 Service 与 DB 的 Runbook，描述操作手册、分析模板、领域知识等。
通过上述建模，我们能直接获知系统中有哪些 Service/DB 实例、产生了哪些数据、存储位置与字段含义，以及操作手册、分析模板、领域知识等，从而支持人/程序/大模型的统一分析。
UModel 的工程体系：从理念到系统工程
UModel 不是一个“静态定义”，而是一套工程体系：
- 元模型架构：UModel 并不直接定义 Field、DataSet、EntityLink 等概念，而是提供了一套“元模型”。基于元模型定义基础属性字段，通过组合、引用、继承等关系，最终生成 UModel 定义，保证其可扩展性。整体迭代路径符合“道生一、一生二、二生三、三生万物”的思想。
- 标准化与自动化：提供标准化的可观测 UModel 定义，大幅降低使用门槛；内部建立 CommonSchema 维护机制，保证 UModel 定义的高质量发展；提供自动化的实体关系生成、数据同步、元数据更新等管理能力，提升可操作性。
- 技术基础设施：专为可观测场景构建的实体、关系的存储计算引擎，能够快速回溯到任意时刻的系统状态，支持高性能的图查询、关系计算、多维分析等能力。提供管道式、高性能 SPL 统一计算框架，支持关联 UModel、实体、关系、观测数据等各类数据。
- 面向对象的分析：从传统面向数据的分析语法，进化到面向对象的“编程式”分析方式，支持运行时多态、动态方法调用等高级特性，让分析过程更加贴近真实世界的对象交互模式。
- 面向 AGI 的能力：集成语义化搜索、GraphRAG 等面向 AI 的核心能力，上层接口提供 MCP、PaaS API 等，各方面均考虑 LLM 友好特性。
在工程化落地上，我们进一步强化了易用性与生产化能力：
- CommonSchema：沉淀阿里云产品、K8s、APM 等常见数据结构，兼容 OpenTelemetry 等标准
- 实体关系自动生成：基于先验知识与计算框架，自动从“应用&业务视角信息”关联到“资源&云产品视角信息”，生成跨域关系
- 分析最佳实践：为 TelemetryDataSet 附加分析最佳实践，包括开箱即用的大盘和告警等
基于 UModel 的可观测应用与实践
上图是一个典型的 UModel 配置，在系统中定义了一系列的实体，包括应用层的服务/服务实例、K8s 相关实体、底层数据库/主机、CICD 相关的 Job/Repo/操作人等。同时这一系列实体对应的可观测数据也分别进行建模（受限于篇幅，实际这里还会定义相关的 Explorer，便于快速查看数据，例如标准的 K8s、MySQL、服务大盘等；同时还有相关的告警配置）。上述所有的实例均以图的方式进行连接。
基于上述的 UModel 配置，我们能够构造出下图所示的具体实体拓扑（受限于篇幅，只显示一些示例实体）。接收到告警事件时，我们能够进行多种排查方式：
- 根据实体的连接关系一步步排查，每类实体都有对应的可观测数据，按图索骥。
- 基于先验知识进行定向排查，例如 Service 出现异常后，优先排查依赖的 Service、DB、中间件等调用是否出现问题。
- 由于故障多数由变更引起，可以优先查看近期相关的服务变更，优先排查变更服务。
- 通常故障时多个实体均会有告警事件产生，可以将所有告警事件关联实体找出，画出最小连接子图辅助排查。
而上述这些排查方式，无论是人、程序还是大模型都可以基于 UModel 这一标准化定义而顺畅工作，发挥出可观测数据真正的价值。
基于 UModel 的可观测应用
类似于 MVC 模型，UModel 在可观测团队中承载着 Model 的工作，在此之上我们彻底融合了原云监控、ARMS、SLS 团队的各类观测应用，构成全新的“可观测 2.0”：
- 覆盖所有类型的数据，从前端到网关、后端，从应用到中间件、基础设施，从运维类数据到安全、业务。
- 抽象并建模各类实体和关系，并生成各类跨域的实体关系，完成所有观测实体的打通。
- 基于 UModel 的统一 UI 能力，在任意界面、任意场景均可以接入可观测“互联网”。
- 算法、模型不再是针对某个数据而设计，只要是 UModel 描述的数据都能够被支持。
关于可观测 2.0 相关的产品和设计理念，可参考：《云栖实录：重构可观测 - 打造大模型驱动的云监控 2.0 与 AIOps 新范式》。
More Than UModel：走向 AGI 的运维数字化
UModel 的核心是一种范式迁移：从“被动收集数据”到“主动建模世界”。当 AGI 成熟时，运维将从“人管机器”转向“AI 理解并优化世界”的新范式：
- 完整上下文感知：瞬间理解任意系统状态的全域背景。
- 主动系统优化：从被动响应告警到持续主动优化。
- 预测性架构演进：基于业务趋势提前规划并自动完成复杂技术迁移。
我们相信，这一愿景一定会实现！
"The best way to predict the future is to create it."
—— Peter Ducker
