RCACopilot: 微软如何用大语言模型自动诊断云事件

本文来自会议EuroSys'24，将大语言模型用于根本原因分析（故障分析）。

确保云服务的可靠性和可用性，需要对云事件进行高效的根本原因分析（RCA）。传统的 RCA 方法，依赖于手动调查数据源，如日志和跟踪，往往既费时又容易出错，对值班工程师来说也是一项挑战。本文介绍了 RCACopilot，这是一个借助大型语言模型实现云事件 RCA 自动化的值班系统。RCACopilot 根据警报类型将传入事件匹配到相应的事件处理程序，汇总关键的运行时诊断信息，预测事件的根本原因类别，并提供解释性叙述。 本文使用来自微软公司一年的真实事件数据集对 RCACopilot 进行了评估。结果显示，RCACopilot 的 RCA 准确度可以达到 0.766。此外，RCACopilot 的诊断信息收集组件已经在微软公司成功使用了四年多。

云计算作为众多应用和服务不可或缺的基础设施，人们每天都需要依赖它。随着云服务的采用持续增长，确保其可靠性、可用性和安全性变得越来越重要。然而，云系统的复杂性使得它们容易受到各种事件的影响，这些事件可能对这些关键属性构成重大挑战。一个典型的事件生命周期包括四个阶段：（1）检测：当观察到异常系统行为时，由监控或服务用户（内部工程师或外部客户）发出警报。（2）分类：在检测到事件后，经过初步评估，事件被分配给合适的技术团队。（3）诊断：指定的值班工程师检查事件的不同方面，并进行多轮的沟通以确定根本原因。（4）缓解：值班工程师采取多种行动来缓解事件并恢复服务健康。

根本原因分析（Root Cause Analysis, RCA）在及时有效地处理这些事件中起着关键的作用。通过准确诊断潜在问题并防止其再次发生，RCA 不仅能够迅速恢复服务可用性，还能加强云服务的整体可靠性。然而，确定这些事件的根本原因通常是一个既困难又耗时的工作，需要大量的人力和干预。传统的云事件 RCA 方法通常涉及手动收集和分析各种类型的数据，如日志、指标、跟踪和事件工单。这种手动过程不仅劳动强度大且容易出错，而且由于可获取信息的不同水平——即所谓的“信息光谱”——可能存在挑战。“信息光谱”描述了信息可获取性的连续统一体，从信息过少到信息过载的情况。在这两个极端，RCA 可能变得特别具有挑战性。相关于 RCA 的信息可能被埋没在大量数据中，导致值班工程师信息过载。他们可能发现很难在大量数据中快速找到相关信息，这阻碍了事件的高效解决。反之，值班工程师也可能会遇到缺乏必要信息以准确理解和处理事件根本原因的情况。

除了这些挑战之外，收集的数据本身通常是嘈杂的、不完整的和矛盾的，进一步复杂化了 RCA 过程。具体而言，工程技术团队以故障排除指南（TSGs）的形式记录常见的故障排除步骤，以方便处理未来的事件。然而，对于值班工程师来说，TSGs 的量是巨大的，使得寻找最相关的指南成为一个耗时的任务，可能导致系统停机。此外，TSGs 很难跟上云系统不断发展的步伐，因此当新的事件类型出现时，常常无法应对。即使找到了相关的 TSG，也可能没有涵盖特定事件的所有复杂性。这可能是由于系统配置的差异、多个相互作用的根本原因的存在，或者是之前未知的问题。

RCA 的核心挑战在于在有限的时间范围内完成高效地收集和解释全面的事件特定数据。值班工程师必须快速识别各种数据类型与手头事件的相关性，并正确解释它们。然而，由云系统生成的数据的复杂性和数量往往阻碍了快速决策。此外，分析各种数据类型所需的专业知识，以及可能导致事件的各种可能原因，使得任务更加困难。因此，值班工程师可能会花费大量时间分析数据并形成假设，从而影响了本可以更好地用于解决事件和恢复系统功能的时间。

数据驱动和人工智能（AI）技术已被用于自动化事件管理。尽管存在一些技术可以推荐相关的 TSGs 并自动化 TSGs 的工作流程，但它们的实用性受到与 TSGs 相关的固有挑战的限制。尽管有了这些自动化流程，值班工程师仍然需要投入大量的人力和时间来筛选海量的信息，解释数据并确定事件的根本原因。

最近，大型语言模型（LLMs）在执行复杂任务方面的出现和成功，为增强 RCA 提供了一个有希望的方向。具体而言，LLMs 可以用来解析大量数据，识别相关信息，并产生简洁、有洞察力的输出。这大大减轻了值班工程师手动筛选大量数据的负担，帮助他们更快速、更有效地解决事件。此外，LLMs 可以适应新出现和不断发展的各种事件类型，通过学习以前的数据来改进未来的预测。尽管 LLMs 可以高效地处理和生成文本，但它们缺乏特定领域的内在知识，尤其是在像云事件管理这样的专业领域。这种对特定上下文（如云事件）缺乏理解可能会限制它们在预测事件根本原因和生成适当解释方面的准确性。

