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

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

经常出现 [4] , 因此忽视缺陷变更的传播会影响缺陷变更检测算法的诊断, 容易导致出现误报, 进而影响方法的效果.
同时, 缺陷程序在变更完成后才表现出异常, 或者其指标在变更服务中没有表现异常, 现有的缺陷变更检测方法就
无法成功识别出缺陷变更. 因此, 仍然需要进一步改进和发展更加全面的方法来解决这些问题.
2.5 服务级别根因定位与根因变更识别差异
在第 2.3、2.4 节中, 我们主要介绍了针对单个变更进行诊断的缺陷变更检测的内容, 在本节中, 本文综述现有
的服务级别根因定位方法的研究进展, 并分析其与根因变更识别工作的核心差异. 如图 1(a) 所示, 现有的服务级别
根因定位方法通常利用系统的运行时信息 (例如指标和调用链) 作为输入, 但未充分利用系统中存在的变更数
据 (如灰度变更的流程和变更时间). 典型的服务级别根因定位方法包括几类: (1) 基于因果推断的根因定位方法 [24–27]
通过构建指标间的依赖关系来形成因果关系图, 然后计算异常指标间的相关性或采用随机游走算法在图上推断根
因服务或服务实例. (2) 基于多维下钻的根因定位方法 [28–31] 将多维根因分析问题分解为多个单维问题, 通过计算不
同指标和属性的预测值与实际值的差异, 以识别最可能导致故障的属性组合进行服务实例级别的根因诊断. (3) 在
工业实践中, GMTA [32] 和 Canopy [33] 是两个基于云原生应用的调用链建立的, 支持工业级云原生应用的流式数据处
理、灵活数据访问和高效数据存储的平台. GMTA 将调用链抽象为不同的 Path, 并进一步将其归类为业务流, 可
以帮助运维工程师理解系统架构、缩小性能问题的根因范围、检索并可视化故障传播链. 但这项研究的重点是服
务级别的根因定位, 并且只使用了异常链路提供的上下文线索. (4) 文献 [4,6,7] 则是通过比较同一种请求的正常和
故障调用链的差异来定位服务级别根因.
现有服务级别根因定位方法的局限性在于诊断粒度不足: 其输出多为服务或实例级根因. 在遇到变更故障时,
运维人员需手动关联故障服务与变更之间的因果关系, 导致回滚操作延迟. 本文提出的方法突破该限制, 直接实现
变更级诊断, 通过推荐可疑根因变更, 使工程师可快速精准回滚, 避免缺陷版本对系统可用性的持续影响.

3 实证研究
为了深入了解缺陷变更的影响和行为, 本节基于大规模即时通信系统微信的真实变更故障进行实证研究, 得
出 5 个关键发现.
3.1 研究问题

本文通过对微信系统内的真实变更故障进行多角度的分析, 旨在回答以下 5 个研究问题.
● 问题 1: 变更故障占总故障数的比重是多少?
● 问题 2: 变更故障是否比其他类型故障更加严重?
● 问题 3: 变更故障是否需要更长的时间来确定其根因?
● 问题 4: 典型的变更故障及其异常表现有哪些?
● 问题 5: 当前的告警系统能否有效定位变更故障?
3.2 数据采集
本文从微信系统内部收集了 2022 年 10 月 1 日–2023 年 3 月 30 日半年期间所有的已经被修复的变更故障.
由于企业数据隐私要求, 本文不披露故障的绝对数量, 而采用相对比例进行量化分析, 以确保数据安全性的同时保
持研究的可解释性. 微信是一个为全球数十亿用户提供服务的在线系统, 它包括即时通信、在线支付、短视频、
社交圈等多种用户场景. 微信的后端采用微服务架构, 包含了超过 20 000 个微服务. 由于企业隐私政策的限制, 本
文隐藏了所收集的故障和变更的具体数量等细节.
微信系统为了便于故障分析并防止其再次发生, 当故障发生后, 负责该故障的工程师被要求将故障处理的整
个过程以事后总结的形式形成文本记录. 这些事后总结包含故障发生时的关键信息, 例如故障表现、告警时间、
告警服务、由负责该故障的工程师确认的最终根因结果、故障严重等级以及其他相关数据. 关于故障分析和变更
类型标记, 3 位工程师通过分析事后总结中记录的故障处理步骤和故障原因描述, 在“Cohen’s Kappa 系数” [34] 的监