災難復原流程圖（IT 系統）

甚麼是災難復原流程圖（it 系統）流程

災難復原是持續運作工作中技術的那一半：在普通事故處理無法解決的事件之後，把 IT 系統和資料恢復回來，例如場地損失、儲存故障，或託管服務供應商發生的大規模中斷。它不是業務持續運作。持續運作計劃涵蓋的是系統停頓期間機構如何繼續營運（人手替代方案、備用場地、人員、供應商、對客戶的承諾）；而本流程涵蓋的是伺服器、資料，以及它們恢復回來的先後次序。兩者只在一個點上銜接：這裏使用的復原優先次序應當來自持續運作計劃中的業務影響分析，而不是來自工程師在中斷當中的臨場判斷。

它同樣不是事故管理流程，亦不是保安事故應變。正常營運中單一服務出故障，仍然留在服務台，永遠不會走到啟動這一步。如果中斷由攻擊造成，保安事故應變流程會與本流程並行運行，並決定何時復原才算安全，因為在範圍尚未弄清之前就重建，可能把存取權重新交回給攻擊者，或者毀掉證據。在流程的另一端，回切是一次有計劃的變更，屬於變更控制，而不屬於應急流程。

大多數災難復原計劃都栽在同樣的那幾件事上：沒有議定的啟動準則，於是大家花幾個小時爭論今次算不算；復原次序隨意，於是應用系統早於它們依賴的身分與資料庫服務上線；還原出來的資料還沒有人驗證就切給了用戶；以及在沒有任何應用系統負責人真正核對過的情況下就宣布服務已經回來。本範本把流程鋪在五條泳道和五個階段上，包含一個啟動決策、一次帶重做迴路的完整性校驗，以及一道由應用系統負責人而不是由做復原工作的基礎設施團隊把守的驗證關卡。

本流程圖涵蓋的內容

本範本包含

• 五條泳道，每個步驟都有明確負責人（偵測／營運、災難復原統籌、管理層、基礎設施團隊、應用系統負責人），橫跨五個階段：偵測與評估、啟動、復原、驗證，以及回切與檢討。
• 偵測與評估階段：「偵測到破壞性事件」接入「評估影響與受影響系統」和「升級至災難復原統籌」，然後才談得上宣布任何事情。
• 災難復原統籌泳道中的「是否符合災難復原啟動準則？」決策：不符合的分支終止於「按普通事故處理」，符合的分支進入管理層泳道的「批准啟動災難復原」，把宣布權留在獲授權的角色手上。
• 動員與優先次序排列：「動員災難復原團隊」，然後「按 RTO 與 RPO 排定系統優先次序」，並附註說明每個目標的含義，以及為甚麼共用依賴（身分、網絡、資料庫）要先於需要它們的應用系統復原。
• 基礎設施泳道中的復原工作：「切換到復原站點」「由備份還原資料」，以及「資料完整性是否已驗證？」決策，其失敗分支走「由較早的副本還原」，並回到還原步驟形成迴路。
• 驗證與結案：「執行應用系統驗證檢查」，以及「服務是否運作正常？」這道關卡把故障退回給基礎設施團隊；隨後是「向用戶通報已恢復的服務」、回切規劃、解除應變狀態、事後檢討，以及更新後的計劃與測試時間表。

何時使用本範本

• 編寫災難復原計劃，或持續運作計劃中的資訊及通訊科技復原章節，令每個步驟的次序和負責人都放得進一頁紙。
• 在凌晨三點的中斷把問題逼出來之前，先議定啟動準則，以及誰握有宣布災難的權力。
• 準備一次災難復原測試或桌面演練：當中的決策、迴路和交接給了你們一份檢驗計劃的腳本。
• 向可能要在計劃編寫者不在場的情況下執行部分復原工作的當值工程師做簡報。
• 向審核師或客戶說明資訊及通訊科技復原既有文件亦有演練（圖示是流程的證據，它本身並不能證明符合任何標準）。

運作方式

1. 把泳道改成你們真實擁有的角色

   把偵測／營運、災難復原統籌、管理層、基礎設施團隊和應用系統負責人換成你們真實的角色：網絡營運中心或監察團隊、IT 服務持續運作經理、危機當值表上的高層、平台與資料庫團隊、具名的服務負責人。規模較細的機構常把統籌和基礎設施兩條泳道合併；如果一條泳道裏沒有人，就刪掉它，而不是留着一條無人承擔的泳道。

2. 把你們的啟動準則寫到決策上

   令「是否符合災難復原啟動準則？」客觀到有人能在壓力之下直接套用：主場地無法進入、預計中斷時間超過某個一級系統的 RTO、主儲存或資料庫在原地無法還原。寫明獲授權啟動的角色和一位替補，並記錄在工作時間以外如何聯絡到他們。

