事故复盘无疑是系统服务可用性管理或DevOps建设中很是重要的一个环节，可是如何作到高效，却很难。我这里对高效复盘的基本原则作一些阐述。安全
背景：网络
咱们先从最近的一则新闻提及，Google 在2020年12月14日凌晨发生一块儿全球Down机的事故，47分钟内Google帐号服务不可用，致使依赖该帐号服务的各类Google产品服务包括Google Cloud Console以及Gmail/Docs和Youtube等都不能正常的使用。看到有同窗搞笑说，SRE的圣经《SRE-Google运维解密》如今能够扔了。哈哈，固然这只是一句玩笑话。架构
其实如今的计算机系统是一个极其复杂，并且依赖不少的分布式系统，出现事故是在所不免的，关键是如何对待事故。是把它视为人为错误（Human Error）致使，找到那个事故负责人，而后对他进行处罚，但愿达到再也不犯错的目的，仍是接受事故是不可避免的事实，进而从各类系统架构设计上/流程设计和执行上进行容错性处理，把每次事故看成一次学习和改进的机会。这是一个传统IT公司和高绩效公司的关键区别之一。less
传统事故复盘：Blame Game 或者甩锅运维
咱们先来看看传统事故复盘是如何进行的吧？不少时候跟电视剧或者电影上审问犯人有些相似，一群人在一个房间里，把“嫌疑工程师”放到一个“Hot Seat”上，而后进行各类追问，来找出这个事故的根本缘由（Root Cause），并讨论采起什么行动计划来确保这种事情再也不发生。关键部分是对这个事故进行定级，和视事故的级别对事故人进行必定的处罚。此外还有一个长长的改进任务列表，列出各类长期或者短时间的任务，从流程上或者意识上避免再犯相似的错误。每每能看到一些诸如参加安全操做培训，之后线上操做更当心之类的改进事项。很遗憾任务列表上的任务每每不多获得跟进。分布式
这种复盘，是一种Blame Game（即甩锅游戏），是不适应现代快速发展的系统架构和云基础设施的要求的。在这种Blame Game的环境下，承担责任的工程师，会以一种沉重的心情来进行事故复盘，他最后会很不愉悦的快速接受责任认定，那么事故过程当中的各类场景不会获得很好的回放，也就不能充分说明当时的场景，同时由于快速得出结论，事故中涉及到的各类架构问题和流程问题不能获得很好的澄清，也不能在团队里面促成很好的知识传递。那么即便换了一我的，一样的事故是不能避免发生的。ide
我不太认同这种Focus在责任事故和负责人认定的Blame Game，由于如今的分布式系统各类依赖，很是复杂，出现事故是在所不免的。首先，其中的网络故障是很是难以免的，并且不可控。其次，硬件设备也是很是容易出错的，咱们在IDC中购买和使用的硬件，都是相对廉价的设备（相对于专有的可靠性很是高的硬件），出错率也是比较高的；最后，软件是人写的，是必定会出Bug的，即便咱们把各类操做都自动化，那些自动化的脚本也是人写的，也是会有Bug的。因此，在Google的SRE中写到，为何100%的可用性是不实际的目标。oop
另外，回到人为错误上，犯错误自己就是作创新性工做的不可避免的副产品。如今的竞争环境下，要求咱们以愈来愈快的速度进行迭代和试错。因此天天10+的部署也是很正常的一件事情。在这种状况下，若是惧怕事故，惧怕出错，是根本无法作到如此之快的开发部署上线的。由于在这种环境下，工程师会选择能尽可能少作就尽可能少作，能尽可能不作就不作，不会采起一些创新甚至冒险的方式。post
最后，DevOps的实施离不开一个信任和合做的文化，而这种文化的创建，是须要在开发团队（Dev）和运维（Ops）中创建起信任。很显然，甩锅游戏会极大的破坏这种氛围，致使没法真正创建起团队的信任，即便他们两个团队被强行捏到一块儿。学习
现代的事故回顾：Blameless PostMortems
那么，该如何进行高效的事故回顾呢？是不作了？仍是把事故回顾看成一个很轻松的游戏？都不是。正确的作法是本着很是严肃认真的态度，召集全部相关的人员，进行事故现场的回顾；而后进行认真的分析，对这种事故，咱们如何能更快的发现？如何能更快的定位和止损？如何从架构上作出改进，来作到自动容错？要点在于把每一次事故当作学习的机会。
咱们来一块儿看看业内如何作的吧。
2012年著名电商Etsy的CTO在他们的Blog上发表文章，题目是“Blameless PostMortems and a Just Culture”, 阐述Blameless PostMortems的重要性和实施方法。该CTO是John Allspaw，不错他就是在DevOps历史上很是著名的演讲Velocity 09上《10 deploys per day- Dev & Ops cooperation at flickr》的两个主讲人之一。他在该博文上描述在他们Etsy公司进行Blameless PostMortems的作法和考虑。为何要这么作呢？他解释：在事故回顾中，但愿涉及的工程师能给出现场的详细信息，便于发现系统弱点或者流程缺失之处，详细信息包括以下内容：
- 他观察到了什么现象
- 他作出什么样的判断
- 他采起什么样的行动
- 行动获得什么样的结果
这些信息都只有在不惧怕被惩罚的状况下才能详细的给出。由于认为本身将受到谴责的工程师没有动机去提供必要的详细信息，以了解该事故的详细缘由。而若是对事故如何发生的了解不足，换一我的还会继续发生。因此该办法并非保证工程师犯错误能够免除惩罚，而是更关注得到重要现场信息来持续对系统进行改进，避免错误重复发生。由于他相信，能得到真实的一手信息来诊断并确保事故不在发生，比起指责甚至处罚事故负责的工程师，对公司的长久利益更重要。
无独有偶，2015年Google发表的《SRE Handbook》中也专门提到如何作PostMortem，
这篇文档中https://sre.google/sre-book/postmortem-culture/给出他们作事故复盘的文化“Postmortem Culture: Learning from Failure”。还给出他们的模版（https://sre.google/sre-book/example-postmortem/）。在这个模版中，详细给出了事故复盘的各个部分，很是有用，能够参考。
总结：
最后说下，事故不可避免，事故复盘同时也是一个学习机会。
参考文档：
- Google对这次事故的官方说明 https://status.cloud.google.com/incident/zall/20013
- Blameless PostMortems and a Just Culture https://codeascraft.com/2012/05/22/blameless-postmortems/
- Postmortem Culture：Learning from Failure https://sre.google/sre-book/postmortem-culture/
- Google SRE postmortem Examples https://sre.google/sre-book/example-postmortem/