Close

针对高速团队的事件管理

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

事件难免发生。

事实就是如此。随着系统规模不断扩大,日益复杂,故障是难以避免的。

事件也是学习的机会。

这是发现系统漏洞的机会,也是减少事件重复发生并尽快解决问题的机会。是时候让您的团队成员齐心协力,规划下次如何做得更好。

事件事后分析,也称为“事后回顾”,是研究事件期间发生情况并总结经验教训的最佳方法。

事后分析可将人们聚集在一起以便讨论事件的细节:为什么会发生,产生的影响,采取了哪些措施来减轻影响和解决事件,以及如何才能防止事件再次发生。

得益于版本控制、功能标记和持续交付等工具,许多事件可以快速“撤消”。许多事件是由推送至生产环境的变更中某一错误引起的,回滚该变更即可重新启动并运行应用。这有助于快速恢复服务,对每个人来说都大有裨益。但通常情况下,它无法帮助您了解具体的故障和原因。而这正是事后分析的用武之地。

事件事后分析是从事件中吸取教训并将问题转化为进展的框架。它还可以与客户、同事和最终用户(基本上指受事件影响的人)建立信任,让他们知晓您的团队正全力以赴地减少未来发生类似事件的次数及其影响。

事后分析周期图示

事后分析是始终在线服务生命周期中的重要一步。事后分析结果应该直接反馈到规划流程中,以确保事后分析中确定的关键修复能在未来的工作中实施,并与其他即将开展的工作和优先级保持平衡。

事件事后分析的好处

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

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

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

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

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

事件事后分析的最佳实践

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

建立无指责的文化

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

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

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

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

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

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

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

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

有效的事件事后分析计划

为了使事后分析有效,并帮助您建立一种持续改进的文化,您需要简单且可重复的流程,以供所有人参与。如何做到这一点,将取决于您的管理文化和团队配合程度。在 Atlassian,我们开发了一套适合自身的方法,您可以阅读我们的事件手册来深入了解。

以下是一些入门技巧:

技巧 1:设置阈值

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

技巧 2:避免延迟

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

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

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

技巧 4:使用模板工作

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

技巧 5:包括时间线

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

要包括的重要时刻。

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

提示 6:细节、细节、细节

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

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

提示 7:捕获事件指标

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

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

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

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

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

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

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

需要召开的会议:

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

需要提前收集的信息:

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