事后析误

什么是事后分析？

事后析误是对事件的书面记录，具体描述：

• 事件的影响。
• 为缓和或解决事件而采取的行动。
• 事件的根本原因。
• 为防止事件再次发生所采取的后续行动。

在 Atlassian，我们使用 Jira 事务跟踪所有的事后析误，以确保事后析误完成并得到批准。如果您的需求不太复杂，可以使用更简单的系统（比如 Confluence 页面）来跟踪每次事后析误。

为什么我们要进行事后析误？

事后析误的目标是：了解所有牵涉到的根本原因；记录事件以供日后参考并发现模式；制定有效的预防措施以减少再次发生的可能性或影响。

为了让事后分析能够有效减少重复事件，审查流程必须激励团队确定根本原因并予以解决。具体方法取决于您的团队文化；在 Atlassian，我们找到了适合我们的事件响应团队的方法组合：

• 面对面会议有助于推动适当的分析，并使团队在需要解决的问题上达成一致。
• 交付和运维团队经理给出对事后析误的审批，以此激励团队全面执行事后析误。
• 指定的“优先行动”具有商定的服务等级目标 (SLO)，可以是 4 周，也可以是 8 周，具体取决于服务；还有提醒和报告，以确保这些行动完成。

参与这一流程并确保流程有效，需要组织的各个层面做出贡献。我们的工程总监和经理决定了各自领域的行动决议的审批者和 SLO。这个体系只是进行编码并尝试执行他们的决策。

何时需要进行事后析误？

我们对严重性级别为 1 和 2 的事件进行事后析误。对于其他事件，事后析误是可选的。

在解决事务期间或之后不久，事后析误负责人会创建一个新的事后析误事务。

由谁完成事后析误？

故障服务的交付团队（在事件事务中拥有“失败服务”的团队）负责完成事后析误。该团队选择事后析误负责人并为他们分配事后析误事务。

• 事后分析负责人会一直通过起草和审批等工作推动事后分析的进行，直至结果发布为止。他们负责完成事后分析。
• 一个或多个事后析误审批者负责审查并批准事后析误，且应该在他们的待办事项列表中将后续行动列为优先任务。

我们有一个 Confluence 页面，上面按服务组列出了事后析误审批者的名单（强制和可选），服务组通常对应着 Atlassian 产品（例如 Bitbucket Cloud）。

如何跟踪事后析误行动？

对于事后析误产生的每一项行动，我们都：

• 在负责团队的待办事项列表中列出一项 Jira 事务。所有事后析误行动必须在 Jira 中进行跟踪。
• 将它们从事后析误事务链接到“优先行动”（针对解决根本原因）或“改进行动”（针对非根本原因的改进）。

我们使用 Jira REST API 构建了一些自定义报告，以跟踪每个严重性级别中有多少事件还未通过事后析误中的优先行动解决根本原因。各部门的工程经理会定期审查这份列表。

事后析误流程

执行事后析误流程包括：创建事后析误事务、召开事后析误会议、制定行动、获得批准以及（可选）通知结果。

事后析误负责人有责任通过以下任务执行事后析误：

1. 创建事后析误并将其链接到事件。
2. 编辑事后析误事务，阅读字段描述并填写字段。
3. 为确定事件的根本原因，使用“五问法”彻查因果链，直至找到真正的根本原因。
4. 安排事后析误会议。使用会议邀请模板邀请交付团队、受影响的团队和利益相关者。
5. 与团队会面并检查下面的会议安排。
6. 跟进负责的开发经理，以获得采取具体行动以预防此类事件的承诺。
7. 在负责团队的待办事项列表中针对每项行动提出 Jira 事务。将它们从事后析误事务链接到“优先行动”（针对解决根本原因）或“改进行动”（针对其他的改进）。
8. 在 Confluence 中查找相应的审批者，并将其添加到事后分析的“审批者”字段中。
9. 选择“请求批准”过渡，以请求指定审批者的批准。自动化功能将用审批者的说明作为对事务的评论。
10. 根据需要进行跟进，直至事后析误获得批准。
11. 如果事后析误获得批准，我们可以自动在 Confluence 中起草事后析误博文，供您编辑和发布。撰写事后析误博文可以分享您的深刻教训，这会增加事后析误的价值。

完成事后析误流程后，开发团队会根据团队的 SLO 确定行动的优先级，作为常规待办事项的一部分。

事后析误会议

我们发现将团队召集在一起讨论收获可以更深入地分析根本原因。我们的团队比较分散，因此我们通常通过视频会议进行，有时事件涉及很多人，就会以小组形式完成。

我们建议的议程：

1. 提醒团队事后析误是无指责的，并说明原因
2. 确定各项活动的时间表
3. 确定根本原因
4. 运用“开放式思维”制定行动 -“我们可以做些什么来防止日后发生此类事件？”
5. 问问团队“哪些方面做得好/哪些方面本来可以做得更好/我们在哪些方面比较幸运？”

建议的日历预约模板：

请和我一起进行 <事件链接> 的无指责事后析误。请参考 <事件摘要>。

事后析误的目标是：了解所有牵涉到的根本原因；记录事件以供日后参考并发现模式；制定有效的预防措施以减少再次发生的可能性或影响。

在本次会议中，我们将设法确定根本原因并决定采取哪些行动来缓解这些根本原因。

如果负责的开发经理不在会议室中，那么请避免在会议中承诺采取具体行动，因为这并不利于优先级决策。人们会对做出承诺感到有压力，并且没有完整的信息。相反，在会议结束后跟进负责的经理，以获得执行所确定的优先行动的承诺。

