一個災害兩樣情，災害復原演練不可臨陣磨槍

備援體系範圍擴大
我們已經有做磁帶備份了，還要做什麼備援，這有不一樣嗎？」

「又是要花錢的，錢花了這麼多，根本看不到效益。」

「真的有天災發生了，大家都逃不掉，為什麼我們要花那麼多功夫？」

「想太多了，事情不會發生，就算發生了，也不見得會出在我們身上。真的碰上了，到時候再來想辦法，反正有錢就可以解決。」

「沒事好端端的，為什麼要參照國外的標準？」

「我們每年都有做測試啊，反正拿一捲磁帶，到廠商那邊重新倒資料，備援演練不是這樣就好了，為什麼還要找使用單位？」

上述這些答案，都是在聽到備援演練時會碰到的反應。直到這幾年，大家對於災害復原計畫 (Disaster Recovery Plan)、企業持續營運計畫（Business Continuity Plan）這些名詞才比較熟悉一些。在國內很多時候，測試報告是為了查核時當作佐證之用。但是在國外，對於備援演練所重視的程度，絕對超出我們的想像。以歐洲某些國家為例，當他們的金融機構設立之初，備援演練一定是金融檢查的重點項目，一旦備援計畫無法執行，甚至連開業的許可登記都無法取得核准。更不要說從美國911恐怖攻擊後，企業加強備援演練的測試與訓練。反觀國內，則是這幾年在推動ISMS認證，因為驗證條款上的相關需要，才逐步受到重視。甚至有國外顧問半開玩笑的說，國內的業務持續性管理這一塊，還是一片完全未經開墾的原始山林。不管這句話背後的依據為何，由此就可知道國內外對於備援所重視的差異程度。

我們先來釐清一個觀念，備援計畫一定是發生意外災害才用的到？如果我說，即便沒有發生地震、洪水等天然災害，備援計畫還是有用到的一刻。不要以為這是天方夜譚，有一句成語叫做「池魚之殃」有聽說過吧！你可以想像一下，在高樓密布的都會叢林中，會因為樓上失火，天花板承受不了消防水柱水壓的負載，而導致機房天花板整個崩塌，機房無法使用的慘狀嗎？你再模擬一下這樣的場景，因為燃燒的灰燼，堵塞了冷氣通風口，進而造成空調設備無法使用，電腦系統被迫關機的窘況嗎？這些都是曾經發生過的案例，只見一群人手足無措，如無頭蒼蠅般到處亂飛，這就是備援計畫可以發揮功用的時候。簡單的說，當系統因為異常事故，在預定的時間內無法恢復系統正常作業，就是備援計畫啟動的時機。所以現在備援計畫已經不僅限於天然災害，包括電腦中毒、系統入侵、硬體故障等事故管理( Incident Management) 都一併納入，把整個備援體系的範圍更加擴大。



隨時做好災害復原演練
但什麼是預定的時間內？三十分鐘、三小時、還是三天？這個時間不是用喊出來的，包括了法令的要求、組織對客戶的承諾，最重要的是組織所能接受業務中斷的時間。在系統復原的時候，有一個很重要的因素是不可忽略的，那就是資源排擠效應。在意外狀況發生的時候，可使用的資源一定不如平日正常那樣豐沛，在有限的資源下，到底那些系統是組織的命脈，這些系統越早恢復正常作業，對組織的損害越小。這一定需要與其他單位事前討論出來，不能到時後再來決定，或是那個系統容易恢復就先恢復作業。不能單純從資訊單位的角度來看，結果資訊單位覺得ERP系統最重要，到頭來是資金調撥系統影響最大。一個不起眼的郵件系統，也許就是組織生存的命脈。因此備援計畫一定要從整體組織來考量，到底組織在系統中斷期間，會產生多少的損失，一般常聽到的營運影響分析(Business Impact Analysis) 指的就是這部分。不論是用問卷、訪談所得出來的結果，都是日後決定需要採用何種恢復方式的依據。

接下來才是備援地點及備援方式的選擇，國內一般是跳過前面評估的階段，直接選擇備援點的比較多。備援地點的遠近，還有備援方式，都會影響到正常作業恢復的時間。不要忘了，系統無法運作的時間，是從系統中斷的那一刻開始，而不是從到達備援點開始作業算起。因此後續的備援計畫，無疑又是一個巨大的工程。舉個最簡單的例子，同樣是系統無法運作，火災處理的方式和水災處理的方式就截然不同。在火災發生的時候，現場因為要經過勘驗，所以整個區域是無法進入的。而水災發生時，還可以踩著滿地的泥濘進行搶救。連續假期的時候，和正常上班的時間，處理的方式也有差別。光是長假期間要找人可能都是一個大問題。這些林林總總的差異，也都是在訂定備援計畫時需要考量的。不要覺得這是件小事，在那種分秒必爭的時候，任何一個小小的閃失都會影響到復原的進度。平日每天見面的同事，一但有狀況要聯絡時，卻發現所留的電話號碼早已暫停使用。更不要說找不到備援地點，或是操作程序錯誤這些瑕疵。

計畫完成之後，如果沒有經過演練，那計畫將永遠擺在桌上，不會有任何的作用。既然整個備援作業是從組織面全面考量，自然使用者也是要參與演練。如果沒有經過演練，如何確保平日已熟悉電腦操作畫面的人員，能夠用人工方式完成既定的工作？每次的演練，各式各樣的狀況都會發生，不是程式版本沒有同步更新，要不然就是網路設定錯誤，還有從備援點切不回來正常作業的情況。其他單位狀況也不見的好到那裡去。會計的報表因為沒有列印而無法結帳，為了節省費用而使用的網路電話也不能用。這些問題都會在測試的時候一個一個浮上檯面。整個測試，不是說恢復正常作業就告一個段落，然後到明年又再重新人仰馬翻的做一次測試。在演練過程中所有發現的問題，都要找出背後真正的原因，然後找出解決方案，並且持續追蹤，直到解決方案確實建置才算完成。同時要修訂相關的計畫及作業程序，以避免同樣的問題再次發生。

業務持續性管理，絕對不是只有資訊單位的事，而是整個組織的業務。計畫制定的過程，除了縝密的思考外，更需要不斷的溝通與教育。備援計劃，也不是一次性的工作，現有系統一但有重大的變動時，都需要更新備援計畫。更不要說系統更新或是作業流程調整。在國內普遍缺乏風險意識之際，未來備援這條路，還有許多值得努力的地方。