本文提出了 RCACopilot，这是一种新颖的值班系统，是一种自动化的端到端方法来处理云事件的 RCA。RCACopilot 作为一个值班系统运行，使值班工程师能够构建“事件处理程序”——针对每种警报类型定制的自动化工作流程，由反映值班工程师专业知识的可重用操作组成。这些预定义的处理程序自动从多个来源收集事件特定的诊断信息，从而确保更集中、更相关的数据积累过程，避免信息光谱两端的问题。随后，RCACopilot 中的 LLM 组件处理这些诊断数据，预测事件根本原因的类别标签并提供相应的解释。事件处理程序和 LLM 的结合使得 RCACopilot 在事件响应中的适应性和可扩展性大大增强。因此，RCACopilot 能够有效地处理各种类型的事件，同时减少对人工干预的需求。

RCACopilot 的诊断信息收集组件在微软公司已经使用了四年多。最近的发展中，一个根因预测组件被原型化，经过一个成功的初步阶段后，已经被微软的事故管理团队积极部署了数月。

本文做出了三个主要贡献：

• 本文提出了 RCACopilot，一个自动化的端到端解决方案，用于云事件根因分析，它使值班工程师能够构建针对特定事件的自动工作流程，以从多个来源高效地收集数据。
• 本文介绍了在 RCACopilot 中集成一个大型语言模型，该模型能够自主分析收集的诊断数据，预测事件根因类别并生成解释，展示了大型语言模型在根因分析中的潜力。
• 本文通过展示 RCACopilot 在微软的成功应用，展示了其在现实世界中的适用性。这证明了它在提高根因分析效率方面的实际效果，展示了我们的方法在现实世界云场景中的可行性和益处。

▶背景

在云服务领域，事件是指任何中断正常服务操作或导致服务质量下降的事件。当此类事件发生时，将执行根本原因分析以识别导致中断的根本问题。云服务中的 RCA 是一个多方面的过程：

• 数据收集：从日志、指标、跟踪或警报等各种来源收集与事件相关的数据。
• 数据分析：对收集的数据进行分析，以识别可能提供事件根本原因线索的模式、异常或相关性。
• 假设验证：根据数据分析，形成关于可能根本原因的假设，并由操作中心工程师（OCEs）进行验证。

鉴于云系统的复杂性和动态性，以及涉及大量数据，进行 RCA 是一项具有挑战性的任务，需要大量的专业知识和时间。以公司邮件服务的规模为例，每天发送超过 1500 亿条消息。确保如此大规模服务的顺畅运行需要高效且有效的 RCA 方法。这对于维护可靠且高性能的通信基础设施至关重要，特别是对于那些严重依赖公司邮件服务器的组织。

>>> Troubleshooting Guide for Poisoned Messages
1. Go to the Poisoned Message Dashboard. This page gives a real-time, high-level view of the Poison Mes- sage feature. The charts should indicate whether the problem has resolved itself or is ongoing, as well as some sense of where it is occurring . . .
2. The Dashboard newly implements an Exception Ta- ble that has poisoned messages within a time frame. In most cases, whatever exception is causing an alert will rise to the top of the table . . .
3. You may also check the Poison Message Logs . . .
4. ...

在云服务的复杂生态系统中管理事件需要全面了解系统状态。这种理解通常源于多源数据的整合，包括跟踪、日志和指标。跟踪表示树状结构的数据，详细记录用户请求的流程；日志是半结构化文本，记录硬件和软件事件；而指标监控服务状态或用户感知的指标，形成时间序列数据。尽管这些单个数据源提供了有价值的见解，但利用它们的潜力具有挑战性。传统的方法如 TSG 虽然有用，但由于固有的局限性，可能无法充分利用多源数据。

多源数据的机会：不同的数据源提供了对系统状态的不同视角。例如，日志可以提供详细的事件序列，指标可以反映系统随时间的性能，而跟踪可以揭示请求在服务之间的传播。整合这些数据源可以提供对系统的更全面视图，使事件诊断和解决更准确、更高效。此外，多源数据可以促进相关性和因果分析，这对于根本原因分析至关重要。通过分析不同数据源之间的关系，我们可以识别可能指示事件根本原因的模式和异常。

多源数据的挑战：尽管其潜力巨大，但在事件管理中有效利用多源数据具有挑战性。来自各种来源的数据的庞大体积和复杂性可能会让人不知所措，使得提取有意义的见解变得困难。更糟糕的是，不同的数据源可能提供不一致或冲突的信息。此外，现实世界的数据往往噪声很大，这可能会复杂化分析并导致错误的结论。

