课程简介

在阿里云可观测体系的研发与交付实践中，我们反复遇到同一类问题：客户与内部团队手中已有日志、指标、Trace、事件等多套数据源，但每新增一个智能运维场景——拓扑探索、跨源查询、故障定位、智能巡检——都要把接入、关联与查询拼接重新做一遍；而把原始日志和指标直接交给大模型后，又出现语义缺失、拓扑认知不足与推理断链，答案看似合理却难以落地。问题不在模型能力，而在缺少一层稳定、可复用的系统语义。
面对这一问题，我们没有选择再建一套集中存储，也没有继续逐场景定制接口，而是通过UModel实践“先统一语义、再统一访问”的路径：以对象图为核心，把实体、观测数据、关系、知识与行动统一建模；用对象与表双模型同时承接面向对象探索与面向表的统一计算，用动静态实体区分运行时拓扑与配置型对象，用三类关系刻画依赖、包含与关联，并以 CommonSchema 做版本治理；底层完整保留企业既有 LogStore、MetricStore 等存储，通过 SPL 统一计算、图存储、全文与向量索引以及面向对象 PaaS 接口，把存储差异屏蔽在模型层之下。
UModel这套做法已在亿级可观测数据规模下跑通：一次建模同时支撑拓扑探索、跨源查询、故障定位与智能巡检，Agent 拿到的不再是散落的原始数据，而是可发现、可调用、带语义的方法接口，AI 由此从“查数据”走向“懂系统”。

目标收益

培训对象

课程内容

1.案例价值的稀缺性：看到一条不搬数据、不换存储就能让大模型“懂系统”的完整落地路径，以及我们为何放弃集中搬数据与逐场景对接两种更直觉的做法；
2.我们的实践相比业界方案的先进性：先进性体现在设计取舍而非功能清单——对象与表双模型、动静态实体、三类关系各自解决什么问题、为何这样切分，均可作为同类语义层建设的直接参照；
3.案例对哪些行业或研发团队有学习性、可即插即用：以保留既有存储为前提的建模方法，加上 CommonSchema 版本治理与自动校验进 CI/CD 的治理实践，多监控源企业可直接套用到自己的统一可观测与 AIOps 建设；
4.案例可以避免同行踩哪些坑：避开我们踩过的三个坑——按数据源、按场景重复建设导致的反复拼接与重复投入；语义层缺乏自动校验与版本治理时质量难以持续；直接把原始数据喂给大模型造成的语义缺失与推理断链。