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

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

算法 GIED [35] 触发. GIED 是一个使用有监督的图神经网络模型进行异常检测, 并结合灵活的转移矩阵设计的
PageRank 算法进行服务级别根因定位的算法. 本文之所以沿用一个成熟的告警算法而非从零开始设计, 是因为根
据发现 5 的结果, 当前的成熟告警算法能够有效约简搜索空间. 根据发现 5 的结果, 在获得 GIED 算法输出的告警
服务后, 根因变更识别算法只需考虑告警服务及其上下游两层调用的服务的变更, 从而能够有效地缩小搜索空间,
加快搜索速度.

缺陷变更得分
① 服务依赖图 ③ 根因变更推断 1 服务: S a
变更单 构建
数据库 变更单: S a_7
S d KPI 得分 时间得分 空间得分
2 服务: S c
S a 变更单: S a_4
触发
告警系统 S b S c 3 ···
S d_6
② 变更依赖 S a_6 S a_7 S a_8
指标 关系构建 S a S c_4 S c_5
数据库 S a_6 S a_7 S a_8 S b_4 S c 运维
工程师
变更回滚
图 5 根因变更识别方法总体框架

本文提出的根因变更识别框架主要包括服务依赖图构建模块, 变更依赖构建模块, 根因变更推断模块 3 个
模块. 在被告警系统触发后, ① 服务依赖图构建模块会以告警服务为中心构建上下游的服务依赖图 (第 4.4 节).
② 针对服务依赖图上的所有服务, 如果服务在 H h 内有变更, 变更依赖构建模块会构建变更之间的依赖关系 (第
4.5 节). ③ 根因变更推断模块则会对每个服务的 H h 内的所有变更计算 KPI 差异得分, 时间衰减得分和空间依赖
得分. 然后将这 3 个得分输入根因变更推断模块, 输出一个根因变更得分列表供运维工程师检查 (第 4.6 节). 在理
想情况下, 根因变更得分排名第 1 的变更就是导致这次故障的根因变更. 运维工程师可通过回滚或快速修复根因
变更使系统恢复正常, 避免对用户的持续影响, 提升系统的可用性.
4.4 服务依赖图构建
在告警系统被触发后, 告警系统将输出一个最可疑的服务让运维工程师检查. 本文将这个告警系统输出的服
务称为“告警服务”. 本节的动机来自对历史故障数据的深入分析 (发现 5): 98% 的根因变更都集中在告警服务的
直接上下游两层调用范围内. 这一发现具有重要的工程实践价值, 它表明在故障诊断时, 只需要重点关注告警服务
周边的局部调用拓扑, 就能以较高概率定位到问题根源. 基于这一发现, 本文的服务依赖图构建模块采用了一种聚
焦式的构建策略: 以告警服务为中心节点, 向外扩展构建两层深度的服务依赖图. 这种局部化的构建方法相比全系
统范围的依赖分析, 可以显著降低计算复杂度, 同时保持较高的根因变更检出率.
在具体构建服务依赖图时, 我们的构建模块采用多阶段处理流程: 首先, 模块会从分布式追踪系统 (如 Jaeger)
和服务网格控制平面 (如 Istio Pilot) 中抽取服务间的实时调用关系数据. 在现代云原生环境中, 这些调用关系可以
通过多种技术手段可靠获取: (1) 对于基于 Spring Cloud 等微服务框架的应用, 可以通过解析 REST API 调用日志
或 Feign 客户端代理信息来建立调用关系; (2) 对于服务网格管理的服务, 可以直接从 Istio 或 Linkerd 的控制平面
获取服务间的流量路由规则; (3) 通过分布式追踪系统 (如 OpenTelemetry、SkyWalking) 收集的调用链 (Trace) 数
据, 可以精确还原服务间的调用拓扑和时间依赖关系. 在构建出完整的二层调用关系图后, 模块会进一步查询变更
管理系统 (如企业内部 CMDB 或 GitOps 工具链), 获取该调用图上所有服务在最近 H h 内的变更记录. 基于对运
维团队的调研访谈, 我们将 H 的默认值设定为 48, 这个时间阈值得到了运维经验的强有力支持: 真实故障统计显
示约 95% 的变更相关故障都会在变更后的 48 h 内显现出来. 对于调用关系图中的叶节点 (即只被调用但不调用
其他服务的末端节点), 如果它们在过去 H h 内没有关联任何变更操作, 构建模块会执行剪枝优化: 递归地将这些
无变更的叶节点从图中移除. 通过这种剪枝处理, 可以显著减少后续计算需要处理的节点数量 (平均减少 62% 的
节点), 从而大幅提升整体分析效率. 最终, 构建模块会将剪枝后的调用关系图与变更信息进行整合, 生成一个服务