故障处理佳实践改进.pdfVIP

18|故障处理最佳实践：故障改进

2017-11-30

18|故障处理最佳实践：故障改进

朗读人：柴巍08′27′′|3.88M

在上篇文章中，我跟你分享了，在故障发生时，我们该怎样做，以及在故障前该做些什么准备。只

要做到我提到的那几点，你基本上就能游刃有余地做好故障处理了。然而，在故障排除后，如何做

故障复盘及整改优化则更为重要。在这篇文章中，我就跟你聊聊这几个方面的内容。

故障复盘过程

对于故障，复盘是一件非常重要的事情，因为我们的成长基本上就是从故障中总结各种经验教训，

从而可以获得最大的提升。在亚马逊和阿里，面对故障的复盘有不一样的流程，虽然在内容上差不

多，但细节上有很多不同。

亚马逊面对S1和S2的故障复盘，需要那个团队的经理写一个叫COE（CorrectionofErrors）

的文档。这个COE文档，基本上包括以下几方面的内容。

故障处理的整个过程。就像一个log一样，需要详细地记录几点几分干了什么事，把故障从发生

到解决的所有细节过程都记录下来。

故障原因分析。需要说明故障的原因和分析报告。

Ask5Whys。需要反思并反问至少5个为什么，并为这些“为什么”找到答案。

故障后续整改计划。需要针对上述的“Ask5Whys”说明后续如何举一反三地从根本上解决所有的

问题。

然后，这个文档要提交到高层管理层，向公司的VP级别进行汇报，并由他们来审查。

阿里的故障复盘会会把所有的相关人员都叫到现场进行复盘。我比较喜欢这样的方式，而不是亚马

逊的由经理来操作这个事的方式。虽然阿里的故障复盘会会开很长时间，但是把大家叫在一起复盘

的确是一个很好的方式。一方面信息是透明的，另一方面，也是对大家的一次教育。

阿里的故障处理内容和亚马逊的很相似，只是没有“Ask5Whys”，但是加入了“故障等级”和“故障责

任人”。对于比较大的故障，责任人基本上都是由P9/M4的人来承担。而且对于引发故障的直接工

程师，阿里是会有相关的惩罚机制的，比如，全年无加薪无升职，或者罚款。

老实说，我对惩罚故障责任人的方式非常不认同。

首先，惩罚故障责任人对于解决故障完全没有任何帮助。因为它们之间没有因果关系，既不是充

分条件，也不是必要条件，更不是充要条件。这是逻辑上的错误。

其次，做得越多，错得越多。如果不想出错，最好什么也不要做。所以，惩罚故障责任人只会引

发大家都很保守，也会引发大家都学会保守，而且会开始推诿，营造一种恐怖的气氛。

说个小插曲。有一次和一个同学一起开发一个系统，我们两个的代码在同一个代码库中，而且也会

运行在同一个进程里。这个系统中有一个线程池模型，我想直接用了。结果因为这个线程池是那个

同学写的，他死活不让我用，说是各用各的分开写，以免出了问题后，说不清楚，会担上不必要的

责任。最后，在一个代码库中实现了两个线程池模型，我也是很无语。

另外，亚马逊和阿里的故障整改内容不太一样。亚马逊更多的是通过技术手段来解决问题，几乎没

有增加更复杂的流程或是把现有的系统复杂化。

阿里的故障整改中会有一些复杂化问题的整改项，比如，对于误操作的处理方式是，以后线上操作

需要由两个人来完成，其中一个人操作，另一个人检查操作过程。或是对于什么样的流程需要有审

批环节。再比如：不去把原有的系统改好，而是加入一个新的系统来看（kān，第一声）着原来的

那个不好的系统。当然，也有一些整改措施是好的，比如，通过灰度发布系统来减少故障面积。

故障整改方法

就故障整改来说，我比较喜欢亚马逊的那个Ask5Whys玩法，这个对后面的整改会有非常大的帮

助。最近一次，在帮一家公司做一个慢SQL的故障复盘时，我一共问了近9个为什么。

1.为什么从故障发生到系统报警花了27分钟？为什么只发邮件，没有短信？

2.为什么花了15分钟，开发的同学才知道是慢SQL问题？

3.为什么监控系统没有监测到Nginx499错误，以及Nginx的upstream_response_time和

request_time？

4.为什么在一开始按DDoS处理？

5.为什么要重启数据库？

6.为什么这个故障之前没有发生？因为以前没有上首页，最近上的。

7.为什么上首页时没有做性能测试？

8.为什么使用这个高危的SQL语句？

9.上线过程中为什么没有DBA评审？

通过这9个为什么，我为这家公司整理出来很多不足的地方。提出这些问题的大