OverOps 在根本原因分析中重要性

服务停机时间的成本正在增长。有可靠的报告指出，停机时间的成本在每分钟 72,000～100,000 美元。识别根本原因（平均识别时间，MTTI）通常要花费数小时。对于复杂的情况，该过程可能需要花费数天的时间。由于各种原因会导致 MTTI 太长，能加速 MTTI 的工具也不多见。

需要能胜任的工具，通过将来自不同 IT 工具（如 APM、ITSM、SIEM 和 ITOM）中的数据与开放式 API 连接器相关联，可以丰富价值。因为微服务及其实例在容器上运行，因此 IT 团队需要管理数百万个数据点，这就需要使用高度先进和自动化的工具。开创性的 AI 算法通常用于自动精确地查找根本原因。

根本原因分析被当作一项重要的在部署后期应该采取的活动，可以准确地指出任何软件应用程序中的错误及其根源。任何标准化的 APM 解决方案都会显示出应用程序抛出的每个错误和异常的堆栈跟踪。在每个异常的顶部，APM 软件显示错误的来源是哪个类和方法。但是，根本原因分析的本质是要进一步深入到根源，了解原因。有一些软件解决方案可以简化根本原因分析的工作。通过显著缩短测试和发布周期（从几周缩短到几天），持续交付的采用正在以指数方式增加将错误引入生产的可能性。

OverOps 在过渡性部署和生产阶段分析代码，以自动检测并提供所有错误的根本原因，而无须依赖日志记录。OverOps 可显示每个错误和异常的堆栈跟踪，它还显示了引发该错误或异常的完整源代码、对象、变量和值，这有助于确定代码中断的根本原因。OverOps 将超链接注入异常的链接中，从而能够直接进入导致异常的源代码和实际变量状态。OverOps 可以与所有主要的 APM 代理和分析器共存于生产环境中。通过一起使用 OverOps 与 APM，可以监视服务器的响应迟缓和错误，并能够深入探究每个问题的根本原因。

日志最强大的用例是进行故障排除，即日志文件中包含记录的错误、警告、捕获的和未捕获的异常。在大多数情况下，必须分解信息以了解在生产环境中执行代码时出了什么问题。

就管理日志记录而言，主要的挑战是它们往往包含难以管理的条目数量，需要手动在海量数据中找到有用的内容。OverOps 通过在现有的日志文件中插入超链接来帮助进行调试，这样运维人员和开发人员就可以立即看到每个事件背后的堆栈、来源和状态。OverOps 还可以对日志文件的内容进行去重，以减少运维噪声以及用于分析它们的时间。可以在 JVM 级别实时检测异常和记录错误，而不需要依赖于日志解析。

• 应用程序流分析：该功能采用控制和数据流细节来查找应用程序和事务错误。通过分析特定的应用程序，可以测量单个事务的性能。应用程序映射工具可以在单个应用程序流中可视化业务应用程序中的故障、警报和故障单。它会自动发现基础设施拓扑以及代表整个业务应用程序的流。如果选择特定的流，则可以可视化在整个基础设施上采用的路径。通过应用故障或警报覆盖，可以可视化受其影响的特定流。

• 业务事务分析：与深入分析事务及其性能有关。事务明细提供了许多可供使用的有用信息。通过分析业务事务的性能来加深了解。可以查看成功和失败事务的数量、它们随时间的响应时间，以及应用程序服务层中每个跃点的延迟。通过单击失败的事务，可以识别 JVM 中发生故障的特定 Java 代码。该信息可以传递给 Java 开发人员，供其修复使用。

当前有几种方法和解决方案正在推出，可以为开发可靠、有价值的软件应用程序和 IT 基础设施提供帮助。这些完善、进步和增强在 IT 的各个层面得到了体现。