事故发生后如何进行无责事后分析
事故发生时，每个人都想知道故障点在哪里。这是人之常情——在 2024 年 CrowdStrike 事故中，我们都紧盯着新闻，寻找我们的 Windows 机器为何会出现 BSOD 的答案。然而，虽然事后分析是一个很好的工具，但它们很快就会变成一场指责游戏，重点是谁犯了错误，而不是错误是如何发生的。
这种事后分析会损害你的团队文化。当员工知道他们犯错会受到批评时，他们就会变得厌恶风险。当人们试图逃避指责时，诚实、学习和责任感就会消失，因为承担错误的责任会受到惩罚。这就是为什么一份好的事后分析必须始终是无可指责的。
在本文中，我将介绍如何进行无责事后分析、其应包含的基本组成部分以及您可以使用的有用模板。
什么是无责事后分析？
无责事后分析是一个结构化的过程，团队会分析过去的事件，以记录根本原因、业务影响、时间线、经验教训和行动项目。主要目标是从事件中吸取教训并防止将来再次发生。无责事后分析强调流程改进而非个人过错，鼓励一种健康、开放的文化，让工程师感到可以放心地承认错误。
无责事后分析对于事件响应至关重要
事后分析在包括事件管理（快速解决问题以限制业务影响的过程）在内的任何领域都很有用，而且几乎总是从不责备中获益。它通常在站点可靠性工程 (SRE) 中实施，但网络安全和云计算等领域，甚至非技术领域（如应急响应、制造业甚至零售业）也受益于不责备的事后分析。
通常，如果您提供的服务需要在商定的服务水平目标 (SLO) 内运行，您希望该系统是可靠的。无责事后分析是帮助您实现这一目标的不可或缺的工具。
进行无责事后分析的其他原因
我们不去粉饰它——进行任何类型的事后分析都很少令人愉快。然而，有几个好处让它值得：
- 全面了解事件：事后分析提供事件的详细说明，包括持续时间、用户影响、财务影响、根本原因和预防措施。
- 根本原因分析：使用“五个为什么”之类的方法，事后分析可以发现系统中潜在的问题。
- 学习机会：事后分析可以帮助团队反思哪些方面可以做得更好，从而促进持续改进。
- 预防措施：他们确定监测和其他预防措施中的差距。
- 责任：明确行动项目、责任主体和最后期限，确保改进工作的顺利完成。
成功的事后分析的组成部分
我们已经介绍了为什么要进行事后分析。但如何进行事后分析呢？事后分析必须至少包含以下高级部分：
1. 执行摘要
执行摘要是一两段简短的文字，概括问题。您应避免涉及过多的技术细节，只需总结细节以便于推断。以下是如果您是站点可靠性工程师，您可能会包含的内容的示例：
由于 10 月 15 日晚上 8:00 至 9:00 CDT 发布失败，20% 的身份验证微服务实例无法连接到后端，导致身份验证服务调用失败。身份验证服务故障影响了交易门户，导致 200 名用户无法登录交易系统。该问题已通过于 10 月 15 日晚上 11:15 CDT 更新失败的身份验证服务实例得到解决。我们已加强监控以在发布期间发现此问题。
2. 业务影响
您进行事后分析的全部原因是因为它破坏了您的理想运营状态。用实际数字量化影响。如果有财务影响，请务必提及这一点。继续我们的 SRE 示例，您可能会写类似以下内容：
10 月 15 日晚上 8:00 至 11:15 之间，我们 2000 名交易用户中有 10%（200 名）无法登录。这些用户仍然可以使用我们的手动交易处理系统下订单。这不会对财务造成影响，而且我们在 4 周周期内仍保持着 SLO（服务水平目标）的水平。
3. 根本原因
每个人都想知道确凿的证据！到底是什么导致了事件的发生？找到根本原因的一个经典方法是使用“五个为什么”方法。这需要问“为什么？”五次，每次都将当前的“为什么”引向前一个“为什么”的答案。第五个“为什么”应该揭示问题的根本原因。
让我们在实践中证明这一点：
20%的用户在登录交易门户时看到“HTTP 500 内部服务器错误”。
为什么？
分析日志后发现，门户在加载用户配置文件时出现错误。
为什么？
调用“auth”微服务时，门户收到“未知错误”。
为什么？
分析 auth 微服务日志后，我们发现它在连接后端 Postgresql 数据库时出错。此错误仅发生在部分 auth 微服务实例上。
为什么？
连接到后端 Postgresql 数据库时，auth 微服务具有不正确的数据库连接配置。
为什么？
昨晚，auth服务的代码已发布以更新数据库连接配置，但代码发布未能更新某些微服务实例，从而导致这些实例的配置已过时。
因此，最终的根本原因是您的应用程序所依赖的远程服务（身份验证服务）上的代码发布部分成功。
注意： 5 个为什么方法是确定根本原因的有效机制。但是，在某些情况下，这种方法可能不适用。例如，如果硬盘驱动器出现故障，您可能需要从五个“为什么”缩减为两个或三个。
4. 时间线
又称为“一系列不幸事件”。本节按时间顺序介绍事件。时间线将帮助团队发现任何未来的流程改进。
例如，如果你是一名站点可靠性工程师，你是否需要等待 25 分钟才能让数据库团队加入作战室？如果是这样，你可能会问自己将来是否可以并行执行特定任务。
5. 经验教训
如果你不吸取任何教训，这种事件肯定会再次发生。本节中可能包含以下内容：
- 哪些方面进展顺利？
- 什么地方进展不顺利？
- 我们可以做些什么来避免将来再发生这种情况？
- 我们的监控是否在最终用户报告问题之前就发现了问题？我们如何改进？
5. 行动项目
了解原因并对发生的事情更加明智是件好事，但您还需要制定行动计划，说明应采取哪些步骤来阻止事件再次发生。每个行动项目都必须有负责人和目标日期。任务负责人还应负责在任务完成后更新事后分析。
培育无责备的事后文化
因此，我们讨论了如何创建出色的事后分析，但如何才能使其“无可指责”呢？这在很大程度上取决于文化，而不是流程。您需要创建一个环境，让您的员工始终如一地撰写事后分析，同时克服时间限制和人们天生不愿承认错误等挑战。以下是您可以使用的一些策略：
1. 高层领导的支持和参与
实施事后总结文化必须自上而下。如果领导者也在回顾自己的错误，那么它就会起到表率作用。此外，确保事后总结与高层领导一起审查。当领导者参与时，团队通常更倾向于撰写事后总结
2. 奖励写得好的事后分析
每个月或每季度对写得好的事后分析报告进行评审，并奖励撰写这些报告的团队。这将鼓励其他团队效仿。
3. 建立事后分析库
所有事后分析报告都必须存储在一个存储库中，以便于访问——Github 是一个很好的选择。随着团队积累了精心编写的事后分析报告，他们将利用过去的事后分析报告来解决新问题。此外，拥有一个集中的事后分析报告存储库有助于提供更智能的解决方案（例如使用机器学习来帮助解决新问题）。
何时应进行事后分析？
并非所有事件都应进行事后分析。创建事件严重性级别，例如优先级一 (P1)、优先级二 (P2) 和优先级三 (P3)，其中 P1 对业务最为关键。在这种情况下，承诺对每个 P1 进行事后分析，并可能对某些 P2 和 P3 进行事后分析，具体取决于业务影响和团队情绪。
以下是我确定是否必须进行事后分析的指导原则：
- 组织授权（例如，您已承诺对所有 P1 事件执行一项任务）
- 该事件导致数据丢失（或您所在行业特有的另一种形式的资源损失。例如货币）
- 对用户/客户产生了重大影响
- 该团队认为他们应该深入挖掘以了解发生了什么。
我建议在五到七个工作日内，趁着你们的记忆还比较新鲜的时候，集体进行冷事后分析。
事后分析模板
正如您已经知道的那样，事后分析报告的各个部分包含大量信息。一开始这可能令人望而生畏，但幸运的是，您不必从头开始构建它们！创建事后分析报告的一种非常有效的方法是使用完善的模板。
有许多事后分析模板可用。我最喜欢的是来自 Google 的模板，但您可以随意使用以下任何模板：
结论：无责事后分析值得投资
无责事后分析对于有效的事件管理至关重要。它们可以帮助团队从事件中吸取教训并防止将来再次发生。为了使事后分析有效，它们必须关注系统和流程，而不是个人。高层领导的支持和中央事后分析存储库进一步提高了它们的价值，从而实现了持续改进和创新。
请先 登录后发表评论 ~