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

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

ORR 核对清单包括架构推荐、运维过程、事件管理和发布质量。我们的更正错误（CoE，Correction of Error）流程是这些项目的主要推动因素。您的事后分析应该可以推动自己的 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 防护机制等服务，将源自 ORR 的最佳实践整合到防护机制中，以实现自动化的最佳实践检测。

客户示例

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

实施步骤

如需详细了解 ORR，请阅读运维准备情况审查（ORR）白皮书。其中详细介绍了 ORR 流程的历史，如何构建自己的 ORR 实践，以及如何制定自己的 ORR 核对清单。以下步骤是该文档的缩减版本。如需深入了解什么是 ORR 以及如何自行构建，建议您阅读该白皮书。

让关键利益相关方聚在一起讨论，包括来自安全、运维和开发部门的代表。
让每个利益相关方至少提一个要求。对于第一次迭代，请尝试将项目数限制为不超过三十个。
- 附录 B：ORR 问题示例源自运维准备情况审查（ORR）白皮书，包含您在开始着手时可借鉴的示例问题。
在电子表格中收集您的要求。
- 您可以使用自定义剖析（位于 AWS Well-Architected Tool 中）开发自己的 ORR，并跨账户以及在 AWS Organization 中分享它们。
确定一个工作负载来运行 ORR。最好选择发布前的工作负载或者内部工作负载。
运行 ORR 核对清单并记录任何发现结果。如果已经有防范措施，那么发现结果可能就不太重要。对于任何没有防范措施的发现结果，请将它们记录到项目的待办事项中，并在发布之前实施它们。
在一段时间后，继续在 ORR 中添加最佳实践和要求。