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

余广坝 等: 面向大规模在线系统的故障根因变更识别 643

● 忽视变更数据. 大多数现有的服务级别根因定位方法 [4–7] (如图 1(a)) 通常利用系统的运行时信息 (例如指标
和调用链) 作为输入, 但忽略了系统相应的变更数据 (例如灰度变更的流程和变更时间). 因此, 它们往往在服务级
别定位根因而无法识别缺陷变更. 在获得服务级别根因定位结果后, 运维工程师需要手动关联相关变更和识别缺
陷变更, 导致根因识别时间较长. 因此应该实现自动化的变更级别的根因分析, 以将缺陷变更与变更故障关联
起来.

未变更正常实例 已变更正常实例 已变更异常实例

变更信息 服务依赖图 服务依赖图

变更信息
DCD
C 1
C 1
DCD
C 2 RCCI
C 2 S 2 , C 2
RCA S 2 C 3 DCD C 3
(a) 服务级根因定位过程 (b) 缺陷变更检测过程 (c) 根因变更识别过程
不考虑变更信息 不考虑服务依赖 考虑服务依赖与变更信息
图 1 服务级别根因定位、缺陷变更检测和根因变更识别过程对比

● 忽视异常传播. 缺陷变更检测方法 [8–12] (如图 1(b)) 则是以变更数据和运行时信息作为输入, 以诊断单次变
更是否是缺陷变更. 但这些缺陷变更检测方法通常不考虑系统中其他服务的变更传播的影响, 只考虑单个服务的
单个变更是否异常. 而故障传播在相互依赖的在线服务中经常出现 [4] , 因此忽视缺陷变更的传播会影响缺陷变更
检测算法的诊断, 容易导致出现误报, 进而影响方法的效果. 图 1(b) 的变更 C 1 的异常是由于 C 2 的缺陷变更故障
传播导致的, 但缺陷变更检测方法会将 C 1 的变更也判定为缺陷变更.
为了突破现有方法的局限性, 受到实证研究结论的启发, 本文同时考虑服务依赖图信息和变更信息, 提出了变
更级根因定位的概念 (如图 1(c) 所示), 本文也称之为根因变更识别 (root cause change identification, RCCI). 需要明
确的是, 本文所讨论的“缺陷变更 (defective change)”是指任何引入错误或漏洞的软件修改, 而“根因变更 (root
cause change)”则是指导致特定系统故障发生的、经追溯分析确定的根本性缺陷变更. 根因变更识别旨在从诸多变
更中精准识别出导致当前故障的根因变更.
为了将根因变更识别的概念应用到真实场景, 本文设计了一种自动化根因变更识别方法, 该方法由既有的告
警系统触发, 并包含以下几个步骤: (1) 服务依赖图构建模块构建以告警服务为中心的服务依赖图; (2) 针对服务依
赖图上的所有服务, 如果服务在 H h (本文默认为 48 h) 内有变更, 变更依赖构建模块会构建服务内变更之间的依
赖关系; (3) 根因变更推断模块则会对每个服务的 H h 内的所有变更计算 KPI 差异得分, 时间衰减得分和空间依赖
得分. 然后将这 3 个得分输入根因变更推断模块, 输出一个根因变更得分列表供运维工程师检查. 在理想情况下,
根因变更得分排名第 1 的变更就是导致这次故障的根因变更. 运维工程师可通过回滚或快速修复根因变更使系统
恢复正常, 避免对用户的持续影响, 提升系统的可用性.
为了验证提出方法的有效性, 本文基于 Python 实现了根因变更识别方法的原型系统, 并在从微信系统采集的
真实变更故障数据集和一个微服务基准测试系统的模拟变更数据集上进行了测试. 实验结果表明, 所提方法在微
信生产环境数据集和模拟变更数据集上的 Top-3 命中率 (即根因变更位于推荐列表前 3 位的概率) 分别达到 80%
和 84%, 其识别效果显著优于当前最先进的缺陷变更检测方法. 此外, 从工程实践角度, 系统在处理典型规模故障
时内存占用仅为 2.3 GB, 平均分析时延 28.6 s, 满足实际生产环境需求.
综上所述, 本研究的主要贡献如下.
● 基于微信系统生产环境的真实故障数据进行了实证研究, 揭示了缺陷变更对生产环境的影响和相关的行为
特征, 并得出 5 个重要发现. 这些发现不仅驱动了本文的研究, 还能够给未来的研究带来启发 (第 3 节).
● 提出了一种根因变更识别方法. 在变更故障发生时, 它能够更准确、更快速地从大量软件变更中识别出导