本文介绍了一项名为CoCa的研究工作，题为“CoCa: Generative Root Cause Analysis for Distributed Systems with Code Knowledge”。该研究由香港中文大学的Yichen Li、Yulun Wu、Jinyang Liu、Zhihan Jiang、Guangba Yu（通讯作者）、Michael R. Lyu，以及中山大学的Zhuangbin Chen共同完成。这项研究工作于2025年9月10日发表于IEEE/ACM第47届国际软件工程会议（ICSE ‘25: Proceedings of the IEEE/ACM 47th International Conference on Software Engineering, April 2025）的会议论文集上，并获得了香港中文大学和中山大学的开放获取支持。

这项研究的学术背景立足于软件工程领域，具体关注分布式系统的可靠性与运维（DevOps/SRE）。在复杂的分布式系统中，运行时故障屡见不鲜。用户通常通过GitHub、Jira等平台提交包含问题描述、日志和堆栈跟踪的故障报告。对于维护者而言，手动诊断这些报告以定位根本原因（Root Cause Analysis, RCA）是一项耗时且需要深厚领域知识的挑战。现有的自动RCA方法主要分为两类：一类严重依赖对正常与故障状态下系统运行时监控数据（如日志、指标、追踪）的全面对比分析，这类方法在实践中常因缺乏完备的监控基础设施而受限；另一类则利用大型语言模型（Large Language Models, LLMs）分析故障报告文本，但其效果受限于用户提供的信息往往不完整或含糊不清。用户通常只能描述故障症状，而难以提供导致故障的底层执行逻辑细节。因此，研究的核心目标是：在仅有有限故障报告数据的情况下，如何从分布式系统的源代码中提取额外的诊断线索，以增强LLMs进行根因分析的准确性和全面性。换言之，CoCa旨在弥合故障报告中的信息鸿沟，通过整合代码知识，为LLMs提供更丰富的执行上下文，从而提升自动RCA的效果。

CoCa的研究工作流程被精心设计为一个包含四个阶段的自动化框架，其输入是故障报告和对应版本的项目源代码，输出是详细的根本原因总结和故障责任组件定位。下面对每个阶段进行详细阐述：

第一阶段：日志源检索（Logging Source Retrieval）。此阶段旨在解决第一个挑战：如何将故障报告中的日志消息精准映射到源代码中对应的日志语句位置。由于日志消息在运行时往往与源代码中的原始日志语句（包含变量、条件分支）存在差异，且缺乏行号等元数据，直接匹配非常困难。CoCa采用了两步法：首先，恢复日志语句。通过对项目日志库进行静态分析，提取所有日志语句及其代码位置。然后，采用基于静态分析的回溯方法，分析数据依赖和控制流，将日志语句中经过拼接构造的复杂变量（如图4中的msg）还原为原始的、包含常量字符串和基本变量的“原始模板”集合。例如，一条日志语句可能根据不同的条件分支被还原为多个可能的原始字符串模板。其次，日志模板匹配。在获得所有原始模板后，CoCa设计了一种非剪枝的递归匹配算法（算法1），将故障报告中的每条日志消息与模板前缀树进行匹配。当一条日志消息能匹配多个模板时，CoCa优先选择静态部分（非变量部分）最多的模板，以实现更精确的定位。这一阶段的输出是一系列与日志消息对应的代码点（即精确的类、方法、行号）。

