如何进行无指责事后分析

事件事后分析注重的是成长，不玩责备游戏

大多数公司每年至少经历几次重大事件。

我们可以努力预防事件，减轻其影响，并缩短其持续时间。但它们或许不会很快完全消失。

好消息是，事件也是一种学习机会。它令我们有机会发现系统中的漏洞，防止将来再次发生事件，完善流程以减轻事件影响，以及在将来构建更好的软件。

从事件吸取经验教训的最好途径是开展事后分析。在 Atlassian，我们采用的是无指责事后分析。

什么是无指责事后分析？

事件事后分析将团队召集在一起，更深入地研究事件，弄清楚发生了什么、原因是什么、团队是如何响应的，以及可以做些什么来防止事件再次发生并改善未来的应对措施。

无指责事后分析在不玩任何责备游戏的前提下完成所有这些工作。

在无指责事后分析中，假定每个团队和员工都本着善意依据当时掌握的信息做出行动。无指责事后分析注重的是改进未来的表现，而不是找出和惩罚搞砸事情的人。

无指责事后分析有无可能？

对无指责事后分析的主要批评之一是它们根本不可能。毕竟，责备和评判是自然而然的。而且问责是成功运营团队的重要组成部分。批评者认为，无指责事后分析就像一场尴尬的家庭聚餐，每个人都试图强颜欢笑而不说出自己的真实想法。

这些批评断定，无指责事后分析的目标是让那些应当对事件负责的人感觉好些，这个目标可能会扼杀真正的对话和问责。

但是，无指责事后分析的真正用意是消除对表现愚蠢、受到谴责甚至失业的恐惧，最终目标是鼓励诚实、客观和以事实为中心的沟通，从而带来更好的未来结果。

例如，假设导致事件发生的原因是员工 A 错误地假定员工 B 部署了修复程序。与其将事后分析花费在试图弄清楚最终应归咎于员工 A 还是员工 B，不如开展无指责事后分析，让每位员工逐步排演自己的工作流程和思维过程，尽力深入探究问题的核心。

通过排演整个过程，我们可以找到能够改进的地方。也许是我们的培训流程效果不佳。也许是文档令人感觉困惑。又或是我们可以想办法在技术系统中建立相互制衡，让员工不必记得应该去找谁核查。

重点不是说无指责事后分析永不排查是谁犯了错。而在于，无指责为沟通开启了大门，并且承认 IT 事件是复杂的，并且可能有多种方法在以后做出改进，而不是羞辱或解雇员工 A。

有效的无指责事后分析有何价值

对许多人来说，无指责事后分析可能需要转变文化。但以我们的经验来看，收益大于实现目标所需的付出。无指责事后分析能够：

· 在团队之间营造健康向上的文化

如果我们不去指责其他团队，就能更有效地协同工作，清晰而无畏地沟通，并且对周围团队抱有同情心。

· 降低因害怕被指责而忽视事件的几率

如果事件不会导致公开受辱或解雇，员工更有可能就该事件进行沟通，提请相关团队注意，并对未来修复分享想法。如果可能会失业，那么心思就是缄口不言、袖手旁观。

· 营造保持开放、不断进取的学习文化

无指责事后分析鼓励团队逐步讨论出了什么问题，并集思广益改进想法。他们还承认，事件是复杂的，是人都会犯错。让员工接受学习和改变，而不是因为害怕承担后果而捍卫自己的选择。

· 加强支持和沟通

如果员工 A 和 B 不必因为发生故障而互相指责，那么他们的关系可能会更加牢固。消除恐惧可以缓解压力，给予人们互相支持的机会。

· 有助于团队实现最佳工作成果

看着队友因失误而受到指责、羞辱甚至被解雇，其他员工会丧失信心，更加畏惧于自己的工作。这可能会拖累运营，给未来进展造成阻碍。

无指责文化的最佳实践

要想成功实施无指责事后分析，首先为无指责文化奠定基础。您可以从这些方面着手：

提前传达一种开放且宽容错误的方法

确保团队在开会之前就知道这不是一次猎巫行动，而是公司学习和改进的机会。大家可以坦诚对待假设、误会或过失，不必担心遭到报复。

鼓励诚实和接受失败

那些批评者说无指责事后分析没有足够的问责？这就是他们错误之处。事后分析应该鼓励诚实和问责。消除对承担后果的恐惧，可使人们坦诚对待自己的失误和误解。而这是改正错误的唯一方法。

共享信息和制定时间线

在开始挖掘事件之前，请确保每个人对实际发生的事情有一致的认识。误解核心问题可能会使事件事后分析很快脱轨。这正是制定事件时间线的重要性所在。

秉持无指责文化

如果一个事后分析是无指责的，其他则不是，那么消除恐惧和加强开放就行不通了。

获得高管支持

对于大多数组织来说，无指责事后分析将是一场文化变革。在开始之前，一定要与公司领导交流，帮助他们了解无指责事后分析和无指责公司文化的好处。只有获得最高层支持，文化转变才可实现。

协作

即使团队没有直接参与事件，也可以在事后分析中得到一些收获或贡献一份力量。

邀请不同团队参与事后分析，可以促进跨团队协作并带来更多视角，最终也会改善事件管理。邀请安全和隐私团队、法务或风险与合规团队的人员，可以帮助确定以前未知的成因、现有流程中的其他潜在隐患，以及其他团队可以改善其对技术系统和流程的支持方式。

做出决定，但要获得批准

良好的无指责事后分析应当能形成一些建议，帮助预防未来的事件。确保找到负责批准建议行动和亲自审核文档的人。

在 Atlassian，这由部门级工程主管担当。他们负责审查结论，并在事后分析之后确定议定行动和缓解措施的优先顺序。

一个无指责事后分析的成功故事

那么，无指责事后分析确实能改善结果吗？在 Atlassian 内部，所有迹象指向肯定答案。

几年前，某工程师在关键设备的配置文件中犯了一个严重语法错误，使整个公司瘫痪了 45 分钟。如果量化一下，那就是数十万美元。

但是，我们没有去羞辱这位工程师，而是开展了无指责事后分析。因为我们的目标不是因为犯错而惩罚一个人，而是弄清楚是不是有办法避免未来犯同样的错误。是人都会犯错，这无法避免。问题在于，我们该如何减少人为错误发生的可能性？想要回答这个问题，我们需要知道发生的事情和具体的原因。

最后，通过一个简单的永久修复，在加载配置文件之前对其进行自动的‘是否启动’检查，最终消除与系统配置的所有人工交互。如今，导致这次中断的问题已通过一个快速技术修复来避免。涉事的工程师仍在 Atlassian 工作，为我们团队增添许多价值。

在 Atlassian，我们热衷于简单并可重复的流程，无指责事后分析也不例外。我们总结了一个对我们来说行之有效的流程，您可以从这里找到分解，或在我们的事件手册中进一步了解它。