Page 166 - 《软件学报》2026年第2期
P. 166
余广坝 等: 面向大规模在线系统的故障根因变更识别 645
Zhang 等人 [13] 通过对 8 个广泛使用的分布式大数据处理系统中 123 个真实世界的变更故障进行了深入研究,
揭示了数据处理系统变更故障的严重性、根因、暴露条件和修复策略. 论文作者观察到, 只有 37% 的软件变更故
障在相应版本发布给公众之前被发现, 而大部分 (63%) 变更故障在生产环境中才暴露出来. 并且大部分变更故障
是由于数据类型、语义的不兼容 (如序列化库或枚举量定义的改变) 导致的. 与本文的工作相比, Zhang 等人的实
证研究主要针对大数据处理系统, 没有考虑为用户提供服务的在线系统, 而这类在线系统也是广泛使用的软件系
统, 变更频繁, 急需针对在线系统的软件变更故障进行深入分析.
2.3 软件变更前缺陷变更检测
在软件变更实施前识别潜在缺陷, 以降低变更风险一直是研究热点. 现有相关工作主要从软件测试 [16,17] 、可
靠性审计 [8,10,18] 和系统验证 [13,19,20] 等方面来检测缺陷变更.
Rex [19] 通过结合机器学习和程序分析的方法, 挖掘故障和错误配置之间的变更规则. Rex 通过两个步骤学习变
化规则: 发现变更规则和重新定义变更规则. 在发现变更规则中, 它利用关联规则挖掘技术寻找“频繁”一起更改的
文件集. 在发现变更规则后, Rex 执行第 2 步, 即变更规则的重新定义. 它能够将每个粗粒度的、文件级别的变更
规则进一步细化, 提高精确性. Rex 分析每个文件中的变化, 确定哪些类型的变化是相关的, 并根据学到的规则向
工程师提出建议. 另一方面, PCHECK [10] 分析源代码并自动生成配置检查代码 (称为检查器), 以检测潜在的配置错
误. 这类软件配置错误检测工具侧重于配置逻辑, 而不是由常见依赖项引起的故障.
Zhang 等人 [13] 提出了变更前数据缺陷检测工具 DUPChecker 和 DUPTester. DUPChecker 是一种静态分析工
具, 用于检查版本升级引发的枚举量改变是否会影响跨版本的数据迁移. 而 DUPTester 会在版本升级之前运行一
个工作负载, 生成数据, 并在升级后加载生成的数据, 以检查是否会引发故障. 然而, DUPChecker 和 DUPTester 主
要关注软件更新时数据格式的兼容性问题, 并不能对通用的软件变更进行检测. 此外, Batta 等人 [8] 的研究通过提
取变更与引发变更事件之间的联系, 主动评估与软件变更相关的风险.
然而, 由于生产环境与开发环境之间存在的差异 (比如生产环境与开发环境的 CPU 型号不同或操作系统内核
版本不同等), 在软件变更前识别缺陷变更的方法无法识别全部的缺陷变更. 除了进行测试和静态分析, 还需要对
生产环境的软件变更过程动态地进行监控和检测, 才能及时发现在生产环境才暴露出来的缺陷变更.
2.4 软件变更后缺陷变更检测
对于大规模系统, 部署一个与生产环境具有相同规模和配置的测试环境是困难的. 因此, 当前测试环境和生产
环境之间会存在部分差异, 这导致部分缺陷软件变更在测试过程中难以被检测出来, 在部署到生产环境后才被暴
露出来. 为了检测在生产环境中暴露的缺陷变更, 目前有一些缺陷变更检测的研究工作专注于识别在软件新版本
上线之后出现异常的缺陷变更 [9–12,21,22] .
[9]
FUNNEL 采用了 SST (singular spectrum transform) 算法, 用于监测在软件变更后服务的指标是否发生变化.
当检测到异常指标时, 它使用 DiD (difference-in-differences) 算法 [23] 来比较已变更的服务实例和未变更的服务实
例之间的差异, 以判断是否是由软件变更引起的指标变化. 如果是, 则判定该变更存在缺陷, 并通知运维工程师执
行回滚操作.
另一方面, SCWarn [12] 利用变更服务的多源可观测数据 (如日志和指标) 作为输入, 通过基于历史正常数据训
练的 LSTM (long short-term memory) 模型, 挖掘多源可观测数据中的时间依赖性和模式. 在程序变更时, SCWarn
利用训练好的 LSTM 模型来检测变更后的可观测性数据是否异常. 如果异常被发现, 则认为该异常是由变更引起
的, 并向运维工程师发出警报. Gandalf [11] 持续监测和提取各种故障信号 (如操作系统事件和服务日志), 并使用
Holt-Winters 预测算法基于历史数据来检测发生异常的实例. 如果在服务变更后出现大量该服务的错误实例,
Gandalf 会将异常与该服务的变更关联起来.
然而, 现有的缺陷变更检测方法主要将软件变更后的缺陷变更问题视为异常检测任务, 并应用异常检测算法
来解决该问题. 缺陷变更检测方法主要负责诊断单次变更是否为缺陷变更. 但这些缺陷变更检测方法通常只考虑
单个服务的单个变更是否异常, 而不考虑系统中其他服务变更的传播影响. 而故障传播在相互依赖的在线服务中

