了解可用性需求

通常最開始會將應用程式的可用性視為整個應用程式的單一目標。但是，在仔細檢查後，我們經常會發現應用程式或服務的某些方面具有不同的可用性要求。例如，某些系統可能會優先考慮在擷取現有資料之前接收和儲存新資料的能力。其他系統優先於即時營運，而不是變更系統組態或環境的營運。服務可能在一天中的某些時段有很高的可用性要求，但可以忍受非這些時段內更長的中斷時間。您可以透過下列幾種方法將單一應用程式分解為若干個組成部分，並評估每個部分的可用性要求。這樣做的好處是可以根據特定需求，將您的工作 (和費用) 聚焦於可用性上，而不是按照最嚴格的要求設計整個系統。

在 AWS 內，我們通常將服務分為「資料平面」和「控制平面」。資料平面負責提供即時服務，而控制平面則用於設定環境。例如，Amazon EC2 執行個體、Amazon RDS 資料庫和 Amazon DynamoDB 資料表讀取/寫入操作均為資料平面操作。相反，啟動新的 EC2 執行個體或 RDS 資料庫，或在 DynamoDB 中新增或變更資料表中繼資料則均會被視為控制平面操作。儘管高可用性對於所有這些功能都很重要，但資料平面通常具有比控制平面更高的可用性設計目標。因此，具有高可用性要求的工作負載應避免控制平面操作上的執行時間相依性。

許多 AWS 客戶都採用類似的方法來嚴格評估其應用程式，並識別具有不同可用性需求的子元件。然後，針對不同方面客製化可用性設計目標，並執行適當的工作以對系統進行設計。AWS 擁有豐富的工程應用經驗，並且具有一系列的可用性設計目標，包括達到 99.999% 或更高可用性的服務。AWS解決方案架構師 (SA) 可協助您針對可用性目標進行適當的設計。在設計程序的早期階段引入 AWS 可以提高我們協助您實現可用性目標的能力。規劃可用性不僅是在工作負載啟動之前進行。在您獲得營運經驗、從實際事件中獲得經驗以及經受各種類型的失敗後，也需持續執行此項工作以完善您的設計。然後，您可以進行適當的工作以改善您的實作。

工作負載所需的可用性需求必須與業務需求和關鍵性一致。先以定義的 RTO、RPO 和可用性定義業務關鍵性框架後，您之後便可評估各工作負載。諸如此類的方法規定，參與工作負載實作的人員需精通該架構，及其工作負載對業務需求的影響。