題幹與適用場景
設計一個協調器，持續判斷多個區域的健康狀態，在滿足條件時切換流量到備用區域，並在恢復後安全回切。說明控制面與資料面的邊界、健康訊號、切換保護、資料狀態、人工核准、審計和演練方式。
AWS ARC 文件把跨區域路由控制描述為可靠的資料面開關，並強調故障機制本身要在災難期間可用。Kubernetes 文件則提醒副本、跨可用區分佈和 PodDisruptionBudget 共同決定可用性。Amazon 的軟體開發面試主題要求把知識應用到系統問題，而不是羅列服務名。
本題不同於“設計多區域 API 閘道”：重點是切換決策和恢復編排；也不同於普通健康檢查：需要處理誤判、腦裂、資料追趕和回切風險。
面試官考察點
- 健康判定是否基於多訊號並避免單點誤判。
- 切換開關、路由傳播和控制面是否能在故障時工作。
- 是否明確 RPO、RTO、資料複寫和寫入策略。
- 是否有防抖、租約、核准、審計和停止條件。
- 是否透過演練、指標和回切計畫證明系統有效。
回答前需要釐清的問題
- 目標 RTO、RPO、可用性和允許的人工介入時間是多少？
- 區域故障是整區不可達、依賴異常、延遲升高還是資料損壞？
- 備用區域是熱備、溫備還是冷備？
- 哪些資料同步，哪些請求可丟棄或降級？
- DNS、Anycast、閘道或用戶端如何接收新路由？
- 自動切換失敗時誰能人工接管？
- 如何避免兩個區域同時接收寫入？
- 回切前需要滿足哪些健康和資料追趕條件？
- 題目是否要求跨雲或只討論抽象架構？
30 秒回答框架
“我先定義 RTO、RPO 和備用區域的準備層級。每個區域獨立執行資料面，協調器只發布經過規則校驗的路由狀態。健康判定結合業務探針、依賴指標和複寫延遲，並用多數訊號、防抖和租約避免誤切。切換前凍結或降級寫入，確認備用區域達到資料門檻，再透過高可用路由控制轉移流量。所有狀態變化可審計、可回滾；回切需要重新驗證資料追趕和一小部分流量試切。”
分步驟深入解答
步驟一：定義故障模型和目標
區分 AZ 故障、區域網路分區、單個依賴故障、錯誤發布和資料損壞。用 RTO/RPO 決定熱備成本、複寫模式和自動化程度。
步驟二：劃分控制面與資料面
資料面負責服務請求和路由執行，控制面負責計算建議狀態、核准和記錄。切換依賴應儘量走高可用資料面，避免控制面故障時無法恢復。
步驟三：構建健康判定
組合業務成功率、關鍵依賴、延遲、複寫延遲、容量和人工訊號。單個探針失敗只產生候選狀態；達到門檻並持續一段時間才進入切換流程。
步驟四：執行安全切換
切換狀態應有準備、候選、已批准、切換中、穩定和回切等階段。使用租約或版本號防止並發操作，設定凍結寫入、最大切換時長和自動停止條件。
| 階段 | 關鍵檢查 | 失敗動作 |
|---|---|---|
| 準備 | 備用區域就緒、複寫延遲達標 | 不允許切換 |
| 候選 | 多訊號持續異常 | 進入核准或觀察 |
| 切換中 | 路由傳播、錯誤率、容量 | 暫停或回退 |
| 穩定 | 業務指標恢復、寫入單一 | 結束切換 |
| 回切 | 主區域健康、資料追趕完成 | 保持備用承載 |
步驟五：處理資料一致性和腦裂
明確單寫區域、全域序列或衝突解決策略。分區期間寧可拒絕部分寫入，也不要讓兩個區域同時接受不可合並的寫入。記錄切換時點和資料缺口。
步驟六：傳播路由並控制容量
路由可以透過 DNS、閘道或邊緣控制傳播；說明 TTL、快取和用戶端重試影響。備用區域必須有容量上限、預熱步驟和降級策略，避免切換後立即過載。
步驟七：可觀測、審計和人工接管
記錄健康證據、規則版本、操作者、狀態變化和路由結果。警示覆蓋切換延遲、錯誤率、複寫滯後、容量和雙寫跡象。人工操作必須冪等且有權限邊界。
步驟八：演練和安全回切
定期做故障注入和分階段流量切換。回切前確認主區域健康、資料追趕、依賴穩定和容量恢復；先小流量試切，再逐步恢復，並保留快速回退路徑。
高品質示範回答
“我設計一個雙區域、單寫主區域的協調器，目標 RTO 為 5 分鐘、RPO 為 30 秒。兩個區域都有完整資料面，備用區域保持熱快取和可接收流量的容量。
健康判定同時看業務成功率、關鍵依賴、複寫延遲和容量。連續三個觀測區間異常才生成切換候選；租約和單調遞增版本號保證只有一個協調器能推進狀態。切換前暫停主區域寫入，確認備用複寫延遲低於門檻，再透過高可用路由控制把流量轉移。路由傳播後觀察錯誤率和延遲，超過門檻立即回退。
所有狀態、規則、核准和證據寫入審計日誌。演練每月驗證 DNS 快取、用戶端重試和備用容量。回切必須等主區域完成資料追趕，先轉 5% 流量，確認穩定後再逐步恢復；若出現雙寫或延遲異常，保持備用承載並停止回切。”
常見錯誤
- 只畫兩個區域，沒有定義誰決定切換。
- 依賴單個 ping 或基礎設施指標判斷業務健康。
- 自動切換沒有防抖、租約、核准和回退。
- 忽略 DNS TTL、快取和用戶端重試。
- 讓雙區域同時寫入，卻沒有衝突策略。
- 備用區域沒有容量預熱，切換後立刻過載。
- 只討論故障切換，不討論回切和演練。
- 把 RTO/RPO 當口號，沒有映射到複寫和成本。
追問及應對
追問一：健康檢查誤報怎麼辦？
使用多訊號、連續觀測區間和防抖；業務探針失敗時先觀察或降級，只有達到規則才切換。
追問二：控制面掛了還能切換嗎？
把執行開關和必要查詢放在高可用資料面，預先分發安全狀態；控制面不可用時限制自動化範圍並提供受審計的人工操作。
追問三：兩個區域都認為自己是主區域怎麼辦？
使用租約、圍欄權杖或外部仲裁；無法確認單寫權時拒絕寫入，優先保護資料一致性。
追問四：備用區域容量不足怎麼辦？
預留容量、分級降級和限流；切換前檢查容量，不滿足就只承接關鍵流量或保持原區域。
追問五：為什麼不完全自動化？
可逆、證據充分的故障可以自動化；資料損壞、腦裂和低信心事件需要人工確認，以降低錯誤切換代價。
追問六：怎樣證明演練有效？
記錄從偵測到恢復的時間、RPO、錯誤率、容量、人工步驟和回退結果，並把缺口轉成有負責人的改進項。