Page 163 - 《软件学报》2026年第2期

642 软件学报 2026 年第 37 卷第 2 期

from this analysis. Based on these empirical findings and conclusions, this study proposes a lightweight root cause change identification
method. This method aims to automatically identify the root cause changes that lead to failure, assisting operations and maintenance
engineers in root cause localization and trouble shooting efforts. To validate the effectiveness of the proposed method, a real dataset
containing various types of defective changes from WeChat’s production environment is collected, along with a simulated change dataset
based on a microservice benchmark system. A systematic evaluation of the proposed method is then conducted. The experimental results
show that the proposed method achieves Top-3 root cause change hit rates of 80% and 84% for the WeChat production environment
dataset and simulated change data, respectively, significantly outperforming the state-of-the-art defective change detection methods.
Moreover, from an engineering practice perspective, the system uses only 2.3 GB of memory and has an average analysis latency of 28.6 s
when processing typical-scale failures, thus meeting the requirements of actual production environments.
Key words: software change; root cause location; failure; online system

1 引 言

在线系统是通过网络连接用户并与用户实时交互的软件系统, 广泛应用于电子商务、社交媒体、金融服务、
在线教育等领域, 其普遍性可归因于以下几个方面的优势. 首先, 全球性连接使得在线系统能够跨越空间和时间限
制, 实现全球范围内的连接和交互. 其次, 实时性是在线系统的重要特征, 用户能够即时发送请求并获得实时反馈
和结果. 第三, 可扩展性使得在线系统能够根据需求动态调整资源和容量, 以适应用户量和数据量的快速增长. 随
着微服务、云原生和 Serverless 等技术的不断成熟和应用, 在线系统将继续发展和演进, 为用户带来更多的便利和
机遇. 为了适应用户需求和新型信息技术的快速变化, 在线系统开发工程师需要频繁地进行软件变更, 从而引入新
功能、改进现有功能或实现创新, 以提供更好的用户体验和满足不断变化的需求. 此外, 进行软件变更还可以有针
对性地对系统的性能瓶颈或漏洞进行优化, 提高系统的响应速度、并发处理能力和系统可靠性.
为了提升软件变更的效率, 持续集成和持续交付 (continuous integration and continuous delivery, CI/CD) 作为
一种新型的软件开发实践和方法论被提出来. CI/CD 的核心思想是自动化和连续地进行软件构建、测试和发布.
通过使用各种工具和技术, 如版本控制系统、测试自动化框架和部署自动化工具, 开发团队可以实现持续集成和
持续交付的目标. 这种方法可以大大减少手动操作和人为错误, 提高软件变更的效率和质量, 同时减少软件变更过
程中的失效风险. 得益于 CI/CD 技术的高效, 据 Meta 公司的研究报告, 当前 Meta 在线系统中软件变更的频率可
以达到每天上千次 [1] .
尽管在软件变更上线之前开发工程师会对变更的服务进行严格和周密的测试, 但由于生产环境和测试环境存
在多种差异以及更加复杂的组件交互关系, 依然会有部分缺陷变更能通过测试, 并且被部署到生产系统中, 然后导
致系统出现故障, 对这些缺陷变更的不当管理可能对用户体验和商业收入产生不利影响. 例如, 在 2021 年, 著名社
交软件 Meta 因为错误的软件配置变更, 导致 Meta 及其旗下 Instagram 和 WhatsApp 等应用全网宕机, 停机时间近
7 h. 这 7 h 的应用宕机直接造成超过 9.68 亿美元的损失, 并使 Meta 的市值损失达 643 亿美元 [2] .
本文将由存在缺陷的软件变更引发的故障称为变更故障. 为了深入了解缺陷变更的影响和行为, 本文基于大
规模即时通信系统微信的真实变更故障进行了实证研究, 得出 5 个关键发现 (见第 3 节). 其中在发现 1 中, 本文发
现约 66% 的生产环境故障可以归因于缺陷变更, 这进一步证实了软件变更容易导致故障的观点. 在发现 2 中, 本
文揭示了与其他故障相比, 在变更引发的故障中具有更严重影响的故障比例更高. 在发现 3 中, 本文统计了不同类
型故障根因定位所需时间, 发现确定变更引发的故障的根因比其他故障需要更多时间, 强调了及时发现缺陷变更
从而启动变更回滚的迫切性, 缩短故障恢复时间, 提升系统可用性.
考虑到 Google SRE 的“先恢复后根治”原则和 DevOps 责任分离原则 [3] , 本文聚焦于运维阶段的快速定位导致
此次故障的缺陷变更 (即根因变更) 并执行变更回滚来恢复系统 (分钟级), 这与后续开发过程中定位具体的代码或
配置缺陷并修复 (小时级) 形成互补. 为了在变更故障发生后快速定位到根因, 当前国内外学者和工业界已经有一
些研究工作. 这些研究工作主要集中在服务级别根因分析 (root cause analysis, RCA) [4–7] 和缺陷变更检测 (defective
change detection, DCD) [8–12] 两个方面. 然而, 本文发现现有方法存在两个主要局限性.