OPS07-BP02 确保以一致的方式对运营准备情况进行审查

使用运营准备情况审查（ORR），确保可以运营工作负载。ORR 是 Amazon 开发的一种机制，用于验证团队是否可以安全地运营工作负载。ORR 是一个使用要求核对清单进行审查和检查的过程。ORR 是一种自助服务体验，供团队用于验证其工作负载。ORR 中包含的最佳实践源自我们多年构建软件的经验教训。

ORR 核对清单包括架构推荐、运营流程、事件管理和发布质量。我们的错误更正（CoE）流程是这些项目的主要推动因素。意外事件后分析应该可以推动自己的 ORR 演进。ORR 不仅在于遵循最佳实践，还在于预防以前的事件再次发生。最后，ORR 中还可以包括安全、治理和合规性方面的要求。

在工作负载正式公开发布之前运行 ORR，然后在整个软件开发生命周期中运行 ORR。在发布之前运行 ORR 可以提升安全运营工作负载的能力。在工作负载上定期重新运行 ORR 可以收集任何偏离最佳实践的情况。可以准备用于新服务发布的 ORR 核对清单以及用于定期审查的 ORR。这有助于遵循最新制定的最佳实践，并吸取从意外事件后分析中学到的经验教训。随着对云的使用日趋成熟，可以将 ORR 要求作为默认设置整合到自己的架构中。

期望结果：已准备好 ORR 核对清单，其中包括适用于组织的最佳实践。在工作负载发布之前执行 ORR。在整个工作负载生命周期中定期执行 ORR。

常见反模式：

您启动了工作负载，但不知道自己是否能够运营工作负载。
在验证工作负载以便发布时，没有包括治理和安全要求。
没有定期重新评估工作负载。
在未准备好所需程序的情况下发布工作负载。
在多个工作负载中发现相同的根本原因反复导致出现故障。

建立此最佳实践的好处：

工作负载包括架构、流程和管理最佳实践。
学到的经验教训可合并到 ORR 流程中。
在工作负载发布时已准备好所需程序。
在工作负载的整个软件生命周期中执行 ORR。

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

实施指导

ORR 关系到两点：流程和核对清单。ORR 流程应该由组织采用并获得执行发起人支持。至少，在工作负载正式公开发布之前执行 ORR。在整个软件开发生命周期中执行 ORR，可确保软件始终遵循新的最佳实践或新要求。ORR 核对清单应包括组织的配置项目、安全要求和治理要求以及最佳实践。随着时间的推移，可以使用 AWS Config、AWS Security Hub 和 AWS Control Tower Guardrails 等服务将源自 ORR 的最佳实践构建到防护机制中，以便自动检测最佳实践。

客户示例

在经历了多起生产意外事件之后，AnyCompany Retail 决定实施 ORR 流程。他们构建了核对清单，其中包括最佳实践、治理要求和合规性要求，以及从中断中学到的经验教训。他们在发布新工作负载之前执行 ORR。每个工作负载会每年执行一次 ORR，其中包括一小组最佳实践，用于整合添加到 ORR 核对清单中的新最佳实践和要求。随着时间的推移，AnyCompany Retail 使用 AWS Config 来检测某些最佳实践，加快了 ORR 流程。

实施步骤

有关 ORR 的更多信息，请阅读《Operational Readiness Reviews（ORR）白皮书》。其中详细介绍了 ORR 流程的历史、如何构建自己的 ORR 实践，以及如何制定自己的 ORR 核对清单。以下步骤是该文档的缩减版本。如需深入了解什么是 ORR 以及如何自行构建，建议阅读该白皮书。

让关键利益相关方聚在一起讨论，包括来自安全、运营和开发部门的代表。
让每个利益相关方至少提一项要求。对于第一次迭代，请尝试将项目数限制为不超过三十个。
- Appendix B: Example ORR questions 源自《Operational Readiness Reviews（ORR）白皮书》，包含在开始着手时可借鉴的示例问题。
在电子表格中收集要求。
- 您可以使用 AWS Well-Architected Tool 中的自定义剖析来开发 ORR，并在账户和 AWS 组织中共享这些剖析。
确定一个工作负载来执行 ORR。最好选择发布前的工作负载或内部工作负载。
运行 ORR 核对清单并记录任何发现结果。如果已经有防范措施，发现结果可能就不太重要了。对于任何没有防范措施的发现结果，请将它们记录到项目的积压工作项中，并在发布之前处理它们。
在一段时间后，继续在 ORR 核对清单中添加最佳实践和要求。