Presentation: Ontology‐Driven Observability: Building the E2E Knowledge Graph at Netflix Scale

基于本体的可观测性：在Netflix规模构建端到端知识图谱 - InfoQ

InfoQ 首页 演讲 基于本体的可观测性：在Netflix规模构建端到端知识图谱

AI、机器学习与数据工程

从Token到特征：构建AI辅助工程的成本归因架构（10月29日网络研讨会）

基于本体的可观测性：在Netflix规模构建端到端知识图谱

点赞

新下拉阅读列表

• 阅读列表

查看演讲

• 垂直

• 水平

• 全屏

速度：

• 1x

• 1.25x

• 1.5x

• 2x

51:03

概要

Prasanna Vijayanathan和Renzo Sanchez-Silva分享了Netflix如何处理每秒3800万事件的可观测性挑战。他们讨论了如何用AI驱动的操作本体和智能代理工作流替代传统监控，使用Claude和图数据库实现。他们解释了如何通过将MELT遥测数据统一到可查询的知识图谱中，实现自动化故障排查、根本原因分析和自愈系统。

人物介绍

Prasanna Vijayanathan是Netflix消费者工程团队的工程师，负责通过客户端平台上的AI/ML创新，推动全球规模的性能、可观测性和QoE（服务质量）计划。Renzo Sanchez-Silva是Netflix可观测性团队的工程师，过去十年专注于构建告警和监控系统。

关于会议

软件正在改变世界。QCon伦敦通过促进开发者社区中的知识传播和创新，赋能软件开发。作为实践者驱动的会议，QCon专为技术团队负责人、架构师、工程总监和项目经理设计，这些人群在团队中影响着创新进程。

INFOQ 事件

• 2026年10月29日，东部时间下午1点 从Token到特征：构建AI辅助工程的成本归因架构 演讲人：Martin Reynolds - Harness公司现场CTO

演讲实录

Prasanna Vijayanathan：我的名字是Prasanna Vijayanathan，我在Netflix的可观测性团队工作。我负责所有会员应用的可观测性、性能和用户体验。这意味着从你点击Netflix标志到开始观看内容的整个过程，我都在研究用户在Netflix上的体验感受。我们应该关注哪些指标？需要哪些工具？要为用户提供哪些洞察，以确保我们理解大家的喜好？如果你喜欢看Netflix，欢迎你。如果你不喜欢，可以怪罪我的同事Renzo。

Renzo Sanchez-Silva：我是Renzo Sanchez-Silva。我在Netflix已经快10年了，属于可观测性团队中的监控和告警小组，构建了多个告警基础设施，现在正在进入AIOps领域。我过去也做过本体论方面的研究。随着AI的发展，所有技术都在融合。

Prasanna Vijayanathan: 今天我们要和大家讨论一个我们一直在解决的问题，表面上看像是一个可观察性挑战，但实际上这是一个复杂的数据工程问题。在深入探讨之前，让我先为大家设定一个背景。为什么在大规模场景下可观察性会变得困难？我们究竟在谈论什么样的规模？让我们做一个快速问答。Netflix推出了直播活动。2024年底是我们首次举办的重大直播活动，一场Jake Paul与Mike Tyson的拳赛。在座的各位可能有部分人观看过。你们认为在那次活动期间我们的峰值流量是多少？毫无疑问，达到了数百万级别。具体来说是6500万并发流。这意味着有6500万用户同时点击播放并观看直播，这就是我们的峰值流量。再问一个。当用户登录Netflix时，应用会向我们的基础设施发送请求，由后端进行响应处理。

你们认为每天来自应用到服务器的请求数量是多少？我们每天处理的请求数超过20亿。最后一个问题是。在所有这些请求发生的同时，我们显然拥有自己的可观察性系统，用于记录指标和各种数据。你们认为我们每秒需要处理多少实时日志事件？这个数字超过每秒3800万事件。这就是我们所面对的规模。全球各地的电视、手机、笔记本电脑等各种客户端平台和设备，数以千计的微服务持续生成数十亿条遥测事件。每个用户都会接触到我们基础设施的各个部分，包括CDN节点等。除此之外，我们生态系统中还同时运行着数千个通过A/B测试的实验。在如此庞大的规模下管理所有这些内容，可谓方方面面、同时发生。