TSG 的局限性：传统的 TSG 是利用多源数据进行事件管理的早期尝试。它们指导 OCEs 从各种来源收集和分析数据，以诊断和解决事件。然而，TSG 面临几个固有的局限性：

• 手动数据整合：TSG 通常需要 OCEs 手动从不同来源收集数据。这个过程可能既耗时又容易出错。尽管存在各种故障排除指南和 TSG 推荐技术，但依赖 TSG 仍然给 OCEs 带来了巨大的压力和疲劳，这是由于手动过程的固有局限性。
• 过时的信息：TSG 作为静态文档，往往难以跟上系统变化和新事件根本原因见解的发展。这种滞后可能导致 OCEs 遵循过时或次优的故障排除步骤。
• 细节不足和覆盖范围有限：TSG 中通常出现高级指令，缺乏详细和具体指导，迫使 OCEs 进行额外的研究，延长了事件缓解时间。

本文的研究动机源于使用手动故障排除指南（TSGs）诊断事件和识别根本原因时所面临的挑战。我们的目标是开发一个自动化的诊断流程，利用大型语言模型的能力更有效地应对各种云事件。与之前使用人工智能技术从现有的 TSGs 生成自动化工作流程的研究不同，本方案的目标是使经验丰富的 OCEs 能够构建用于事件诊断的自动化 pipeline。 这种方法允许 OCEs 在不需要调查中间诊断信息的情况下直接得到帮助识别根本原因，尽管他们仍然有选择这样做的选项。我们设想的未来是一个根本原因分析主要自动化，只有在必要时才需要最少手动验证的未来。我们的方法旨在为 OCEs 提供及时、相关和准确的特定事件信息，从而实现更高效的根本原因分析（RCA）。通过利用大型语言模型预测根本原因类别，本研究旨在减轻与事件管理相关的压力和认知负担，最终提高解决事件的效率和效果。

本文对微软的一家电子邮件服务公司一年内的事件进行了全面研究，采用了严格的定性分析方法。具体来说，经验丰富的 OCEs（操作危机专家）对每个事件进行了仔细的审查，并根据问题的特点、问题的来源以及事件对系统的影响进行了分类。本文特别关注事件的根本原因、响应效果以及类似问题的再次发生。虽然本文的见解确实是直观得出的，但它们都基于实证数据和分析，具有坚实的基础。本研究不仅对事件模式和挑战提供了有价值的见解，还促进了我们方法的发展和改进。

洞察 1：基于单一数据源确定根本原因可能具有挑战性

例如，考虑表 1 中的事件 2，其中一台服务器由于前端机器的 UDP 端口耗尽，无法对传入的数据包进行 DNS 解析。这个例子突显了仅依赖单一来源（监控警报）诊断复杂问题的困难。

当邮箱服务器向外部电子邮件接收者发送邮件时，它会使用特定的前端服务器（代理）。然而，每个前端服务器都有有限的 SMTP 出站代理连接数量。如果邮箱服务器的代理连接请求失败，它将无法向外部接收者发送消息。在此事件中，监控首先发出警报，指出连接前端服务器时检测到故障。然而，这个警报仅表示邮件服务器与前端服务器之间的连接问题，并未提示 DNS 解析问题。因此，根本原因仍然不清楚。

洞察 2：源于相似或相同根本原因的事件往往在短时间内重复发生

本文发现，大多数重复发生的事件（93.80%）倾向于在短短 20 天内再次出现。例如，考虑表 1 中事件 9 的类别。这类事件由无效的客户配置触发，导致消息队列中未处理的消息积压，从而严重削弱了其可用性。有趣的是，这类事件在短短 15 天内重复发生了 11 次。同样，DispatcherTaskCancelled 事件（表中的第 10 号）和 DeliveryHang 事件（第 3 号）在一周内和一个月内分别重复出现了 22 次和 6 次。这些可能归因于几个因素。初次响应未解决的根因可能导致相同问题再次出现，尤其是问题复杂或未完全理解时。其次，如果系统性漏洞未得到解决，可能会被反复利用，导致类似事件发生。第三，依赖经常出现故障的外部服务也可能导致重复事件。这些模式表明，通过利用以前事件的见解，我们可以迅速识别具有相同根本原因的新事件的根因。

洞察 3：具有新根本原因的事件频繁发生，分析起来更具挑战性

