題幹與適用場景
面試官問：「我們的 B2B SaaS 已在兩個區域複製，是否應該讓客戶在主要區域故障時自行觸發切換？」先假設客戶不能直接操作底層資料庫，產品需要保護租戶隔離、資料駐留與稽核。目標職位是平台產品經理、基礎設施產品經理或技術專案負責人。
這題考察產品邊界，不是簡單回答「自動化更快」。AWS 將多區域用於極端韌性場景，同時提醒跨區域依賴會削弱可靠性；Google Cloud 強調必須設計、建置並測試復原；Azure 則要求用業務需求決定區域、RTO、RPO、成本與複雜度。
面試官考察點
- 能否把「客戶想要控制權」拆成可驗證的 RTO、RPO、資料駐留與合規要求。
- 能否區分自動切換、營運人員核准切換、客戶請求切換三種權限。
- 能否指出複製延遲、雙寫、DNS 快取、配額不足與誤判造成的失敗場景。
- 強回答會把客戶操作限制在租戶級控制面，提供預檢、核准、演練、稽核與回切；普通回答只說「給一個 failover 按鈕」。
回答前需要釐清的問題
客戶要解決什麼故障？
單租戶應用故障可用隔離與重啟解決；整個區域不可用才需要跨區域切換。若只是低延遲需求，多區域不一定比單區域多可用區更合適。
RTO 與 RPO 是多少？
非同步複製代表切換可能遺失最近寫入；若客戶要求零資料遺失，就不能承諾一個普通的非同步副本按鈕。RTO 決定是否需要預熱容量，RPO 決定能否接受複製落差。
哪些資料可以離開原區域？
資料駐留、加密金鑰、備份與日誌的邊界會改變候選區域。不能把「備用區域」預設當作合規可用區域。
30 秒回答框架
「我會先按租戶的可用性目標、可接受資料遺失量與駐留限制分層。預設由平台依健康訊號自動或經營運核准切換；只有通過預檢的客戶，才可以提交受稽核的切換請求，而不是直接提升副本。請求必須檢查複製落差、目標容量、金鑰、版本與依賴健康度，並先進入唯讀或凍結寫入階段。切換後持續觀察錯誤率、寫入狀態與 RPO，符合回切條件再恢復。先在少量租戶演練，比較復原時間、誤切換與客戶影響，再決定是否擴大權限。」
分步驟深入解答
- 定義產品契約。 把「區域故障轉移」定義為租戶級災備操作，寫明預計 RTO、最大 RPO、不可用功能、費用與客戶責任。未達契約的複製狀態不能顯示為可切換。
- 建立三層控制。 平台自動切換適合明確的區域健康訊號；營運核准適合有業務影響的共享依賴；客戶請求只產生受限工單或 API 命令，由策略引擎核准。客戶不能直接改 DNS、提升資料庫或重放訊息。
- 執行預檢。 檢查副本追平時間、目標區域配額、應用版本、金鑰可用性、佇列積壓、外部依賴與資料駐留。任何一項不符合都回傳可行動原因，而不是接受請求後才失敗。
- 保護寫入一致性。 先停止或排空主要區域寫入，記錄最後可確認位點；提升副本後只允許一個寫入權威。非同步複製的未知窗口要向客戶標明，不能聲稱「複製完成」就等於零遺失。
- 驗證和回切。 用合成交易驗證登入、讀寫、非同步任務與稽核；監控錯誤率、複製位點、佇列年齡與租戶成功率。回切前先反向追平並演練衝突，避免主要區域恢復後雙主寫入。
- 選擇發布策略。 先給內部租戶和願意演練的客戶開放唯讀模擬，再開放人工核准切換，最後評估自動化。每一步都設定停止條件：誤切換、RPO 超標、目標容量不足或稽核缺失即暫停。
高品質示範回答
我不會把按鈕直接交給客戶。先確認客戶是否真的需要跨區域 RTO，以及他們能接受多少 RPO 和哪些資料駐留限制。產品可以提供「請求切換」能力，但請求先經過租戶策略、複製位點、目標容量、版本、金鑰與依賴健康檢查。
切換時平台凍結或排空主要區域寫入，記錄最後確認位點，只提升一個寫入副本，並給出預計遺失窗口與受影響功能。切換完成後用合成交易驗證讀寫、任務與稽核，再按租戶維度觀察錯誤率、複製狀態與復原時間。回切必須先反向追平並證明沒有雙主寫入。
我會從內部租戶開始演練，再開放人工核准，最後才考慮自動化。若誤切換率、RPO 或容量預檢失敗超過門檻，就關閉客戶觸發入口並保留稽核記錄。這樣既提供客戶需要的可見性與控制，也避免把底層災備風險轉嫁給客戶。
常見錯誤
- 把多區域當作自動高可用 → 忽略副本提升、依賴與回切 → 為每個元件寫出 RTO/RPO、演練與回切步驟。
- 讓客戶直接提升資料庫 → 可能造成雙主寫入或跨租戶影響 → 客戶只呼叫租戶級受稽核命令，由策略引擎執行。
- 只檢查區域健康 → DNS 正常不代表資料、金鑰與配額可用 → 將複製位點、容量、版本、金鑰與外部依賴納入預檢。
- 承諾零資料遺失 → 非同步複製存在未追平窗口 → 明確 RPO，記錄最後確認位點並展示可能遺失範圍。
- 沒有回切計畫 → 主要區域恢復後產生雙寫與漂移 → 設計反向追平、衝突偵測與分階段回切。
追問及應對
客戶要求零 RPO，怎麼回答？
先說明非同步複製無法提供零 RPO。可評估同步複製或業務級雙寫，但要重新計算跨區域延遲、可用性、成本與一致性；若目標不成立，應把契約改為可量測的最大遺失窗口。
健康檢查誤報導致自動切換怎麼辦？
增加多訊號確認、最短持續時間與人工中止窗口；對高價值租戶先進入凍結與預檢狀態，不立即提升副本。記錄每次判定，按誤切換率與復原時間調整門檻。
客戶觸發後目標區域沒有容量怎麼辦？
預檢配額與容量，並為關鍵租戶保留容量預算或自動擴容計畫。預檢失敗時回傳明確原因並保留主要區域狀態，不能為了滿足按鈕成功率而切換到未準備好的區域。
資料駐留限制在故障時能否例外？
不能預設例外。把允許的備用區域、加密金鑰與日誌範圍納入租戶合約與策略；若法律或客戶政策不允許跨境，就提供同區域多可用區或明確的降級方案。