端到端可观察性 - 它是什么？

即使在这样的规模下，Netflix的目标始终是为每个用户提供最佳体验。我们在可观察性方面的策略非常明确。我们是否拥有合适的工具、指标和洞察力来实现这一目标？策略本身很简单，但执行起来并不容易。在如此庞大的规模下，将用户体验与系统性能关联起来是一个根本性挑战。这已经不再是工具层面的挑战，而是数据工程层面的挑战。传统上，可观察性系统是监控和告警工具，用于观察应用程序和服务。当出现问题时，系统会发出告警，然后相关人员会查看情况，将问题分派给合适的团队，寻找需要修复的开发人员，部署修复方案，并观察数据是否恢复到预期状态。这是传统可观察性系统的运作方式。通过端到端可观察性，我们希望重新思考可观察性的实现方式，将其从被动的监控体验转变为积极的洞察引擎。

在展示我们如何实现之前，我想先谈谈我们构想的愿景。想象一个系统能够在几分钟内自动检测整个技术栈中的问题。这不仅仅是针对某个服务或应用，而是覆盖整个技术栈。无论问题出现在哪里，你都能立即知道发生了什么。然后，系统会根据问题对用户的影响程度自动对问题进行优先级排序，并自动将问题分派给合适的团队。你不需要盯着某个应用和某个错误，试图在 haystack 中找到那根 needle，再逐一联系不同的服务团队。那么，我们能否自动识别根本原因？不仅仅是分诊，我们是否能真正找出问题的根本原因？更进一步，我们是否能预测问题在实际影响用户之前就提前发现，甚至主动建议或采取纠正措施？

这可能吗？我们希望实现这一点。构建这样的系统将使我们能够从用户设备到网络，再到网关服务，直至后端依赖服务的深处，实现无缝的实时可见性。用户在 Netflix 上的体验将不会受到任何干扰。每次观看 Netflix 时，你都会爱上它。你的体验将始终令人惊叹。这就是我们的愿景。

听起来很棒。但目前这还远未成为现实。今天的情况与之截然不同。我将带你回顾一次近期调查的时间线，大概是在过去一年左右发生的。当时，我们的某个客户端平台在大约 3:30 触发了一个告警。通常，值班人员会先观察一段时间，看看问题是否会持续。也许问题会神奇地自行消失。有时确实如此，有时则不会。几个小时后，他们开始认真查看：“我认为这是一个真实的问题，我需要去查明，追踪这根 needle，看看是否有其他服务受到影响。”在一般情况下，确实会发现其他服务的影响。然后问题被分派到合适的团队。结果发现，该团队早在当天 1:30 就已经开始调试这个问题。相关人员已经介入处理。

此时，多个团队开始参与进来。不同团队之间的调试工作变得频繁。当调试开始后，他们最终找到了问题的根本原因，追踪到实际出问题的服务。在这个案例中，某个服务误判了自己的重要性，主动降低了容量，导致了反向传播错误。这发生在大约 6:30，距离客户端应用实际察觉到用户影响已经过去了三个小时。我们部署了修复方案，问题在一小时内得到解决。这是一个典型情况。听起来似乎并不太糟糕，耗时四小时。不算太差。但当你考虑到这段时间内有九个团队被通知，超过 30 名工程师以不同角色参与了整个调试过程，还有三个其他相关事件也被标记出来，各团队中到处弥漫着恐慌。这通常就是典型的场景，而且这只是一个普通案例，甚至不是一个糟糕的例子。当你把四小时和所有投入的资源综合起来，这种低效的感觉就显而易见了。这就是你希望通过端到端可观测性解决的问题。

我们分析了原因。为什么会发生这种情况？我们总结出四个主要主题。首先，你拥有过多的数据孤岛。我们大约有日志、指标、事件和追踪数据，它们以不同的形式存储在不同的数据存储中。这些数据彼此隔离，无法沟通，缺乏标准化，结构各异，等等。这导致了孤立且缺乏上下文的告警，这意味着每个团队只关注其数据孤岛中对他们有利的数据源并设置告警。当告警触发时，不同团队从不同视角看待同一问题，他们本应相互沟通，但实际并未发生。这导致了团队在问题分类和实际排查过程中复杂度增加。最终的结果是，我们实际上无法检测到对用户的影响。如果你是一个下游服务，距离用户5跳甚至10跳之远，你几乎无法理解自己的系统和服务如何影响最终用户。