TSGs（技术支持指南）可以帮助 OCEs 诊断问题，提供清晰的研究指导。然而，当事件源于新的、以前未遇到的根本原因时，OCEs 面临一系列挑战。对于这类事件，没有现成的 TSG，OCEs 可能难以确定根本问题。例如，事件 1 是一个由配置错误引起的高严重性（严重性 1）事件，阻止了身份验证令牌的生成，导致严重的中断。同样，事件 6 是由攻击者发起的恶意攻击，利用恶意的 blob 发起攻击。这种类型的攻击以前从未遇到过，使得 OCEs 没有现成的 TSG 可以参考。严重性较低的（严重性 2）事件，如事件 5，也容易受到这种挑战，尤其是当垃圾邮件发送者首次滥用系统时。如图所示，具有新根本原因类别的事件占所有事件的 24.96%（653 起中的 163 起）。如果 OCEs 花费时间寻找不存在的 TSGs，事件的影响可能会进一步升级。认识到这一挑战，有必要提出一种新的方法，该方法能够有效地推断、分类和解释这类未见事件的根因，从而减少 OCEs 识别和处理这些独特事件所需的时间。

RCACopilot 有两个阶段：诊断信息收集阶段和根本原因预测阶段。诊断信息收集阶段：这是初始阶段，在该阶段中，会对事件进行解析并与预先定义的事件处理程序匹配。每个事件处理程序都是针对特定警报类型定制的。匹配到适当的事件处理程序后，RCACopilot 将开始从各种来源收集相关的诊断数据。根本原因预测阶段：收集完诊断信息后，RCACopilot 进入根本原因预测阶段。在这个阶段，RCACopilot 使用其预测模块来确定事件可能的根本原因类别。这个预测不仅仅是简单的分类，而且还附带了详细解释 RCACopilot 是如何得出该预测的。随后，预测的类别标签会呈现给经验丰富的操作控制工程师（OCEs）进行审查。

在 Insight-1 的推动下，RCACopilot 旨在收集多源数据用于根本原因分析（RCA）。具体来说，对于每种警报类型，构建了一个事件处理器，其中包含一系列用于收集诊断信息的操作。警报类型用于根据特定的监视器对警报进行分类。具有相同警报类型的事件表现出类似的症状，尽管它们可能源于不同的根本原因。

RCACopilot 的事件处理器是一个工作流，由一系列操作组成。每个操作是一个可以从目标数据源收集特定诊断信息的函数。操作专家（OCE）可以根据自己的专业知识构建和修改这些处理器。处理器包括三种不同的操作：范围切换操作，查询操作和缓解操作。每个操作都会生成一个输出，指导事件处理器的控制流程。本文以诊断表 1 中事件 7 的 RCACopilot 处理器为例，说明处理器的使用方法。

▶事件处理器

当操作专家处理事件时，他们采用的决策过程类似于决策树的控件流程。事件处理器中的根节点是事件警报类型，这是从系统监视器中获取的。在构建事件处理器时，本文将操作专家的操作提炼为三种操作。由于操作专家的操作可能对不同的突发事件类型相似（例如，执行常见的磁盘检查或查询数据库），因此本文设计了 RCACopilot 处理器的操作以在所有处理器之间可重用。本文还在数据库中维护处理器版本，这可以用来跟踪它们的历史更改。

RCACopilot 的事件处理器首先手动构建，然后可以由操作专家动态更新和修改，使他们能够跟上最新的系统更改和最新发现的根本原因。例如，当系统中引入新的度量标准时，操作专家只需要构建一个新的操作来收集相关数据并将其纳入相应的事件处理器中，这可以确保及时适应。

▶处理器操作

RCACopilot 利用多源数据的协同作用。系统使用事件处理器中预定义的可重用操作来自动从各种来源收集相关的诊断信息。数据的自动集成不仅可以节省时间，还可以减少人为错误的可能性。它提供了系统状态的更全面的视图，有助于高效、准确地解决事件。这大大减轻了操作专家的工作量，降低了压力和倦怠，并提高了事件解决过程的有效性。处理器中的操作可以是以下之一：

范围切换操作：此操作通过允许根据每个事件的具体需求调整数据收集范围，从而提高根本原因分析的精确度。例如，如图 5 所示，如果警报源自“森林”级别，表示特定森林内存在问题，并且问题类型被识别为“繁忙枢纽”，则范围切换操作可以将范围调整到“机器”级别。这种修改允许更细致的调查，特别是评估单个枢纽服务器是否过度繁忙。

此操作的实现确保本文可以有效地导航信息频谱。当需要更精确的方法进行调查时，此操作可以缩小数据收集范围。相反，如果需要更全面的视图，它也可以扩大范围，例如从单个机器到整个森林。这种灵活性有助于更平衡、更有效的诊断数据收集。

查询操作：查询操作可以从不同的源查询数据，并将查询结果输出为键值对表。这类操作还可以连接到执行具有预定义参数的特定脚本的钩子。通常，脚本是为服务内部自动调查的工具，只有服务团队才能访问这些工具。

