事件事后分析过程的重要性

事件事后分析的好处

如果您清楚事件起因，并且很确定问题已经解决，您可能会想跳过正式的事件事后分析会议和报告。

对您来说，这可能没错。但是，您的团队成员可能尚未了解事件起因，他们可以从您的透彻解释中受益，并改善他们对团队和客户的服务品质。

人们携手并进，参与结构化的协作流程。每个人都能发表心得体会，在团队中相互建立信任和韧性。记录事件内容以及团队如何对其进行补救，为未来发生此类事件时该如何处理提供参考信息。

您也可以向客户或组织的其他成员公开事件事后分析要点。对于在事件发生时未曾密切参与的人来说，这可大力帮助他们重拾信心。组织中的其他团队，尤其是领导层，可能需要查看问题的详细信息以及为解决问题而采取的步骤，以避免将来对您的团队进行二次猜测。

合作伙伴、客户和最终用户可能也想了解发生的情况，以及您采取了哪些措施来改善他们的体验。将事件事后分析公布到面向公众的网站上，这可能并非在所有情况下都适合，但您的营销或公共关系团队能够精心设计话术，以便人们充分掌握信息，并充分信任您的服务。

事件事后分析的最佳实践

您对待事件事后分析的方式与您所采取步骤的清单，这两者同等重要。事件发生后，紧张局势可能会加剧。为了让人们参与这个过程，并为解决棘手问题做好准备，最关键的是给予他们一种心理安全感。

建立无指责的文化

Etsy 前任首席技术官 John Allspaw 撰写了一篇关于“无指责事后分析”的开创性文章。这种调查事件的方法有助于事件相关人员详细阐述自己的所有行为、影响、事件内容以及事件发生时间，而无需担心受到惩罚或报复。

这种方法是确保团队公开分享信息并找出事件根本原因的关键。人们可能会因为害怕受到斥责，而隐瞒信息或试图转移指责。发生这类情况时，人们就会失去彼此的信任。而且，组织会失去在其团队和系统中建立韧性的机会。为避免以上陷阱，包括 Atlassian 和 Google 在内的许多团队都开始采用无指责事后分析。

避免相互指责，保持建设性批评

在事后分析会议以及随后的调查结果撰写过程中，您要避免使用指责个人应对事件负全责的措辞。相反，应专注于行动、结果和影响。

虽然保持对话的安全性和客观性很重要，但找出事件的根本原因对于解决问题也至关重要。您可以在会议中运用一种名为“五问法”的技巧。首先要确保每个人都同意问题的具体情况。然后，询问发生这种情况的原因，并追问导致以上原因的答案。重复至少五次，以确保您发现导致问题的所有深层因素。确保参与讨论的人不试图避开令人不安的事实或设法达成简单共识。您可以通过查阅我们的行动手册，了解有关“五问法”技巧的更多信息。

对每一次事后分析进行回顾，并融入您的进程

事件事后分析报告未经回顾，也可能是因为从未撰写过。一旦起草事件事后分析报告，就必须对其进行回顾，以找出所有未解决问题，捕捉想法以供将来考虑，并最终确定报告。您甚至可以认为，只有经历过回顾，事件才算真正解决。

如何做到这一点？安排与工程部门（以及其他可能感兴趣的人，例如客户支持人员或客户经理）的定期会议，至少每月一次，以回顾事件事后分析报告。您可以选择回顾最近报告或更早的报告，并分享对今仍有意义的经验教训。

有效的事件事后分析计划

为了使事后分析有效，并帮助您建立一种持续改进的文化，您需要实施一个简单且可重复的流程，让每个人都能参与其中。如何做到这一点取决于您的企业文化和团队。在 Atlassian，我们开发了一套适合自身的方法，您可以阅读我们的事件手册来深入了解。

以下是一些入门技巧：

技巧 1：设置阈值