连接性 - 桥接鸿沟，打破孤岛

基于我们对端到端可观测性的愿景，如何解决这个问题并从现实状态转向愿景？这个问题的关键词答案是“连接性”。这是我们最初的想法。核心主题正是这一点。我们希望实现数据连接、告警连接、调试系统、工作流程和根本原因分析的连接。如果我们为端到端可观测性创建这一主题，就不需要10个不同的数据源产生6种不同的工具。我们希望构建一个集成的可观测性层。一个抽象层，能够全面描述系统可观测性的所有信息。这意味着我们的仪表板、告警、调试工作流程和事件响应工具都将使用相同的语言。这样就能减少在调试和分类相同问题、相同症状时的重复工作，这意味着你可以沿着线索追踪，从用户设备到实际根本原因的路径变得清晰。

你可以从不同的线索追踪，但最终都能进入问题根本原因的主路径。这将减少解决问题所需的时间，最终提高诊断准确性，为用户提供更少中断和更优质的体验。所有这一切的核心始于数据，即连接的数据。我们拥有用户、设备和应用程序、服务和基础设施，它们共同产生这四个广泛的数据类别：指标、事件、日志和追踪。我们统一这些数据并将其放入一个层，即MELT层。一旦统一所有数据源，问题就得以解决。重要的是，即使所有数据共存，我们也需要确保数据准确且可操作。

让我再带你看一个场景。假设我们已经有了这一层。假设我们发现了一个回归问题，LOLOMO TTR。LOLOMO是Netflix上你看到的电影列表列表的指标。TTR是这个电影列表列表的渲染时间。你在这里看到了一个回归。有一个缓慢的泄漏，还有一个较大的回归。开发人员注意到这个问题，并询问我们的统一数据层发生了什么？现在所有可观测性数据都存在于一层中，所以请告诉我发生了什么。然后指标系统会告诉你，是的，我看到LOLOMO TTR出现了回归。我还看到其他5个不同服务中的12个指标同时发生了相关变化。它们也在回归。我们发现了一些相关性。这是个好消息。然后事件系统可以告诉你，在这个回归开始之前，所有这些不同应用和服务中发生了47个事件。是的，我可以在图表上看到这些事件。

我可以看到这些事件和指标一起呈现。然后日志会告诉我，我认为在其中一个服务中，此时连接池耗尽的错误突然激增。这可能就是问题所在。同时，其他所有服务中也出现了大量超时错误。然后追踪系统会讲述一个不同的故事。如果我要谈论我们在追踪方面的工作，那将是一个独立的专题讨论。为了给你一个概念，追踪会给你一个特定请求和响应从用户到所有相关服务的路径。你可以追踪这个路径。追踪的挑战在于，除非你确切知道要查找哪个追踪，否则很难用它来准确调试问题。它甚至不是大海捞针。它更像是在黑暗中蒙着眼睛在森林里寻找一片树叶。这非常困难。

本体论 - 关系，而不仅仅是连接

我们真正缺失的不仅仅是连接性，而是这些拼图碎片之间的关系。我们需要知道这些组件之间的连接，没错，但我们还想了解它们如何相互作用以及它们之间的关系。我们将这种可观测性关系称为本体论。Renzo将向你展示我们如何构建这些关系，以及我们如何每天实际应用它们。

Renzo Sanchez-Silva：什么是本体论？它只是对类型、属性和关系的正式定义。它是如何编码意义的。它的基本结构就是你所说的三元组。三元组包括一个主体、一个谓词和一个客体，每个三元组代表一个事实。它可以是“一个人是员工”，“一个服务很重要”或“属于第0层”，例如。它也可以是属性。这就是我们编码知识的方式。实际上，它非常基础，非常原始。就像说“泰山爱简”、“妈妈爱爸爸”。婴儿的脑海中也有微型本体论。我们只是开始在脑海中收集所有这些符号三元组，并开始提出命题和推理等。本体论是编码知识的一种方式。我们使用W3C标准，如RDF、OWL、网络本体语言、SPARQL查询语言、SHACL形状约束语言，我们可以说“服务可以在AWS中终止”，但另一个约束是“如果服务的容量超过或低于10%，则不能终止”。

