# REL11-BP07 构建产品以满足可用性目标和正常运行时间服务水平协议（SLA）
<a name="rel_withstand_component_failures_service_level_agreements"></a>

构建产品以满足可用性目标和正常运行时间服务水平协议（SLA）。如果您公开或私下同意可用性目标或正常运行时间 SLA，请确保架构和运营流程的设计支持它们。

 **期望结果：**每个应用程序的性能指标都有明确的可用性和 SLA 目标，可以监控和维护目标，实现业务成果。

 **常见反模式：**
+  在不设置任何 SLA 的情况下设计和部署工作负载。
+  在没有理由或业务需求的情况下将 SLA 指标设置得很高。
+  在设置 SLA 时不考虑依赖项及其基础 SLA。
+  设计应用程序时不考虑韧性的责任共担模式。

 **建立此最佳实践的好处：**根据关键韧性目标设计应用程序，有助于实现业务目标并满足客户期望。这些目标有助于推动评估不同技术并考虑各种权衡的应用程序设计过程。

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

## 实施指导
<a name="implementation-guidance"></a>

 应用程序设计必须考虑因业务、运营和财务目标而产生的各种要求。根据运营要求，工作负载需要具有特定的韧性指标目标，以便进行监控并予以支持。不得在部署工作负载之后才设置或引出韧性指标。这些指标应该在设计阶段得到定义，有助于指导作出各种决策和权衡。
+  每个工作负载都应有自己的一组韧性指标。这些指标可能与其他业务应用程序的指标不同。
+  减少依赖项可以对可用性产生积极影响。每个工作负载都应考虑自己的依赖项及其 SLA。一般来说，选择可用性目标等于或大于工作负载目标的依赖项。
+  若可行，尽量考虑采用松耦合设计，让工作负载可以在依赖关系受损的情况下正常运行。
+  减少控制面板依赖项，特别是在恢复或降级期间。评估可确保任务关键型工作负载静态稳定性的设计。使用资源节约来提高工作负载中这些依赖项的可用性。
+  可观测性和检测能力对于通过减少平均检测时间（MTTD）和平均修复时间（MTTR）来实现 SLA 至关重要。
+  降低故障频率（提高 MTBF）、缩短故障检测时间（缩短 MTTD）和缩短修复时间（缩短 MTTR）是提高分布式系统可用性的三项因素。
+  设立并满足工作负载的韧性指标，这是所有有效设计的基础。这些设计必须在设计复杂性、服务依赖项、性能、扩展和成本之间作出权衡。

 **实施步骤** 
+  检查并记录工作负载设计，考虑以下问题：
  +  在工作负载中的什么地方使用控制面板？ 
  +  工作负载如何实施容错？ 
  +  扩展、自动扩展、冗余和高可用性组件的设计模式是什么？ 
  +  数据一致性和可用性的要求是什么？ 
  +  是否考虑了资源节约或资源静态稳定性？ 
  +  有哪些服务依赖项？ 
+  与利益相关方合作时，根据工作负载架构定义 SLA 指标。考虑工作负载使用的所有依赖项的 SLA。
+  设立了 SLA 目标后，优化架构来满足 SLA。
+  确定了满足 SLA 的设计后，实施侧重于减少 MTTD 和 MTTR 的运营更改、流程自动化和运行手册。
+  部署之后，监控和报告 SLA。

## 资源
<a name="resources"></a>

 **相关最佳实践：**
+  [REL03-BP01 选择如何划分工作负载](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL10-BP01 将工作负载部署到多个位置](rel_fault_isolation_multiaz_region_system.md) 
+  [REL11-BP01 监控工作负载的所有组件以检测故障](rel_withstand_component_failures_monitoring_health.md) 
+  [REL11-BP03 自动修复所有层](rel_withstand_component_failures_auto_healing_system.md) 
+  [REL12-BP04 使用混沌工程测试韧性](rel_testing_resiliency_failure_injection_resiliency.md) 
+  [REL13-BP01 定义停机和数据丢失的恢复目标](rel_planning_for_recovery_objective_defined_recovery.md) 
+ [了解工作负载运行状况](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)

 **相关文档：**
+ [Availability with redundancy](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [可靠性支柱 – 可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [衡量可用性](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html)
+ [AWS Fault Isolation Boundaries](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [韧性的责任共担模式](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/shared-responsibility-model-for-resiliency.html)
+ [使用可用区的静态稳定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [AWS 服务水平协议（SLA）](https://aws.amazon.com/legal/service-level-agreements/)
+ [Guidance for Cell-based Architecture on AWS](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/)
+ [AWS infrastructure ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html)
+ [ Advanced Multi-AZ Resilience Patterns whitepaper ](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html)

 **相关服务：**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)