组织中事件的严重性级别应明确且可衡量。这些严重级别可用于触发事后分析过程。例如，任何 1 级严重性或更高级别的事件都会触发事后分析过程，而对于不太严重的事件，可以选择事后分析。对于任何未达到阈值的事件，考虑让团队领导或管理层有机会提出请求，对其进行事后分析。

技巧 2：避免延迟

适当休息很重要。事故发生后，休息一下。但不要间隔太久，才去撰写事件事后分析。等待时间过长，重要细节可能会丢失或遗忘。理想情况下，在事件解决后的 24 至 48 小时内会举行事件后回忆会议，事后分析将在事件后回忆会议之后立即起草，一般不超过五个工作日。

技巧 3：分配角色和负责人

在事件后回顾会议上，您将仔细讨论细节，并记录在事故事后分析中。最好将事后分析草稿委托给特定人员，最好是熟悉事件的人员，并且具备足够的技术水平和组织知识，能够理解事件原因和缓解措施。

技巧 4：使用模板工作

模板能够避免遗漏关键细节。这是在整个事后分析过程中保持一致性的好方法。

技巧 5：包括时间线

时间线对于事件记录非常有帮助。通常，当读者对情况进行快速估计时，首先看到的就是时间线。所以时间线尽量做到明确和具体。例如，应表示为“太平洋标准时间上午 11:14”，而不是“11 点左右”。将时间戳具体化，有助于绘制出高保真度的事件链，这对于确定需要改进的领域非常有用。例如，您可能会发现影响开始时间与客户收到通知的时间相隔太长。

要包括的重要时刻。

• 第一个警报或请求单
• 首次沟通公告（内部和/或外部）
• 状态页面更新时间
• 任何补救行为的时间（代码回滚等）
• 解决问题的时间

提示 6：细节、细节、细节

对于撰写于事无补且含糊不清的事后分析，略过细节是快速途径。针对事件期间的发生情况和所做工作，尽可能多地添加细节。与其说“公开沟通发布了”，不如说“我们在公开状态页面和 Twitter 帐户上发送了该事件的初步公开沟通公告。”

尽可能包含链接和名称，如请求单和状态更新的链接以及事件状态文档和监控图表的链接。大胆添加相关图形或仪表板的屏幕截图。来自监控系统的图表非常有价值，因为它清晰显示事件的开始和结束时间（例如，请求率下降后恢复正常）。如果将其与显示这段时间内幕后发生情况的图表（例如数据库连接、网络链接状态或同一时间段内的 CPU/内存/io/带宽消耗）结合使用，效果将更强大。

提示 7：捕获事件指标

在事后分析中捕获指标时，您会将硬数据应用于事件及其影响。拥有这些数据点有助于确定团队是否朝着正确方向前进，并减少事件数量、降低事件严重性和缩短停机期间。通过衡量一致性指标，您可以后退一步，查看一段时间内的事件趋势。

事后分析追踪中需要考虑的一些指标：

• 停机期间的分钟数，您可以跟踪此数字在上升还是下降
• 事件的严重性，您可以确定系统的相对可靠性。
• 平均解决时间 (MTTR)，用于衡量从最初报告事件到事件被解决所经历的平均时间。

最重要的提示？不要跳过任何步骤。进行事件事后分析的关键在于，要有一个流程并坚持下去，才能帮助您提升团队和系统能力。

使用事件事后分析模板，简化流程

为了确保团队形成事件事后分析审查的习惯，请保证成员能够轻松捕获信息、安排会议，并使用可重复利用的清单和模板发布最终报告。可重复的流程能提供一致性，帮助人们预判未来，并以富有成效的心态开启流程。

事件事后分析流程的典型清单项目：

需要召开的会议：

• 信息收集会议
• 报告审查
• 报告陈述

需要提前收集的信息：

• 每次会议的标准议程
• 参与者、利益相关者、审查人员
• 使用模板标准化事件事后分析报告撰写