你可以对所有这些内容进行编码。你可以描述你的服务和整个基础设施。例如，我们有API网关。它属于应用程序类型，由某个团队拥有，在某个区域部署，依此类推。我们可以对基础设施的每一个组件进行描述，每个组件都有命名空间。我们最初通过描述事件来构建这个本体论。我们已经识别出几个命名空间。我们正在构建一个操作本体论。目标再次回到Prasanna的愿景，即开始构建一个涵盖所有基础设施连接组件的端到端可观测性图。让我们称其为操作本体论。例如，我们识别这些命名空间，它们可以在三元组中被正式引用。

问题在于如何将这种操作混乱整理有序，这些事件分散在Slack、PagerDuty、MELT层、指标、追踪、日志和事件中。我们所有人都聚集在频道里。有数百条消息，涉及许多服务和人员互动。直到找到根本原因，数小时后才能解决问题。我们想要做到的是实时观察这些情况，开始实时编码。捕捉结构并以机器可读的类型保存这些信息。一条消息显然可以用英语表达。然后有人会说，"API网关在此次部署后出现了延迟峰值，然后Jane正在回滚"。然后你可以用三元组描述这些信息。这就是这样做的理念。手动完成这项工作非常困难。事实上，在没有AI的年代，你需要一个本体论专家，他一直在标注：这是什么，这是某个人，这是某个服务，依此类推。

借助AI，我们可以更快地完成这项工作。为此，我们创建了所谓的收割管道（harvest pipeline）。事件发生在Slack中，这是行动发生的地方。对于每个频道，我们转换每条消息，并将每条消息发送给一系列增强器（enrichers）。我们调用可观测性API，并在上面使用大语言模型（LLMs）进行额外分类，然后进行关联。我们将这些信息保存在图数据库中，我们称之为QuipuDB。绿色的增强器非常确定性。我们希望识别——例如，这是在incident.io上，我们将其用作事件管理软件——它具有这个ID。例如，我们提取了触发的PagerDuty警报。我们有各种非常确定性的、小型算法来分类事物，因为我们知道URL，例如，我们提取ID。我们还提取了线程或消息中发生事件的情绪。

在蓝色区域，我们展示了警报和正在发生的时间线。人们正在分享链接到我们的仪表板。我们对这些信息进行编码，并理解其含义。当有人上传快照或截图时，我们会保存这些内容。这些截图与当前图表和指标相关。在识别出所有基本模式或实体后，我们还会在流程末尾使用大语言模型（LLM），开始发现新的关系或概念，以及新的定义。可以看到，LLM能够识别出诸如“金丝雀分析”、“部署失败”等信息。它会从当前收集的数据中发现概念。如果发现新内容，我们会尝试提出新的定义。这在本体论中被称为“开放世界假设”，即你可以自由添加关系，但我们有方法来控制这一过程。这是一个高度可控的流程。这个过程是顺序进行的。有时如果某一步骤失败，我们会直接跳过。例如，我们无法获取某些数据时，就会将其忽略。随后，我们会与主要的元数据来源进行核对。例如，软件目录中包含了我们所有服务的定义。我们识别出每个服务，并知道它们的类型等信息。整个过程非常可控。

我们的目标是从非确定性中创建确定性。非确定性首先源于通道中的混乱，例如这是第一个非确定性来源。然后我们有一系列规则用于提取数据。最后，锦上添花的是大语言模型（LLM）会指出“这可能是一个新的关系”，并发现新的连接等。这里的矛盾之处在于，我们使用随机性工具来生成确定性的SPARQL可查询图。本体论是桥梁，所有数据都会保存在这里。我们识别出五个层级。这是一个引导启动的过程。确定性提取对应绿色部分的步骤。例如，我们有一系列正则表达式，可以通过ID或服务器来提取Jenkins作业的信息，这构成一个实体。这些是众所周知的模式。随后是目录验证，即核对服务是否是该区域部署的有效服务等。

