Azure Site Recovery如何按RPO及RTO規劃容錯移轉？

先了解問題：雲端服務如何維持可用性

Azure Site Recovery（ASR）是協助工作負載在主要位置中斷時複寫及接管的災難復原服務。真正的設計起點不是按下「啟用複寫」，而是先與業務定義 RPO（可接受的資料遺失量）及 RTO（可接受的恢復時間），再決定複寫頻率、依賴順序、網絡、容量、測試和回復策略。 對企業而言，設計的價值在於把技術設定轉化為可量度、可監控及可恢復的服務能力。下文從架構、操作流程、安全控制及本地部署情境逐步說明，方便管理員建立自己的檢查清單。

任何雲端配置都應先在測試環境驗證，再以最小範圍推進生產。記錄變更前後的設定、測試時間、責任人及回復方法，出現異常時才可以快速還原，而不是在事故中猜測哪一項設定曾經被修改。

RPO、RTO與Site Recovery的關係

RPO回答「事故發生時最多可以遺失多久的資料」，例如 RPO 15 分鐘表示企業不能接受超過約 15 分鐘的資料差距；RTO回答「由中斷到服務恢復可接受多久」。兩個數字越嚴格，通常代表複寫頻率、備用容量、網絡頻寬及演練要求越高。RPO/RTO 應按業務服務而非單台 VM 訂立，並記錄相依的 DNS、身份驗證、資料庫及網絡設備。

Microsoft Azure Site Recovery概覽說明複寫及復原能力；事件後復原亦應參考 NIST網絡安全事件復原指南，包括決策、溝通、取證及復原後檢討。

不同容錯移轉模式

設計復原計劃

1. 建立服務依賴圖——排列身份、DNS、網絡、資料庫、中介軟件及前端的啟動順序，不能只按 VM 名稱排序。
2. 配置複寫及容量——驗證來源與目標區域、網絡、磁碟、IP、配額及加密設定，按變更率估算複寫頻寬。
3. 建立Recovery Plan——將機器分組，加入啟動延遲、腳本及人工檢查點，並把 RPO/RTO 目標寫入驗收標準。
4. 執行隔離測試——測試應用登入、資料一致性、DNS、監控、備份及外部整合，量度實際恢復時間。
5. 正式切換與回復——準備通訊、決策權、變更凍結及回復條件；服務穩定後重新保護並更新文件。

網絡、身份與資料一致性

容錯移轉後能啟動 VM，只是第一個檢查點。目標區域要有可用子網、NSG、路由、VPN/ExpressRoute、負載平衡、DNS 及身份驗證；應用亦可能依賴硬編碼 IP、外部 API、授權伺服器或資料庫一致性。測試時應用與業務驗證清單逐項確認，而不是只看 Azure Job 顯示成功。

對有交易性的系統，須由應用及資料庫負責人確認複寫點可接受，並在正式切換前明確決定是否允許部分交易重做或資料核對。網絡安全策略不應在災難時被完全放寬，可參考零信任架構及網絡分段。

演練、溝通與改進

至少按業務重要性安排週期性測試容錯移轉，測試包括技術操作、值班通知、管理層決策、供應商聯絡及客戶溝通。每次演練要記錄開始時間、達到可用的時間、實際 RPO、失敗步驟及未覆蓋的依賴，再由負責人跟進修正。災難復原不是一份放在抽屜的文件，而是需要持續測量的營運能力。

常見問題

延伸閱讀

權威資料來源

Microsoft Learn：Azure Site Recovery概覽；NIST SP 800-184：Guide for Cybersecurity Event Recovery。