devgo.cn想象一下这个场景：你负责的线上服务在下午 3:30 触发了一个告警，但你不敢立刻处理——因为类似的告警经常自己消失。等到 5 点多你确认这是真问题时，才发现另一个团队从下午 1:30 就在调试同一个故障了。接下来是 9 个团队被拉进群、30 多个工程师参与排查、3 个相关事故被连带标记，最终在 6:30 定位到根因——某个下游服务觉得自己不重要，悄悄砍了容量，导致错误向上游传播。这整个过程花了 4 个小时，而这在 Netflix 还只是"平均情况"。
这是 Netflix 可观测性团队在 QCon 上分享的真实案例。他们面对的核心问题，表面上是可观测性（observability，即监控系统能否看清系统内部状态的能力），但正如演讲者所说，这本质上是一个数据工程难题。先看他们面临的规模：2024 年底 Jake Paul 对 Mike Tyson 的拳击直播，峰值有 6500 万并发流；应用每天向服务器发送超过 20 亿次请求；实时日志事件每秒高达 3800 万条。在如此规模下，传统监控工具的做法——出问题告警、人工排查、分派给对应团队——彻底失效了。
为什么难？他们总结了四个痛点。第一，数据源严重割裂：日志（log，记录事件细节的文本）、指标（metric，数值型统计数据）、事件（event，离散的状态变化）、追踪（trace，一次请求经过所有服务的完整路径）分别存在不同的数据存储里，格式不统一，彼此不关联。第二，告警缺乏上下文：每个团队只看自己那一亩三分地的数据源来设告警，同一个故障，A 团队从客户端视角看，B 团队从后端视角看，两边各说各话，对不上。第三，排查靠人肉：工程师像在干草堆里找针一样，沿着一条线索逐个服务排查，效率极低。第四，根因分析滞后：即使定位到问题，往往已经过去了几个小时，用户早就受到了影响。
Netflix 的解法是彻底重构可观测性的思路，从"被动监控"转向"主动洞察引擎"。他们的愿景是：系统能在几分钟内自动检测跨整个技术栈的问题，自动按用户影响程度排序，自动分派给正确的团队，甚至自动定位根因、预测未来可能发生的问题。
实现这个愿景的关键，是他们构建的端到端知识图谱（E2E Knowledge Graph）。这个图谱把用户设备、网络、网关服务、后端依赖服务全部连接起来，实时更新。它的核心是本体驱动（ontology-driven，本体在这里指对领域内概念及其关系的正式、显式的规范描述）。简单说，他们不再把日志、指标、追踪当作孤立的"数据点"，而是把它们建模成一张网里的节点和边——一个用户请求从点击播放到视频流出的完整路径，每一步涉及哪个服务、产生了哪些指标、调用了哪些依赖，全部在图谱里关联起来。
有了这张图谱，AI 才能发挥作用。因为 AI 模型（比如用于异常检测的模型）需要结构化的、有关联的数据才能做推理。如果数据是割裂的，AI 只能做单点检测；数据关联成图后，AI 才能做跨服务的根因分析。这正是他们把本体论（ontology，哲学里研究"存在"的学问，在计算机领域指对概念和关系的显式建模）和 AIOps（AI for IT operations，用人工智能来辅助运维决策）结合的原因——AI 让一切汇聚到一起。
这个思路对任何做复杂系统运维的团队都有直接借鉴意义。如果你也在被"告警轰炸但不知道哪个重要""排查故障靠老师傅经验""跨团队协作靠拉群"这些问题困扰，Netflix 的路径值得参考：先别急着上更多监控工具，而是想想怎么把已有的日志、指标、追踪数据打通，建立它们之间的关联关系。数据关联起来，AI 才有用武之地。当然，这个方案的门槛也很明显——构建和维护知识图谱本身是巨大的工程投入，需要专门的数据建模和治理能力，不是小团队能轻易复制的。但其中的理念——把可观测性从"工具问题"重新定义为"数据工程问题"——是普适的。
内容与图片版权归原作者所有 · 原文: https://www.infoq.com/presentations/netflix-observability-aiops-ontology-scale/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global