我们通过API（如可观测性API）进一步丰富数据，然后将数据传递给LLM进行分类和发现新谓词。我们还有一个最终步骤，称为概率相关性分析。我们会首次在所有对话中进行搜索，找到事件链，例如某个应用引发影响应用B的事件，原始应用被回滚后问题得到解决。这条链也会被识别为一个实体和模式，保存下来以便未来可能发现类似事件的相似性。同时，所有内容都受到约束。我们有分类、一些分类法，它们都受到严格限制。当LLM进行分类时，例如判断某次对话是事件、问题、讨论还是决策，它只能从这四个选项中选择。我们不会让它随意生成新内容，除非它明确告知我们，然后我们会评估如何处理。所有内容都通过类型约束，例如“线程123相关”中的“true”是一个布尔值。

我们描述的这个过程是一个引导过程，我们称之为“知识飞轮”，每一次旋转都可能启动一个线程。我们开始识别实体。随着更多数据的输入，我们通过观察、丰富、推断和适应不断循环这个飞轮。我们观察MELT数据，通过各种丰富器进行数据增强，推断出新的或已有的模式并加以应用，同时通过适应来收集知识。从一个事件中得出的因果链将成为下一个事件的已知模式。观察、丰富、推断，这就是主要流程。在每次迭代中，我们都会编码知识。每个循环都会教会系统如何将本体论的模式演化到内存中。我们还有一个数据转化为信息的过程，这些信息被编码为知识。第四个阶段是智慧，即我们能够找到根本原因。我们今天可以编码这些内容，也可以在未来进行。

我们在这里尚未进行预测，只是在描述。首先是描述，就像婴儿所做的那样。父亲爱母亲，他知道这是事实，但之后还会发生更多事情。所有内容都可以通过SPARQL进行查询。SPARQL的语法有些奇怪，但你会逐渐习惯。大型语言模型（LLMs）喜欢它。我们并不在意。有时我甚至不阅读它。同样，本体论会积累持续发生的结构。模式会变成可查询的事实。

我们使用AI来处理这一点并不令人意外。我们使用Claude作为我们的协作者。当我们在事件中收到新线程或新消息时，我们会运行这个收割器。它会创建一个git工作树，因为我们不希望与其他分支发生冲突，因为可能有多个事件在同时发生，或者可能有另一个迭代即将开始。之前的收割可能仍在处理某些内容，尚未完成。它会创建一个git工作树或分支。然后我们还使用Claude进行收割。我们不仅仅运行脚本，而是运行Claude并结合收割脚本提取数据，因为LLM步骤可以发现新模式。同时，我们还用它来查找脚本中的潜在错误，使其能够自我修复。当这个循环结束时，我们最终为这一系列迭代只创建了15个分支，用于一个事件，然后人类介入进来。

无论是我还是Prasanna都可以介入，我们可以说：“我们有这么多分支，然后让Claude进行挑选，看看发生了什么。”它会发现一些非常有趣的事情。它会发现新的事实。例如，它会指出这五个分支几乎做了相同的事情，发现了这个模式。另一个分支意识到它正在运行Sonnet 4.5，于是决定将其升级到4.6，这很酷。它同时具备自我修复能力。你说：“好的，合并。”然后继续前进。这是一个元循环。飞轮产生知识，第二个飞轮改进机制，并目前使用我们。这个想法实际上是让系统不再依赖人类，而是自行合并。然后我们继续在上面迭代，形成许多飞轮，像金字塔一样层层叠加。直到系统完全自主运行后，我们再转向其他领域或命名空间。这就是我们在Slack中看到的情况，因为Slack很方便。

这是它的样子。例如，在每次迭代中，我们会找到一些频道，然后这些频道恰好是一个平台运营频道、一个指标/分析工程频道，所有这些分类都是它之前已经识别过的。我从未告诉它这些频道的分类，但我接受了它的判断。我查看并进行了抽查。这是一个告警管理频道，而不是事件响应频道。这些都是通用频道。我们也在监控所有Slack频道。因为请记住，这个想法不仅仅是从一个小本体开始，然后逐步扩展到基础设施的更大部分进行描述。这仅适用于通用频道。这是某次迭代结束时发生的情况。例如，在这次运行中，它发现了一些Turtle。Turtle是我们用本体语言序列化RDF的方式。它发现了一些正则表达式模式的问题，URI没有正确保存为有效的Turtle。

