怎么用5个Why分析法做故障复盘

最近有位研发同学参与故障复盘，将他的分析发给我double check，发现部分的故障原因没有太深入的挖掘，停留在了表面现象，导致后续制定的行动项可能治标不治本。这种现象其实还挺普遍，我们可以尝试使用一种简单有效的根因分析（RCA：root cause analysis）方法来更好做故障复盘：5个Why分析法（5 whys）。

方法概述^[1]：

5 Whys是一种反复询问的技巧，用于探索特定问题背后的因果关系。该技术的主要目标是通过重复问题“为什么？”来确定缺陷或问题的根本原因每个答案构成下一个问题的基础。名称中的“5”源于对解决问题所需迭代次数的轶事观察。

5个why方法故障复盘主要的思想

1. 拉长逻辑链条，找到深层原因

2. 抛弃主观假设和逻辑陷阱

3. 分清现象与原因

4. 步步分析，不直接跳跃下结论

5. 原因永远不在个人身上，不要将诸如“人为疏忽”，“没有注意”作为根因

5个why方法主要步骤

1. 分解问题，找到现象[2]

2. 问5个why（注意这里的5是概数，可以小于5，也可以大于5），直到无法再问why，找到根因。

3. 从最后的答案反过来问，看逻辑链是否反向成立，进行验证。

举几个例子来说明如何使用。这边取1个经典案例及1个我参与过的历史线上故障复盘案例举例（当时复盘没有使用5个why分析，所以我们可以看看区别）。

经典案例

现象：一个博物馆的东边外墙面上有非常严重的腐蚀，需要经常涂刷新的油漆。

浅显的分析及措施：经过调查以后，你发现，原来博物馆的清洁人员在洗墙的时候，用了一种高腐蚀度的清洁剂，这才导致了墙面的腐蚀。所以后续的措施是，在喷刷修补了这一次的墙面以后，要求清洁人员下次清洗墙面时换用低腐蚀度的清洁剂。

5个Why分析及措施：

第一个why：为什么这个清洁工要用高腐蚀度的清洁剂？

答：因为东边的墙上经常有很多鸟粪粘着，用一般的清洁剂洗不干净

第二个why：为什么东边的墙上有很多鸟粪？

答：因为墙上有很多蜘蛛，而这些鸟以蜘蛛为食，所以经常在墙附近活动

第三个why：为什么墙上有很多蜘蛛？

答：因为墙上有很多小虫子，而蜘蛛以这些小虫子为食

第四个why：为什么墙上有很多小虫子？

答：因为东面墙上有几扇窗子，晚上，博物馆里的光会从这里透出去，而这些趋光性很强的虫子就被光吸引过来了。

所以解决方案是：在窗户那里安装遮光性很强的厚窗帘，每天太阳落山之前拉上窗帘。

好了，我们似乎拿到了根因及解决方案，我们反过来再推导一遍：

1. 厚窗帘拉上后趋光性很强的虫子就不会被吸引【符合逻辑】

2. 趋光性很强的虫子不再聚集，蜘蛛不会再来聚集【符合逻辑】

3. 蜘蛛不再来聚集，吃蜘蛛的鸟不再经常来活动【符合逻辑】

4. 吃蜘蛛的鸟不再经常来活动，东面的墙不再有很多鸟粪【符合逻辑】

5. 东面的墙不再有很多鸟粪，清洁工不需要用高腐蚀度的清洁剂【符合逻辑】

6. 不适用高腐蚀度的清洁剂，墙面不再总是被腐蚀【符合逻辑】

至此，我们确定拿到了根因及正确的解决方案。

故障复盘案例

现象：商户使用银行打款流水号查询账单发现交易记录缺失

浅显的分析及措施：（之前没有使用5个why分析得到的结论）由于get(0)只拿到了部分数据，所以研发重新做代码的全量get(0)分析。

5个Why分析及措施：

第一个why：为什么使用流水号查询交易记录有缺失？

答：因为客户期望的是能用这个流水号查询到多笔（天）账单信息

第二个why：为什么同一个流水号有多笔（天）账单信息？

答：因为银行周六、周日休息，将合并周五、周六、周日账单一并打款，生成同一个流水号，关联到多笔（天）账单信息

第三个why：为什么一个流水号关联了多笔（天）账单信息，系统没有返回？

答：因为代码内使用了get(0)方法，只取了第一项数据

第四个why：为什么代码内使用了get(0)方法？

答：因为get(0)方法在编码中没有被禁止/提醒，研发在开发中没有注意到风险

所以解决方案是：在研发架构层面宣导get(0)风险，使用明确的业务语义来定义代码处理替换get(0)，在代码扫描工具中提醒get(0)属于高风险编码。

反过来推导验证：

1. 研发架构层面了解get(0)风险，在代码提交时被提醒为高风险编码，研发会谨慎使用get(0)或者避免使用get(0)【符合逻辑】

2. 所有研发谨慎使用get(0)，如果选择继续使用get(0)，那么在提交查询账单的编码中，工具提示风险【符合逻辑】

3. 工具提示get(0)风险后，在设计编码时，研发关注业务场景是否存在一对多的场景【符合逻辑】

4. 研发关注业务场景存在一对多的场景，一定程度上更有可能分析和感知到银行合并打款场景【符合逻辑】

反向推导逻辑链正确，解决方案成立，且该解决方案没有归结于人的处理，而归结于架构治理及工具。而之前的解决方案仅仅关注了get(0)在当时代码里面的风险，并不持续跟踪，所以仅仅治标未治本。