99.9% 情境

下一個可用性目標是針對那些必須具有高度可用性的應用程式，但它們可以容忍短期的不可用性。這種類型的工作負載通常用於內部操作，而這些操作會在員工宕機時對他們產生影響。這種類型的工作負載還可以面向客戶，但對於企業而言並不會產生很高的收益，且可以承受更長的復原時間或復原點。此類工作負載包括用於帳戶或訊息管理的管理應用程式。

我們可以透過使用兩個可用區域來進行部署，並將應用程式劃分為不同的層級，從而提高工作負載的可用性。

監控資源

透過檢查主頁上的 HTTP 200 OK 狀態，監控範圍將擴大以提醒整個網站的可用性。此外，每次更換 Web 伺服器以及資料庫庫進行容錯移轉時，都會發出提醒。我們還將監控 Amazon S3 上的靜態內容的可用性，並在其不可用時發出提醒。系統將彙總日誌記錄，以簡化管理並幫助進行根本原因分析。

適應需求變更

已將自動調整規模功能設定為監控 EC2 執行個體上的 CPU 使用率，以及新增或移除執行個體，使 CPU 目標維持在 70%，但每個可用區域不得少於一個 EC2 執行個體。如果 RDS 執行個體的載入模式指出需要擴展，我們會在維護時段變更執行個體類型。

實作變更

基礎設施部署技術保持與先前情境相同的狀態。

新軟體的交付按固定的時間表 (每兩到四週一次) 進行。軟體更新將自動進行，且並不使用 Canary 或藍/綠部署模式，而是使用就地取代。回復的決定將透過執行手冊決定。

我們擁有的程序手冊可用於確定問題的根本原因。在確定根本原因之後，營運和開發團隊將攜手合作，以確定錯誤的糾正措施。在開發修補程序後部署糾正措施。

備份資料

可以使用 Amazon RDS 完成備份和還原。我們將使用執行手冊定期執行，以確保我們能夠滿足復原要求。

彈性架構師

我們可以透過使用兩個可用區域來進行部署，並將應用程式劃分為不同的層級，從而提高應用程式的可用性。我們將使用可跨多個可用區域工作的服務，例如 Elastic Load Balancing、Auto Scaling 和 Amazon RDS 異地同步備份，並透過 AWS Key Management Service 加密儲存。如此一來，將能確保在資源層級和可用區域層級上對故障的容忍度。

負載平衡器只會將流量路由到運行狀態良好的應用程式執行個體。運行狀態檢查需要在資料平面/應用程式層執行，以指示執行個體上應用程式的功能。此檢查不應與控制平面相悖。隨即將顯示 Web 應用程式的運行狀態檢查 URL，並會將其設定為由負載平衡器和 Auto Scaling 使用，以便刪除及取代失敗的執行個體。如果執行個體在主要可用區域中失敗，則 Amazon RDS 將管理第二可用區域中提供的活躍資料庫引擎，然後進行修復以還原到相同的彈性。

分離各層之後，我們可以使用分散式系統彈性模式來提高應用程式的可靠性，以便即使在可用區域容錯移轉期間資料庫暫時不可用時，該應用程式仍然可用。

測試彈性

我們進行功能測試，與之前情境相同。我們不會測試 ELB、自動調整規模或 RDS 容錯移轉的自我修復功能。

我們將提供程序手冊，其中說明了常見資料庫問題、與安全相關的事故和部署失敗。

災難復原 (DR) 計畫

我們擁有可用於完整工作負載復原和通用報告的執行手冊。復原使用的備份會存放在與工作負載相同的區域。

可用性設計目標

我們假設至少某些故障將需要人工決策才能執行復原。但是，在這種情境下，如果自動化程度更高，我們會假設每年僅需要兩次事件就可以作出此決定。我們需要 30 分鐘的時間來決定執行復原，並假設會在 30 分鐘內完成復原。這意味著需要 60 分鐘才能從故障中復原。假設每年兩次事件，則我們估計全年的影響時間為 120 分鐘。

這表示可用性的上限為 99.95%。實際可用性將還取決於實際故障率、故障持續時間以及每個故障實際復原的速度。對於這種架構，我們要求應用程式短暫離線處理更新，但是這些更新是自動進行的。我們估計為此每年需要 150 分鐘：每次變更 15 分鐘，每年 10 次。當服務不可用時，每年總計 270 分鐘， 因此我們的可用性設計目標 是 99.9%。

總結