事后析误事务字段

我们的事后析误事务需要填写一系列的字段，以鼓励大家在召开事后析误会议前，收集与事件相关的所有重要详细信息。以下是一些如何填写这些字段的示例。

直接原因和根本原因

如果您正在撰写或阅读事后析误，则需要区分直接原因和根本原因。

• 直接原因是指直接导致此事件的原因。
• 根本原因是指在事件链中处于最要害位置的原因，对其进行更改将防止所有此类事件。

事后分析力图挖掘根本原因并决定如何最大限度地缓解根本原因。在事件链中找到最要害位置是事后分析的真正艺术。使用五问法之类的方法沿着事件链顺藤摸瓜，寻找根本原因。

以下是一些直接原因和根本原因的示例：

根本原因分类及其行动

我们使用这些分类对根本原因进行分组，并讨论针对每种分类的相应行动。

与依赖关系相关的根本原因

当您的服务因为依赖关系出现故障而发生事件时，故障所在位置以及根本原因取决于依赖关系是属于 Atlassian 内部还是第三方，以及对依赖关系性能的合理期望。

如果是内部依赖关系，则问“依赖关系的服务级别目标 (SLO) 是什么？”

• 依赖关系违反了它们的 SLO 吗？
  • 故障在于依赖关系，它们需要提高可靠性。
• 依赖关系遵守它们的 SLO，但您的服务仍然出现故障？
  • 您的服务需要增强弹性。
• 依赖关系没有 SLO？
  • 它们需要 SLO！

如果是第三方依赖关系，则问“我们对第三方依赖关系的可用性/延迟等的合理期望*是什么？”

• 第三方依赖关系超出了我们的期望（以一种糟糕的方式）吗？
  • 我们的期望不适当。
    • 我们是否能够确信它不会再次发生？例如，我们审查并同意它们的 RCA。在这种情况下，行动就是它们的 RCA。
    • 或者，我们需要调整我们的期望吗？在这种情况下，行动就是提高我们的弹性并调整我们的期望。
    • 我们调整后的期望不可接受？在这种情况下，我们需要以某种方式解决需求和解决方案之间的脱节，例如寻找其他供应商。
• 第三方依赖关系符合我们的期望，但您的服务仍然出现故障？
  • 在这种情况下，您的服务需要提高弹性。
• 我们真的没有期望吗？
  • 第三方依赖关系的负责人需要建立期望，并与团队共享，以便他们知道需要在其有依赖性的服务中构建哪种级别的弹性。

*为什么要建立期望呢？我们不是与第三方签订了 SLA 吗？事实上，以合同形式与第三方签订的 SLA 太低，无法用于确定故障和缓解措施。例如，AWS 几乎不为 EC2 发布 SLA。因此，当我们依赖第三方服务时，我们必须决定我们合理期望他们提供的可靠性、可用性、性能或其他关键指标的级别。

事后析误行动

来自 Google 的 Sue Lueder 和 Betsy Beyer 就事后析误行动事项制作了精彩的演示文稿并撰写了优秀的文章 ，我们在 Atlassian 使用它们来提示团队。

通过提出以下问题来帮助确保 PIR 涵盖短期和长期修复：

“缓解未来事件”和“预防未来事件”是解决根本原因的最可能的行动来源。务必至少提问其中一个问题。

事后析误审批

Atlassian 在使用 Jira 工作流的同时采用审批步骤，以确保事后析误获得批准。审批者通常是服务负责人或其他负责服务运营的经理。对事后析误的批准表明：

• 同意事后审查的结果，包括根本原因；
• 同意相关的“优先行动”行动是解决根本原因的可接受方式。

我们的审批者通常会要求采取更多行动或确定某些未被提议的行动未解决的因果链。通过这种方式，我们看到审批为 Atlassian 的事后析误流程增加了很多价值。

事件较少或基础架构不太复杂的团队可能不需要事后析误审批。

无指责的事后析误

当事情出错时，寻找被指责的对象是人之常情。不过，避免这种指责才符合 Atlassian 的最佳利益，因此在执行事后析误时，您需要有意识地克服这种倾向。我们假定我们的员工心怀善意，并且从不指责人们的过错。事后析误需要诚实、客观地审视导致故障的情况，以便我们可以找到真正的根本原因并予以缓解。指责他人会危及这一点，因为：

• 如果人们感受到他们在同事眼中的地位或他们的职业前景有危险，这种感受通常会在他们的个人等级中超越“我的雇主企业的最佳利益”，因此他们会自然地掩饰或隐藏真相以保护他们的基本需求。
• 即使一个人做出了直接导致事件的行动，我们应该问的也不是“为什么 x 这个人会这样做”，而是“为什么体制允许他们这样做，或者让他们相信这样做是正确的”。
• 责备他人是不友善的，而且，如果经常再三地责备他人，就会创造出一种恐惧和不信任的文化。

在我们的事后析误中，我们使用以下方法为所有参与者创造个人安全：

• 事后分析会议的开场白会声明这是一次无指责的事后分析以及原因
• 按角色（例如“待命的小工具工程师”）而不是姓名称呼个人（同时对事实绝不含糊其辞）
• 确保事后析误时间表、因果链和缓解措施在系统、流程和角色而不是个人的背景下进行设计。

我们的无指责事后析误的灵感和“第二个故事”的有用概念来自于 John Allspaw 所写的这篇具有深远影响的文章。