第二阶段：执行路径重建（Execution Path Reconstruction）。此阶段旨在解决第二个挑战：如何基于上阶段获得的代码点，重建故障发生前的系统执行路径。在分布式系统中，日志通常不密集，仅提取日志周围的几行代码会遗漏大量关键的系统运行时信息。CoCa通过构建并分析过程间控制流图（Inter-procedure Control Flow Graph, ICFG）来连接这些代码点。这包括分析方法的调用图（Call Graph）以识别方法间的直接和间接调用关系，以及分析方法内部的控制流。然而，分布式系统中广泛使用的远程过程调用（Remote Procedure Call, RPC）机制（如gRPC）会打破静态调用栈，因为客户端调用是通过网络工具动态绑定到服务器实现的。为此，CoCa提出了一个创新的 RPC桥接（RPC Bridge）方法。该方法通过解析接口描述语言（IDL）文件（如gRPC的.proto文件）来识别RPC函数名和接口名，然后在调用图中查找匹配的调用点，确认为客户端到服务器的RPC调用。接着，通过模糊匹配（如子串匹配）和接口实现验证，找到服务器端的实现类和方法。最后，在调用图中用服务器端实现方法替换原始的客户端RPC调用点，从而“桥接”起跨越网络边界的调用栈（如图5所示）。经过RPC桥接增强的调用图和分析，CoCa能够基于指定的代码点，识别出故障前可能的多条执行路径，为下一步分析提供更全面的执行上下文。实验表明，在重建的执行路径中，约有15.7%的调用是RPC调用，凸显了该步骤的必要性。

第三阶段：故障相关代码画像（Failure-related Code Profiling）。此阶段旨在解决第三个挑战：如何处理重建执行路径所涉及的大量代码，避免超出LLMs的上下文窗口限制并减少无关代码干扰。CoCa采用了一种两阶段的代码索引与检索方法。首先，代码片段索引。为执行路径中的每个方法创建索引条目。索引内容包含方法的签名（由Soot工具生成）和标准化的方法文档。如果文档缺失，可以使用基于LLM的方法自动生成。这些索引为LLM提供了足够的关键信息，使其无需处理完整代码即可做出初步判断。其次，代码片段检索。CoCa将故障报告、分析出的执行路径以及所有方法的索引信息组合成一个提示（Prompt），输入给骨干LLM（例如GPT-4o）。该提示要求LLM基于对问题的初步理解，从索引中识别出那些对理解故障有贡献或容易引发故障的方法签名（如图6上半部分所示）。然后，根据LLM返回的方法签名列表，从代码库中提取对应的完整方法代码。这一步骤有效地从海量执行路径代码中筛选出最相关、最精简的代码子集，显著降低了输入LLM的上下文长度。

第四阶段：根因分析（Root Cause Analysis）。这是最终推理阶段。CoCa结合了情境学习（In-context Learning, ICL）策略来利用历史经验。它使用BM25相似性算法（一种基于关键词加权的检索方法）从已标注的数据集中检索出与当前故障报告最相似的5个历史故障报告及其诊断结果，作为上下文示例。接着，CoCa构建最终的诊断提示，该提示按顺序包含：当前故障报告、重建的执行路径信息、上阶段检索到的相关代码片段、以及精选的历史案例。该提示明确要求LLM完成两项任务：根因总结（提供清晰、简洁的根本原因描述，指导后续修复）和根因定位（列举并排序最有可能导致故障的组件，包括代码类和非代码因素，如网络、竞争条件等）。LLM根据所有输入信息进行推理，生成最终的诊断结果。

研究的主要结果基于从五个真实世界分布式系统（MapReduce, HDFS, HBase, Cassandra, ZooKeeper）收集的106个已标注故障报告数据集进行评估。评估围绕三个研究问题展开：

RQ1：CoCa的有效性。实验结果表明，在以GPT-4o为骨干模型的统一设置下，CoCa在根因总结和定位两方面均显著优于现有最佳基线方法（如RcaCopilot和React）。在根因总结方面，CoCa在BLEU-4、ROUGE-1、METEOR等文本相似性指标上平均分别提升了22.0%、6.8%和10.6%。更重要的是，在由领域专家评定的“实用性”人工评估指标上，CoCA也取得了显著提升（例如，在MapReduce系统上从基准的0.645提升到0.795），证明其总结对维护者更具实际帮助。在根因定位方面，CoCA在“精确匹配”（Exact Match）这一最严格的指标上，相比最佳基线平均提升了28.3%，相比仅使用原始LLM（Base Model）更是提升了56.3%。在Top-3和Top-5命中率指标上也有明显优势。这些结果强有力地证明了将代码知识整合到RCA流程中的有效性，其价值超过了仅依赖历史故障报告数据的方法。