例如，在图 5 中，“已知问题？”操作节点根据其警报消息查询数据库，以查看当前事件是否为已知问题。如果是已知问题，执行流程将进入“True”分支以直接提供缓解操作。否则，将执行一个查询脚本，该脚本可以汇总具有相同堆栈跟踪的线程。它将获得目标进程中所有受管理线程的堆栈的即时列表，然后将常见的堆栈组合在一起，以识别进程中的潜在死锁/阻止代码路径。

查询操作还可以输出一个枚举值，以决定要执行的下一个操作节点，例如，在获得异常堆栈跟踪上的顶级错误消息（即“获取顶级错误消息”节点）之后，接下来要运行的 操作节点取决于异常类型。根据错误消息，将报告并通知特定的团队。

缓解操作：此操作是指为缓解事件而建议的策略步骤，例如“重启服务”或“联系其他团队”。需要注意的是，处理器并不总是为每个事件提供确切的缓解策略，因为处理器预定义的性质可能无法涵盖所有可能的情况。例如，表 1 中的事件 4，归类为代码回归，就是这样一个案例：识别和修复此类代码问题可能具有挑战性。在处理器不确定的情况下，它会向操作专家提供中间诊断信息。

▶多源诊断信息

RCACopilot 的诊断信息收集阶段通过整合众多来源的数据，为运维工程师（OCEs）提供了一个宝贵的工具。OCEs 只需在处理器中定制操作，即可从目标来源获取诊断信息。例如，如图 6 所示，RCACopilot 能够整合特定事件相关的多样化数据，如错误日志、异常堆栈跟踪和套接字指标。仅凭错误日志和异常堆栈跟踪本身并不能提供足够的洞察力来识别事件的根本原因。然而，当补充了套接字指标后，就会出现更全面的图景。在这个例子中，很明显 UDP 套接字耗尽，这是根本原因。对于新的事件，RCACopilot 可以执行一系列常见检查，如评估配置状态或分析线程栈。这有助于 OCEs 全面了解情况。请注意，在 RCACopilot 处理器的动作中预定义了收集的信息，确保只收集相关数据，从而避免收集不必要的海量信息。通过提供这种全面的诊断信息，RCACopilot 使 OCE 团队能够高效地排查问题。他们可以利用收集到的信息作为指导，更有效地处理事件。

▶llm 用于事件解释

经过彻底的调查，服务中的每一个事件都由经验丰富的 OCE 手动分配一个根本原因类别。OCE 将使用这些类别来分类历史事件，并指导新事件的 RCA（根本原因分析）。然而，对事件进行推理并推断其类别是耗时且可能让 OCE 感到不堪重负的，因为他们的时间非常紧张。因此，本文将事件根本原因的分类确定为主要下游任务。

大型语言模型（LLMs）在理解下游任务的上下文以及从演示中生成相关信息方面表现出非凡的能力，使其成为事件 RCA 的一个可能选择。但是，对事件根本原因进行推理并非易事，如果没有指导，LLMs 可能无法在长尾或特定领域的任务上取得最佳结果。Chain-of-Thoughts（CoT）提示是一种无梯度的技术，可以引导 LLMs 生成导致最终答案的中间推理步骤。在少量样本的 CoT 提示中，有一些手动演示，包括一个问题和导致答案的推理链。受到上述想法的启发，RCACopilot 处理程序提供的诊断信息可以作为事件推理过程的“原料”。

Embedding 模型：本文观察发现，事件的语义可以从描述诊断信息的上下文中揭示出来。提取这种上下文语义的常见方法涉及使用 Embedding 模型。目标是将诊断信息映射到嵌入空间（即数值向量空间），其中向量之间的距离表示事件语义的相似性。选择一个计算效率高的 Embedding 模型可以在处理大量事件时保持准确度。本文采用 FastText，它既高效，又不敏感于文本输入长度，并且能生成密集矩阵，使得计算相似向量之间的欧几里得距离变得容易。此外，由于本文的下游任务特定于事件根本原因推理，并且事件相关信息是公司内部的，因此本文选择在历史事件上训练一个 FastText 模型，而不是使用成本高昂且效率低下的预训练大型语言模型。此外，如果需要，本文还提供用户自定义 Embedding 模型的灵活性。

最近邻搜索：事件是异构的，由于提示词长度的限制，即使是经过总结后，将所有过往事件的信息结合起来进行采样也是不切实际的。为了在提示词中选择性地将过往案例作为样本，本文设计了一个新的相似度公式：

来计算两个事件之间的相似度。它首先计算每对事件向量之间的欧几里得距离。重要的是，它还考虑了事件之间的时间距离，反映了 Insight-2。这里， 代表事件 的日期。这种对时间距离的考虑至关重要，因为它影响了过往事件对当前事件的相关性。计算出相似度后，本文从不同类别中选择最相似的 个事件作为 LLM 的演示。这种方法确保了用于有效 LLM 推理的事件集合的多样性和代表性。 和 的值已通过实证评估确定为 0.3 和 5。