它发现了一些差异等。这就是我可以继续说明的部分，你可以合并这个更改，然后它会自动执行。所有测试通过。合并已经完成且成功。让我创建一个总结。这意味着在下一次迭代中，这段代码已经存在于主分支中。下一次迭代时，有人会在频道中添加新消息或发现新内容。有人找到根本原因，这将实际运行这段新代码。下一次启动的git工作树会自动合并这个修复。

我之前提到的提取这些链的部分，属于我们的相关性引擎。它会找到所有这些链。例如，某个提交包含了重试逻辑，它以这个版本部署。三分钟后出现了错误，连接超时，触发了告警，事件开始。然后LLM会生成自己的置信度，但我们保存了这条链。一个事件中可能有多个链。想象所有这些链一起存在，未来我们将拥有大量数据用于微调和相似性分析。代理实际上就是熵的减少者。正如我所说，我们接收的是嘈杂的输入。最终我们输出的是三元组，包含新的关系，同时我们找到了更有效提取数据的方法，因为代理循环正在发生。例如，我们执行SME（领域专家）检测。这个人实际上是一个领域专家，我们也能识别出主题。

这些三元组的积累最终会告诉我们，这个人是服务系统领域的专家，或者Kafka等领域的专家。我们还拥有这些基于现有Turtle的服务拓扑图，因为我们从多个来源自底向上构建，使用了eBPF、日志和追踪。我们创建了所有数千个服务依赖关系的图谱，说明哪些服务互相调用。这是其中的一部分。对于增强器的契约，我们有一个类，这是一个接口，你可以看到增强部分，可以向图中添加三元组等。我们有多个这样的类，随着更多数据的输入，会有更多增强器被添加。Claude实际上会告诉我们需要构建新的增强器，因为我们发现了之前历史中没有的新事物。它不在代码中，也不在本体中。我们需要创建。实体中的每个URI都是稳定的。我们有域名和ID。我们始终可以通过命名空间引用它们。

从图数据出发，我们进入知识库。在每次运行收割器时，我们都会将Turtle文件保存到S3。我们创建一个Parquet文件。我们有一个持续轮询该数据流的图数据库。实际上这是一个CDC（变更数据捕获）流，将三元组加载到内存中。我们可以实时查询，因为此时数据已经存在。例如，我们已经描述了该事件。其他人在Claude Code会议、Cursor或其他工具中，可以查询事件123的当前状态。我们已经拥有这些数据。大语言模型会生成SPARQL查询并开始提问，然后可能将其与过去发生的其他事件进行关联，依此类推。您可以使用其他MCP工具进行相关操作。我们还会保存Blob对象。例如，当有人上传图数据时，该文件会被保存到S3，并且我们知道它与某个指标相关。

这是使用的查询方式。所有内容都已描述。我所说的图，指的是仪表板中的图，它包含截图。截图的字节数据被保存在S3中。该Blob对象也是一个实体。所有内容都相互关联。我们可以恢复所有这些数据。也许您需要进行取证分析，回溯并精确还原事件发生时的具体情况。本体是混沌与理解之间的契约。我们的随机引擎被限制在这个基于本体的强类型系统中，它们生成可查询的确定性三元组。这就是我们最初构建事件本体的方式，包含几个命名空间、众多代理和信号。

这是每次运行时生成的产物之一。这只是一个保存在S3中的HTML文件。我们使用它来进行调试，因为刚才我正在查看，是否提取了正确的内容？我知道必须存在Jira问题、Slack用户或文件附件等所有这些内容。每次运行时，有时我会发现无法找到文件附件。我需要一些产物作为目标，因为我要一直查看代码。我查看这些结果是因为我知道里面必须包含什么。如果缺少这些内容，我们需要持续修复。最终，通过使用这个产物，我能够进行检查。这只是一个事件的时间线。所有内容都经过类型定义并相互关联。这是一个包含许多关系的大事件。拓扑结构和服务依赖关系也编码其中。任何人都可以提出任何问题，比如哪些团队参与了事件。

