情绪问题往往会在发生事故时凸显出来。在做免责事后剖析（blameless post-mortems）中，心理安全对于从事故中汲取经验教训至关重要。事后剖析会必须完全适度，最好由局外人主持，并让每位与会者轮流发言，避免妄加批评。在对事故的实际发生情况达成明确的共识之前，不要着手去分析事故。
在Atlassian 欧洲 2018 峰会上，Adaptavist 公司的 DevOps 主管Matt Saunders做演讲介绍了免责事后剖析中的心理安全问题。InfoQ 以问答、汇总报道和文章覆盖大会全程。
InfoQ 采访了 Saunder，问答内容涉及：应于何时开展免责事后剖析、免责事后剖析与敏捷回顾（retrospective）的差异之处、如何处理好情绪问题、如何让事后剖析会的每位与会者具有安全感，以及如何有效地开展免责事后剖析。
InfoQ：您建议应于何时开展免责事后剖析?
Matt Saunders： 最好的回答是：在每次发生导致客户服务中断事故时，都应该做事后剖析。此外，还应该百分之一百地确保事故的完全免责。对运行事故的分析很容易演变为揪出追魁祸首，但问题的根源却很少在此。当有人犯了错误时，如果我们不去分析为什么会将该人置于可能出错的位置，那么我们就会犯短视的错误。因此，每次发生事故时，甚至是出现意外情况时，都应该做免责事后剖析。
InfoQ： 敏捷回顾和免责事后剖析这两者间存在着哪些差异和类似之处？
Saunders： 两者使用的一些技术非常相似。敏捷回顾的一个关键原则是从团队的角度分析已发生的事情，事后剖析也是如此。然而，事后剖析通常是在困难的环境下开展的。例如，企业因服务中断而发生了客户流失，为此大家诚惶诚恐，并且开始查找原因。当然，有时在敏捷回顾中也会存在类似的压力，但是事后剖析常常是在充斥压力和步步紧逼方式下开展的。
InfoQ：您在演讲中深入探讨了情绪对事故处理以及对工程人员的影响。您能否再展开介绍一下。
Saunders： 工程师总是希望能正确做事。这不仅仅关乎职业自豪感，而且由于人们在一些情况下很难保持冷静，尤其是发生事故时，因此情绪也往往会发作。每个人都希望能尽快解决服务中断问题，因而表现出情绪激动，大喊大叫。人们会带着情绪去重新审视那些在很久以前做出的决定，通常这样毫无裨益。理查德·库克（Richard Cook）博士有一篇广为引用的论文，“复杂系统是如何发生失败的”（How Complex Systems Fail）。该论文解释了计算机系统为何变得非常复杂。后见之明通常会令事后剖析产生偏差，导致人们感到愚蠢、心怀戒备，甚至会导致他们的职位受到威胁。在开展事后剖析时，应将这些问题铭记于心。
InfoQ： 在免责事后剖析中，存在哪些可能出错的关键因素？
Saunders： 一个常见的问题是预判输出结果。当导致问题的现实情况非常复杂时，我们在前面提到的那些后见之明会导致事后剖析给出存在明显问题的结论。另一类常见问题是情绪反复无常和人们自行其是，此外还应该考虑到高层员工的影响问题。或许一位雇员在经理在位的情况下，他（她）会依照经理的建议做事，而经理的建议最终被证明是错误的。这会令员工处于两难境地，他（她）会感觉到无法自由地发表意见。
此外，强加于团队的组织约束可能也会导致错误。部署或许会出错，因为部署是由一位中心团队的员工执行的，而中心团队不了解该系统与其它系统间存在的一些关键差异。虽然该可导致事故的因素并非团队可控制的，但仍然需要加以考虑。
InfoQ： 如何能让每位参与者在整个过程中具有安全感？
Saunders： 关键在于我们是对事故而非犯错误者做事后剖析（如果的确是由单一问题引发的事故）。应该从此着手并以此为中心开展事后剖析。关键一点是，应从一开始就澄清这是团队或组织的一次学习过程，而不是开批斗大会。
责备他人并不是一种好的做法，对此人们目前已形成共识，因为这可能会导致人们日后在做事时畏手畏脚。不敢去运维系统，系统运行的顺畅性普遍放缓。反之，正确的做法应该是以如何改进团队流程的学习过程作为事后剖解的基础，使得系统帮助运维人员避免再次犯错误。
如果我们能够将工作场景设置为这种方式，并且让高级利益相关者确信输出结果就是如此，那么人们将会具有安全感，愿意为组织做出贡献，并帮助组织设计更适用于未来的系统。
InfoQ： 要有效地开展免责事后剖析，您有哪些建议？
Saunders： 应确保会议的正确组织。最好是由一位局外人主持，并让每位与会者轮流发言，避免妄加批评。并且在大家对事故的实际发生情况达成明确共识之前，不要着手去分析事故。会议应分为三个阶段，即对时间表达成共识、对问题出现位置达成共识，以及更关键的是，对需要采取哪些措施来防止问题的再次发生达成共识。这是一种开展免责事后剖析的好做法。
注册/登录 InfoQ 发表评论