171023 5 whys

引用自 http://coolshell.cn/articles/17680.html

一般说来，故障都需要反思，在Amazon，S2以上的故障都需要写COE（Correction of Errors），其中一节就是需要Ask 5 Whys，我发现在Gitlab的故障回顾的blog中第一段中也有说要在今天写个Ask 5 Whys。关于Ask 5 Whys，其实并不是亚马逊的玩法，这还是算一个业内常用的玩法，也就是说不断的为自己为为什么，直到找到问题的概本原因，这会逼着所有的当事人去学习和深究很多东西。在Wikipedia上有相关的词条 5 Whys，其中罗列了14条规则：

• 你需要找到正确的团队来完成这个故障反思。
• 使用纸或白板而不是电脑。
• 写下整个问题的过程，确保每个人都能看懂。
• 区别原因和症状。
• 特别注意因果关系。
• 说明Root Cause以及相关的证据。
• 5个为什么的答案需要是精确的。
• 寻找问题根源的步骤，而不是直接跳到结论。
• 要基础客观的事实、数据和知识。
• 评估过程而不是人。
• 千万不要把“人为失误”或是“工作不注意”当成问题的根源。
• 培养信任和真诚的气氛和文化。
• 不断的问“为什么”直到问题的根源被找到。这样可以保证同一个坑不会掉进去两次。
• 当你给出“为什么”的答案时，你应该从用户的角度来回答。

http://coolshell.cn/articles/17737.html
AWS对于后续的改进可以看出他的技术范儿。可以看到其改进方案是用技术让自己的系统更为的高可用。然后，对比国内的公司对于这样的故障，基本上会是下面这样的画风：

a）加上更多更为严格的变更和审批流程，

b）使用限制更多的权限系统和审批系统

c）使用更多的人来干活（一个人干事，另一个人在旁边看）

d）使用更为厚重的测试和发布过程

e）惩罚故障人，用价值观教育工程师。

这还是我老生长谈的那句话——如果你是一个技术公司，你就会更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题。（注意：这里我并没有隔离技术和管理，只是更为倾向于用技术解决问题）

最后，你是要建一个 “高可用的技术系统” ，还是一个 “高用的管理系统”？ ;-)