選擇跨可用區與跨區域的可用性設計

從使用者操作開始

高可用性（HA）的目標，是在元件故障時仍讓服務可用。選擇架構前，先定義何謂可用。預訂頁面能載入，但所有預訂請求都失敗，不能算可用的預訂服務。

為重要操作設定服務水準目標（SLO）。定義計入哪些請求、成功代表什麼，以及測量期間。雲端服務 SLA 描述提供者的承諾，不能證明應用程式實測的可用性。

舉例而言，以時間計算的 99.9% 可用性，在 30 天月份容許 43.2 分鐘不可用。以請求計算的 SLO 使用不同分母。兩種衡量方式都沒有說明可以損失多少資料，也不保證單次中斷的最長時間。

AWS 可用區（AZ）是區域內隔離的基礎架構位置。一個區域包含多個 AZ。多區域設計將工作負載元件分散到不同區域。其他提供者有各自的邊界與服務行為，應檢查實際選用服務。

這些是設計可能性，不是可用性保證。名稱無法證明每個必要元件都採用預期邊界。

考慮虛構預訂服務。網頁副本在兩個 AZ 執行，但都使用 AZ A 內同一個資料庫與對外閘道。呼叫付款提供者時，必須經過該閘道。

AZ A 若故障，AZ B 的網頁副本可能仍然健康，但預訂依舊失敗。團隊必須評估資料庫、網路路徑、身分提供者、付款相依服務和路由。檢查實際代管資料庫模式：複寫、容錯移轉和讀取副本行為，依產品與設定而異。

也要檢查容量。剩餘資源必須承擔必要負載。若設計依賴在事件期間新增容量，就會受到配額、可用資源和控制平面操作影響。

執行受控演練，定義邊界、停止條件和負責人。驗證完整預訂，包括付款對帳。記錄失敗請求，以及恢復有用服務所需的時間。

多區域維運會增加資料傳輸、重複資源、部署協調和維運工作。主動／被動模式讓一個環境準備好接收流量；主動／主動模式則讓多個環境同時提供服務。兩者所需準備程度與資料行為不同。

對預訂服務而言，同時寫入會帶來一個問題：兩個區域能否賣出同一個座位？定義哪裡有權確認預訂，以及複寫中斷時的行為。「複寫資料庫」不是完整答案。

檢查允許的資料位置、加密金鑰、數位憑證、DNS、機密值和外部服務。共用身分服務中斷或有缺陷的發布版本，都可能影響多個區域。增加位置，不會移除每個共同原因。

HA 處理運作期間的特定故障。災難復原則在破壞正常運作的事件後，恢復可用服務與資料。多區域服務仍需要處理資料刪除或毀損的復原計畫。

記錄選擇處理的故障情境，以及業務接受的其他情境。應用程式改變時，讓測試與基礎架構定義保持一致。繼續閱讀RTO、RPO 與災難復原。