🤖 AI

A Topology-Aware, Memory-Centric Architecture that Separates Root-Cause Derivation from Root-Cause Explanation

本文介绍了 OPS CORTEX，一种拓扑感知且以内存为中心的架构，它通过维护系统行为和依赖关系的持久化结构化表示，将确定性的根因推导与基于大语言模型的解释解耦，从而应对现代微服务部署中故障传播带来的挑战。

原作者： Momil Seedat

发布于 2026-06-23

📖 1 分钟阅读☕ 轻松阅读

原作者： Momil Seedat

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下你是一位庞大、高科技飞船的舰长。突然，到处响起了警报声。灯光闪烁着红光。飞船在剧烈摇晃。

问题所在：
在现代计算机系统（称为“微服务”）中，当发生故障时，触发警报很容易，但理解警报却很难。这就像是有50个不同的传感器同时在尖叫“起火了！”。真正的难题不在于传感器不起作用，而在于负责指挥的人类（工程师）被淹没了。他们必须弄清楚：

哪个传感器才是“真正的火源”？
哪些传感器只是在对第一场火灾产生的烟雾做出反应？
为什么这件事现在才发生，而不是昨天？

通常，计算机系统在警报停止的那一刻就会忘记一切。它不知道周二凌晨3点是什么样子的，也不知道它的各个部件是如何连接在一起的。因此，工程师每次都必须从零开始扮演侦探的角色，而且往往是在系统仍在崩溃的过程中进行。

解决方案：OpsCortex（“运维记忆”）
这篇论文介绍了一种运行这些系统的新方法。作者并没有试图通过一个巨大的大脑（比如超先进的AI）来让计算机变得更“聪明”去猜测答案，而是说：“给系统一个记忆。”

把 OpsCortex 想象成一个高度组织化的、长期的计算机系统记忆库。它被构建成一个四层结构的图书馆：

热桌（第一层/Tier 1）： 这是“当下”。它保存着当前温度、速度和警报。它就像桌子上的便利贴，每隔几小时就会被扔掉。
实时地图（第二层/Tier 2）： 这是所有计算机服务如何相互通信的图谱。如果服务 A 与服务 B 通信，这张地图就会知道。它是实时更新的。
相册（第三层/Tier 3）： 系统每分钟会对整个地图拍摄一张“快照”并保存。这让你能够回溯查看：“噢，连接是在5分钟前断开的，而不是1秒前。”
百科全书（第四层/Tier 4）： 这是永久的大脑。它记得：“在周二凌晨3点，系统通常会稍微变慢，这是正常的。”它还记得过去的灾难以及是如何修复的。

它是如何工作的：“侦探与翻译官”
论文认为，寻找问题的根源和“解释”问题是两项不同的工作。OpsCortex 将它们分开了：

步骤 1：侦探（确定性逻辑）：
首先，系统使用简单的、硬性的数学规则（就像侦探追踪脚印一样）。它观察“实时地图”并询问：“哪个服务最先损坏？”以及“哪些服务与其相连？”
- 类比： 如果一个多米诺骨牌倒下并撞倒了后续的10个骨牌，数学规则不会进行猜测。它只是简单地指向第一个倒下的骨牌。这是100%可靠且快速的。
步骤 2：翻译官（AI/大语言模型）：
只有在 侦探找到了罪魁祸首之后，系统才会调用“AI 翻译官”。
- 类比： AI 不被要求去猜测谁干的，而是由侦探递给它一份证据文件夹（包含地图、时间线、第一个倒下的骨牌）并说：“这就是发生的情况。现在，请用人类能听懂的自然语言写一份报告给舰长，并告诉他们如何修复它。”
- 这使得 AI 的工作效率更高，因为它不是在猜测，而是在解释事实。

为什么这更好（“静默”技巧）
系统还学会了忽略“噪音”。

问题： 每天晚上，某个计算机可能会运行一个大型、缓慢的任务，这看起来像是崩溃，但实际上是正常的。旧系统会不断发出“警报！”的尖叫。
OpsCortex 的解决方法： 系统学会了：“噢，这每天凌晨2点都会发生，这是正常的。”于是它保持沉默。
安全网： 但如果同一个任务突然比平时更慢了，或者它发生在下午2点而不是凌晨2点，系统就会记住：“等等，这跟平时的模式不一样！”然后唤醒警报。

现实世界的证明
作者在一个模拟的在线商店上测试了它。他们以8种不同的方式破坏了它（比如让队列积压或使某个服务过载）。

当他们针对现实世界的灾难（如论文中提到的 Slack 停机事件）进行测试时，该设计直接解决了这些公司面临的问题：
- Slack 2021： 他们的仪表盘本身也坏了，因为仪表盘依赖于同样的受损网络。OpsCortex 不需要仪表盘；它拥有自己的永久记忆（第四层），所以即使主要工具失效，它仍能正常工作。
- Slack 2022： 一个微小的变化在高峰时段引发了巨大的崩溃。OpsCortex 记得“高峰时段”通常是什么样子的，因此它能在警报响起之前就发现向灾难演变的“漂移”。

底线
论文声称，修复计算机系统的最大问题不在于我们缺乏更好的传感器或更聪明的 AI。问题在于我们缺乏记忆。

OpsCortex 说：“让我们建立一个能记住什么是正常的、记住事物是如何连接的、以及记住过去错误的系统。”通过这样做，它可以利用简单的数学找到根源，然后仅使用 AI 来清晰地解释它。这使得系统更便宜、更冷静，并且修复自身的速度更快。

技术摘要：OpsCortex —— 用于自诊断微服务系统的操作记忆

问题陈述

