非指责性事后调查

阅读数:535 2014 年 8 月 15 日

话题:DevOps语言 & 开发文化 & 方法

非指责性事后调查

对于生产事故的非指责性事后调查日益被当成组织程序中不可或缺的一环。Travis CIMathias Meyer分享了非指责性事后调查Blameless post-mortems)是如何彻底地影响了他。InfoQ 趁此机会对诸如 Etsy、GitHub 和 Chef 这样的组织是如何进行事后调查的进行了探讨。

非指责性事后调查聚焦于从事件当中吸取教训。John Allspaw 这样写道

(在 Etsy,)我们希望从学习的角度去看待失误、错误、过失、疏忽。对服务中断和生产事故采取非指责性事后调查是其中的一环。

Mathias Meyer 是这样描述非指责性事后调查的:

(……)一个所有相关方都必须出席的会议。人们在会议上汇集对意外事件发生期间和之后的状况和看法。

其主要目标是找到事故是什么、如何及为何事故会发生。调查必须得出可操作的措施,以防止类似事情重复发生。

非指责性事后调查假设人性总的来讲是有好意的。如果不秉持这样的假设,组织就会试图指责某人。如果是这样的话,技术人员为了躲避惩罚,会隐藏一些信息,那么在未来类似的事情一定会再次发生。如 John Allspaw 指出的,组织有必要“平衡安全性和问责制”:

我们相信,在 Etsy 这个细节对于提高安全性是极为重要的。

Mathias Meyer 认为“人为错误”这个概念应该被摒弃:

它对于找出问题和解决方案没有什么帮助。它假设出问题的、以及需要解决的是在组织中的人。(……)在(复杂)系统中人们触发的行为是无人预见也不可能预见的。

在几个案例中,GitHub今年早些时候的一次DNS 宕机说明了在复杂系统里引发一连串的故障是多么容易的一件事。GitHub 发布了一份事后调查,显示一次错误的 DNS 变更导致了文件服务器故障,进而导致路由层故障。报告指出了基础架构上的几个弱点和 6 个补救措施,没有一个是与导致该次宕机的那个行为相关的。

在另一个案例中,Chef以非常公开且非指责性的方式进行了事后调查,并通过 Google Hangout 进行了广播

确保补救措施的执行是至关重要的,否则整个过程就会失去它的目的。在Etsy有一个政策:这些事情“胜过工程师手头的任何其它工作,包括交付产品。”

根据 InfoQ 的报道,Etsy 开发了开源的Morgue,这是一个记录事后调查的应用。一份 Morgue 报告包含了与事故相关的所有信息,回答了事故是什么、如何及为何事故会发生,并包含了补救措施。该报告中的信息来源广泛,包括 IRC 日志、论坛讨论或监控图表。

一份Morgue事后调查报告,摘自该项目主页的案例

Mathias Meyer 发现非指责性事后调查对他本人和他的团队都有深远的影响。那么,你也做(非指责性的)事后调查吗?它对你和你的组织有什么影响吗?

【译注】

Post-mortem 原意指尸体解剖,引申为事后调查。Morgue 原意指停尸房、太平间,在译文中做不翻译处理。由此也可以看出引导事后调查的人员对待故障的态度:既然它(系统)已经”死”了,那么就做一个彻底的根源调查,而非头痛医头脚痛医脚,随便找个替罪羊了事。后一种态度是非常司空常见的。

查看英文原文:Blameless Post-Mortems


感谢赵震一对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。