这里谁的情绪值较低？谁压力特别大？所有内容都相互关联。想象所有这些事件在大图中相互连接，我们可以同时查询它们。真正的挑战在于如何保持所有这些数据随时间流动，我们称之为时间旅行。目前，我们只保存几周的数据。所有数据都存储在S3中，最终我们可以构建一个庞大的数据库，随时进行查询。

AutoSRE - 应用本体

我们如何使用本体？其中一个应用是我们称之为AutoSRE的解决方案。这是我们的AI SRE方案，现在在业界被称为站点可靠性工程的AI辅助工具。AutoSRE的功能是实时接入指标、日志、追踪信息以及Slack。它包含拓扑结构，也包含设备信息，并能以端到端的方式查看设备图谱。通过接入本体，它在知识图谱中建立更高层次的概念关系。以LOLOMO事件为例，AutoSRE不仅会通知值班人员，还会分析所有MELT数据和正在运行的A/B测试版本，其关联分析速度远超人类。它能快速识别涉及的事件或应用，并找到相关日志。

它会利用这些信息。我们有一系列MCP和CLI工具，用于查询基础设施，不仅限于本体，还包括整体数据。它还会分析代码，因为如果不深入代码就无法理解系统。这是它的输出结果：它指出，这个记录操作出现了GraphQL错误激增，下一步建议采取这些措施。我们实际上增加了交互功能，用户可以提出后续问题，因为目前任何AI都很难在第一次交互中就给出准确答案。需要经过多次迭代才能深入挖掘，因为大语言模型可能会偏离主题。

未来展望

我们未来将聚焦三个方向。首先是实现自动根本原因分析，我们不再需要反复排查，只需给出结论：这就是根本原因。其次是实现自动修复。例如，当我们识别到某些模式时，本体会建议：在这种情况下，最佳做法是直接终止实例。执行即可，无需人工干预。第三是自愈基础设施，这是终极目标。我们甚至不想发生事件，不想收到任何告警。我们希望持续向左移动，最终达到基础设施自动修复的境界。当我们将不仅限于描述事件和运营数据，还会将本体与数据血缘关系合并，最终形成一个完整的体系。例如，某部电影的诞生可能源于某个团队在特定时间由某人运行的流水线中出现的数据错误，最终导致用户服务的点击率下降。这就是我们希望实现的端到端愿景：不仅构建本体，还要与其他更大领域融合，创建一个描述一切的大型企业本体。这正是Prasanna最初展示的端到端轮子概念，将所有小型本体连接成一个巨大的循环。

在座有人知道《Dark》中的这个角色吗？他们实际上是时间旅行者。有一个组织成功掌握了时间的力量，他们能够前往未来，也能够获取知识。这里的灵感来自他们的一句箴言："Der Anfang ist das Ende und das Ende ist der Anfang"（开始即是终结，终结即是开始）。这句话意味着观察、丰富、推断。我想用这个类比作为结尾。

问答环节

参与者1：在处理这些事件的图中，如何处理重复项和歧义项？

Renzo Sanchez-Silva：目前我们允许LLM进入这个开放世界。它会进行检索并创建三元组，然后指出某些关系已经存在，我们让它继续创建。这会产生需要合并的分支，但我会让它继续执行，不断向本体中添加内容。我们可能会得到许多相似的概念，但尚未验证这一点。理想情况下，对于这个较小的本体，过程会趋于稳定，我看到需要合并的PR数量在减少。最终它确实会变得稳定，但需要经过人工审核。例如，本体专家需要实际查看这些内容并仔细检查。我看到的是，去重过程非常可控，这是可以实现的。

Prasanna Vijayanathan：未来我们还需要构建一个模式提取层，通过泛化模式来辅助去重。目前我们尚未实现这一点，但已经能够处理。

参与者2：在这些图中，所有事物都可能与其他事物产生关联。如何优化基础设施以从噪声中提取更多有效信号，使输出内容不是幻觉或可能相关的信息，而是真正可操作、真实且对用户有价值的信号？

Anand：如何消除虚假相关性？这是否可行？

