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

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

在微信告警系统中, 绝大多数根因变更服务与告警服务之间存在着较近的调用关系. 然而, 需要进一步的分析来确
定这些服务之间的因果关系. 这对于改进告警系统的根因定位能力具有重要的指导意义.
发现 5. 绝大多数根因变更对应的服务与告警服务之间存在较近的调用关系.

4 根因变更识别方法
受第 3 节实证研究中 5 个发现的启发, 当前工业界迫切需要一种专门针对变更故障的根因变更识别方法, 以
便快速定位导致变更故障的根因. 本节以服务依赖图和服务变更信息为输入, 提出了一种智能的根因变更识别算
法, 旨在帮助运维工程师快速和准确地定位导致变更故障的根因变更.
4.1 问题定义
在介绍根因变更识别框架前, 本文首先对两个关键术语进行区分: 缺陷变更是指任何在功能或行为上引入错
误的软件修改. 根因变更则特指在系统发生故障后, 通过综合分析系统运行时信息和变更上下文, 最终被确定为引
M 个服务
起该特定故障的根本原因的缺陷变更. 接着, 本文对根因变更识别问题进行定义, 对一个在线系统包含
C
的集合 S , 给定包含 N 个变更的集合 , 以及该系统的服务依赖图 G 和 KPI (key performance indicator) 数据 K, 那
么关于一个变更故障的根因变更识别问题可以定义为:

F : (C,S,G,K) → Score (1)
其中, Score = {(Service,Change i ,Score i )} N 是一个根因变更的得分列表. 列表中的实例不仅包含了根因服务, 还明
i=1
i
确了服务对应的可疑变更, Change i 分别表示第 个变更, Service 表示 Change i 关联的服务, Score i 表示 Change i 变
更的可疑得分, 得分越高意味着这个变更越有可能是根因变更. 这个得分列表能够为运维工程师提供故障诊断参
考, 优先检查可疑得分较高的变更, 这能够加快根因变更的回滚, 加快故障修复速度, 缩短用户受故障影响的
时长.
4.2 研究挑战
在第 4.1 节中, 本文对根因变更识别的问题进行了定义. 但是想要在大规模在线系统中解决这个问题主要还
存在以下几个挑战.
● 挑战 1: 系统规模大、服务间依赖复杂、系统中同时存在多个变更. 在大规模在线系统中, 通常涉及大量的
服务和组件, 这些组件之间存在复杂的依赖关系, 这增加了根因变更识别的挑战, 因为一个变更可能会对多个服务
产生影响, 并且可能会引发级联故障. 除此之外, 在大规模系统中通常在一段时间内同时存在多个变更, 在这种情
况下, 确定哪个变更是导致问题的根因变得复杂.
● 挑战 2: 根因变更不表现出 KPI 异常. 在问题 3 中, 本文发现部分存在根因变更的服务并不表现出 KPI 异常,
而是其上游或下游服务表现异常. 这意味着仅考虑 KPI 将无法发现这种类型的根因, 需要挖掘其他数据源提供的
线索来定位这种类型的根因.
● 挑战 3: 表现出 KPI 异常的变更并非是根因变更. 在一个复杂的系统中, 一个服务在变更后该服务 KPI 出现
异常除了由缺陷变更导致之外, 还有其他外部因素 (例如故障传播或资源竞争) 也会导致 KPI 异常. 因此无法通过
简单判断 KPI 是否异常来判定当前的变更就是根因变更.
当前故障根因分析方法 [4–7] 虽然能够有效地解决挑战 1 中复杂依赖关系带来的挑战, 但是由于没有考虑变更
数据, 直接将故障关联到根因变更. 而缺陷变更检测方法 [8–10,12] 虽然能够在一定程度上解决挑战 3, 但是由于其没
有考虑到服务间的依赖关系, 对挑战 2 束手无策. 因此, 需要更先进的变更故障诊断框架来解决以上的挑战, 帮助
运维工程师快速回滚根因变更, 提升系统的可用性.
4.3 方法概述
为了解决已有方法的不足和上述的挑战, 本文同时考虑服务依赖图信息和变更信息, 提出了一种自动化根因
变更识别方法. 图 5 展示了本文提出的根因变更识别方法的总体框架. 这个根因变更识别方法由当前成熟的告警