诊断信息摘要：LLMs 在自动总结方面显示出潜力。然而，从 RCACopilot 处理程序那里收集到的诊断信息长度通常过于庞大。如图 6 所示，一个事件的诊断信息可能有超过 2000 个标记，并且日志消息的可读性很低。事件描述中大量的标记可能会对 LLM 的有效处理提出挑战，并可能引入噪声。因此，将事件的诊断信息直接输入 LLM 以进行预测可能不是理想的选择，更不用说使用来自多个来源的信息了。在这方面，本文添加了另一层，利用 LLM 的总结能力先总结诊断信息，然后再进行诊断推理。本文按照图 7 的方式构建提示。要求 LLM 将诊断信息总结为 120-140 个词，不输出任何不相关的信息。这种总结过程使诊断信息更加简洁和有信息量，为后续的 CoT 提示奠定了基础。

图 8 展示了由 RCACopilot 生成的更加易读和简洁的文本，这是图 6 中先前诊断信息示例（113 个标记）的总结，突出了关键细节，例如使用的 UDP 端口数量以及使用最多端口的过程。具体来说，本文使用 tiktoken 计数器来统计文本标记。

预测提示构建：CoT 提示是一种无需梯度的技术，它指导大型语言模型（LLMs）生成中间推理步骤，以得出最终答案。在少样本 CoT 提示中，几个示例包括一个问题和一个推理链，该推理链指导答案。通过从自动构建提示以形成推理链中获得灵感，我们可以将总结的诊断信息和标记的根因类别视为问题和推理，因此找到最近的事件邻居是自动推理链构建，这与 CoT 提示的上下文非常契合。请注意，我们使用原始事件信息进行嵌入和最近邻搜索，并使用相应的总结信息作为提示中的示例。我们像图 9 那样构建提示，要求 LLM 选择最有可能与当前事件具有相同根本原因的事件，并明确地通过在提示中使用“给出你的解释”的指示来推动 LLM 进行推理。

▶实现

本文开发并部署了 RCACopilot，共计使用了 58,286 行代码，其中包括 56,129 行 C#代码和 2,157 行 Python 代码。

为了方便构建 RCACopilot 的事件处理器，本文将 RCACopilot 的处理器构建实现为一个网页应用程序，如图 10 所示。在 RCACopilot 中支持新的警报类型时，OCEs 只需根据其专业知识，在处理器构建界面中添加一个新的处理器即可。新处理器构建完成后，它将被存储在数据库中，OCEs 可以通过创建新的动作节点或删除旧节点来修改它。

本文旨在回答以下评估中的问题：

• RCACopilot 作为一个随叫随到的系统，在预测根因类别和协助 OCE 方面有多有效和高效？在预测云事件根因类别时，RCACopilot 的 Micro-F1 和 Macro-F1 分别达到 0.766 和 0.533，超过了所有基线，并且运行开销较低（4.205 秒）。RCACopilot 还能为未见过的突发事件生成新的根因类别标签，并附上解释。
• RCACopilot 的不同组件如何促进其诊断和预测？已经证明，RCACopilot 的诊断信息收集组件、GPT 摘要和链式思维提示都对其预测效果有所贡献。
• RCACopilot 是否适合部署在真实的生产服务中，其结果是否可靠？RCACopilot 的诊断信息收集模块已经在公司内部 30 多个团队中部署超过四年。为了评估 RCACopilot 的可靠性，每个实验进行了三轮，RCACopilot 始终能够获得超过 0.70 的 Micro-F1 和超过 0.50 的 Macro-F1。

所有实验都在配备 Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz，32.0 GB 物理内存和 Intel UHD Graphics 630 的服务器上进行。服务器的操作系统是 Windows 11 Enterprise。

▶目标系统和数据集

本文在公司的全球电子邮件服务系统 Transport 内评估 RCACopilot。该 Transport 团队负责开发和维护负责邮件流、路由和投递的组件。该系统与多种其他服务交互，以确保与众多产品和服务的无缝集成，具有复杂、真实世界系统的代表性。

每天约有 1500 亿条消息通过 Transport 投递，它在巨大规模上运行，并为全球客户提供服务，增加了多样性和复杂性。系统确保用户之间电子邮件的安全有效传输，使用 SMTP、IMAP 和 POP3 等多种协议。鉴于其在通信基础设施中的关键角色，拥有有效和高效的事件管理能力至关重要。

本文收集了公司 Transport 服务的一年数据集，包含 653 个事件，以调查 RCACopilot 在实际中的效果。每个事件都代表了大规模、全球分布式系统中的复杂问题，因此都提供了有价值的见解。数据集由经验丰富的 OCE 手动标记根因类别，作为本文的基准。

▶方法对比

