Atlassian 认为，在微服务环境中，事故根因分析已经不能再仅依赖人工审查。当数百项相互关联的服务跨多个区域运行时，单个故障会产生大量指标、日志和追踪数据，而值班工程师通常不得不在相互独立的仪表板之间切换，并在脑中构建关于问题来源及其传播路径的假设。
在 CNCF 博客的一篇文章中，Atlassian 的 Santosh Balaranganathan、Michael Yoo、James Moessis、James Kieltyka、Jason Lee 和 Lavender Neesham 介绍了一套自动化根因分析系统，旨在自动生成假设，使响应团队能够更快进入验证和修复阶段，而不是手动重新汇总证据。
将根因分析转化为多信号关联问题
该设计基于对三层证据的关联：信号类型、时间和服务拓扑。信号包括指标、日志和追踪数据；时间同步关系用于确定可能相关的事件；服务依赖图则有助于区分最先出现故障的服务与之后受到影响的服务。
流程首先通过从 OpenTelemetry 推导出的服务地图缩小搜索范围。系统不再分析平台中的所有服务，而是确定处于受损用户体验路径上的服务，通常将范围缩小到几十项服务，而不是数百项。该地图反映的是从生产流量中时间片段之间的父子关系提取出的实际通信，而不是文档中假定的架构。
从监控数据到有序假设
确定范围后，独立模块会分别在每种信号中发现异常。在指标方面，Atlassian 监控 RED 指标，即请求速率、错误速率和响应时长，并使用中位数绝对偏差和百分位数范围等统计方法。每个异常状态都会生成严重度值、观测值以及发生偏离的基线。
对于分布式追踪数据，系统会检查意外异常、错误传播的新模式，以及特定片段响应时间的上升。日志则使用基于嵌入的聚类技术，将语义相似的条目归为一组，然后相对于服务的常规分布突出显示新的或罕见的错误集群。
所有检测器都会将结果转换为具有统一架构的事件，其中包括时间戳、服务名称、信号类型、严重度和详细信息。该层使关联引擎能够分析事件，而不依赖每个检测器发现状态的方式；同时也允许添加新的检测器，或将一种统计模型替换为基于机器学习的模型，而无需重建整个系统。
利用时间和依赖图确定故障方向
引擎会将时间上接近的事件聚合到可配置的时间窗口内，通常为正负五分钟。每个组都会获得一个时间一致性分数；事件越接近，其相关的可能性就越高。为避免同一个假设被重复生成数十次，系统使用服务序列指纹，并将重复的故障链合并为一个组，同时记录重放次数。因此，可以将五分钟内重复 47 次的故障模式描述为一个模式，而不是创建 47 个相同的假设。
随后，系统确定受影响最严重的节点，即所谓的下游节点，然后沿依赖图反向移动，寻找在时间上更早出现异常的服务。如果服务 A 调用服务 B，而 B 的问题早于 A 的问题出现，那么 B 就会成为更有力的故障源候选，而 A 的问题则被视为后续影响。最终评估会综合时间一致性和传播路径分数，对假设进行排序。
结果并不只是服务列表和置信度分数。每个假设都包含疑似服务、传播路径以及每个节点上的证据，例如超出边界的指标或与故障相关的追踪数据编号；此外还会提供一段人类可读的叙述，解释事件顺序以及某个来源为何获得更高优先级。
为什么这种方法对运维团队很重要？
这里的实际价值并不是取代响应工程师，而是缩短获得可验证假设所需的时间。Atlassian 将根因分析引擎与更广泛的事故响应平台相连接，其中包括发现故障对用户的影响、确定负责团队，以及一个能够根据现有证据提出操作建议的事故助手，例如回滚版本或禁用功能标志。平台还会记录工程师是否接受、拒绝或修改了假设，以便随着时间推移改进权重。
这项实践表明，与其为每种信号构建复杂的机器学习模型，从简单且可解释的方法入手可能更合适。例如，中位数绝对偏差和百分位数范围足以发现许多指标异常；而在日志聚类和追踪数据结构分析中，则使用了机器学习方法，因为统计方法在这些场景下适用性较低。
但这种方法并不能消除限制。假设的质量取决于监控数据的一致性、服务依赖图的准确性，以及检测器区分真实故障与噪声的能力。此外，置信度并不是因果关系的最终证据；因此 Atlassian 强调展示每项证据的来源，以及将证据与结论联系起来的叙述的重要性。该公司之后还在探索使用基于语言模型的编排方式，使系统能够请求额外数据并调整假设，同时要求设置速率限制、隔离执行环境，并清晰记录证据来源。
certi.news 的编辑解读：这种方法的实际变化，是将事故分析从对多个独立工具进行人工比对，转变为一种统一流程，整合信号、时间和拓扑。其运营成效将取决于可解释性、数据质量和反馈闭环，而不仅仅是排序算法本身。因此，模块化、消除重复以及记录证据，似乎比承诺实现根因分析的完全自动化更具即时可行性。