春节期间IT运维界出了一件影响比较大的事，大年初五那天，Gitlab的一位同学误删了数据库，导致gitlab丢失了6个小时数据。Gitlab公开了整个事件的处理过程，原因是一位同学在长时间疲劳工作，又是高度紧张的情况下，本应该删除备份数据库时误删除了生产数据库。 rm -rf 这个命令相当有杀伤力，前不久我们也碰到过一起类似的误删除事件，一个脚本本来是要到一个目录中去清空日志，结果没正常进入日志目录，直接在根目录就rm -rf了！还好是一个不太重要的应用服务器，并且有备份，短时间内恢复了业务。
关于这个事件具体的处理过程和一些思考网上有不少相关的文章，这里不多提了，重点说说Gitlab在声明中说的会使用5Why来对这次事故进行深入分析。IT运维人每天都周旋于bug之间，故障分析是家常便饭。5why是故障分析的常用方法和手段，或多或少的都会用到。
什么是5Why
5why简单点说就是“打破砂锅问到底”，多问几个为什么，一直问到问题的根因。5why是丰田公司最先提出来的，也是质量管理领域一个重要的工具手段。
丰田汽车公司前副社长大野耐一曾举了一个例子来找出停机的真正原因：
★问题一：为什么机器停了？
答案一：因为机器超载，保险丝烧断了。
★问题二：为什么机器会超载？
答案二：因为轴承的润滑不足。
★问题三：为什么轴承会润滑不足？
答案三：因为润滑泵失灵了。
★问题四：为什么润滑泵会失灵？
答案四：因为它的轮轴耗损了。
★问题五：为什么润滑泵的轮轴会耗损？
答案五：因为杂质跑到里面去了。
经过连续五次不停地问“为什么”，才找到问题的真正原因和解决的方法，在润滑泵上加装滤网。
如何运用5why
5why方法看起来是比较简单，一直往下问，直到问到根因为止，但是在实际应用中有些方面需要注意，否则可能得不到主要问题的根因：
1、问题和答案都应该是客观的，不能是主观的
2、区别问题的症状和原因
3、注意问题分析对事不对人，最终原因不能归结为人的疲劳、疏忽等
4、最好是能有一个团队一起分析，查找5why
5、问题不一定正好是5个，有的情况下可能要多问些为什么
6、需要从多个角度来问，最简单的从管理、技术两个角度来问
7、要抓住问题的主要原因，避免过度纠缠于次要原因
提问式会议
对于重大的问题，原因一般不止一个，如果没能抓住主要原因，就无法做到对症下药。一种可行的方式是采用提问式会议，大概的方法是：
**1、参加人: **5~6人
2、工具：白板和笔
3、步骤：
1）将问题的整个过程向参加者说明清楚；
2）每个人问1~2个问题；
3）主持人组织大家投票选择出最重要的3个问题 （不同角度，横向）；
4）从这三个主要问题轮流进行追问。（纵向深入挖掘根因）
这种方式相对比较正规，耗费时间也比较长，但是通过这种有流程的讨论，更容易找到问题的根本原因，想出更好的对策。
很多运维工作是发现问题、找出问题根因、最终解决问题，这一过程又称“填坑”，找到问题根本原因是能否将“坑”填好填实，避免下次再掉坑里的重要前提，5why是一种分析问题的方法更是一种思维方式，值得多练多用。
