REL12-BP02 执行事后分析 - 可靠性支柱
实施指导资源

REL12-BP02 执行事后分析

审核影响客户的事件，确定这些事件的成因和预防措施。利用这些信息来制定缓解措施，以限制或防止再次发生同类事件。制定程序以迅速有效地做出响应。根据目标受众，适当传达事件成因和纠正措施。如果需要，可将这些原因告知他人。

评估为什么现有测试找不到问题。如果还没有，增设测试。

期望结果：您的团队采用商定的一致方法来进行事后分析。一种机制是错误更正（COE）流程。COE 流程有助于您的团队识别、理解和解决事件的根本原因，同时还可以建立防护机制，以限制同一事件再次发生的可能性。

常见反面模式：

  • 查找事件成因，但不继续深入探究其他潜在问题和缓解问题的方法。

  • 只找出人为错误原因，但不提供任何培训或可防止人为错误的自动化功能。

  • 只注重追究责任，而不去了解根本原因，营造恐惧文化，阻碍开诚布公的交流

  • 见解分享不畅，事件分析结果仅限于一小群人知道，其他人无法从中吸取经验教训

  • 没有收集制度性知识的机制，因此无法以最新最佳实践的形式保存经验教训，从而失去宝贵见解，导致根源相同或相似的事件反复发生

建立此最佳实践的好处：执行事后分析并且分享分析结果，可以减轻其他实施了相同故障因素的工作负载发生故障的风险，并且让它们能够在事件发生前就实施缓解措施或自动恢复。

在未建立这种最佳实践的情况下暴露的风险等级：高

实施指导

有效的事后分析让您有机会针对系统中其他地方使用的架构模式存在的问题提出常见的解决方案。

COE 流程的基础是记录和解决问题。建议定义一种标准化的方法来记录关键的根本原因，并确保其得到分析和处理。为事后分析流程分配明确的责任人。指派负责的团队或个人来监督事件调查和后续行动。

鼓励注重学习和改进而不是互相推脱责任的文化。强调目标是防止将来发生事件，而不是惩罚某些人。

为执行事后分析制定明确定义的程序。这些程序应概述要采取的步骤、要收集的信息以及在分析期间要解决的关键问题。彻底调查事件，除直接原因外，还要找出根本原因和影响因素。使用诸如“五个为什么”之类的技巧来深入研究潜在问题。

维护从事件分析中吸取的经验教训的存储库。这些制度性知识可以作为未来的事件和预防工作的参考。分享在事后分析中发现的结果和洞察，并考虑召开公开的事后总结会议，讨论经验教训。

实施步骤

  • 在执行事后分析时，确保整个过程不是以追究责任为目的。这使事件中涉及到的人员能够冷静地看待建议的纠正措施，并促进诚实的自我评测和团队间的协作。

  • 定义记录关键问题的标准化方法。此类文档的示例结构如下所示：

    • 发生了什么？

    • 客户和您的业务受到了什么影响？

    • 根本原因是什么？

    • 您有哪些数据来支持这一点？

      • 例如，指标和图表

    • 对关键支柱有什么影响，特别是在安全方面？

      • 在构造工作负载时，您需要基于您的业务环境在各个支柱之间做出权衡。这些业务决策可以确定设计优先事项。在开发环境中，您可能会通过降低可靠性来降低成本；而对于任务关键型解决方案，您可能会通过增加成本来提高可靠性。安全始终是头等大事，因为您必须保护您的客户。

    • 您获得了哪些经验教训？

    • 您采取了哪些纠正措施？

      • 行动项

      • 相关事项

  • 为执行事后分析制定明确定义的标准操作程序。

  • 设置标准化事件报告流程。全面记录所有事件，包括最初的事件报告、日志、通信和事件期间采取的行动。

  • 请记住，并不是发生了停机才叫做事件。这可能是未遂事件，也可能是系统能够履行其业务功能，但以意外的方式运行。

  • 根据反馈和经验教训，持续改进事后分析流程。

  • 在知识管理系统中记录关键调查发现，并考虑应添加到开发人员指南或部署前清单中的任何模式。

资源

相关文档：

相关视频：