題目與使用場景
這是一題多區域高可用設計。重點不是畫出多個區域，而是說明流量決策、健康訊號傳播、故障時的容量與資料邊界，以及如何演練與回切。
面試官考察什麼
- 是否區分 DNS、邊緣代理與應用層路由的職責和時效。
- 是否使用多來源、分層健康訊號，而非只探測單一端點。
- 是否計算故障轉移後的容量、連線與限流壓力。
- 是否說明有狀態資料的讀寫、複製延遲與區域限制。
- 是否防止腦裂、震盪切換與回切放大事故。
- 是否定義 RTO、RPO、SLO 與演練證據。
作答前的釐清問題
- 目標區域、流量峰值與單區域失效模型是什麼？
- RTO、RPO、資料駐留與合規限制是什麼？
- 請求以無狀態讀為主，還是包含寫入與長連線？
- 調度粒度是 DNS、Anycast、邊緣代理還是服務網格？
- 健康判定需要哪些使用者路徑與依賴檢查？
- 用戶端 DNS TTL、連線遷移與回切窗口有何要求？
30 秒回答框架
「我先定義單區域故障、峰值與 RTO/RPO。入口由邊緣或 DNS 依延遲選候選區域，但只有通過多層健康檢查且有餘量的區域才接收流量。容量不足時逐步降級與限流，避免故障流量壓垮備援區。寫入遵循資料主從或分片邊界，明確複製延遲與重試語意。切換由具防抖動的控制器執行，回切前先演練、預熱並驗證指標。」
分步驟深入解答
步驟 1：定義故障與目標。 寫出區域、依賴、網路與控制面的故障範圍，量化 RTO、RPO、峰值與降級等級。
步驟 2：分離決策層。 DNS 或全球入口負責粗粒度區域選擇，邊緣／服務層負責即時權重、連線與局部限流；不要讓單一控制面承擔全部切換。
步驟 3：建立健康訊號。 結合多地探針、關鍵使用者路徑、依賴狀態、錯誤率與容量水位；連續失敗、恢復窗口與多數判定避免瞬間抖動。
步驟 4：計算容量保護。 預留備援餘量，設定每區域並發、佇列與速率上限；故障時按優先級捨棄非關鍵流量，避免級聯過載。
步驟 5：處理資料邊界。 說明讀副本延遲、寫入歸屬、衝突解決、冪等鍵與跨區重試；路由切換不能掩蓋資料不可寫。
步驟 6：執行切換。 控制器記錄原因、版本與審批，逐步降低故障區權重，先小比例導流再擴大；長連線需要重連退避與工作階段恢復。
步驟 7：回切與演練。 備援區預熱、指標穩定並完成資料校驗後才回切；定期注入區域、依賴與控制面故障，保存真實 RTO/RPO 證據。
高品質示範回答
「我會把每個區域分成入口、無狀態服務與資料單元。全球入口依延遲選候選區域，但只有同時符合多地關鍵路徑檢查、錯誤率門檻與容量餘量的區域才接收流量。控制器對權重變化設定最短持續時間與冷卻期，先把 5% 流量導向備援區；若備援區達到並發上限，優先保護登入與寫入，暫停低優先級報表。寫入依租戶歸屬區域處理，跨區重試帶冪等鍵並暴露複製延遲。切換與回切都透過演練驗證 RTO、RPO、重連成功率與資料校驗結果。」
常見錯誤
- 只畫 DNS 與兩個區域 → 忽略容量與資料 → 補充控制器、護欄與寫入邊界。
- 單次探針失敗就摘除區域 → 造成震盪 → 使用連續窗口、冷卻期與多數訊號。
- 假設備援區能接全部流量 → 故障時級聯過載 → 計算餘量並設定分級降級。
- 把 TTL 當成完成時間 → 用戶端仍快取舊結果 → 說明連線、快取與邊緣層實際延遲。
- 只說 active-active → 沒有衝突策略 → 明確寫入歸屬、複製與冪等。
追問及應對
追問 1：DNS TTL 很長怎麼辦？
讓邊緣入口承擔更快的權重調整，把 TTL、遞迴快取與連線存活納入 RTO 預算；不能承諾瞬時切換。
追問 2：健康檢查本身故障怎麼辦？
使用多地、多探針與獨立控制面，記錄探針新鮮度；檢查過期時保持上次安全狀態或進入人工保護模式。
追問 3：備援區容量不夠怎麼辦？
預留容量並在切換前預熱，按優先級限流、降級或排隊；用壓測證明單區域故障的上限。
追問 4：如何避免切換來回震盪？
設定失敗與恢復的不同門檻、最短駐留時間、冷卻期與人工確認，記錄每次權重變化原因。
追問 5：跨區寫入衝突怎麼辦？
優先按租戶或鍵指定寫入歸屬，使用版本或冪等條件；若必須多主，明確衝突規則與不可自動合併資料。
追問 6：如何證明設計有效？
演練區域、依賴、網路與控制面故障，測量 RTO、RPO、錯誤率、恢復容量、重連成功率與資料校驗結果。
追問 7：什麼時候不該做多區域？
資料駐留、複製語意、營運能力或成本無法達標時，先做單區域加可驗證災備；多區域不是預設答案。