# 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)

 **相關文件：**
+ [備援的可用性](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 故障隔離界限](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/)
+ [AWS 上小組型架構指南](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/)
+ [AWS 基礎設施](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html)
+ [《進階多可用區域彈性模式》白皮書](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/)