RCA(Root Cause Analysis)根因分析图解
RCA(Root Cause Analysis)根因分析图解

RCA(Root Cause Analysis)根因分析图解

RCA(Root Cause Analysis)根因分析图解

一句话理解

RCA 不是为了找“谁犯错”,而是为了找“系统为什么允许问题发生”,然后设计能防止复发的改进。

1. RCA 是什么?

RCA 是一种结构化的问题分析方法,用来从表面现象一路追溯到真正的根本原因。它常用于事故复盘、质量问题、系统故障、流程缺陷和客户投诉。

flowchart LR
    A[问题现象] --> B[收集事实]
    B --> C[识别直接原因]
    C --> D[追问为什么]
    D --> E[找到根因]
    E --> F[制定纠正措施]
    F --> G[验证是否防止复发]

普通排查经常停在“哪里坏了”;RCA 继续追问“为什么会坏、为什么没有提前发现、为什么系统允许它扩大”。

2. 表象、原因、根因的区别

层级 例子 处理方式 风险
表象 服务 10:05 宕机 重启服务 问题可能再次发生
直接原因 数据库连接耗尽 增加连接池上限 只缓解压力
根因 发布前没有容量验证,告警阈值也过晚 建立容量测试和早期告警 才能降低复发概率
判断是否是根因

如果移除这个原因后,同类问题很难再次发生,它更可能是根因;如果只是让这次问题恢复,它通常只是直接原因或临时修复。

3. 常用方法一:5 Whys

5 Whys 是最轻量的 RCA 工具。它通过连续追问“为什么”来突破第一层解释。

flowchart TD
    P[问题:客户订单延迟发货] --> W1[为什么?仓库没有及时拣货]
    W1 --> W2[为什么?系统没有生成拣货任务]
    W2 --> W3[为什么?订单状态没有从已支付变为待履约]
    W3 --> W4[为什么?支付回调失败后没有重试]
    W4 --> W5[为什么?回调重试机制没有纳入上线验收清单]
    W5 --> R[根因:关键异步流程缺少可靠性验收标准]

5 Whys 的关键不是一定问满五次,而是问到能够产生系统性改进的位置。

4. 常用方法二:鱼骨图

鱼骨图适合多人讨论,把潜在原因按类别展开,避免只盯着某一个方向。

flowchart LR
    M1[人员<br/>培训不足<br/>交接不清] --> P[问题:线上事故]
    M2[流程<br/>缺少发布检查<br/>审批流形式化] --> P
    M3[工具<br/>监控缺口<br/>自动化不足] --> P
    M4[环境<br/>流量突增<br/>依赖不稳定] --> P
    M5[方法<br/>测试场景不完整<br/>容量评估缺失] --> P
    M6[材料/数据<br/>配置错误<br/>脏数据] --> P

常见分类可以用 5M1E:Man(人员)、Machine(机器/工具)、Method(方法)、Material(材料/数据)、Measurement(测量)、Environment(环境)。

5. RCA 的标准流程

sequenceDiagram
    participant T as 团队
    participant S as 事实
    participant A as 分析
    participant C as 改进
    T->>S: 定义问题和影响范围
    T->>S: 收集时间线、日志、证据
    S->>A: 区分事实、假设和观点
    A->>A: 5 Whys / 鱼骨图 / 变更分析
    A->>C: 提出纠正和预防措施
    C->>T: 指定负责人、截止时间和验证指标

6. 一个完整小例子

场景

周一上午 10:05,用户无法提交订单,持续 18 分钟,影响约 12% 的请求。

时间 事实
09:50 新版本上线,包含支付状态回调处理逻辑
10:03 支付回调错误率开始上升
10:05 订单提交大量超时
10:12 值班同学收到用户反馈,开始排查
10:23 回滚版本,服务恢复

分析链路

flowchart TD
    A[订单提交超时] --> B[订单服务等待支付状态]
    B --> C[支付回调处理失败]
    C --> D[新字段为空时触发异常]
    D --> E[测试数据没有覆盖旧版支付渠道]
    E --> F[发布验收没有要求兼容性用例]
    F --> G[根因:支付链路缺少跨渠道兼容性验收机制]

行动项

类型 行动 负责人 验证方式
纠正措施 修复空字段异常处理 开发负责人 单元测试覆盖旧版渠道
预防措施 发布清单加入支付渠道兼容性检查 技术负责人 每次发布前检查记录
检测措施 支付回调错误率 3 分钟告警 SRE 演练触发告警
学习措施 复盘支付链路数据契约 产品+研发 输出接口契约文档

7. RCA 输出模板

## 问题摘要
- 发生时间:
- 影响范围:
- 用户影响:

## 时间线
- HH:MM 发生了什么

## 根因
- 直接原因:
- 促成因素:
- 根本原因:

## 行动项
| 行动 | 类型 | 负责人 | 截止时间 | 验证方式 |
|---|---|---|---|---|

## 复发验证
- 我们如何确认同类问题不会再次发生?

8. 常见误区

RCA 不是甩锅会

如果结论是“某某不小心”“某某忘了检查”,通常还没有分析到根因。更好的问题是:为什么流程、工具、评审或告警没有帮助人避免这个错误?

  • 只写临时修复,不写预防措施。
  • 把“人为失误”当根因。
  • 没有事实证据,全靠回忆。
  • 行动项没有负责人和截止时间。
  • 没有验证措施,无法判断是否真的降低复发。

9. 快速记忆图

mindmap
  root((RCA))
    定义问题
      影响范围
      时间线
      事实证据
    分析原因
      5 Whys
      鱼骨图
      变更分析
    找到根因
      系统缺陷
      流程缺口
      检测不足
    防止复发
      纠正措施
      预防措施
      验证指标
最终目标

一份好的 RCA 应该让团队下一次更早发现、更快恢复,并且更难犯同类错误。

发表回复