Page 165 - 《软件学报》2026年第2期
P. 165

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


                 致故障的根因变更. 这有助于运维工程师关注根因变更并采取适当的措施, 以避免进一步的服务中断                                (第  4  节).
                    ● 实现了根因变更识别算法的原型, 并使用真实生产环境的变更故障数据集和模拟变更数据集进行了验证.
                 实验结果表明, 本文方法能够分别以           80%  和  84% 的  Top-3  命中率识别出根因变更, 并且根因变更识别效果显著优
                 于当前最先进的缺陷变更识别方法            (第  5  节).
                    本文第   2  节介绍软件变更故障相关的实证研究、软件变更前识别缺陷变更、软件变更后定位缺陷变更、服
                 务级别根因定位等相关研究工作. 第           3  节介绍基于大规模即时通信系统微信系统中的真实变更故障实证研究, 得
                 出  5  个关键发现. 第  4  节详细阐述本文提出的在线系统根因变更识别方法. 第                5  节通过实验证明本文提出方法的
                 有效性. 第  6  节针对性讨论根因变更识别真实案例和本文的局限性. 最后, 在第                   7  节对全文进行总结, 并简要介绍
                 下一步工作.
                  2   研究背景和相关工作

                    在本节中, 本文首先介绍软件变更与软件变更故障的相关背景. 接着, 为了更好地展示本文与已有工作的区
                 别, 将从软件变更实证研究、软件变更前缺陷变更检测、软件变更后缺陷变更检测、服务级根因定位与根因变更
                 识别差异这    4  个方面介绍相关工作.
                  2.1   软件变更故障
                    软件变更是指对软件系统进行修改、更新或调整的过程                    [1] . 这些变更可以涉及软件的功能、性能、安全性、
                 用户界面、数据库结构、代码优化等方面. 软件变更的目的是改进软件系统, 使其更加稳定、可靠、安全, 并且能
                 够满足用户的需求. 软件变更可以分为以下几种类型.
                    ● 模型变更 (model change): 这种变更类型通常涉及修改现有的机器学习模型以提升其性能或准确性. 然而,
                 引入有缺陷的模型可能导致意外行为, 例如公众号推荐模型不准确导致用户点击率下降.
                    ● 客户端变更 (client change): 这种变更类型涉及更新用户设备上的            Android  或  iOS  应用程序. 有缺陷的客户
                 端变更可能导致兼容性问题或应用程序崩溃等问题, 从而影响用户的使用体验.
                    ● 资源变更 (resource change): 这种变更类型涉及根据运维工程师或自动伸缩方法确定的资源分配的更改. 不
                 适当的伸缩操作可能导致服务过载和请求超时, 从而影响系统的可用性和性能.
                    ● 配置变更 (configuration change): 这种变更类型指的是对服务的配置设置进行的调整. 不正确或不兼容的配
                 置变更可能导致系统不稳定、请求错误或其他意外行为.
                    ● 后端变更 (backend change): 这种变更类型涉及对后端服务进行的修改. 有缺陷的后端变更可能导致服务崩
                 溃或响应时间变慢等问题, 从而影响用户的访问体验.
                    尽管在软件变更上线之前工程师会对变更的服务进行严格和周密的测试, 但由于生产环境和测试环境存在多
                 种差异和更加复杂的组件交互关系, 有部分缺陷变更仍会通过测试, 并被部署到生产系统中, 然后导致系统出现故
                 障. 本文将由缺陷软件变更引发的故障称为变更故障. 这种故障类型并非由外部因素                           (如资源竞争、网络中断等)
                 导致, 通常是通过执行代码回滚或者上线新的软件版本来进行修复.
                  2.2   软件变更实证研究
                    软件变更及其引发的故障一直以来都是软件工程研究的热点, 已有大量高质量的研究工作专注于分析不同场
                 景下软件变更的特征及其引发故障的根因              [1,13–15] .
                    Savor 等人  [1] 介绍了  Meta 和  OANDA  两家公司实施持续部署    (continuous deployment) 的详细经验. 文中通过
                 具体案例全面阐述了两家公司的部署流程、测试策略与发布策略, 并从组织与技术层面深入分析了实施持续部署
                 面临的挑战, 得出实施持续部署可以显著提高部署效率、缩短交付时间、改进产品质量与用户满意度的结论. Li
                 等人  [15] 收集并分析了在   Google、AWS  和  Azure 这  3  大云平台上的  354  份公开故障报告, 总结了故障出现的主要
                 原因并进行实证研究. 该论文研究发现            46.6%  的云平台故障涉及软件变更, 这个结果与本文的结果接近. 但是                   Li
                 等人的研究并不是专门针对变更故障的, 没有针对变更故障的具体原因和定位时长等方面进行深入研究.
   160   161   162   163   164   165   166   167   168   169   170