现代微服务架构面临着一个关键的不对称性：故障检测已经成熟且自动化，但根因定位与解释仍然依赖人工，过程缓慢且容易丢失上下文。当故障通过服务依赖关系传播时，会触发“告警风暴”，使工程师应接不暇。识别出的核心挑战包括：

告警疲劳： 基于阈值的系统是“无记忆”的；它们无法区分良性的循环事件（如夜间批处理作业）与真正的危机。
上下文丢失： 关键的诊断数据——例如实时调用图、时段基线以及最近的配置变更——往往是瞬态的或分散的，迫使诊断工作变成一种“考古学”。
级联问题： 故障信号具有拓扑性和时间性（谁先损坏以及损害如何扩散），然而扁平化的告警流丢弃了这种结构，使得区分根因与下游受害者变得困难。

本文认为，自主运维中缺失的要素不是更好的异常检测器或规模更大的大语言模型（LLM），而是操作记忆（operational memory）：一种关于系统行为、依赖关系和历史故障的持久化、结构化表示。

方法论

OpsCortex 是一个多智能体原型，它将操作记忆组织为四层架构，并将根因推导与解释进行分离。

1. 四层操作记忆架构

系统按生命周期和用途对记忆进行分层，以确保系统在重启时不会处于“盲目”状态：

第一层（热工作记忆 - Redis）： 存储当前指标值、滑动窗口和告警流，带有短生存时间（TTL）。这代表了系统的“现在时”。
第二层（实时依赖图 - NetworkX）： 一个进程内的三层有向图（服务 $\rightarrow$ 类别 $\rightarrow$ 指标），包含 CALLS 边。状态向上层传播（最差的指标决定类别的状态等），以便进行快速遍历。
第三层（快照历史 - Neo4j）： 每 60 秒序列化一次完整的图。这使得系统能够分析在事件发生前的几分钟内状态是如何变化的，从而区分缓慢的泄漏与突发性的崩溃。
第四层（永久大脑 - SQLite）： “学习”到的状态。它存储每个服务/指标/小时/工作日的基线、具有置信度计数的已确认调用边、结构性噪声注册表以及完整的事件历史。在冷启动时，此层会在新遥测数据到达前重建图和基线，确保系统在重启后仍能保留知识。

2. “先推导，后解释”流水线

诊断过程被刻意分为两个截然不同的阶段，以利用确定性逻辑和生成式 AI 的各自优势：

阶段 1：确定性推导：
- 根因计算： 系统在已确认的 CALLS 边上执行广度优先搜索（BFS），以识别所有与故障相关的服务。
- 时间排序： 根因被定义为第一个跨越其告警阈值的服务（即 $\arg \min t_{amber}$ ）。这实现了原因与受害者的分离。
- 噪声处理（先抑制后检测）： 系统学习结构性噪声（例如无害的夜间作业）并抑制此类告警。然而，当出现突发尖峰（自 z 分数）、渐进漂移（趋势 z 分数）或同行服务的相关异常时，抑制机制会被覆盖。
- 时间感知基线： 检测过程使用按（服务、指标、小时、工作日）分组的基线，以应对正常的周期性变化。
阶段 2：生成式解释：
- 仅在确定性层识别出根因并组装好证据（故障路径、z 分数、孤立森林得分、状态演进）之后，才会调用 LLM。
- LLM 的任务被限定为基于提供的证据进行解释、确认和提供修复建议，而不是从原始遥测数据中推断因果关系。
- 模式匹配： 如果新发生的事件匹配了“永久大脑”中的已知特征，系统会重建先前的诊断并完全绕过 LLM，从而降低成本和变异性。

核心贡献

四层记忆架构： 一种将当前状态、实时拓扑、变更历史和永久知识分离的设计，防止了重启时的上下文丢失。
两阶段根因法： 一种结合了确定性方法（BFS + 时间排序）来计算原因，并由 LLM 严格承担解释者角色（使用预组装证据）的方法。
学习型“先抑制后检测”生命周期： 一种既能静默结构性噪声，又能根据真实的退化情况（尖峰或漂移）动态取消抑制的机制。
显式的失效模式映射： 一种直接的架构映射，其中每一个设计选择都针对了在记录的生产事故（Slack 2021 和 2022 中断）中观察到的特定失效模式。

结果与验证

该原型在了一个带有可注入故障场景的仪表化电子商务基准测试上进行了验证，其中包括请求激增、队列延迟、级联故障和资源耗尽。

学习行为： 系统成功展示了学习并抑制良性循环模式（批处理作业）的能力，同时能在这些作业发生退化时立即检测并取消抑制。
模式绕过： 系统成功识别了已知模式以绕过 LLM，证明了随着系统“学习”所带来的成本效益提升。
验证范围： 作者明确指出，这是对端到端机制的验证，而非针对生产数据或其他工具（如 MicroRCA）的比较准确性评估。

意义与主张

本文认为，自主运维的瓶颈在于记忆，而非感知。虽然检测系统层出不穷，但理解常态、依赖关系和历史的系统却并不多见。

OpsCortex 声称其意义在于为以下内容提供了具体的架构论证：

重构目标： 从每次收到告警时都从头开始推断根因，转向维护一个“活的模型”，其中答案往往是已知的。
分工协作： 将确定性任务（定位、排序）分配给基于规则的系统，而将生成式任务（解释、建议）分配给 LLM，从而降低了产生幻觉根因的风险。
降低成本： 通过学习抑制噪声和针对已知模式绕过昂贵的 LLM 调用，使系统随着时间的推移变得更加“廉价”。

作者对该原型的当前状态保持谦逊，承认了其局限性，例如使用“首次跨越”作为因果关系的代理指标（这在反馈耦合系统中可能会失效），以及缺乏在真实世界标记事件语料库上的评估。未来的工作方向被确定为从时间启发式转向因果推理，并在真实的后置分析（post-mortem）数据上进行验证。