事故复盘无疑是系统服务可用性管理或DevOps建设中非常重要的一个环节，但是如何做到高效，却很难。我这里对高效复盘的基本原则做一些阐述。
背景：
我们先从最近的一则新闻说起，Google 在2020年12月14日凌晨发生一起全球Down机的事故，47分钟内Google账号服务不可用，导致依赖该账号服务的各种Google产品服务包括Google Cloud Console以及Gmail/Docs和Youtube等都不能正常的使用。看到有同学搞笑说，SRE的圣经《SRE-Google运维解密》现在可以扔了。哈哈，当然这只是一句玩笑话。
其实现在的计算机系统是一个极其复杂，而且依赖很多的分布式系统，出现事故是在所难免的，关键是如何对待事故。是把它视为人为错误（Human Error）导致，找到那个事故负责人，然后对他进行处罚，希望达到不再犯错的目的，还是接受事故是不可避免的事实，进而从各种系统架构设计上/流程设计和执行上进行容错性处理，把每次事故当作一次学习和改进的机会。这是一个传统IT公司和高绩效公司的关键区别之一。
传统事故复盘：Blame Game 或者甩锅
我们先来看看传统事故复盘是如何进行的吧？很多时候跟电视剧或者电影上审问犯人有些类似，一群人在一个房间里，把“嫌疑工程师”放到一个“Hot Seat”上，然后进行各种追问，来找出这个事故的根本原因（Root Cause），并讨论采取什么行动计划来确保这种事情不再发生。关键部分是对这个事故进行定级，和视事故的级别对事故人进行一定的处罚。此外还有一个长长的改进任务列表，列出各种长期或者短期的任务，从流程上或者意识上避免再犯类似的错误。往往能看到一些诸如参加安全操作培训，以后线上操作更小心之类的改进事项。很遗憾任务列表上的任务往往很少得到跟进。
这种复盘，是一种Blame Game（即甩锅游戏），是不适应现代快速发展的系统架构和云基础设施的要求的。在这种Blame Game的环境下，承担责任的工程师，会以一种沉重的心情来进行事故复盘，他最后会很不愉悦的快速接受责任认定，那么事故过程中的各种场景不会得到很好的回放，也就不能充分说明当时的场景，同时因为快速得出结论，事故中涉及到的各种架构问题和流程问题不能得到很好的澄清，也不能在团队里面促成很好的知识传递。那么即使换了一个人，同样的事故是不能避免发生的。
我不太认同这种Focus在责任事故和负责人认定的Blame Game，因为现在的分布式系统各种依赖，非常复杂，出现事故是在所难免的。首先，其中的网络故障是非常难以避免的，而且不可控。其次，硬件设备也是非常容易出错的，我们在IDC中购买和使用的硬件，都是相对廉价的设备（相对于专有的可靠性非常高的硬件），出错率也是比较高的；最后，软件是人写的，是一定会出Bug的，即使我们把各种操作都自动化，那些自动化的脚本也是人写的，也是会有Bug的。所以，在Google的SRE中写到，为什么100%的可用性是不实际的目标。
另外，回到人为错误上，犯错误本身就是做创新性工作的不可避免的副产品。现在的竞争环境下，要求我们以越来越快的速度进行迭代和试错。所以每天10+的部署也是很正常的一件事情。在这种情况下，如果害怕事故，害怕出错，是根本没法做到如此之快的开发部署上线的。因为在这种环境下，工程师会选择能尽量少做就尽量少做，能尽量不做就不做，不会采取一些创新甚至冒险的方式。
最后，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/