OPS11-BP02 在意外事件发生后执行分析 - AWS Well-Architected 框架

OPS11-BP02 在意外事件发生后执行分析

审查影响客户的事件,确定这些事件的成因和预防措施。利用这些信息来制定缓解措施,限制或防止再次发生同类事件。制定程序,以便迅速有效地做出响应。根据目标受众,适当传达事件成因和纠正措施。

期望结果:

  • 已建立包括意外事件后分析在内的事件管理流程。

  • 已制定可观测性计划来收集事件数据。

  • 利用这些数据,可以了解并收集指标,用于支持意外事件后分析流程。

  • 从意外事件中吸取教训,以便改善以后的结果。

常见反模式:

  • 管理应用程序服务器。大约每 23 小时 55 分钟,所有活动会话都会终止。已尝试找出应用程序服务器上出现的问题。曾怀疑可能是网络问题,但由于网络团队工作繁忙无法提供支持,因此无法与他们合作。由于缺乏可遵循的预定义流程,因此难以获取支持并收集必要的信息,来确定发生了什么情况。

  • 工作负载中出现了数据丢失的情况。这是第一次发生,原因不明。您认为数据丢失不重要,因为可以重新创建数据。数据丢失变得愈发频繁,并对客户造成影响。还原丢失的数据时,这也会增加运营负担。

建立此最佳实践的好处:

  • 建立了预定义流程,可确定导致意外事件发生的要素、条件、操作和事件,有助于找到改进机会。

  • 可以使用来自意外事件后分析的数据进行改进。

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

实施指导

通过流程来确定事件成因。审查所有影响客户的意外事件。设置流程来确定并记录导致意外事件的因素,以便制定缓解措施来限制或防止事件再次发生,并且还可以据此制定及时有效的响应程序。酌情传达造成意外事件的根本原因,并针对目标受众量身定制传达内容。在组织内公开分享经验教训。

实施步骤

  1. 收集各种指标,例如部署更改、配置更改、意外事件开始时间、警报时间、参与时间、缓解措施开始时间和意外事件解决时间。

  2. 在时间表上描述关键时间点,用于了解意外事件。

  3. 提出以下问题:

    1. 能否缩短检测时间?

    2. 是否更新了可以更快地检测到事件的指标和警报?

    3. 能否缩短诊断时间?

    4. 您的响应计划或上报计划是否有更新,可以更快地与正确的响应者进行互动?

    5. 能否缩短缓解时间?

    6. 可以添加或改进哪些运行手册或行动手册步骤?

    7. 未来能否防止意外事件再次发生?

  4. 创建检查清单和操作。跟踪并交付所有操作。

实施计划的工作量级别:

资源

相关最佳实践:

相关文档: