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

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

缺陷变更引起的故障, 因为它们对微信系统的稳定运行具有重大影响.
发现 2. 与其他故障类型相比, 缺陷变更导致严重故障的比例更高.
3.5 问题 3: 变更故障的根因识别时间
为了回答问题 3, 本文需要明确“根因识别时间 (time to identify, TTI)”的定义. 根因识别时间是指从故障发生
到运维工程师定位到根因 (如网络中断或模型更改) 所花费的时间. 在图 3 中, 本文展示了由缺陷变更导致的故障
和由其他原因导致的故障的根因识别时间的累积分布函数 (cumulative distribution function, CDF) 图.

1.0
累计概率分布 0.6 变更故障根因定位时间
0.8
其他故障根因定位时间
0.4
0.2
0 100 200 300 400 500 600
时间 (min)
图 3 变更故障和其他故障根因定位时间对比

通过观察图 3, 得出以下结论: 对于大多数故障, 运维工程师往往很难及时确定故障的根因. 具体而言, 对于由
缺陷变更导致的故障和由其他原因导致的故障, 至少有 50% 的情况下, 运维工程师需要分别花费 25 min 和 15 min
来确定根因. 而对于 10% 的故障, 这个时间甚至超过了 185 min 和 105 min. 由图 3 可见, 与其他故障相比, 运维工
程师需要更长的时间来确定由缺陷变更导致的故障的根因. 这种情况部分归因于当前的根因定位方法在识别由缺
陷变更引起的根因方面的不足. 另一个重要因素是一些有缺陷变更的服务不会表现出异常, 而是其上游或下游服
务表现异常, 这使得运维工程师更难以确定根因变更.
值得注意的是, 在对这些持续时间较长的定位过程作进一步分析时, 我们发现存在少量需要处理多个变更的
故障案例 (总计约 1.8%). 这些多变更故障可以进一步分为两类: 一类是协同变更故障 (约 0.7%), 即由于服务间接
口变更不同步或版本不匹配, 需要回滚多个相关服务的变更才能恢复系统; 另一类是级联变更故障 (约 1.1%), 通
常发生在一个服务的变更触发了其他服务的自动响应性变更 (如负载过高导致的自动扩容或配置自动调整), 这些
连锁反应共同导致了系统故障. 多变更故障比例较低主要得益于微信的工程实践. 首先, 微信采用严格的微服务架
构设计, 通过明确的服务边界和标准化的接口契约有效降低了服务间耦合; 其次, 变更管理流程规定高风险变更必
须单独发布, 避免了复杂变更的同时上线; 最后, 采用严格的灰度发布策略, 通过分批次部署进一步降低了多变更
同时故障的可能性.
总体而言, 这些结果强调了在处理由缺陷变更引起的故障时, 根因变更识别的复杂性和耗时性. 为了加快根因
识别的速度, 运维工程师需要在现有服务级别根因定位方法基础上进一步改进和完善, 特别是当故障背后隐藏了
多次变更的相互作用时, 更需要结合变更依赖关系、服务依赖关系、变更时序等多种信息来提升故障诊断效率.
发现 3. 定位由缺陷变更导致的故障的根因需要比由其他原因导致的故障花费更长的时间.
3.6 问题 4: 典型软件变更故障及其表现
为了进一步深入理解变更故障的表现, 本文系统地总结了一系列典型变更故障, 详见表 2 中的前 9 行. 通过这
个表, 可以观察到系统的业务指标 (如请求响应成功率或请求延迟) 以及机器指标 (如 CPU 利用率或内存利用率)
都可能会受到软件变更的影响.
在某些故障情况下, 已变更的服务实例与未变更的服务实例在软件灰度变更阶段会展现出明显的指标差异,
这种差异可以用来推断变更是否出现异常. 以后台变更引入错误的参数顺序为例, 已变更的服务实例会出现函数
调用失败和请求响应成功率下降的表现, 而未变更的服务实例则保持稳定的请求响应成功率. 通过对比已变更与
未变更的服务实例的请求响应成功率差异, 运维工程师可以推断出该变更是缺陷变更.
此外, 还存在部分变更故障在灰度变更阶段不表现异常, 而是在变更完成后才显现出问题. 举例来说, 当程序