Prasanna Vijayanathan：回到传统的测试系统，我们采用的是瑞士奶酪模型。我们希望尽可能提供准确且可操作的信息，而目前最了解这一点的是用户。正如Renzo提到的，系统能够自主创建并自我修复。我们还跟踪多种质量指标，包括在线日志提取指标、评估系统以及冻结输入输出后的持续测试。我们还引入了人工反馈机制。所有这些系统都会反馈到模型中，虽然目前尚未大规模应用，但未来将通过强化学习利用这些信号进行优化。

参与者3：我对规模问题很感兴趣，因为看起来整个图都是用Turtle格式通过PR代码创建的。这似乎只是那些每秒3200万次查询中的一小部分，我们并没有将这些数据点关联起来。这是一个更高层次的结构，对吗？

Renzo Sanchez-Silva：对于这种高吞吐量场景，我们只会收集元数据，记录某些事物已开始的指纹。我们已经发现这种模式，但不会获取完整的Turtle数据，这在技术上不可行。我们将找到正在发生事件的指纹，并将其关联到整个图的其余部分。同时我们始终控制着基数规模。

参与者4：如何检测重要事件未发生的情况，而不是仅仅关注负面事件的发生？

Renzo Sanchez-Silva：本体实际上具有非常强大的形式化推理能力。这与AI无关，而是基于比例和逻辑的严格算法。这些算法能够发现不一致、传递性或矛盾关系。我们计划利用形式化推理来捕捉这些现象。这不仅能发现数据中的不一致性，还能发现新的关联。我们可以使用非AI方法进行形式化推理，同时也可以用AI来增强基础推理能力。

Prasanna Vijayanathan：在该系统中，人工干预也起到了很大作用。当开发人员发现某些未被检测到的问题，或我们注意到需要解决的事件或问题时，我们会分析系统为何未能捕捉到这些问题。事实上，最近有一个案例，有人指出并问：“为什么没有提前告诉我？”系统随后自行修正并生成了新的关联对。这就是该系统的另一面。

参与者5：能否告诉我您多久允许本体论进行一次更改？这会对知识图谱的重建产生什么影响？

Renzo Sanchez-Silva：我们采用开放世界假设来处理本体论的变更。至少在事件处理方面，系统表现得相对稳定，但我们也会通过警报发现新的关联。这是一个非常小的本体论，因为我们只关注警报的元数据。警报中包含的关键词或概念非常有限，例如信号部分。而对于管道、任务等其他内容，也有相应的控制方式。整体规模很小。真正具有挑战性的是事件处理，因为任何情况都可能发生。虽然概念在不断扩展，但如我所说，最终会趋于稳定。在某些时候，我们需要回溯并依靠人工进行压缩，从而保持可控性。我们确实需要人工参与。

参与者6：有计划开源吗？

Prasanna Vijayanathan：可能有，但目前还没有具体安排。

查看更多带字幕的演讲

录制时间：

2026年10月9日

由以下人员呈现：

• Prasanna Vijayanathan

• Renzo Sanchez-Silva

#### 相关赞助商

• AI的物理限制：AI如何重构数据中心

#### 相关赞助商

PostgreSQL为时间序列数据而生：无需牺牲性能即可处理海量时间序列数据。了解Tiger Data如何实现高速数据摄入、快速查询和可扩展存储。了解更多。

#### 本内容属于AI、机器学习与数据工程主题

##### 相关主题：

• 架构与设计

• DevOps

• AI、机器学习与数据工程

• 运维监控

• WebSphere MQ

• WebSphere

• 应用服务器

• AIOps

• Java

• 持续交付

• 敏捷技术

• Web服务器

• 可观测性

• 敏捷开发

• Web开发

• QCon伦敦2026

• 自动化部署

• 监控

• QCon软件开发大会

• 字幕

• 应用性能管理

• 本体论

• IT服务管理

• IBM

• 站点可靠性工程

• 性能优化

• 机器学习

• 扩展性

• InfoQ

• 架构设计

• 云计算

• 相关编辑内容

• InfoQ热门内容 Uber Eats重建搜索管道，将端到端延迟降低50% 未来网络安全：硬件内存安全、自动化治理与后量子密码学 OpenTelemetry使Kubernetes属性处理器随着可观测性模式成熟而稳定 Pizza Bot：用于后台AI代理的开源收件箱 Akka通过65个开源项目实现基于规格的AI交付 GitLab漏洞正在被积极利用，可实现未认证数据泄露