當資料中心因天災、火災或重大故障全面癱瘓，Disaster Recovery Plan（DRP） 是唯一能讓業務在預定時間內重新上線的技術保障。本文聚焦 RTO/RPO 目標下的異地切換核心策略。
RTO 與 RPO：DRP 的兩大設計基準
RTO（Recovery Time Objective） 定義系統必須在多少時間內恢復服務；RPO（Recovery Point Objective） 定義最多可接受遺失多少時間的資料。兩者直接決定備援架構的成本與複雜度。
RTO 越短，代表需要 Active-Active 或 Warm Standby 架構；RPO 越小，代表需要同步複寫（Synchronous Replication）而非非同步。業務關鍵系統通常設定 RTO ≤ 4 小時、RPO ≤ 1 小時，一般內部系統則可放寬至 RTO 24 小時、RPO 8 小時。兩個數字必須經業務單位與技術團隊共同確認，不可由 IT 單方決定。
異地備援切換：三層核心程序
DRP 切換程序分三層執行。第一層：宣告災難（Disaster Declaration），由授權人員確認觸發條件成立，啟動 DRP 流程，避免誤觸造成不必要的中斷。第二層：基礎設施切換，將 DNS、負載平衡器、資料庫主從角色切換至備援站點，此步驟需預先腳本化以減少人為失誤。第三層：應用層驗證，逐一確認關鍵服務健康狀態（Health Check）、資料一致性與外部整合連線，確保系統切換後真正可用而非僅能啟動。
每次切換步驟須記錄時間戳記，作為事後 RTO 是否達標的驗證依據，並納入 DR Runbook 持續更新。
💡 重點整理
- RTO/RPO 需業務共識：數字必須反映真實業務容忍度，而非技術假設。
- 切換程序必須腳本化：災難現場的人工操作極易出錯，自動化是關鍵。
- 定期演練不可省略：每半年至少執行一次完整的 DR Drill，確認 Runbook 有效。
- 回切（Failback）同樣需要計畫：主站恢復後的資料同步與服務回切，需獨立設計程序。
DRP 的價值不在文件本身，而在可執行、可驗證的演練記錄。一份從未測試過的 DRP，在真實災難發生時幾乎等同於沒有計畫。從 RTO/RPO 定義到切換 Runbook，每個環節都需要持續維護。
留言
張貼留言