跳到主要内容

什么是根因分析

· 阅读需 10 分钟
Kindling-OriginX
Kindling-OriginX
故障根因推理引擎

根因分析（Root Cause Analysis，RCA）是一种问题解决方法，用于识别问题的根本原因，然后通过解决这些原因来防止问题再次发生。它是一种回溯性过程，旨在发现问题的深层原因，而不仅仅是处理表面的症状或后果。

在可观测领域和IT领域内，根因分析是指在软件工程和系统管理中，当服务或应用出现故障时，通过监控和日志数据来识别导致问题的基本原因的过程。可观测性通常涉及三个主要的数据源：日志（记录事件的详细信息）、指标（系统性能的定量数据）和跟踪（记录请求流程的路径）。

不同人眼中的根因分析​

运维工程师眼中的根因分析​

在运维工程师或SRE部门承担着业务稳定的职责，所以出现问题之后，第一职责是确认到底该如何操作才能恢复业务。那么这里面需要根因分析吗？可能会有部分人认为运维不需要对故障做根因分析，只需关注进程是否存在，机器是否正常就好了，如果没有问题，就无脑重启业务就应该恢复业务了。 在一些IT架构不复杂，问题故障原因单一的情况下，很多时候是可以通过重启、回滚等手段恢复，但是IT架构一旦庞大起来，或问题根因比较复杂，特别是以微服务架构运行在云原生环境中时，重启能够恢复业务的几率就大大降低了，往往重启也只是一种无目的的猜测手段了。 在云原生环境中，运维工程师需要通过根因分析来达到恢复业务的目的。所谓根因就是运维工程师在故障发生时能够依据的结论，其后依靠这些结论来指导业务的恢复和故障的处置。 在这里例举下运维工程师可以采取的恢复手段，即使同类故障仍旧会在不久的将来再次发生。

  • 识别是代码缺陷，例如内存泄露、GC频率过高等，重启恢复业务。
  • 识别是代码缺陷导致CPU飙升、数据库QPS过高，在允许代码回滚的情况下通过回滚恢复业务。
  • 识别是流量过大的问题，如果确认是流量过大超过系统设计负载能力，在不变更架构设计的情况下，只能通过扩容或者限流措施来快速恢复业务。
  • 识别是共享资源的问题，取得明确的证据，减少跨公司跨团队的协作沟通成本，提交工单提供数据或相关日志，协助公有云或者云供应商更快的解决故障，恢复业务。
  • 识别是第三方软件依赖的问题，取得明确的证据，减少跨公司跨团队的协作沟通成本，督促第三方软件依赖快速解决故障，恢复业务。

运维工程师不可能在不了解故障根因的情况下，依靠穷举猜测试验的方式恢复故障，所以运维工程师非常需要了解到底发生了什么故障，该故障的根因是什么，才能真正的快速恢复业务，做到快速止血。所以针对运维工程师，故障根因结论是以下几种：

  • 位于哪个微服务节点的内存泄露、代码死锁——重启能够解决，确认是否能够重启还是扩容机器，减少风险。
  • 位于哪个服务节点的CPU飙升——确认是否能够回滚，或者扩容机器，减少风险。
  • 访问量激增——确认是扩容哪些节点还是限流某些节点来恢复业务。
  • 共享资源的问题
    • 如果是网络问题，确定哪个节点与节点之间的网络有问题，还是整个网段都有网络问题，提取证据，提交给公有云或者云供应商。
    • 如果是存储问题，确定是何种存储，提取证据，提交给供应商解决。
    • 如果是节点硬件或者配置故障，迁移机器。
  • 第三方依赖的问题，提交证据，交于第三方依赖厂商解决问题。

开发工程师眼中的根因分析​

开发工程师往往承担业务实现的职责，但在系统故障时常需协助运维工程师定位运维中的根本原因。同时，开发工程师还需要承担软件缺陷和架构设计问题所致故障的复盘工作，以避免未来类似故障再次发生，并确保对系统及时进行优化。

因此，开发工程师视角下的根因分析需要有效指导故障复盘，能更好地还原故障现场，帮助开发人员理解故障发生的代码层或配置层原因，并及早发现业务架构设计层面的潜在风险。

常见的开发人员视角下的根因包括：

  • 代码死锁现象——开发工程师想知道的根因是锁住的代码块是哪些，代码分别持有锁的时间长度是多久。
  • CPU飙升——开发工程师想知道哪段代码导致的CPU飙升。
  • 内存泄露——开发工程师想知道哪些函数申请的内存具体多少。
  • 网络问题——开发工程师想知道具体访问哪些请求，做了哪些操作从而提取优化思路。
  • 存储问题——开发工程师想知道具体访问了什么文件，I/O是多少，访问频度如何，从而提前设计优化方案。

故障根因分析实践中的困境​

虽然在现代IT系统中，各环境参与人员都急需合适的根因分析工具介入来提高效率，优化故障处置流程，但是目前根因分析在真正落地实施时面临多种挑战和困境：

  • 复杂性

现代系统的分布式和微服务架构增加了系统的复杂性，特别是云原生环境下资源服务的动态变化和基础设施故障也会对定位造成干扰，这些都使得故障的定位和根因分析难以实现。

  • 信噪比

系统可能会产生大量的日志和各类指标数据，特别是发生故障时尤为突出，但并非所有数据都与问题相关。过滤出有用信息并从中识别和定位出故障根因非常具有挑战性。

  • 文化和流程

组织文化和相关流程需要能够有所支持，一方面组织内部必须能够切实有效的认识到根因分析对于提高系统可靠性和发生故障时真正快速止血的必要性，另一方面团队内部也需要有适宜的协作机制和流程，促进各团队间能够快速修复问题，并且深入挖掘其根本原因，能够做到快速止血的同时也能够彻底解除隐患，落地实践 1-5-10 等高效的故障处置流程。