可能的根本原因：利用因果 AI 加速事件修复 – IBM 博客

一次又一次的事实证明，业务应用程序的中断代价非常高昂。平均停机时间可运行的估计成本 每小时 50,000 美元至 500,000 美元, 随着企业积极转向数字化，情况会更加严峻。应用程序的复杂性也在不断增加，因此站点可靠性工程师 (SRE) 需要数小时（有时甚至数天）来识别和解决问题。  

为了缓解这个问题，我们引入了新功能 可能的根本原因 作为 Instana® 智能事件补救的一部分。创建事件后，Instana 使用 Causal AI 自动分析呼叫统计、拓扑和周围信息；并快速有效地识别应用程序故障的可能根源。这使得 SRE 能够通过直接查看问题的根源而不是症状来解决事件，从而节省了他们大量的工作时间并避免了相当大的业务成本。  

这个空间的结果通常取决于众所周知的三元组： 数据、所做的假设和应用的方法. 

数据 

Instana 100% 监控每个调用跟踪，维护有关 API 调用、数据库查询、消息传递等基础设施和应用程序的信息。它还以一秒的粒度维护基础设施和应用程序指标，以及事件、动态应用程序和基础设施拓扑以及用户的进一步相关数据点。这意味着 Instana 具有无与伦比的数据粒度和可用性，使我们能够使用因果人工智能以特定的细节和准确性识别可能的根本原因。  

假设 

大多数 IT 管理工具中关于根本原因分析的核心假设之一是应用程序的拓扑在非常精细的级别上始终可用且完整。对于许多 IT 管理工具来说，这种假设不成立，因为 IT 管理流程是专门化的，并且不同的团队拥有多层应用程序的不同部分。这种情况的发生通常是由于团队之间的职责分离、整个组织使用不同的监控工具以及各种其他可能的管理流程相关原因。 

IT 管理工具可能无法完全观察多层应用程序的拓扑。然而，由于我们使用因果人工智能和通用算法，即使在数据粒度有限和部分拓扑的情况下，我们也能够识别根本原因。我们甚至可以在没有噪音追踪的情况下提供洞察力。  

方法 

使用因果人工智能，我们可以通过加入不同的数据源（例如调用、指标、事件和拓扑）来识别影响应用程序的故障的根本原因。不仅如此，我们还能够展示某些实体如何以及为何被识别为可能原因，从而使所识别的问题实体具有信心和可信度。因果人工智能为我们提供了对问题组件的定位和调查的强大洞察力。  

SRE Stan 的示例用例 

让我们来回顾一下 SRE 斯坦所面临的经历。 Stan 是一名 SRE，在一家小公司工作，该公司拥有 机器人商店应用 部署在由 Instana 监控的 Kubernetes 集群上。他们最近打开了可能的根本原因功能并配置了一些应用程序智能警报。  

有一天，他从 Slack 警报通道收到这条消息，该通道配置了公司机器人商店应用程序上设置的智能警报。他了解到机器人商店应用程序似乎存在性能问题。斯坦点击该事件以查看调查过程的更多信息。  

他会看到事件页面以及新的可能根本原因面板。事件页面为斯坦提供了一些更具可操作性的信息，但重要的是，他现在有了开始和解决调查的方向。可能的根本原因指向机器人商店应用程序中的特定流程。此进程代表目录服务的一个实例（三个副本中的一个）。  

然后，他单击“可能的根本原因”实体链接，将 Stan 发送到呼叫分析页面，他立即在其中查看导致下游延迟影响的错误呼叫。  

他发现对此目录 pod 实例的所有调用均失败，并出现 503（服务不可用）错误。这导致他检查了更多基础设施指标，发现该 pod 的可用内存不足，并且它已经运行了相当长一段时间而没有重新启动。他重新启动 Pod 以在短期内进行修复，并将其标记为进行审查，以确保将来不会发生这种情况。  

在这里，我们可以看到 Stan 在事件调查和补救工作流程中节省了大量时间。如果没有可能的根本原因功能，他将不得不从事件通知开始，探索应用程序仪表板，手动查看调用跟踪，回溯调用跟踪直到找到目录服务，然后进一步查找以确定哪个 Pod 是问题。然后他必须验证这是否是根本原因并采取相应的补救措施。借助可能的根本原因功能，Stan 节省了大部分时间和金钱，并且可以直接进行修复。  

未来愿景 

在接下来的几个月里，我们将扩大我们的根源能力，超越我们今天所拥有的。虽然定位可能的根本原因对于缩短解决应用程序故障的平均时间非常有效，但在接下来的几个月中，我们还有一些机会可以探索。  

• 增强的可解释性： 由于使用因果人工智能，该算法是完全可解释的，使我们能够轻松构建可解释性工具，这些工具不仅可以告诉 SRE 他们的问题出在哪里，但为什么 这个结论是以一种优雅而自然的方式得出的。这使我们能够围绕已确定的根本原因构建故事和经验，从而创建快速且值得信赖的智能补救措施。 
• 了解 什么 发生了，不仅仅是 哪里 它发生了：我们不断增强我们的解决方案，不仅能指出根本原因发生的位置，还能更好地分析发生了什么以及如何发生。通过更多的分析，我们可以开发一个公式来告诉 SRE 错误实体中出现问题的准确解释，而不仅仅是指出错误实体。这也促进了智能事件补救计划中更强大的下一步——补救行动建议。  

我们相信这里有巨大的潜力，我们对已经完成的工作感到非常自豪。这是工程与 IBM® 研究之间的独特合作，使我们能够快速行动并即时解决问题。  

我们相信这里有巨大的潜力，我们对已经完成的工作感到非常自豪。这是工程与 IBM® 研究之间的独特合作，使我们能够快速行动并即时解决问题。  

注意：可能的根本原因功能当前处于技术预览阶段，并在从应用程序或服务级别智能警报配置创建的事件时触发。完整版即将推出！

详细了解 IBM Instana 的可能根本原因功能和智能修复管道