OPS07-BP02 Ensure a consistent review of operational readiness
Use Operational Readiness Reviews (ORRs) to validate that you can operate your workload. ORR is a mechanism developed at Amazon to validate that teams can safely operate their workloads. An ORR is a review and inspection process using a checklist of requirements. An ORR is a self-service experience that teams use to certify their workloads. ORRs include best practices from lessons learned from our years of building software.
An ORR checklist is composed of architectural recommendations, operational process, event management, and release quality. Our Correction of Error (CoE) process is a major driver of these items. Your own post-incident analysis should drive the evolution of your own ORR. An ORR is not only about following best practices but preventing the recurrence of events that you’ve seen before. Lastly, security, governance, and compliance requirements can also be included in an ORR.
Run ORRs before a workload launches to general availability and then throughout the software development lifecycle. Running the ORR before launch increases your ability to operate the workload safely. Periodically re-run your ORR on the workload to catch any drift from best practices. You can have ORR checklists for new services launches and ORRs for periodic reviews. This helps keep you up to date on new best practices that arise and incorporate lessons learned from post-incident analysis. As your use of the cloud matures, you can build ORR requirements into your architecture as defaults.
Desired outcome: You have an ORR checklist with best practices for your organization. ORRs are conducted before workloads launch. ORRs are run periodically over the course of the workload lifecycle.
Common anti-patterns:
-
You launch a workload without knowing if you can operate it.
-
Governance and security requirements are not included in certifying a workload for launch.
-
Workloads are not re-evaluated periodically.
-
Workloads launch without required procedures in place.
-
You see repetition of the same root cause failures in multiple workloads.
Benefits of establishing this best practice:
-
Your workloads include architecture, process, and management best practices.
-
Lessons learned are incorporated into your ORR process.
-
Required procedures are in place when workloads launch.
-
ORRs are run throughout the software lifecycle of your workloads.
Level of risk if this best practice is not established: High
Implementation guidance
An ORR is two things: a process and a checklist. Your ORR process should be adopted by your organization and supported by an executive sponsor. At a minimum, ORRs must be conducted before a workload launches to general availability. Run the ORR throughout the software development lifecycle to keep it up to date with best practices or new requirements. The ORR checklist should include configuration items, security and governance requirements, and best practices from your organization. Over time, you can use services, such as AWS Config, AWS Security Hub, and AWS Control Tower Guardrails, to build best practices from the ORR into guardrails for automatic detection of best practices.
Customer example
After several production incidents, AnyCompany Retail decided to implement an ORR process. They built a checklist composed of best practices, governance and compliance requirements, and lessons learned from outages. New workloads conduct ORRs before they launch. Every workload conducts a yearly ORR with a subset of best practices to incorporate new best practices and requirements that are added to the ORR checklist. Over time, AnyCompany Retail used AWS Config to detect some best practices, speeding up the ORR process.
Implementation steps
To learn more about ORRs, read the Operational Readiness Reviews (ORR) whitepaper. It provides detailed information on the history of the ORR process, how to build your own ORR practice, and how to develop your ORR checklist. The following steps are an abbreviated version of that document. For an in-depth understanding of what ORRs are and how to build your own, we recommend reading that whitepaper.
-
Gather the key stakeholders together, including representatives from security, operations, and development.
-
Have each stakeholder provide at least one requirement. For the first iteration, try to limit the number of items to thirty or less.
-
Appendix B: Example ORR questions from the Operational Readiness Reviews (ORR) whitepaper contains sample questions that you can use to get started.
-
-
Collect your requirements into a spreadsheet.
-
You can use custom lenses in the AWS Well-Architected Tool
to develop your ORR and share them across your accounts and AWS Organization.
-
-
Identify one workload to conduct the ORR on. A pre-launch workload or an internal workload is ideal.
-
Run through the ORR checklist and take note of any discoveries made. Discoveries might not be ok if a mitigation is in place. For any discovery that lacks a mitigation, add those to your backlog of items and implement them before launch.
-
Continue to add best practices and requirements to your ORR checklist over time.
AWS Support customers with Enterprise Support can request the Operational Readiness
Review Workshop
Level of effort for the implementation plan: High. Adopting an ORR practice in your organization requires executive sponsorship and stakeholder buy-in. Build and update the checklist with inputs from across your organization.
Resources
Related best practices:
-
OPS01-BP03 Evaluate governance requirements – Governance requirements are a natural fit for an ORR checklist.
-
OPS01-BP04 Evaluate compliance requirements – Compliance requirements are sometimes included in an ORR checklist. Other times they are a separate process.
-
OPS03-BP07 Resource teams appropriately – Team capability is a good candidate for an ORR requirement.
-
OPS06-BP01 Plan for unsuccessful changes – A rollback or rollforward plan must be established before you launch your workload.
-
OPS07-BP01 Ensure personnel capability – To support a workload you must have the required personnel.
-
SEC01-BP03 Identify and validate control objectives – Security control objectives make excellent ORR requirements.
-
REL13-BP01 Define recovery objectives for downtime and data loss – Disaster recovery plans are a good ORR requirement.
-
COST02-BP01 Develop policies based on your organization requirements – Cost management policies are good to include in your ORR checklist.
Related documents:
Related videos:
Related examples:
Related services:
