目標:通過盡快恢復的服務操作,來最小化事故的負面影響。
為了避免對用戶滿意度產生巨大影響,應在期望的時間內解決,并根據約定的分類分級標準,優先解決影響業務最大的事故。
通過資源分配,確保那些影響較小的事故不會消費太多的資源。
使用能夠關聯CI、變更、問題、已知錯誤和其他知識鏈接的工具,實現快速有效地診斷和恢復。
處理事件可能觸發變更,因此變更應包括癥狀、業務影響、受影響的CI、已完成的操作、操作的時間戳以及人員信息。
極端情況下,可能會觸發災難恢復計劃。
與供應商交互,讓雙方之間的合同成為事故管理實踐的一部分。
企業應當根據自身的規模和行業特點,在內部組建一支專門的計算機事故響應團隊(CIRT)。不過,光有事故響應人員是遠遠不夠的,我們還應該通過事先準備好一整套處置的流程,來實現對于不同事故的管理。
團隊成員參考本企業和系統以往的事故報告,通過開展業務影響分析(BIA),來推算出MTD。為了根據現有的資源,來制定相應的應急響應計劃,我們需要參照業界常規的處置標準與方法,來定義事故的級別(從一般性的事件到嚴重的災難)和中斷的分類。具體類別包括但不僅限于如下方面:
(1)內/外部網絡、以及云端服務的中斷。
(2)針對系統漏洞的攻擊。
(3)針對主機與網站的惡意代碼注入。
(4)應用程序的自身缺陷和異常終止。
(5)信息數據的篡改、泄漏與刪除。
(6)硬件設備與設施的故障。
(7)大面積的自然或人為災難等。
面對用戶反饋來的且帶有主觀判斷的報告、以及自動化工具平臺推送來的海量平臺信息,值守監控人員根據自己的經驗、以及制定好的事故分類標準,剔除誤報并初步分揀定級。
為了界定系統與服務的受損程度,響應團隊需要從數量與程度兩個維度進行分析。當然,在需要時也會涉及通過深入調查與跟蹤,來對一些滯后、間接的影響予以評估。
如果是安全攻擊類事故,那么取證環節是必不可少的。安全專家可以從主機系統、網絡數據、軟件應用、存儲介質四個邏輯層面,以及現場物品等物理層面上,開展取證工作。
為了實現有效的危機管理,事故管理團隊需要做到如下幾個方面:
(1)根據聯系人列表,以郵件、電話、微信、甚至是廣播的形式,告知可能波及到的內部相關人員。
(2)按照“快報事實、慎報原因”的原則,向客戶、合作方以及外部監管部門提供事故情況說明、以及必要的技術細節問答。
真正的補救工作,在這個階段才正式打響。其中可能會包括:
(1)基礎設施的恢復。
(2)系統與主機的安裝。
(3)網絡的搭建與恢復。
(4)軟件應用的安裝與調試。
(5)數據的恢復與服務的測試。
在針對事故的抑制、恢復、以及根除過程中,響應團隊需要根據既定的業務單元優先級,來穩步推進。當然,各種職能角色之間的溝通與協調,也是非常必要的。
在整個事故處理的最終階段,我們需要回顧響應的執行情況,事故管控的效果,提出建設性整改意見,并防止問題的復發。
在我們企業中,為了有效地管理好各種潛在的事故,我們在前期準備階段就事先準備好了各種參考表格,其中包括:緊急聯系人列表、業務單元優先級列表、事故界定與分類參考表、嚴重性矩陣參考表、事故原始記錄表、事故性質與嚴重性報告、以及具體的應急響應計劃與測試演練報告等。當然,這些表格與報告模板都被呈交到了各個相關的業務部門,根據收集和反饋的意見進行了及時調整,并最終得到了管理層的批準。
另外,由于我們用到了云業務環境,因此對于上述解讀中所提及的通用流程,我們進行了針對云服務的細化。其中包括:
我們分別抓取和過濾來自各個虛擬機的系統事件、以及基于網絡的異常流量信息,然后持續將經過整理的日志信息寫入HBase 數據庫,為后期的各種關聯分析、以及攻擊取證提供重要的判定依據。
我們運用工具按照特征代碼,對事件的種類予以分組、對事件的發生頻率進行統計。同時,我們引入了應用性能分析(APM)模塊,精確地定位應用服務中是哪個URL 的訪問速度出現了驟降、或是用戶在提交哪個SQL 語句時碰到了延時,這些都能夠協助運維人員更快地定位事故背后的問題。
我們可以通過暫停被攻破的虛機鏡像,來隔離它與其他系統及服務之間的邏輯聯系,此舉既不會破壞該虛機上的證據,又能夠阻止事態的惡化。
此外,根據云服務的特點,許多業務系統已不再孤立地存在于我們可控的環境中,而那些針對云服務商或其他租戶系統的攻擊,也可能可能殃及我們的服務。
因此,我們需要通過對現有管理流程的整改,以實現事前防范、事中控制以及事后溯源。
綜上所述,我們從企業日常服務運維的角度,解讀了在ITIL 4 的服務管理實踐中,所涉及到的可用性管理、業務分析、能力和性能管理、變更控制以及事故管理。常言道:“工欲善其事,必先利其器。”可見,這些都是我們進行常規化服務管理的基本方面,也是我們需要夯實與做透的基礎。