沒測試過的災備系統才是企業最危險的敵人
原創【51CTO 7月11日外電頭條】編者按：在自然災害頻發的地區，企業往往比較重視災難備份、恢復的工作；但是每年真正遇到災難的時候，總是有企業因為關鍵數據的恢復遇到問題而遭受損失。在這種情況下，是否真實的測試你的災難恢復系統，是確保在災難真正來臨的時候能夠按照預期進行數據恢復的關鍵要素；而且身為管理員，一定要清楚的認識到，不是所有的數據都需要在第一時間得到恢復，確認哪些數據是業務最關鍵的部分也是在制定恢復策略中重要的工作之一。下面，CIO.com的企業應用和SaaS專家Todd R. Weiss為我們介紹了他對災難恢復系統定期測試的建議和經驗。
如今美國已經整體步入夏季，這意味著我們企業中的IT系統隨時可能在剎那間遭受颶風、龍卷風、洪水、森林火災、劇烈的雷暴以及其它各種自然災害的襲擊。
考慮到上述情況，相信大家一定都已經為自己的企業IT系統及關鍵性企業應用準備了災難恢復方案。然而，這些方案只能說是防范措施的基礎。
上述體系一旦搭建完成，只需輕按一個開關，我們就能在必要時從異地數據中心處托管自己的關鍵性應用程序備份。然而要保證其正常工作，必要的維護、更新及定期測試絕對不能缺少。因為只有這樣，災備體系才能在災難來臨時真正成為積極可靠的安全后盾。
對于多數IT機構來說，往往壓根不做這類測試。事實上如果沒有按計劃嚴格執行的審查及測試，災難恢復體系本身就是一顆蠢蠢欲動的定時炸彈。
沒做過測試，一切都是浮云
“我理解對于機構來說，隨便湊過去按下開關將正在運行產品的服務器關閉這種狀況聽起來有多可怕。不過在進行災備機制檢測時，這是必要的一環。”Daniel M.Kusnetzky說道。他是Kusnetzky集團有限責任公司的首席分析師。“其實一套從未進行過測試的災備系統才是企業最危險的敵人。”
測試整套體系最重要的原因是，Kusnetzky說，一旦設備并未如預期般運作，那么立即著手處理問題總比到了電力真的中斷時才干著急要好。畢竟進行測試時我們的技術支持團隊能提供在線指導、整套業務系統也并未真正面臨自然災害。
IT專職人員必須能在緊要關頭為關鍵性業務應用的上線及運行、包括這些應用所必需的一切連接系統提供保障，Kusnetzky說道。“這不僅涉及到應用程序，同時還要考慮支持這類應用運行所必不可少的完整配置。如果這些條件不能保證，我們恐怕就必須對進程或是應用程序本身進行重新配置。”
而要想檢驗上述設置是否按既定方針實施，惟一的方法就是進行測試。測試、調整、再測試，災備體系必須通過這種流程加以完善，他說。
“僅僅將應用程序復制到別處并嘗試啟用，這種無意義的做法不會為企業中的員工帶來任何實質性的幫助，”Kusnetzky如是說。
在這方面，虛擬化技術能夠幫上大忙，因為如果工作負載實際是運行在一套或多套虛擬機上的，那么這些負載就能夠良好地適應我們在災難恢復策略中所預留的后備硬件設備，Kusnetzky指出。基于同樣的原因，使用虛擬存儲技術也是有所助益的。
與此同時，虛擬化也要被客觀看待，它無法解決災備方案中的全部問題。“虛擬化幫得上忙，但與其它各種技術一樣，它也不是萬能的。”他說。“它只是種工具。我們需要同時引入其它技術協同作戰。”
測試方式的選擇非常關鍵
Gabriel咨詢集團的一位分析師Dan Olds在談及災備時表示，災備機制測試方式的選擇非常關鍵。他認為最好的辦法是每次對企業內部的單獨一套系統進行測試，這樣不僅達到了預期目的，更可以盡量減少對IT人員及公司日常工作的影響。
“這不僅是為了保證緊急情況下能夠正常工作而對你的（災難恢復服務）供應商進行測試，這個過程同時也能夠讓企業中的員工切身了解具體的操作流程，”Olds說道。“有了這樣的知識及經驗儲備，意外發生時大家就不會驚慌失措了。事實上災備體系的使用過程應該是舒適自然的，而且以這樣的狀態進行操作也的確能使其發揮更好的保障效果。通過體驗我們會認清啟動災備不需要像與時間賽跑那樣搏命，也不存在洪水持續上漲那種不成功便成仁的緊迫感。”
通常情況下，這種注重細節的測試并不該由客戶來進行，當然干脆不做就更不可取了。“我要對這些應用程序進行測試；我必須有膽量著手進行。大家要給自己這樣的信念。”
Olds強調，請務必留心冗余性與可用性之間的差異，這在涉及到緊急情況下企業數據及應用程序的保障方面至關重要。“我們都希望自己的數據得到全天候的保護，無論遭遇何種惡劣的情況，數據絕不能丟失。當然，輕度損失在所難免，最近半小時的數據無法保障可以理解。”
但我們同時要看到，如果災難真的來臨，并不是所有數據都需要立即恢復訪問。那些最重要、最關鍵的業務信息才是我們在緊急情況下亟需保護的重中之重。
“這就要求我們制定優先次序，”Olds說。“將整套基礎設施完全制作成鏡像，雖然可以保證立即恢復每一個應用程序，但這種做法無疑是愚蠢的，且帶來的成本既高昂又不必要。絕大多數企業根本不需要這種級別的可用性。”
排布優先級的方式之一，是為那些在緊急情況下會最先被用到的業務應用及數據制作名單，恢復時即從名單上的項目入手。而其它那些相對將要的應用程序及數據則可以在災難過后慢慢恢復。
同時，在制訂這些規劃時也別忘了從企業內部聽取不同的聲音。“IT部門負責人需要確認自己名單上的項目確實是最關鍵、最需要及時恢復的業務內容，”他說。“我們必須確保IT人員的想法能夠得到業務部門人員的認可和支持。”
通過對應急預案進行定期測試，我們能夠確保全部關鍵性內容都涵蓋其中而沒有遺漏，例如網絡拓撲細節及公司的IP地址等。“這都是我們無需論證就必須保護好的重要信息，”Olds說道。“大家必須竭盡所能將其全部導入鏡像，以便在服務中斷時能夠借助企業外部的基礎設施使其盡快重新運作。而如果企業中的數據中心被洪水吞沒，那么這種災備預案還要具備一定的可持續性。”
一旦大家開始進行測試，一定記得將這種良好的習慣堅持下去，尤其是應用程序或基礎設施出現變動時。原因很簡單：我們必須確保系統方面的定期變動不會與現有的災難恢復系統相沖突，并進而導致緊要關頭失去保護作用。
“我們要時刻提醒自己，能夠通過正確的數據及其它相關因素將應用程序恢復到災前狀態才是我們建立災備機制的根本目的，”他說道。“目的清晰是關鍵。我建議大家在應用程序更新過程中添加檢查對話框，這樣一來就能及時了解應用程序或系統的變更是否會對相關備份恢復計劃產生影響。一切按計劃進行是我們的終極目標，因此上述類型的變化都應詳細加以記錄并不斷檢查，以確保整套體系運行良好。”
缺少了測試，這樣的災難恢復規劃就是不完整的，并且很可能在需要的時候起不到應有的作用——這就違背了當初我們部署該系統的初衷了。
原文：If disaster strikes, will your critical enterprise apps be ready?
【編輯推薦】
