實施IT服務連續性管理的目標是確保發生災難時,IT服務的可用性(可用性介紹,參見「DevOps運維繫列:可用性管理」)和性能保持在足夠的水平。其實連續性管理就是目前的災備管理(IT方)。安全
定義:災難 (ITIL 4)網絡
對組織形成重大損失或重大損失的突發性意外事件。要將事件歸類爲災難,該事件必須符合組織預約義的某些業務影響標準。架構
如今不少企業都在作連續性管理,尤爲是金融行業,包括銀行、證券、保險、消金等等。企業首先要應對監管的要求。不管國際仍是國內的標準組織和監控機構,針對連續性,都出臺了一系列的管理規範,見下(只是一部分):運維
國際標準 | ISO 22301:2012業務連續性管理 |
國家標準 | GB/T30146-2013 公共安全業務連續性管理體系要求 |
國家標準 | GB/T20988-2007 信息安全技術信息系統災難恢復規範 |
行業標準 | 保險業信息系統災難恢復管理指引(保監發[2008]20號) |
行業標準 | 銀行業重要信息系統突發事件應急管理規範 |
行業標準 | JR/T 0044—2008 銀行業信息系統災難恢復管理規範 |
其次,確保服務連續性變得愈來愈重要和困難。尤爲在數字化轉型的背景下,不少企業的業務都嚴重依賴於IT系統,使得IT服務連續性的做用也愈來愈大。嚴重的服務中斷可能會給企業帶來災難性的影響。ide
在ITIL 2中,服務連續性管理流程是服務交付其中的一個流程。在ITIL 3中,連續性管理是作爲服務設計中的一個流程,流程活動與ITIL2相比,沒有大變化,不過針對風險管理的方法進行了詳細的解釋。那麼在ITIL 4中,IT服務連續性管理有哪些新亮點呢?微服務
定義:服務連續性性能
在發生災難事件或中斷性事件後,服務提供商在可接受的預約義級別上繼續服務運行的能力。測試
在這個定義中,咱們須要界定連續性管理的範疇是災難,連續性管理是針對災難性事件而制定的計劃和響應措施。非災難性事件的管理,通常不包括在IT服務連續性管理實踐中,如雲計算
●小故障。根據業務影響,應將故障視爲輕微或重大故障。重要的是要考慮諸如受影響的維修行動、故障規模、故障時間等因素。spa
●戰略、政治、市場或行業事件
定義:服務連續性計劃
服務連續性計劃指導服務提供商在服務中斷後響應、恢復和恢復到正常水平.
服務連續性計劃一般包括:
●響應計劃:服務提供商最初如何應對破壞性事件,以防止損壞,例如在火災或網絡***狀況下。
●恢復計劃:服務提供者如何恢復服務以實現RTO和RPO。
●恢復正常的操做計劃:服務提供商在恢復後如何恢復正常操做。
指標:RTO和RPO
定義:RTO 恢復時間目標
在服務中斷後,業務功能的缺少嚴重影響組織以前,能夠通過的最長時間。這表示必須恢復產品或活動或必須恢復資源的最長商定時間。
定義:RPO 恢復點目標
爲了使活動在恢復時可以有效地運行,必須將活動使用的信息恢復到該點。
RTO 規定了業務能夠中斷的時間。RPO規定了可接受數據丟失的時間段。一般,RTO和RPO都是做爲連續性管理的衡量指標,寫入SLA中。
服務連續性管理活動分爲如下五個過程:
●服務連續性管理的治理
●業務影響分析
●制定和維護服務連續性計劃
●測試服務連續性計劃
●響應和恢復。
1. 服務連續性管理的治理
服務連續性治理主要包括三個活動,定義範圍、策略選擇和意識與演練計劃的開發。通常作連續性的企業,主營業務都非龐大,IT系統更是錯綜複雜,交互繁多。出於經濟效益的考慮,企業不可能保證全部的應用和基礎設施組件都有備份,因此首先根據BIA(業務需求分析),肯定關鍵業務和組件。而後根據不一樣的級別,選擇不一樣的災備方式和演練計劃。
2. 業務影響分析 BIA
業務影響分析包括如下活動:
●VBF識別
●中斷後果分析
●VBF相互依賴性識別
●肯定服務連續性要求
ITIL 4中對於這些活動並未給出具體的實施方法。後面我會專門寫一篇,如何開展BIA。BIA的難點在於技術實施層面,必須有系統架構師參與,進行風險評估也須要技術人員。
3. 制定和維護服務連續性計劃
這個過程包括的步驟是:
●服務連續性策略制定
●服務連續性計劃制定
●服務連續性計劃初步測試
服務連續性策略能夠包括連續性的等級,對應的RTO和RPO的目標,可用性目標,演練的等級。如:
金融領域的雲計算平臺容災能力等級要求
影響範圍 |
危害程度 |
||
較小影響 |
通常影響 |
嚴重影響 |
|
內部輔助管理 |
1級 |
2級 |
3級 |
內部運營管理 |
2級 |
3級 |
4級 |
公民、法人和其餘組織的金融權益 |
3級 |
4級 |
5級 |
國家金融穩定、金融秩序 |
4級 |
5級 |
6級 |
關鍵指標:
容災等級 |
RTO |
RPO |
可用性 |
3級 |
<=24小時 |
<=24小時 |
|
4級 |
<=4小時 |
<=1小時 |
|
5級 |
<=30分鐘 |
約等於0 |
|
6級 |
<=2分鐘 |
0 |
演練等級在《保險業信息系統災難恢復管理指引(保監發[2008]20號)》規定爲:桌面演練、模擬演練、實戰演練、部分演練和全面演練。
4. 測試連續性計劃
這個過程包括執行演練和連續性評審兩個活動。
5. 響應和恢復
響應包括對應供應商服務連續性計劃的調用。
先說區別。
從目標來看,服務連續性管理不包括對沒有嚴重影響的小故障或短時間故障的處理。它側重於與重大損害相關的風險,而無論其發生的可能性或可能性有多大。一般,這些都是緊急狀況:火災、洪水、停電、數據中心故障等等。可用性管理實踐並無忽略故障對服務提供者和使用者的負面影響,可是在這個過程當中也會考慮到單個組件的輕微中斷。
從衡量指標看,服務連續性是RTO和RPO,可用性的指標是MTTR,MIBF,Availability%。
再說聯繫。
服務連續性和可用性在實施方法上,都會用到VBFs和風險評估,須要對服務失敗進行BIA分析。因此實施過程當中造成的文檔和輸出內容,均可用於這兩個實踐。由此能夠看出,系統拓撲圖,VBF,風險評估,對於IT服務運維管理,是多麼的重要,這些都是基礎信息,除了用於這兩個實踐,還能夠用於配置管理。惋惜的是,不少企業在這個基礎層面都是缺失的。不少人提了一堆高大上的方法論和技術,可是基礎卻作不到位,致使運維管理就是一團散沙,無據可依。
咱們若是去作災備,只看ITIL講解的IT服務連續性管理實際上是遠遠不夠的,還須要結合行業標準和管理規範,來解讀監管要求。主要緣由是ITIL中所講解的IT服務連續性管理實踐主要是從IT層面來說解的,可是從企業運維的角度,應該實行的是「業務連續性管理」。惋惜的是,ITIL4對於這個層面有一些解釋,可是解釋的不夠全面。關於業務連續性管理的監管解讀,後面我會再寫一篇。
連續性管理不管是從方法論仍是技術實施方案,都是很是複雜的,尤爲是不少企業目前在應用雲架構和微服務的新技術。如何作災備,其技術方案是目前討論的熱點。當前市場上出現了很多專門作服務連續性管理的公司,企業也能夠選擇將連續性管理外包,不過效果如何,還不得而知。