3. 為每個系統附上真實的 RTO 與 RPO 數值

   這些目標應取自業務影響分析，而不是取自基礎設施目前做得到的水平，並按層級列在「按 RTO 與 RPO 排定系統優先次序」旁邊。除了優先次序，亦要記錄依賴次序，因為一個一級應用系統在它下面的身分、網絡和資料庫服務起來之前，根本無法驗證。

4. 寫清楚你們真實的復原機制

   對複製式基礎設施、暖備站點、第二個雲端區域和由備份媒體重建來說，「切換到復原站點」的含義各不相同。把機制、操作手冊連結、憑證與緊急存取帳戶的存放位置，以及任何需要人手執行的 DNS 或網絡變更寫進方格註釋，令這張圖在復原過程中亦用得着，而不只是在檢討時才拿出來看。

5. 定義「完整性已驗證」是甚麼意思，以及由誰判定

   把「資料完整性是否已驗證？」背後的檢查項定下來：紀錄條數、一致性與參照完整性檢查、應用層冒煙測試、與最後一個已知良好狀態的比對。決定「較早的副本」指的是甚麼、在升級呈報之前你們嘗試幾次還原，並註明每向回退一步，你們最終要按 RPO 申報的資料流失量就會增加。

6. 補上回切，然後演練這張圖並保留版本

   確認回切路徑與你們的實際做法一致：時間窗口、由復原站點回同步資料、變更控制審批，以及正式解除災難復原狀態的時點。然後演練這張圖，在事後檢討中把你們實際達成的復原時間和資料流失量與目標對照，並發布獲批版本，令大家演練的修訂版就是他們在真實事件中會遵循的那一版。

常見問題

災難復原和業務持續運作有甚麼分別？

業務持續運作關注的是在中斷期間用一切可用手段令機構繼續交付產品與服務：人手替代方案、備用場地、人員調配、備用供應商、客戶溝通。災難復原是當中的 IT 部分：恢復機構賴以運作的系統、資料和基礎設施。優先次序由持續運作工作設定，因為業務影響分析決定哪些活動最重要、以及它們最長能中斷多久；災難復原把這些時限承接為 RTO 與 RPO 目標並去達成。沒有持續運作輸入的災難復原計劃，往往會先復原最容易復原的東西。

RTO 和 RPO 到底是甚麼意思？

RTO，即復原時間目標，是一個系統或服務必須重新可用的目標時間，由中斷發生起向前計算，而不是由有人簽署啟動表格的那一刻起計。RPO，即復原點目標，是資料必須被還原到的那個時間點，由中斷向回計算，因此實際上它就是機構願意接受的最大資料流失量。兩者驅動的投入並不相同：RTO 取決於你們把基礎設施拉起來的速度（備用容量、自動化、演練），而 RPO 受限於資料被複製出去的頻率，因此無論還原跑得多快，每晚一次的備份都支撐不了短於約一日的 RPO。這兩個術語在 ISO 22301 等業務持續運作標準中都有定義。

災難復原的啟動應由誰批准，甚麼時候批准？

啟動權應當落在能夠承擔切換成本與風險的角色上，通常是一位高層或危機負責人，並配一位具名替補和一條成文的非工作時間聯絡路徑。本圖刻意把它與災難復原統籌的角色分開：統籌評估並提出建議，管理層批准，然後由統籌執行復原。觸發條件應當事先寫好，並且能夠用中斷早期就拿得到的事實來檢驗，因為代價高昂的錯誤不是啟動得太早，而是在 RTO 時鐘一直在行的時候，花三個小時討論今次算不算。

如果還原出來的資料通不過完整性校驗會怎樣？

本圖選擇形成迴路，而不是硬着頭皮往前推：「資料完整性是否已驗證？」的失敗分支通向「由較早的副本還原」，再回到還原步驟，於是驗證會重新執行一次。這個迴路正是 RPO 在真實條件下受到檢驗的地方，因為每向回退到一個更舊的副本，你們最終要申報的資料流失量就更大；到了某個程度，誠實的答案是目標無法達成，業務方需要被告知他們必須人手重建哪一段時間的資料。值得事先議定的是：你們嘗試幾次、誰有權接受比 RPO 更差的復原點，以及這個落差如何記錄。

災難復原流程應該多久測試一次？

頻率要足以令計劃反映當前的環境，而且結果要寫下來。大多數機構採用組合做法：對備份做頻密的還原校驗，全年做若干次組件級或部分切換測試，並按固定週期做一次更完整的演練，通常是一年一次，受監管行業和關鍵服務會被期望做得更多。比間隔更重要的是測試了甚麼。一份從未真正掛載並讀取過的備份甚麼也證明不了；而一次略過驗證與回切步驟的演練，往往會掩蓋真實事件中最傷的那兩個問題：應用系統負責人發現了無人預料到的故障，以及沒有議定好回到主場地的路徑。