關於災備和業務連續性,前期已經分享了很多技術相關知識,如雙活解決方案,資料中心業務負載均衡技術等(整理成文的“技術解析”資料和文章連結如下,請需要的小夥伴可以透過“原文連結”獲取)。
但災備建設的最終目的就是要保護業務的連續性執行,除了技術層面的支撐外,還有人員、規劃和流程等非技術決策層面支撐。養兵千日,用在一時。只有技術和規劃通力配合,才能在真正發生災難時保證業務連續性(以下內容參考自英方“中國災備技術和行業白皮書”,首先關註公眾號,然後在底部採用鍵盤迴復關鍵字“災備白皮書”獲取完整白皮書)。
因此,業務連續性規劃是進行災備建設的大前提。沒有業務連續性規劃,災備建設就沒有意義,充其量只能做到資料不丟失,不能及時恢復業務執行,而保障業務連續性執行才是真正核心。透過業務連續性規劃,分析梳理出各項業務的恢復優先順序及其恢復要求(RTO、RPO 以及恢復業務所需的資源等),進行業務連續性規劃的方法通常採用國際上流行的DRI 十大最佳慣例:
-
①規劃啟動與管理
-
②風險評估與控制(RA)
-
③業務影響分析(BIA)
-
④制定業務連續性策略
-
⑤應急準備及響應
-
⑥編製和貫徹實施業務連續性計劃
-
⑦認知與培訓計劃
-
⑧業務連續性計劃的演練、審計和維護
-
⑨危機溝通
-
⑩與外部機構的協調
這是國際通用BCM規劃的方法,適用於企業和業務功能,當然也適用於資訊系統。業務連續性規劃確定了保護業務的各項要求(如RTO、RPO等),支援業務執行的資訊系統自然就要根據這些要求來確定相應的資訊系統恢復標的和恢復策略。
另外,透過業務連續性規劃梳理出業務的恢復要求和恢復優先順序後,就要根據這些要求來梳理支援這些業務的IT 應用,同樣需要分析出這些IT 應用的恢復優先順序和恢復指標(RTO、RPO,以及恢復所需的資源等)。
災備規劃採用的方法與業務連續性規劃的方法基本一致,主要區別僅在於前者針對的是支援業務執行的IT應用和系統,後者主要關註的是業務流程。這裡針對IT應用和系統的恢復要求應該與針對業務的恢復要求相匹配。透過災備規劃,確定所有支援業務執行的IT系統的各項恢復指標,並制定IT系統的恢復策略以及IT系統的恢復計劃。
根據災備規劃對支援業務執行的IT 系統提出的恢復要求和恢復策略來設計災難恢復技術方案,例如同城災備、異地災備、兩地三中心、雙活、雲災備等等。需要註意的是,評價這些技術方案的適用性時,並非恢復時間越短就越好(恢復時間越短往往成本也越高),滿足災備規劃確定的恢復要求才是最為重要的。只有滿足災備規劃提出的恢復指標要求、技術成熟可靠、成本效益高的災備方案才是最佳選擇。
災備方案的實施是確保所設計的災備方案真正有效的重要環節,需要制定詳細的工作計劃,包括場地選址、產品選型、服務商選擇、資源保障、項目管理、驗收評審、演練測試等內容。同時還應該根據災備設計方案,結合業務連續性規劃要求,制定出完整的災備計劃(包括災難應急響應總體預案、危機溝計劃、各系統的專項應急預案等),確保各部門在災難發生時能夠統一協調地行動。
風險分析與業務影響分析
1. 風險分析
企業需要根據自身所處環境的實際情況,確定IT執行環境中存在哪些無法接受的物理威脅或者可能發生的災難,並對災難發生的可能性、目前可能的防護措施的有效性和該災難所威脅的資產價值進行分析,最終得到帶有優先順序別的需要防範的風險及其分級串列,並制訂出可能的處理方法。例如接受該災難發生時的風險而不進行防範、制訂該災難的預防措施或者採取購買保險等風險轉嫁策略。
2. 業務影響分析
在本階段,透過走訪各業務部門的相關人員對各種業務流程進行分析,瞭解各種業務流程對企業的重要性和時間敏感性。同時根據相關的評判原則,得出在核心流程由於災難發生而無法正常進行時企業本身的損失情況。這種損失可能是可以量化的,例如單據的丟失、計算的錯誤而導致的直接損失;也可以是無形的損失,例如客戶滿意度及競爭優勢的丟失。透過對可量化和不可量化損失的綜合考慮,得出各種核心業務流程對於災難受損的可容忍程度,並作為確定其恢復優先順序的決策依據,最終確定這些核心業務流程的恢復要求指標。
災備方案設計
結合分析階段的分析成果,以及企業本身在災備上的投入,制訂企業短期、長期範圍內的災備策略和標的,並有意識地將企業本身的人員組成和組織架構做出調整以適應策略要求。本階段最為重要的是制訂出災備的具體實施方案。
災備方案可供選擇的範圍很大,但所有的災備方案都必須考慮的因素包括恢復時間、實施與維護災備策略所需的投入等。災備恢復時間的需求越短,所需的實施成本就越大,實施難度也就越高。
災備計劃制定
有了IT 系統的恢復方案,只能夠保證在災難發生時,IT 系統的恢復能夠支援業務的恢復標的,但是業務的連續性並不只是IT 系統的恢復。因此,災備方案在設計中還需要涉及包括辦公場地、辦公裝置、緊急流程、指揮架構、人員排程等多方面、多部門的綜合考慮。只有業務執行過程的每一個環節都達到災備標的的要求,才能夠認為災備方案的標的得到了滿足。因此,需要制定一個完整的災備計劃,來統一協調各部門在災難發生時的行動計劃。同時制定災備計劃時需要確保其與企業業務連續性計劃協調一致。一般來說,每個企業都應該設立一個由領導掛帥,各業務部門和IT 部門聯合組成的一個災備指揮小組。
災備方案實施
災備體系的搭建經常需要涉及到公司內多個部門的協調,因此在方案實施的過程中,需要把每項工作的內容、標的要求、實施的方法步驟以及督促檢查等各個環節都做出具體明確的安排,具體落實到工作分幾個階段、什麼時間開展、什麼人來負責、領導及監督如何保障等。
方案在實施的過程中具有很強的規定性,表現在一方面,方案實施要根據方案分析和方案設計的具體操作流程進行,而不能是隨意進行。有效的災備操作流程往往可以節省大量的時間和減少錯誤。反之,就會帶來不必要的損失。例如,在虛擬環境下的災備系統,就要提前規劃需要用幾臺伺服器去虛擬出三十、四十,甚至上百的虛擬伺服器,而且需要長期執行。如果沒有好的操作流程,不利於災備中心的運維。另一方面,方案實施工作具有強制性,一旦開啟,相關部門單位就要按照具體計劃認真組織實施。
災備演練
災備演練是基於不同災備類別中某一特定的場景而進行的,災難場景不同、災備技術複雜度不同,演練的技術過程與週期也不盡相同。
具體的演練包括:系統更新、調整,原有的災難恢復預案是否仍然有效;災備系統是否需要進行有效的更新;系統切換流程、步驟是否有遺漏和錯誤;災備系統的切換時間是否可以滿足業務的恢復需要等。常見的三種災備演練方式包括:
桌面演練也叫“沙盤推演”,是最基礎的災備演練方式。透過對初始災難恢復預案的一個理論驗證,進而測試急響應預案和災難恢復體系的完整性和有效性,使相關人員瞭解應急響應及業務恢復流程,全面驗證技術及業務管理指揮、流程操作、協調配合等方面的綜合能力。
模擬演練以桌面演練結果為基礎,由IT 部門與相關業務部門參加模擬演練,採用模擬資料和模擬業務系統執行演練。模擬演練的過程高度接近真實災難發生時的處理過程,透過演練可以檢驗災備系統的可用性、災難恢復預案的可行性以及增加參演人員對災難處理過程的感知度與配合的默契度。
作為災備演練的最高的階段,實戰演練的場景最為真實,更易於發現潛在問題併進一步完善災備系統,但隨之而來的就是演練成本的提高。因此,在實戰演練中,也會存在很多挑戰,這時,關鍵是使其理解並支援演練能夠週期性地進行,同時發現問題及時改進才是成功的演練(無論是否用到真實環境),應避免流於形式的表演。
專家服務(ADTIS)是災備行業常見的諮詢服務,以英方為例,已經推出的專家服務業務,旨在減少中間環節、降低無效成本,並最終實現快速部署、高效可靠的專家級業務服務體系,從0 到100全程專家指導;專家服務特點是:
-
①針對性強、效力高、可執行;
-
②階段劃分和決策點明晰;
-
③經驗證的模組化實施方法;
-
④終身服務。專家服務的5個階段如下:
評估階段(Assessment)
需要對企業的整體災備標的及投入進行有效的評估,包括RPO、RTO的相關指標以及IT 系統的整體架構,主要以專題會的形式進行,並且就相關事項形成書面紀要,評估階段主要以免費的形式進行,但由於評估階段也需要投入大量的資源進行對接,因此部分服務會保留收費的權利。
設計階段(Design)
針對評估的具體結果,在雙方合作意向明確的前提下,由專家團隊主導進入設計階段。此階段將會直接影響專案的最終交付。因此,英方將以經驗證過、定的系統為藍本提供完善可執行的災備設計規劃,併在此過程中,積極聽取需求方的意見。
測試階段(Test)
為保證專案的順利進行,英方將對已經設計好的災備系統進行實地測試,同時保證在測試的過程中不對使用者的現有系統造成影響,測試階段主要包括軟體的具體使用、功能的具體實現以及災備演練。測試可以暴露災難恢復計劃的不足之處,測試也可以幫助我們評估計劃執行人員的快速響應能力和效率,災難恢復計劃的每一個要素都必須測試,保證其恢復過程的準確性。
實施階段(Implementation)
此階段指專案的現場或遠端交付階段,此階段的主要工作是專案實施人員根據設計、測試階段確認的具體需求內容進行具體功能的實現工作。在功能實現的過程中,專案實施人員將記錄軟體實現的詳細過程,便於售後服務之用。每一個實施技術人員都將嚴格按照要求記錄、存檔。
維護階段(Support)
在新需求、新技術的不斷湧現以及新的內部和外部規則的變化過程中,IT 系統也會隨之改變,所以要確保災難恢復計劃的有效性就必須定期的檢查和修改計劃。專案上線執行後,系統運營維護的主要工作將交由客戶進行,但英方將提供一整套完善的技術支援服務,保證在產品生命週期內有效性。
技術相關文章
溫馨提示:
請搜尋“ICT_Architect”或“掃一掃”二維碼關註公眾號,點選原文連結獲取更多技術資料。
求知若渴, 虛心若愚—Stay hungry, Stay foolish