基礎要點

目標：通過盡快恢復的服務操作，來最小化事故的負面影響。

為了避免對用戶滿意度產(chǎn)生巨大影響，應在期望的時間內(nèi)解決，并根據(jù)約定的分類分級標準，優(yōu)先解決影響業(yè)務最大的事故。

通過資源分配，確保那些影響較小的事故不會消費太多的資源。

使用能夠關聯(lián)CI、變更、問題、已知錯誤和其他知識鏈接的工具，實現(xiàn)快速有效地診斷和恢復。

處理事件可能觸發(fā)變更，因此變更應包括癥狀、業(yè)務影響、受影響的CI、已完成的操作、操作的時間戳以及人員信息。

極端情況下，可能會觸發(fā)災難恢復計劃。

與供應商交互，讓雙方之間的合同成為事故管理實踐的一部分。

解讀

企業(yè)應當根據(jù)自身的規(guī)模和行業(yè)特點，在內(nèi)部組建一支專門的計算機事故響應團隊（CIRT）。不過，光有事故響應人員是遠遠不夠的，我們還應該通過事先準備好一整套處置的流程，來實現(xiàn)對于不同事故的管理。

1.前期準備

團隊成員參考本企業(yè)和系統(tǒng)以往的事故報告，通過開展業(yè)務影響分析（BIA），來推算出MTD。為了根據(jù)現(xiàn)有的資源，來制定相應的應急響應計劃，我們需要參照業(yè)界常規(guī)的處置標準與方法，來定義事故的級別（從一般性的事件到嚴重的災難）和中斷的分類。具體類別包括但不僅限于如下方面：

（1）內(nèi)/外部網(wǎng)絡、以及云端服務的中斷。

（2）針對系統(tǒng)漏洞的攻擊。

（3）針對主機與網(wǎng)站的惡意代碼注入。

（4）應用程序的自身缺陷和異常終止。

（5）信息數(shù)據(jù)的篡改、泄漏與刪除。

（6）硬件設備與設施的故障。

（7）大面積的自然或人為災難等。

2.檢測與識別

面對用戶反饋來的且?guī)в兄饔^判斷的報告、以及自動化工具平臺推送來的海量平臺信息，值守監(jiān)控人員根據(jù)自己的經(jīng)驗、以及制定好的事故分類標準，剔除誤報并初步分揀定級。

3.調查與分析

為了界定系統(tǒng)與服務的受損程度，響應團隊需要從數(shù)量與程度兩個維度進行分析。當然，在需要時也會涉及通過深入調查與跟蹤，來對一些滯后、間接的影響予以評估。

4.取證

如果是安全攻擊類事故，那么取證環(huán)節(jié)是必不可少的。安全專家可以從主機系統(tǒng)、網(wǎng)絡數(shù)據(jù)、軟件應用、存儲介質四個邏輯層面，以及現(xiàn)場物品等物理層面上，開展取證工作。

5.報告與公關

為了實現(xiàn)有效的危機管理，事故管理團隊需要做到如下幾個方面：

（1）根據(jù)聯(lián)系人列表，以郵件、電話、微信、甚至是廣播的形式，告知可能波及到的內(nèi)部相關人員。

（2）按照“快報事實、慎報原因”的原則，向客戶、合作方以及外部監(jiān)管部門提供事故情況說明、以及必要的技術細節(jié)問答。

6.抑制與補救

真正的補救工作，在這個階段才正式打響。其中可能會包括：

（1）基礎設施的恢復。

（2）系統(tǒng)與主機的安裝。

（3）網(wǎng)絡的搭建與恢復。

（4）軟件應用的安裝與調試。

（5）數(shù)據(jù)的恢復與服務的測試。

在針對事故的抑制、恢復、以及根除過程中，響應團隊需要根據(jù)既定的業(yè)務單元優(yōu)先級，來穩(wěn)步推進。當然，各種職能角色之間的溝通與協(xié)調，也是非常必要的。

7.總結與整改

在整個事故處理的最終階段，我們需要回顧響應的執(zhí)行情況，事故管控的效果，提出建設性整改意見，并防止問題的復發(fā)。

實務

在我們企業(yè)中，為了有效地管理好各種潛在的事故，我們在前期準備階段就事先準備好了各種參考表格，其中包括：緊急聯(lián)系人列表、業(yè)務單元優(yōu)先級列表、事故界定與分類參考表、嚴重性矩陣參考表、事故原始記錄表、事故性質與嚴重性報告、以及具體的應急響應計劃與測試演練報告等。當然，這些表格與報告模板都被呈交到了各個相關的業(yè)務部門，根據(jù)收集和反饋的意見進行了及時調整，并最終得到了管理層的批準。

另外，由于我們用到了云業(yè)務環(huán)境，因此對于上述解讀中所提及的通用流程，我們進行了針對云服務的細化。其中包括：

1.在檢測與識別階段

我們分別抓取和過濾來自各個虛擬機的系統(tǒng)事件、以及基于網(wǎng)絡的異常流量信息，然后持續(xù)將經(jīng)過整理的日志信息寫入HBase 數(shù)據(jù)庫，為后期的各種關聯(lián)分析、以及攻擊取證提供重要的判定依據(jù)。

2.在調查與分析階段

我們運用工具按照特征代碼，對事件的種類予以分組、對事件的發(fā)生頻率進行統(tǒng)計。同時，我們引入了應用性能分析（APM）模塊，精確地定位應用服務中是哪個URL 的訪問速度出現(xiàn)了驟降、或是用戶在提交哪個SQL 語句時碰到了延時，這些都能夠協(xié)助運維人員更快地定位事故背后的問題。

3.在抑制與補救階段

我們可以通過暫停被攻破的虛機鏡像，來隔離它與其他系統(tǒng)及服務之間的邏輯聯(lián)系，此舉既不會破壞該虛機上的證據(jù)，又能夠阻止事態(tài)的惡化。

此外，根據(jù)云服務的特點，許多業(yè)務系統(tǒng)已不再孤立地存在于我們可控的環(huán)境中，而那些針對云服務商或其他租戶系統(tǒng)的攻擊，也可能可能殃及我們的服務。

因此，我們需要通過對現(xiàn)有管理流程的整改，以實現(xiàn)事前防范、事中控制以及事后溯源。

結語：

綜上所述，我們從企業(yè)日常服務運維的角度，解讀了在ITIL 4 的服務管理實踐中，所涉及到的可用性管理、業(yè)務分析、能力和性能管理、變更控制以及事故管理。常言道：“工欲善其事，必先利其器?！笨梢姡@些都是我們進行常規(guī)化服務管理的基本方面，也是我們需要夯實與做透的基礎。