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

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

根因变更后, 运维工程师还需要考虑第 4.5 节中变更之间的依赖性决定回滚的版本. 如图 5 所示服务 S a 在故障发
生前 48 h 内存在 3 次变更, 根因变更得分列表 Score 中可疑得分排名前二的是变更 S a_ 和 8 S a_7 , 运维工程师检查
变更后判定 S a_ 是根因变更, 需要回滚 S a_ 到 7 S a_6 . 同时考虑到变更之间的依赖性, 即变更 S a_ 依赖于 S a_7 , 也需
8
7
要将 S a_ 回滚到 S a_6 , 这能够加速系统恢复的过程, 减少故障影响范围.
8
5 实验分析
本节将用从微信系统中采集的真实变更故障数据集测试本文提出的方法, 并回答以下问题.
● 问题 6: 本文提出的方法在根因变更识别上的准确性如何?
● 问题 7: 本文提出的 3 个可疑得分对根因变更识别的贡献如何?
● 问题 8: 本文提出的方法是否容易受参数影响?
5.1 实验设置
● 微信变更故障数据集: 本文从为十几亿用户提供服务的微信系统的真实环境中采集变更故障数据用于验证
本文提出的方法. 在微信中, 软件变更频率每天可达数千次. 在微信运维工程师的配合下, 本文采集了包括 30 个带
标注的变更故障的真实数据集. 本文数据集中不包含多变更故障, 这是因为根据第 3.5 节的分析, 多变更故障在真
实故障中的占比较小 (约 1.8%), 存在一定的偶发性, 本文的数据采集阶段没有遇到多变更故障. 表 3 中展示了本
文采集变更故障的详细信息, 包括缺陷变更发生故障的阶段、变更类型和数量的具体分布情况. 这些故障发生在
即时聊天、移动支付、短视频、公众号等多个领域, 这使得实验的结果更有代表性和泛化性. 每个变更故障数据
集都包含本方法所需的告警服务、变更信息、服务请求成功率等指标数据以及由运维工程师手动标注的根因变
更. 对每个故障, 本文还采集了以告警服务为中心两跳范围的所有服务在告警前 48 h 内的所有变更. 平均每个变
更故障在时空范围内关联 218 个变更, 手动从这些变更中定位根因变更需要耗费大量的人力.

表 3 微信变更故障数据集中缺陷变更的发生阶段、变更类型和数量分布

故障发生阶段 变更类型 故障数量
模型变更 0
资源变更 2
灰度变更
配置变更 2
后台变更 12
模型变更 2
资源变更 2
变更完成
配置变更 2
后台变更 8

● 模拟变更故障数据集: 本文在一个拥有 10 个节点的 Kubernetes 平台上部署了开源微服务基准测试系统
OnlineBoutique (OB) (https://github.com/GoogleCloudPlatform/microservices-demo). OB 模拟了一个电子商务微服务
系统, 用户可以在其中浏览、查看和购买产品. OB 已在许多先前研究中被广泛使用 [4,5] . 因 OB 应用不涉及模型变
更, 基于先前对真实变更故障的研究 [37,38] , 本文精心设计并模拟了 OB 应用中不同服务的缺陷后台变更、缺陷配
置变更和缺陷资源变更. 此外, 本文还将正常变更纳入数据集以确保其多样性. 对于每个案例, 我们随机选择一个
缺陷变更以及 2–5 个不同服务上的正常变更, 形成了一个多样化且全面的数据集. 模拟变更故障数据集共包含 50
个故障案例.
● 评价指标: 本文采用了一种广泛使用的评价指标 Top-k 命中率 (HR@k) 来评估本方法和对比方法的性能 [4] .
HR@k 指的是根因变更出现在根因列表结果中前 k 位的概率. HR@k 可以形式化为如下:

1 ∑ N ( )
HR@k = C i ∈ Score i [1:k] ,
N i=1
其中, C i 是第 i 个故障的根因变更, Score i [1:k] 是第 i 个故障的前 k 个结果列表, N 是所有故障的数量. 本文设置 k=1,