99.95%，復原時間在 5 到 30 分鐘之間

要實現應用程式的這一可用性目標，需要停機時間極短，並且在特定時間幾乎沒有資料丟失。具有此可用性目標的應用程式包括以下領域的應用程式：銀行、投資、緊急服務和資料捕獲。這些應用程式的復原時間和復原點非常短。

透過在兩個 AWS 區域之間使用 「暖待命」 跨兩個 AWS 區域的方法。我們會將整個工作負載部署到兩個區域，縮小被動站點的規模，並使所有資料最終保持一致。兩個部署在 各自區域內都保持 靜態穩定。應使用分散式系統彈性模式來建置應用程式。我們需要建 立輕量型路由元件， 該元件可監控工作負載的運作狀態，並視需要設定為將流量路由到被動區域。

監控資源

在每次更換 Web 伺服器，資料庫和區域進行容錯移轉時，都會發出提醒。我們還將監控 Amazon S3 上的靜態內容的可用性，並在其不可用時發出提醒。系統將彙總日誌記錄，以簡化管理並幫助每個區域進行根本原因分析。

路由元件會同時監控我們的應用程式運作狀態和所擁有的任何區域硬相依性。

適應需求變更

與 99.99% 情境相同。

實作變更

新軟體的交付按固定的時間表 (每兩到四週一次) 進行。軟體更新將使用 Canary 或藍/綠部署模式自動進行。

執行手冊適用於發生區域故障移轉的時間，事件期間發生的常見客戶問題以及常見報告。

我們將提供程序手冊，其中說明了常見資料庫問題、與安全相關的事故、部署失敗、區域故障移轉上的意外客戶問題以及確定問題根本原因。在確定根本原因之後，營運和開發團隊將攜手合作，以確定錯誤的糾正措施並在開發修補程序時部署這些措施。

我們還將與 AWS Support for Infrastructure Event Management 接洽。

備份資料

與 99.99% 情境一樣，我們會使用自動化 RDS 備份並使用 S3 版本控制。系統會自動非同步地將資料從主動區域中的 Aurora RDS 叢集，複寫到被動區域中的跨區域僅供讀取複本。S3 跨區域複寫可用來自動非同步地將資料從主動區域移至被動區域。

彈性架構師

與 99.99% 情境相同，且可能發生區域容錯移轉。此為手動管理過程。在容錯移轉期間，我們將使用 DNS 備援將請求路由到靜態網站，直到在第二個區域中進行復原。

測試彈性

與 99.99% 情境相同，我們將使用執行手冊在整個演練日驗證架構。此外，RCA 糾正措施應優先於功能發佈，以便即時實作和部署

災難復原 (DR) 計畫

區域容錯移轉是手動管理過程。所有資料都會以非同步方式複寫。暖待命中的 基礎架構 會向外擴展。這可以使用 AWS Step Functions 上執行的工作流程來自動化。AWS Systems Manager (SSM) 也可協助進行此自動化，因為您可以建立更新 Auto Scaling 群組和調整執行個體大小的 SSM 文件。

可用性設計目標

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

這表示可用性的上限為 99.95%。實際可用性還取決於實際故障率、故障持續時間以及每個因素實際復原的速度。對於這種架構，我們假設應用程式可透過更新持續聯網。因此，我們的 可用性設計目標 為 99.95%。

總結