左耳听风_019_18_故障处理最佳实践故障改进
你好，我是陈浩网名做耳朵耗子。
在上节课呢我跟你分享了在故障发生的时候啊，我们该怎么做？还有呢就是在故障发生之前啊，就该做一些什么准备。
只要做到我提到的那几点啊，你基本上就能游刃有余的处理好故障。
但是呢在故障排除之后，怎么做故障复盘和整改优化是更加重要的那在这节课中呢，我就来跟你聊一聊这几个方面的内容。
我们先来讲一故故障复盘的过程。
对于故障来说啊，复盘是件非常重要的事情。
因为我们的成长基本上就是从故障中总结各种经验教训，从而可以获得最大的提升。
在亚马逊和阿里呢面对故障的复盘有不一样的流程，虽然内容差不多，但是在细节上有很多的不同。
在亚马逊内部呢，面对s一和s二的故障复盘，需要故障所在的团队经理写一个叫COE的文档。
那这个COE文档基本上来说要包括这几个方面的内容啊，第一呢是故障处理的整个过程啊，就像一个log一样，需要详细的记录，几点几分干了什么事儿。
把故障呢从发生到解决的所有细节过程都记录下来。
第二呢是故障原因分析，需要说明故障的原因和分析报告。
第三呢是ask five wise,意思就是需要反思啊，反问至少五个，为什么，并且啊要给这些，为什么找到答案。
另外呢就是故障的后续整改计划，需要针对上面的ask five once啊，说明后续应该怎么举一反三呢？从根本上解决所有的问题。
然后呢，这个文档要提交到管理层向公司的VP级的负责人进行汇报，并且啊由他们来审查。
所以阿里呢会有故障复盘的会议啊，会把所有的相关人员啊都叫到现场去进行复盘。
啊，我比较喜欢这样的方式，而不是亚马逊的让经理来操作这个事的方式。
虽然说阿里的故障复盘会议啊会开很长的时间，但是把大家叫在一起复盘的确是一个很好的方式。
一方面信息是透明的那另一方面呢也是对大家的一次教育。
那阿里的故障处理内容呢和亚马逊呢很相似啊，只是没有us five wise.但是呢加入了故障等级和故障责任人，对于比较大的故障责任人啊，基本上都是由p九或者m四的人来承担。
而且对于引发故障的直接工程师啊，阿里是有相关的惩罚机制的。
比如全年没有加薪，没有升职或者罚款。
有实话呢，我对惩罚故障责任人这样的方式啊非常不认同。
首先呢惩罚故障责任人对于解决故障完全没有任何帮助。
那如果他们之间啊没有因果关系，既不是充分条件件，不是必必条件件，不是充充条件件，这是逻辑上的错误。
其次呢做的越多，错的越多。
那如果不想出错，最好就什么也不要做。
所以呢惩罚故障责任人啊只会让大家都很保守。
首以让大家都学会保守其且啊开始推诿营造一种恐怖的气氛。
啊，这里呢我说一个小插曲，有一次呢我和一个同学一起开发一个系统，我们两个人的代码在同一个代码库中，而且呢也会运行在同一个进程里。
那这个系统中啊有一个线程池模型，我就想直接用了。
结果呢因为这个线程池是那个同学写的，他死活不让我用，说是各用各的分开写啊，以免出了问题，说不清楚，引起不必要的麻烦。
最后呢在一个代码库中实现了两个线程式模型啊，我也是很无语。
另外呢，亚马逊和阿里的故障整改内容不太一样。
亚马逊更多的是通过技术的手段来解决问题啊，几乎没有增加更复杂的流程，或者是把现有的系统复杂化。
而在阿里的故障整改中呢，会有一些复杂化问题的整改项，比如对误操作。
那他的处理方式呢是以后线上操作都需要有两个人来完成其中一个人操作。
另一个人呢检查操作过程，或者对于某些流程需要有审批环节。
那再比如不去把原有的系统改好，而是加一个新的系统，来管着原来那个不好的系统。
呃，当然啊也有一些整改措施是好的，比如通过灰度发布系统来减少故障面积。
那故障到底应该怎么整改呢？就故障整改方法来说呢，我比较喜欢亚马逊的那个us five wice的玩法，这个对于后面的整改啊会有非常大的帮助。
最近一次呢我帮一家公司做一个慢sql的故障复盘，我一共啊问了近九个，为什么？首先第一点啊，为什么从故障发生到系统报警，花了二十七分钟，为什么只发邮件没有短信？第二，为什么花了十五分钟开发的同学才知道是mysql的问题。
第三，为什么监控系统没有监测到n这个四九九错误，以及n这x的upstream response time和request time.第四点，为什么一开始按d dos处理了？那第五为什么要重启数据库？第六，为什么这个故障之前没有发生？第七，为什么上首页的时候没有做性能测试？第八为什么要使用这个高危的sql语句？那最后呢上线的过程中啊，为什么没有DBA评审？通过这九个，为什么我给这家公司整理出来很多不足的地方，提出这些问题的大致逻辑啊是这样的。
第一点是优化故障获知和故障定位的时间。
首先是从故障发生到我们知道的时间是否可以优化的更短。
其次呢，定位故障的时间啊是否可以更短。
最后呢有哪些地方可以做到自动化。
第二呢是优化故障的处理方式。
首先是故障处理时的判断和章法是否科学啊是否正确啊。
其次是故障处理时的信息是否全透明。
最后呢故障处理时人员是否安排得当。
第三点呢是优化开发过程中的问题。
最后呢call review和测试中的问题和优化点有哪些？那最后呢是软件架构和设计啊是否可以更短？最后呢对于技术欠债或者相关的隐患问题是否被记录下来了，是否有风险计划第四点呢是优化团队能力啊，首先是怎么提高团队的的技术能力，还有就是怎么让团队有严谨的工程意识，而具体采取什么样的整改方案，会和这些为什么有很大的关系。
呃，总之还是那句话，解决一个故障，可以通过技术和管理两方面的方法。
那如果你喜欢技术是个技术法，你就更多的使用技术手段。
那如果你喜欢管理啊，那么你就会使用更多的管理手段。
我是一个技术人员，所以我更愿意使用技术手段。
随后呢对于故障处理，我能感觉到啊一个技术问题，后面隐藏的是工程能力的问题。
而工程能力问题后面隐藏的是管理问题，管理问题后面呢隐藏的是一个公司文化的问题。
而公司文化的问题则隐藏着创始人的问题。
所以我在这里呢给出三条我工作这二十年总结出来的原则和供你参考。
第一条原则呢是举一反三的解决当下的故障，给自己赢得更多的时间。
第二条呢是简化复杂不合理的技术架构、流程和组织。
因为啊你不可能在一个复杂的环境下根本的解决问题。
第三条原则呢是全面改善和优化整个系统和包括组织解决问题的根本方法，是改善和调整整体结构。
那只有简单优雅的东西才有被改善和优化的可能。
换句话说啊，我看到很多问题出了右厨换着花样的厨。
那大多数情况下呢，是因为这个公司的系统架构太过复杂和混乱，以至于你不可能在这样的环境下干干净净的解决所有的问题。
所以呢你就先要做大扫除，简化掉现有的复杂和混乱。
那如果你要从根本上解决一个事儿，那么首先呢就得把它简化了。
啊，这就是我这么多年来啊得到的认知。
但是很不幸啊，我们就是生活在这么一个复杂的世界，有太多的人啊喜欢把简单的问题复杂化。
所以呢要想做到简化啊，基本上来说啊是非常非常难的。
文中这里呢有个小视频很有意思，非常形象的说明了想在一个烂摊子中解决问题，几乎是不可能的事儿。
那在这节课的末尾呢，我想再发个邀请给你，请你在评论区里聊一聊啊。
在处理好故障之后，你所在的企业会采取什么样的付盘方式？。