本文通过预测事件根因类别来评估 RCACopilot 的效果，使用微 F1 和宏 F1 分数作为指标。这些指标计算精度和召回率的调和平均值。微 F1 分数汇总了所有类的性能，而宏 F1 分数关注每个单独类的性能。在测试数据集上，RCACopilot 达到了 0.766 的微 F1 分数和 0.533 的宏 F1 分数。

如下表所示，RCACopilot 超过了其他方法，并且倾向于带来可接受的更高运行时开销。基线方法的性能较差，因为多个根因类别表现出长尾（不平衡）分布，传统的机器学习模型需要大量训练数据才能准确预测。

本文选择了 XGBoost、FastText 和微调后的 LLMs 作为基线，与 RCACopilot 进行比较。在用训练数据集训练或微调后，我们直接将这些方法应用于测试集进行分类任务。我们还制作了另外两个变体，即 GPT-4 Prompt 和 Embed.，以评估 RCACopilot 的设计。

• XGBoost 提供了一种并行树增强技术，通常用于网络系统诊断。
• FastText 是一种流行的轻量级文本嵌入方法，已在测试床研究中采用，通过故障注入进行根本原因诊断任务。我们直接将 FastText 应用于我们的数据集进行分类。
• 微调 GPT 是为了用我们的数据集微调预训练的 GPT-3.5 模型，并在测试数据集上评估其性能，温度参数设置为 0。它不使用像 RCACopilot 那样的提示设计（即 CoT 提示），而是直接用原始诊断信息预测类别。请注意，GPT-4 目前不可用进行微调。GPT-4 Prompt 是 RCACopilot 的一个变体，直接用 RCACopilot 的诊断信息摘要预测类别。它的提示只包含正在预测的事件，因此没有历史事件信息作为示例。
• GPT-4 Embed.是 RCACopilot 的一个变体，它将嵌入模型从 FastText 更改为 GPT 嵌入。

▶有效性和效率

本文通过使用 micro F1 和 macro F1 得分指标，基于总结的诊断信息来预测事件的根本原因类别，来评估 RCACopilot 的有效性。这些指标计算了精确度和召回率的调和平均值。micro F1 得分汇总了所有类别的性能，考虑了每个样本的贡献，而 macro F1 得分则侧重于每个单独类别的性能。在我们的测试数据集上，RCACopilot 实现了 0.766 的 micro F1 得分和 0.533 的 macro F1 得分。

如表 2 所示，RCACopilot 的表现优于其他方法，并且它倾向于产生可接受的更高运行时间开销。基线方法的性能较差，因为多个根本原因类别呈现出长尾（不平衡）分布，传统的机器学习模型（FastText 和 XGBoost）和微调后的 GPT 模型需要大量的训练数据才能产生准确的预测。没有我们的设计直接使用 GPT-4 提示或 GPT-4 嵌入方法缺乏 GPT-4 做出决策所需的特定领域知识。相反，RCACopilot 利用强大的 LLM 从最少的案例中学习特定领域的知识，因此它能够实现最佳性能。结果表明，RCACopilot 不仅提供了更高的准确性，而且还保持了合理的效率水平，使其成为事件根本原因分析的合适选择。面对 RCACopilot 从未见过的事件时，RCACopilot 能够生成一个新的类别关键词来描述新的事件案例。例如，表 1 中的事件 8 是 RCACopilot 从未遇到过的新事件案例。RCACopilot 的预测组件能够预测其为新类别“I/O 瓶颈”。尽管运维工程师在后续调查中将其归类为“磁盘已满”，但 RCACopilot 识别出的问题的基本方面与人工派生的标签非常接近。相应的 RCACopilot 的解释，说明了它是如何得出“I/O 瓶颈”分类的，如图 11 所示。

▶对比分析

为了理解 RCACopilot 的不同组件如何促进根本原因分析，本文对 RCACopilot 的不同组件进行了消融研究。

对诊断信息的评估。 首先，我们评估诊断信息对有效性的影响。具体来说，我们将收集阶段收集的诊断信息与其他不同的与事件相关的信息进行比较，即事件警报信息和 RCACopilot 处理器动作输出。AlertInfo 包括警报类型和警报范围。警报类型是监控器预先定义的异常描述，它只反映了事件的症状而不是根本原因，例如来自外部监控的异常类型。警报范围是事件的范围，例如单一机器。ActionOutput 是一系列执行的 RCACopilot 动作的输出，这些动作被哈希为键值对。如表 3 所示，仅使用诊断信息就可以在 micro F1（0.689）和 macro F1 得分（0.510）上胜过其他方法。这里有趣的观察是，将诊断信息与其他信息混合并不会增强 RCACopilot 的预测能力。这表明信息过剩可能对 LLM 的预测性能产生负面影响。

