事故分析的趋势和行为

Eric Siegler 是 PagerDuty 公司 DevOps 的负责人，他在上个月于伦敦举办的 Velocity 大会上发表了一份报告，分析了来自125 个不同组织在六个月的时间内的1000 份事故分析（post-mortems）【译注1】。他分析出的主要的趋势包括：无可非议的事故分析的普遍性；仅有1/100 的事故分析源于“人为错误”；以及对事件生命周期的分析可以提供对事件响应过程中相关弱点的深入见解。

由于信息是经由PagerDuty 的事故分析构建器功能从客户端处匿名收集(并保存) 的，Sigler 挖掘了这些数据，寻找常见的人名，结果发现一半的事故分析中都没有出现人名。Sigler 强调说，另外的一半数据中出现了人名也并不一定意味着存在一种指责文化，因为数据可能会以其他方式被曲解；例如，事故分析报告中提及了一个名为“Bob”的服务器（这种情况下，“Bob”也会被识别成人名，但其实是服务器的名字）。

至于明确提到的“人为的错误”，它作为事故被审查的一种可能的原因，经由Sigler 调查，他发现几乎没有证据可以证明事故分析的原因源于“人为错误”（只有1% 的事故分析与“人为错误”有关）。Sigler 以去年3 月的AWS S3 的故障为例强调了这一点，该事件的事故分析并没有声明人为错误是导致故障的一个原因，但媒体的报道却泛泛地将其原因归咎于个人。

收集到的数据还表明，许多组织花费了大量的精力来详细说明事件的时间线（并且很多事故分析都不包含任何关于其他方面的文本信息）。Sigler 警告说，尽管了解被审查的事故是一项有用的练习，但跟踪常见事件的状态转换（启动、自检、改进、解决）可以得到更好的见解以改善整个响应过程。例如，在启动状态和自检状态之间的不断重复就对我们的监测和仪器的正确性提出了疑问。在启动状态和自检状态之间的不断重复可能表明在组织中的知识共享和职责分配方面存在瓶颈，或者仅仅是因为积累了太多的技术债务导致了系统的失败。

Sigler 的另一发现是，大多数的组织平均每月进行事故分析的次数不足一次。有三分之一的组织会在事故后的 24 小时内进行事故分析，还有三分之一的组织会在事故后的一星期内进行事故分析，剩下的那部分在一周后才会进行分析（这样通常很难能克服选择性遗忘）。

Sigler 还强调说，这只是一个小型的数据集，所以分析出结果可能会偏向于一些已经具有完备事故分析过程的组织，因次它们的运营看起来似乎更为成熟。

最后，Sigler 给观众提供了许多建议。首先，事故分析对于检查过程改进是否有助于消除系统中的错误很有帮助，另外，如果我们反复遇到相同的问题，事故分析也能起到很好的作用。其次，事故分析可以发现组织问题，因此，对事故分析结果的应用不能仅仅局限于技术改进。

想要了解更多关于建立事故分析过程的信息，请参考 PagerDuty 关于事故分析过程以及事故分析模板或者 Etsy 事故分析实践的相关内容。Etsy 同样开源了他们的数据收集和事故分析追踪工具。

译注1：post-mortems，事故分析，又称事故复盘。当任何生产系统发生严重停机或类似事故时，所涉及的人员都必须写一份事故分析文档。文档描述事故，包括标题、摘要、影响、时间表、根本原因、什么工作/ 什么没有和行动项目。文档的重点是问题本身，以及如何在未来避免他们，而不是针对人或分摊责任。

查看英文原文： Post-Mortems Trends and Behaviors