要做一個IT運維管理的項目，客戶提到了ITIL（IT Infrastructure Library），所以談需求之前我研究了一下ITIL，發現東西比較多，但是裏面的服務運維部分是項目一期所需要的，那我就把我這部分的學習筆記貼一下。
ITSM，ITIL
有個術語叫做ITSM（IT Service Management）IT服務管理，簡單的來說它就是指對企業IT系統的規劃、研發、實施和運營的管理，我認爲它就是一個概念。
而ITIL（IT Infrastructure Library）IT基礎架構庫，它就是適用於ITSM的一個框架，一套最佳實踐。
ITIL®是英國AXELOS有限公司的註冊商標。
我今天介紹的內容是基於ITIL 2011版本的。
ITIL分爲5個階段或叫生命週期：
- 戰略階段（Service Strategy)；
- 設計階段（Service Design)；
- 轉換階段（Service Transition)；
- 運營階段（Service Operation)；
- 改進階段（Service Improvement)；
看下圖：
我要介紹的就是左下角服務運營（Service Operation）階段的5個管理流程。而服務運營階段的職能（Function），我在這裏不介紹，因爲我有的地方還不太清楚。
事件管理（Event Management）
作爲IT服務的提供商，我們需要很好的理解和利用事件管理。
Event是有生命週期的，Event也需要在整個生命週期內被管理。這將是未來實現運維監控的基礎。這是因爲事件管理包括了所有諸如事件檢測、事件分析、事件響應等等內容，這裏所說的既包含普通的運維操作也包括警告和異常等，所以說它是自動化運維管理的基礎。
在ITIL裏事件（Event）指的是什麼？
有時候可以這樣認爲：“所有的信息都很重要”。
簡單的說呢，事件就是對IT服務管理或其它配置項管理很重要/有意義的那些狀態的改變，就是一些狀態的改變，例如升高或者下降等。
例如硬盤使用率從35%升到了45%。
基本上，事件就是IT運維人員需要做一些處理，或者至少記錄（日誌）一下的東西。
警報（Alert）
警報是由事件管理流程創建並管理的。
事件可能會產生警告，警報就是某個狀態達到閾值後發出的通知。例如狀態的改變，或服務發生了一些失敗（Failure）。
例如，我在所有PC上部署了一個Windows啓動時應自動運行的軟件，部署後大部分的PC上都可以自動運行，但是有些PC上的軟件無法自動運行。所以我讓IT運維人員設置了警告，如果軟件沒有自動運行，這個警告就會被觸發，同時也可以做一些應急處理工作。也可以給IT運維人員的電腦屏幕彈出警告信息。這些都屬於事件管理的範圍。
事件管理的目標
事件管理的目標都是很直接的：
- 檢測所有對於配置項管理/IT服務有意義的狀態的變化。
- 爲事件決定具體的響應措施，並確定這些動作都和相應的職能組溝通過。
- 可以觸發或提供切入點到其它運維管理流程。
- 提供比較實際效果和設計標準的比較方法。
- 爲服務保障，報告和服務改進提供基礎。
事件管理的範圍
它支持任何需要被控制並可以自動化的服務管理，例如配置項、環境條件（例如煙火探測器）、軟件許可的監控、入侵檢測、服務器性能監測等等。
針對這裏提到的監視（Monitoring），它的範圍更廣。而事件管理是被監控內容的一個子集，事件管理更關注於那些對提供服務和管理配置項有意義的事件。
事件的類型
從測試的角度來看，事件又分爲三種類型，每一種類型對服務提供商又具有不同等級的重要性/意義：
- 信息性事件，就像趨勢和分析等。例如xxx用戶在週二使用了財務軟件，電子郵件被閱讀了，數據備份完畢等等類似的事件。
- 警告（Warning），就是早期的警告信息，它可以防止或最小化業務影響，或對用戶的影響。例如服務器CPU的使用率距離閾值只有5%的距離了。
- 異常（Exception），意味着不好的事情已經發生了，並需要後續處理措施。例如CPU的使用率已經超過了閾值，DevOps在他們的電腦上安裝了監控，所以他們可以進行後續處理。
警告和異常的區別？
這是服務商根據具體情況自己定的。
事故管理（Incident Management）
無論你在設計服務和支持服務中預先準備的有多好，但是我們畢竟是人，肯定會發生意外。
事故管理的目標
所以事故管理的目標就是：
- 修復服務的中斷，儘快恢復服務運營
- 最小化對業務運營的不利影響
事故（Incident）的定義
事故（Incident）就是，IT服務計劃外的中斷，或IT服務質量的下降，或暫未對IT服務產生影響的失敗配置項。
例如RAID裏面一塊損壞的硬盤，現在雖然可以正常運行，但是如果不把它換掉，那麼未來總有一天會遇到麻煩。
事故管理的目標
- 確保使用了標準化的方法和過程，以保證效率。例如快速響應，報告，事故即時管理。
- 爲業務和IT人員提高事故的透明度和溝通性。如果他們不知道事故，他們就無法進行響應。
- 通過使用專業方法來處理這些事故，將有助於增強企業對IT的業務認知。
- 將事件管理活動和優先事項與業務決策相結合，最終還是爲業務選出最好的決策。
- 維護好IT服務的客戶滿意度。畢竟如果客戶不高興的話，那麼就沒有人會開心，即使服務的質量高於需求。
事故管理的範圍
下面這些屬於事故管理的範疇：
- 任何表明IT服務中斷的事件（Event）。
- 任何可以造成IT服務中斷的事件。例如之前提到的RAID中損壞的硬盤。
下面這些不屬於事故管理的範疇：
- 信息新事件。例如，“數據庫備份已完成，請呼叫服務檯”，這完全沒有必要。
- 服務請求。它是在請求完成管理和常規運維裏處理的。
- 常規運維。就是計劃內的服務。例如，已經預先通知客戶週六晚8點至9點服務器停機維護等等。
如何處理事故
處理事故需要一個模型：這需要在處理事故前就設計好，就是一套預定義的步驟，這些步驟都是業務和IT人員同意的，它們可以用來處理特定類型的事故。
時間表
事故處理的步驟會涉及到誰來處理以及順序問題。這就涉及到了時間表。
時間表可以表示特定事件應該發生的時間總量。
在事故管理裏，時間表就表示了事故管理中每一個活動花費了多少時間來解決這個事故。
時間表需要遵循以下原則：
- 對於所有的事故處理階段，我們必須共同協商同意所需的時間。
- 根據優先級和嚴重性的不同，時間也會不同。
- 必須是基於SLAs（我不知道這是什麼東西）。
- 通常這些時間表應作爲目標，支持每項服務的運營級別協議和基礎合同，並確保內部和外部團隊在同一面上。
事故的狀態追蹤
事故應該在全生命週期中被追蹤。這有助於報告，事故升級，形成一個精確的精心安排的事件管理系統而不是雜亂無章的。
這個追蹤的模型如下：
- 首先是打開（Open），在這裏事故會被辨別，但是還未被分配到資源。
- 然後就是進行中（In Progress），事故處於被調查和解決的過程中。
- 然後是解決了（Resolved），提供瞭解決辦法，但是還沒有驗證是否可以進行正常的服務運營，這需要到用戶或業務那裏調查滿意度。
- 當用戶滿意了，這時就可以關閉（Close）了。這就說明用戶或業務已經認同事故被解決了，並且NSO（不知道是啥）已經實現了。
重大事故 Major Incident
重大事故基本上時DEFCON 5，也就是所有事故分類裏影響最大的那類。
實際上，因爲重大事故太嚴重了，所以它經常會激活IT服務連續性計劃。
重大事故會引起服務的長時間中斷，通常也會造成經濟上或用戶滿意度上的重大損失。
重大事故應該有單獨的處理流程，和更短的時限。
重大事故還需要審查，以確保它被正確的處理。
事故管理的流程
每個企業和組織用於處理事故的管理流程肯定是不一樣的，但是ITIL確實提供了一個比較標準的框架或者叫模板。
下面是這個“較爲標準”的框架的流程圖：
整個流程可能從事件管理、幫助網頁、電話、或電子郵件等發起。
首先需要識別事故，識別的方法就有很多種了，也許通過打電話給服務檯就能識別出來，也許需要事故管理。
在識別的時候，我們就需要判斷這到底是不是事故。
如果確實是事故的話，那麼就進入下一步“記錄事故（logging）”。所有的事故必須被記錄，包括日期時間等必須都有，這一點對問題管理和變更管理都很有用。
然後就是給事故分類，這將有助於過濾服務請求，並確保事故可以基於事故的原因正確地進行升級。例如，這是服務器環境事故還是網絡環境的事故。此外，分類也有助於設置優先級。
下一步就是事故優先級的設定，優先級要綜合考慮影響程度和緊急性。例如對業務的影響程度有多大，多久能夠恢復等等。
這時，你就需要確定一下這個事故是不是一個重大事故了。如果是重大事故的話，就需要進入重大事故的處理流程了。
否則的話，就需要做一些事故診斷工作了。診斷腳本、事件模型和已知錯誤記錄將在這個階段對您有幫助。
如果你能識別出一個已知的錯誤記錄，那麼就有可能有一個解決辦法可以讓服務快速的恢復。
在初步診斷後，也就可以弄清楚服務檯是否能把服務給恢復了。如果服務檯沒能在時間限內找到解決辦法，那麼可能就需要事故升級處理了。
這裏有兩種事故升級類型，一個是職能性升級，也就是把事故轉交給擁有更高專業水平的某個技術團隊。例如從1級技術轉到3級技術等等。
還有一種是層次性升級，這時你的主管就會介入了。有人曾把這種事故叫做超過工資等級的事故，所以需要通知主管/老闆，讓他們授權支出。而有時則是讓主管決定由哪些團隊來處理這個事故，或激活IT SCM計劃（不知道是什麼），它也需要對事故進行層次升級。
大部分時候你會調查並得出一些事故的診斷。
如果發現處理辦法了，那就來到下一步解決和恢復。在這可能需要一些測試，看看服務是否已經恢復到達成共識的程度了。
然後就可以返回到服務檯來關閉事故。
服務檯會給用戶打電話，並且詢問客戶，“這個解決辦法是否能夠讓您滿意?” 一旦得到了肯定的回答，那麼這個事故的處理流程就結束了。