2024年11月，杰克·保罗与迈克·泰森的拳击赛吸引了约6500万并发用户，Netflix基础设施成功承载了这一流量洪峰。在日常运营中，该平台每天接收超20亿次请求，每秒处理高达3800万个实时日志事件。在这种规模下，单一仪表板或工程团队的认知已无法覆盖全局视图。随着直播、播客和实时流业务的扩张，快速理解并更新系统状态成为保障用户体验的关键。
四小时排查困境
以一次典型的回归问题为例：电影列表主屏渲染延迟增加1.5秒。警报触发后，工程师需排查潜在原因，包括客户端应用因新版本或A/B测试导致的回归、基础设施负载削减，或是下游服务部署引发的GraphQL查询错误。回答“是什么导致了问题”需要跨系统洞察，涉及多层数据的繁琐梳理。
在传统模式下，此类调查往往耗时四小时。其中极少时间用于复杂计算，大部分精力耗费在重建可观测性系统已知、但未以机器可读形式记录的关系上。
数据孤岛与语义鸿沟
简单的增加数据或优化仪表板无法解决根本问题。而在引入AI智能体（Agents）时，若缺乏准确上下文，系统易产生幻觉，误导值班工程师。Netflix的各个系统内部连贯但外部隔离：Atlas掌握遥测数据，Radar负责警报，incident.io管理事故严重性，PagerDuty处理轮值，Spinnaker追踪发布，而Slack则记录了工程师的历史排查经验。
难点在于各系统对实体的定义不一致：同一对象在不同系统中可能被称为“应用程序”、“服务”或“集群”，仅由后缀或大小写区分。跨系统连接依赖人工记忆映射，成为调查瓶颈。端到端可观测性的核心挑战，实质上是数据建模问题。
构建可观测性本体
为解决这一问题，Netflix引入了本体（Ontology），即对类型、属性及关系的正式规范。其基本单位是三元组（Triple）（主语-谓语-宾语）。例如：
api-gateway rdf:type ops:Application .
api-gateway ops:ownedBy "Team Bedrock" .
INC-5377 ops:affects api-gateway .通过这种结构，原本需跨越三个工具的查询可简化为一次SPARQL查询。Netflix基于W3C标准栈构建可观测性本体：使用RDF作为数据模型，OWL定义本体，SHACL进行验证，SPARQL执行查询。数据持久化至自研的RDF图数据库QuipuDB，该数据库基于Rust嵌入式键值存储redb构建。
本体层按12个命名空间组织，涵盖不同运营领域。建设中两个关键决策包括：拒绝通用的“Service”类型，将应用精确解析为ops:Application并经软件目录验证；限制依赖边数以避免热门服务主导图谱。
从非确定性到确定性
构建图谱涉及LLM总结、模糊匹配等非确定性工具。为确保输出稳定，Netflix设计了“熵减”流水线，将随机过程约束为确定性契约。例如，LLM的输出必须符合预定义的类别和情感标签，最终生成标准的三元组。
增强器（Enrichers）是这一机制的核心。数十个增强器顺序运行，读取嘈杂输入并发射类型化三元组。每个实体均带有rdf:type，URI遵循统一命名方案。这种顺序执行消除了竞争条件，虽牺牲部分速度，但确保了图谱的一致性。
关联引擎则吸收日志错误、指标异常、部署等13种信号，在十分钟窗口内搜索因果或相关链。置信度低于0.6的链被丢弃，高置信度链（如0.87）作为假设供工程师或智能体检阅。
知识飞轮与AutoRCA
系统通过“观察-增强-推断-适应”四个步骤形成知识飞轮。每次事故中发现的因果链被编码为本体条目，随着循环积累，图谱从模式识别进化为智慧记忆。例如，系统可学习到“api-gateway部署导致40%的SEV-2事故”。
在此基础上，AutoRCA（自动根因分析）代理系统协调各专业智能体。本体充当通用接口，使不同领域的专家智能体无需相互了解即可交换信息。虽然最终修复仍需人类工程师，但本体和图谱吸收了原本需数小时组装的上下文，使工程师在调查伊始便掌握完整画面。
最佳实践与未来展望
Netflix总结了构建此类系统的核心原则：首先建模身份并验证实体；将本体视为代码进行版本控制；分离概念与实例；基于RDF等开放标准；用类型系统约束随机工具；使增强过程尽力而为且有序；将人类推理与机器遥测共同建模；并让人类担任最终审批者。
未来，Netflix计划将可观测性本体与统一数据架构（UDA）核心的领域建模语言Upper集成。这将把操作概念连接到更广泛的业务领域，为工程师和智能体提供共享语义层，最终迈向自动补救乃至自愈基础设施。