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

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

5.6 方法分析开销
本文针对微信生产环境中的典型规模故障 (涉及 50 个服务、200 个变更), 对本文提出的方法进行了工程性
能评估, 重点关注内存占用和故障分析时延两项关键指标. 实验结果如表 7 所示. (1) 内存占用: 本文方法在处理时
的峰值内存占用约为 2.3 GB, 其中服务依赖图构建模块占用约 0.8 GB, 变更依赖关系构建模块占用约 0.6 GB, 根
因变更推断模块占用约 0.9 GB. 在大规模故障场景下, 系统通过增量计算和数据压缩优化, 将内存峰值控制在
4.5 GB 以内, 满足生产环境资源限制要求. (2) 故障分析时延: 在标准配置服务器 (16 核 AMD EPYC 7K62 CPU
(2.6 GHz), 32 GB 内存) 上, 本文方法在处理典型规模故障时完成根因变更识别的时延为 28.6 s, 其中服务依赖图
构建耗时约 6.8 s, 变更依赖关系构建耗时约 8.4 s, 根因变更推断耗时约 13.4 s.

表 7 方法分析开销

指标类别 测试模块 性能数据
标准规模故障总开销 2.3
服务依赖图构建 0.8
内存占用 (GB)
变更依赖关系构建 0.6
根因变更推断 0.9
标准规模故障总开销 28.6
服务依赖图构建 6.8
故障分析时延 (s)
变更依赖关系构建 8.4
根因变更推断 13.4

6 讨 论

6.1 工业部署案例分析
在本节中, 本文将展示一些微信中的真实根因变更识别案例. 为了保护公司的隐私, 本文对其中一些案例中的
部分细节 (例如服务名和具体功能) 进行了匿名处理.
真实案例 I: 开发工程师在服务 S 1 的新版本中引入一段有缺陷的代码, 导致服务在执行该代码段时崩溃, 从而
导致服务 S 1 的响应成功率下降. 这一故障是在灰度变更期间由微信的告警系统检测到的. 通过比较服务 S 1 变更
前后服务实例的 KPI 曲线, 本文提出的根因变更识别方法能够精准判定该告警是由服务 S 1 的缺陷变更引起的, 并
将 S 1 的缺陷变更输出为根因变更得分表的第 1 位. 与运维工程师手动识别根因变更相比, 使用本文的方法根因变
更的识别速度提前 61 min 发现了根因变更. 在这个案例里, 当前的缺陷变更检测方法能够识别出服务 S 1 的缺陷
变更. 但是, 缺陷变更检测方法同样也将服务 S 1 的上游服务 S 2 的正常变更识别为缺陷变更, 因此 S 2 因异常传播也
出现了 KPI 的异常, 没有考虑服务依赖的缺陷变更检测方法会导致误报.
真实案例 II: 开发工程师修改了服务 S 3 某一个函数的返回值类型. 在 S 3 软件变更之后, 服务 S 4 调用服务 S 5
来获取缺陷函数的返回值, 并将该返回值用于调用服务 S 5 . 但由于新的返回值的类型与服务 S 5 需要的输入类型不
兼容, 导致服务 S 4 调用服务 S 5 返回失败, 从而导致服务 S 4 和 S 5 的响应成功率下降. 在这种情况下, 运维团队首先
会检查服务 S 4 和 S 5 , 而没有检查到服务 S 3 这种没有出现 KPI 异常的情况. 而本文的方法通过评估故障与变更时
间之间的相关性, 能够将服务 S 3 的根因变更排名为最可疑变更 (比运维工程师手动定位根因变更提前 40 min). 由
于 S 3 没有出现 KPI 异常, 当前的缺陷变更检测方法 (如 SCWarn) 都未能识别到 S 3 的缺陷变更.
真实案例 III: 开发工程师在服务 S 6 变更时引入了一个内存泄露的代码缺陷. 内存泄露的故障并没有在变更后
立即表现出来, 而是在变更完成后 6 h 才出现内存溢出 (OOM), 进而导致影响到用户的访问. 已有的缺陷变更检测
方法通常在变更完成后就判定此次变更为正常变更, 因此他们不能处理这种变更完成后才表现异常的缺陷变更.
本文提出的方法在这个案例中没有将 S 6 的变更排名为最可疑的变更, 这是因为系统中存在一个 S 7 的正常变更的
变更时间与故障发生时间上关联很高, 所以认为运维工程师应优先检查 S 7 . 但考虑了已完成变更的本方法还是能