RQ2：CoCa各阶段的影响。通过消融研究，作者验证了框架中每个核心组件的重要性。实验创建了三个变体：移除日志源检索阶段（改为基于嵌入相似性搜索代码）、移除执行路径重建阶段（仅使用日志周围的代码）、移除故障相关代码画像阶段（将完整执行路径代码全部输入LLM）。结果表明，移除任何一阶段都会导致性能显著下降。例如，没有日志源检索，Exact Match下降18%，METEOR下降22.9%；没有执行路径重建，BLEU-4下降16.6%，实用性得分下降11.7%。特别地，当仅通过相似性搜索代码而不经过CoCa框架的系统性分析时，性能甚至不如原始LLM，这表明引入不相关的代码片段反而会误导模型。此外，实验还探讨了执行路径分析深度（1度、2度、3度）的影响，发现2度路径（默认设置）能在引入足够上下文和避免过多噪声之间取得最佳平衡。这些结果共同证实了CoCa设计的每个阶段都是不可或缺的，协同工作才达成了最佳性能。

RQ3：CoCa的通用性。研究测试了CoCa框架与不同骨干LLM（GPT-4o, GPT-3.5, LLaMA-3.1-405B, Claude-3.5-Sonnet, Gemini-1.5-Pro）的适配效果。结果显示，无论使用哪种LLM，CoCa框架都能一致地、大幅度地提升其RCA性能。平均而言，在Exact Match指标上，所有模型提升了43.3%；在BLEU-4指标上，提升了33.2%。值得注意的是，即使某些原始模型（如Claude-3.5）在某些指标上表现优异，CoCa仍然能带来显著的额外增益。这证明了CoCa框架的通用性和鲁棒性，其性能提升并非依赖于特定LLM的“记忆”能力（实验通过对比输入完整Jira讨论后的性能跃升，以及多个模型在原始故障报告上表现平平的现象，排除了数据泄露导致模型“背诵”答案的主要威胁），而是源于其提供的结构化代码知识与分析流程。

研究的结论是，CoCa是首个将代码知识整合到分布式系统故障报告自动根因分析框架中的工作。它通过创新的四阶段流程（日志源检索、执行路径重建、故障相关代码画像、根因分析），特别是其中解决RPC调用跟踪的RPC桥接方法，有效克服了在仅有有限报告数据下进行准确诊断的三大挑战。全面的实验评估证明，CoCa在多个真实系统数据集上显著超越了现有方法，并且在不同的骨干LLM上表现出强大的通用性。这项研究不仅为软件工程领域的自动运维（AIOps）和故障诊断提供了新的有效工具，也展示了结合静态代码分析与大语言模型推理在解决复杂系统问题上的巨大潜力。

本研究的亮点在于：第一，研究视角新颖：首次系统性地将源代码静态分析作为补充知识，用于增强基于LLM的故障报告根因分析，填补了监控数据驱动方法和纯文本分析方法之间的空白。第二，技术创新性强：针对分布式系统的特殊性，提出了包括日志语句恢复与匹配、RPC桥接在内的多项创新性技术，有效解决了代码知识与运行时日志、跨节点调用的关联难题。第三，实验设计严谨：基于大规模、真实世界的、已标注的分布式系统故障数据集进行系统评估，并进行了充分的消融实验和通用性测试，结论可信度高。第四，实用价值显著：CoCa能够在不复现故障、不依赖完备监控数据的情况下，在数十秒内为维护者提供高质量的诊断线索，有望大幅提升分布式系统运维的效率。案例研究（如对HBase-9821问题的分析）生动展示了CoCa如何将需要数小时人工分析的执行逻辑自动提炼出来，生成深入、准确的根因分析，验证了其在实际运维场景中的巨大应用前景。