REL11-BP07 Architect your product to meet availability targets and uptime service level agreements (SLAs)
Architect your product to meet availability targets and uptime service level agreements (SLAs). If you publish or privately agree to availability targets or uptime SLAs, verify that your architecture and operational processes are designed to support them.
Desired outcome: Each application has a defined target for availability and SLA for performance metrics, which can be monitored and maintained in order to meet business outcomes.
Common anti-patterns:
-
Designing and deploying workload’s without setting any SLAs.
-
SLA metrics are set too high without rationale or business requirements.
-
Setting SLAs without taking into account for dependencies and their underlying SLA.
-
Application designs are created without considering the Shared Responsibility Model for Resilience.
Benefits of establishing this best practice: Designing applications based on key resiliency targets helps you meet business objectives and customer expectations. These objectives help drive the application design process that evaluates different technologies and considers various tradeoffs.
Level of risk exposed if this best practice is not established: Medium
Implementation guidance
Application designs have to account for a diverse set of requirements that are derived from business, operational, and financial objectives. Within the operational requirements, workloads need to have specific resilience metric targets so they can be properly monitored and supported. Resilience metrics should not be set or derived after deploying the workload. They should be defined during the design phase and help guide various decisions and tradeoffs.
-
Every workload should have its own set of resilience metrics. Those metrics may be different from other business applications.
-
Reducing dependencies can have a positive impact on availability. Each workload should consider its dependencies and their SLAs. In general, select dependencies with availability goals equal to or greater than the goals of your workload.
-
Consider loosely coupled designs so your workload can operate correctly despite dependency impairment, where possible.
-
Reduce control plane dependencies, especially during recovery or a degradation. Evaluate designs that are statically stable for mission critical workloads. Use resource sparing to increase the availability of those dependencies in a workload.
-
Observability and instrumentation are critical for achieving SLAs by reducing Mean Time to Detection (MTTD) and Mean Time to Repair (MTTR).
-
Less frequent failure (longer MTBF), shorter failure detection times (shorter MTTD), and shorter repair times (shorter MTTR) are the three factors that are used to improve availability in distributed systems.
-
Establishing and meeting resilience metrics for a workload is foundational to any effective design. Those designs must factor in tradeoffs of design complexity, service dependencies, performance, scaling, and costs.
Implementation steps
-
Review and document the workload design considering the following questions:
-
Where are control planes used in the workload?
-
How does the workload implement fault tolerance?
-
What are the design patterns for scaling, automatic scaling, redundancy, and highly available components?
-
What are the requirements for data consistency and availability?
-
Are there considerations for resource sparing or resource static stability?
-
What are the service dependencies?
-
-
Define SLA metrics based on the workload architecture while working with stakeholders. Consider the SLAs of all dependencies used by the workload.
-
Once the SLA target has been set, optimize the architecture to meet the SLA.
-
Once the design is set that will meet the SLA, implement operational changes, process automation, and runbooks that also will have focus on reducing MTTD and MTTR.
-
Once deployed, monitor and report on the SLA.
Resources
Related best practices:
Related documents:
Related services:
