聰明自動化持續營運再升級

分享文章:

隨著IT技術的不斷演進，各種型態的IT服務交付模式也不斷推陳出新，這些IT服務的創新不僅改變整個IT市場的生態，也改變了企業建構及運維IT的模式，但這樣的改變過程也讓許多企業IT處在過渡的新舊並存狀態下，管理上變得相對複雜，應用服務與IT基礎間的關聯性與可視度(visibility)並不再像過去管理伺服器、網路、儲存器硬體般那麼直觀，傳統的以系統管理工具導向的IT營運管理模式，在高度虛擬化及採取雲端部署的as-a-service環境下變得相對困難；全新的IT持續運行的思維，已經進入由系統管理朝向服務管理並採「人與機器」協同作業，透過AI「擴增」IT管理人員的視角，預測洞察IT並自動化協作 IT營運管理。

IBM認為的AI，是一個擴增的概念，它並不是像全自動駕駛，完全交由機器去接手IT運作，而是指在整個IT運營管理的作業中，讓機器它所擅長的需長時間操作運維、重複性高、耗費人力部分，而複雜且需要決策性的作業，仍是由IT人員來做判斷與執行。

IT人員平時日常作業當中，會有相當多來自使用者報修等日常維運事件發生並需要及時處理，像是系統或網路服務中斷、IT使用者服務請求等各種的事件等。面對這些事件，系統IT人員常需耗費時間要進系統查找，整理，以回應處理事件，也讓IT部門必須編制各種不同系統技能的維運工程師隨時回應各種事件需求。在未來的IT系統架構下，事件的管理與服務請求將會讓自動化系統接手。原本在第一線面對使用者接收事件的請求，將會先讓動態自動化事件關聯分析(Dynamic Automatic Event co-relation)先行過濾並處理掉大部分事件服務請求，後續再交由虛擬機器人(Virtual Engineer)依據所被訓練且被授權處理的範圍支援IT事件處理，當虛擬機器人能力或權限不足以處理的工作，才交由資訊人員接手處理；而所有的處理過程與解決方法，也都會記錄儲存下來，做為未來改善、查核與精進虛擬機器人IT處理能力的所謂 “資料湖(Data Lake)” 當中。這樣的做法已被實證並長期應用在IBM為客戶提供IT營運的資料中心環境當中。

談到IT服務管理，我想不能不提一下ITIL(Information Technology Infrastructure Library) ，它所描述的IT服務管理流程與作法，目前仍是IT 服務管理的最佳實踐典範。目前多數企業在導入ITIL不管是為了改善本身IT服務品質或取得ISO20000認證，都較著重在一般IT營運當中所經常需要使用的12種IT運作管理流程，包括像是日常系統變更時，為避免影響日常IT運作的變更管理(Change Management) 、使用者有IT需求時對IT部門提出服務請求的服務請求管理(Service Request Management)或故障發生時依據僅及程度啟動不同程度通報處理機制的事故管理流程(Incident Management)等，

但其實在ITIL的核心架構中除一般IT服務運維的流程建議之外, 同時也為IT治理的終極目標也就是支持業務的持續運行所需 ，定義了IT服務持續營運管理(Service Continuity Management,簡稱ITSCM)並歸類在服務設計(Service Design)的分類當中，無非是希望透過服務設計的手法，將業務持續運行管理(Business Continuity Management,簡稱BCM)的營運目標，透過與業務單位的互動，將業務需求理解萃取做為發展IT服務持續運行管理的基礎，讓整體IT治理中,營運IT服務的日常作業的準備上，不論是標準操作流程(SOP)的制定或是IT維運組織的編制，都能更貼近業務持續營運管理的業務目標。

為什麼要特別談這一個在ITIL這樣以IT服務管理最佳實施範本的框架下，被潛藏在服務設計當中，卻鮮少有被特別的議題？主要著眼於IT被商業應用服務已經深入到許多企業的業務核心，但IT的營運管理許多卻仍停留在企業員工或資料中心的IT基礎設施運作使用上的支援，從ITSCM視角出發切入在IT服務管理，將更能契合於現在許多高度仰賴IT維運其商業運作的企業 。

由上圖所示 , 我相信相對於長期管理IT營運的各位資訊部門主管應該不難理解為什麼ITSCM相較於其他管理流程更容易在企業內推廣，主要原因在於它從業運維運所追求企業永續管理的營運目標出發 , 推導出要達到該業務營運管理目標所需IT服務與現行運維環境之間的服務水準落差，進而將補足該落差所需要的IT持續運營策略、必須建立的標準程序、人員組織及管理工具逐一規劃並導入自動化持續管理流程工具以協助IT 運維。

上圖是一家我在國外的客戶，導入ITSCM的其中一個流程。是該銀行在遭遇到重大災害時，用以啟動災害備援的管理程序。圖中不難看出在這樣的設計中，它的IT 服務流程，在遭遇災害且被管理人員斷定為重大事件時 ，由ITSC主管擷取ITSC計畫中的災害備援計畫，並啟動該計畫中的作業程序，再由ITSC的分析人員依據程序中已預先定義好的事件嚴重等級，按BCM建立時所分析得知的對業務衝擊程度通報該重要事件訊息給與業務將受影響的業務主管，接著執行緊急通知在該計畫中已經預先排定好必須進入災備計畫執行中的相關成員及廠商支援團隊，以支援業務回復及相關IT持續運行的計畫其中可能是系統的切換、人員的就位、資料回復的操作或甚至是IT作業地點的遷移等….用以支持IT服務在災害發生時依舊能夠讓業務持續運作的相關措施。各個ITSC的工作角色及計畫啟動後每個階段按程序所需執行的事項，都預先被清楚制定，當面對重大事件時，IT人員按其在該重大事件處理流程中所被派任的角色執行計畫所授權的操作，什麼時候應該通知管理團隊?什麼時候應該再啟動另一個計畫?都被嚴謹地定義，以避免災害發生時在慌亂中出錯，造成更大的業務損失。

在ITSCM 的程序與計畫運作中，提供服務持續運行的角色被統稱為Continuity Provider，可以是IT部門或廠商技術人員，同時也包括支援IT服務持續運行的管理工具。在管理工具方面，自動化管理工具也成為Continuity Provider選項。

上圖則是典型的倒入自動化IT服務持續管理工具的步驟 ，最左邊的黃色方塊所呈現的在完全手動的IT營運環境下，各系統有其個自的操作台(console) ，各系統的管理員也隨時收到許多無需任何回應動作的系統紀錄(log)且必須手動操作除錯或清除，當系統發生事故也由人工作業開出問題單派工處理，重大事故的等級處理則需人力介入以聯繫支援廠商做故障排除，導入自動化的第一步可以先將控制台集中、並自動清除無需任何處理動作的事件紀錄、自動開問題單並派工甚或可嚴重等級較高的事件轉交由廠商技術支援人員等，這些可快速達成的自動化工具。當手動環境被初步自動化工具完成優化後，即可開始著手規劃導入進階型的自動化工具，像是動態自動化系統(Dynamic Automation)、虛擬機器工程師(Virtual Engineer) 、流程自動化(Process Orchestration)等，逐步擴增自動化工具參與IT服務持續運作,降低人工手動操作所可能發生人為操作失誤影響IT持續運行。

此外，自動化工具也開始往認知科技（例如Watson Automation，DR Orchestration等）這類進階自動化管理工具發展，朝向到自動化服務交付與「交付即服務(Delivery as a Services)」的走向，支持ITSCM支援業務持續運行，但真正導入自動化IT服務持續管理後，IT人員在日常運維將扮演甚麼角色？上圖我們可以看到在資訊策略、設計、持續服務等，即需要管理階層，IT服務人員、IT practitioner執行，其它基礎操作、服務轉換等工作，交給自動化虛擬機器人接手。從圖中可見，在自動化IT服務持續管理導入協助IT運作後，人力配置將會有很大改變。

這是一個日本企業客戶導入的狀況，圖的上面是他的應用模式。各位可以看到，被管理的伺服器在進入被自動化服務持續系統接管後，該伺服器所發生得任何重覆事件，都將被發現並在 correlation後事件數量大幅縮減。進入事件管理系統之後，遭遇重大事件時，Auto- ticketing system也自動將報修給正確的人員來處理，直到最後問題完全解決。

圖的下面兩個趨勢圖中，我擷取2016年9月的資料。它在4月導入虛擬機械人之後，事件通報的自動復原時間，降到大約9分鐘處理好，甚至可以看到當事件通報數量很多的時候，需要的人力資源也沒因此有太大的增加。這已經實證在日本導入了兩年，在去年正式提供出來，我們也在今年下半年開始向我們在台灣得用戶推廣這樣的做法。

最後，我們請各位再次回顧這張在IT業界行之多年用以定義業務永續中，廣泛被參考的災備等級標準，從最早期用保全運送磁帶的Tier-1等級，到目前各大金控為保障業務持續運行而不斷投資提升到雙中心架構的Tier-6等級，而支持業界標準得最高災備等級的Tier-7，也就是一小時內回復IT服務運作這個目標，在標準形成的當時就理解非得透過自動化工具及流程導入，方有機會達成的高難度目標，但我相信對許多企業來說， 長期投資並建立希望達成的高規格災備中心無非是為了滿足業務持續運作的需求，在面對當前業務營運對IT的仰賴度與重要性，已不可同日而語。超越災備業界標準的 Tier-8，也就是幾近不中斷的IT服務，相信對許多IT營運主管也不再是最高標準，而已經成為業務單位對IT營運的基本要求。IT科技的快速發展與演進不斷持續在創新商業模式，數位創新需要IT持續提供營運服務，7×24不中斷，也該適用自動化IT優化IT營運的時候了。