对 GPT 摘要的评估。 我们评估 GPT 摘要在提高 RCACopilot 有效性方面的作用。如图 3 所示，使用摘要的诊断信息能够带来最高的 micro F1 和 macro F1 得分，分别比非摘要的诊断信息提高了 0.077 和 0.023。结果表明，摘要步骤有效地浓缩了信息，允许更高效和准确地处理事件数据。

对少样本 CoT 推理的评估。 我们评估少样本 CoT 推理如何有助于提高有效性。表 2 中的 GPT-4 提示方法，直接预测类别而不使用任何样本，仅在 micro F1 和 macro F1 上分别达到了 0.026 和 0.004。如图 12a 和图 12b 所示，我们比较了 RCACopilot 在不同数量样本的思考链推理中的性能。我们的分析揭示了样本数量和 alpha 值的最佳组合是 5 和 0.3，这达到了最高的 F1 得分。注意，在 CoT 推理中更多的样本并不总是导致 RCACopilot 性能的提高，alpha 的值在决定有效性方面起着重要作用。当 alpha 值适当时，它允许 RCACopilot 更好地捕捉不同事件之间的时间关系，从而进行更准确的预测。

▶部署与可靠性

RCACopilot 的诊断信息收集模块已成功部署在公司内超过 30 个团队中，使用时间超过四年。系统根据每个团队的具体需求进行定制，为每个独特环境构建了自定义处理程序。

为了确保 RCACopilot 中 GPT 预测能力的可靠性和稳定性，每个实验进行了三轮。在每一轮中，RCACopilot 都能够保持高水平的性能，Micro-F1 始终高于 0.70，Macro-F1 始终高于 0.50。

RCACopilot 的有效性取决于 LLM（大规模语言模型）的能力。目前，RCACopilot 仅与 OpenAI 的 GPT 模型集成，本文尚未探索其他可用 LLM 的潜在有效性。因此，模型的性能可能会因所采用的特定 LLM 的优势和劣势而有所不同。

本文对 RCACopilot 的预测模块进行了评估。需要注意的是，RCACopilot 的有效性也受到人类编写的根本原因类别标签质量的影响。目前，所有根本原因类别都是本文经验丰富的 OCE 手动标注的。RCACopilot 的诊断信息收集已经在超过 30 个团队中部署。因此，未来有价值的工作是对不同服务中的 RCACopilot 进行评估，以更全面地了解其普遍性和适应性。

RCACopilot 中的处理程序旨在根据监视器/看门狗的警报启动响应。这确保了当有特定警报类型的指定事故处理程序时，它能够以 100%的准确率被激活。然而，重要的是要强调，在监视器未能检测到事故或特定事故缺乏相应处理程序的情况下，RCACopilot 的能力受到限制，这反过来限制了 RCACopilot 的适用性。

本文进行了三轮实验来评估 RCACopilot 的有效性。然而，LLM 偶尔的不稳定性可能会影响其有效性，导致不同轮次之间的变化。另一个潜在的内部有效性威胁在于本文方法的实施以及与我们进行比较的方法。为了减轻这一风险，两位作者已经仔细检查了代码。特别是，本文的实现基于成熟的框架。

根本原因分析：在大规模云服务中，根本原因分析已成为系统和软件工程社区研究的热门话题。该方法旨在基于各种数据源，如指标、日志和追踪，识别故障和性能问题的根本原因。先前的研究已经提出了使用这些数据源之一进行根本原因分析的不同方法。例如，一些方法依赖指标来提取故障模式，或者构建服务依赖图。其他方法使用日志来分析日志消息的子集或检查每个日志消息的细节。此外，一些技术利用追踪来定位故障服务。与之前的工作不同，本文构建了一个系统，可以自动整合指标、日志和追踪，用于根本原因分析，并使用最先进的大型语言模型。

大型语言模型：近年来，大型语言模型（LLM）的兴起为软件系统领域带来了新的机遇，使诸如代码生成、摘要、修复、测试和根本原因分析等各种任务成为可能。例如，一些研究已经使用 LLM用于以下任务：自动修复错误、生成断言语句、代码摘要和注入代码变种。而本文采用的是先进的大型语言模型来总结诊断数据，并利用思维链能力来预测和解释根本原因。

RCACopilot 是云事件管理领域的一个开创性工具，它能够帮助 OCEs 高效地进行根本原因分析。本文引入了一种独特的方法，在诊断信息收集阶段通过预定义的事件处理程序进行多源数据收集。这些由 OCEs 构建的处理程序会系统地收集多源诊断信息，为后续的分析奠定了基础。

此外，RCACopilot 在其根本原因预测阶段集成了一个大型语言模型。这个模型可以自主处理收集到的诊断数据，预测并解释根本原因的类别。将 AI 技术整合到云事件管理中，展示了 RCACopilot 在提高根本原因分析的效率和准确性方面的潜力。