如何做一次高效的事故复盘?

语言: CN / TW / HK

事故复盘无疑是系统服务可用性管理或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/)。在这个模版中,详细给出了事故复盘的各个部分,非常有用,可以参考。

 

总结:

       最后说下,事故不可避免,事故复盘同时也是一个学习机会。

 

 

参考文档: