之前寫的關於ITIL 4的實踐（Practice)服務目錄，可用性，連續性, 在日常的運維或者服務管理中，也許很多公司都沒有用到。春節前的工作告一段落，今天終於有時間寫寫我們最常用的實踐：事件管理（Incident Mangement)
事件管理是每個實行ITIL的公司必用的流程，是最常見的流程。可是，我發現有些公司還是不清楚事件的定義，事件流程得管理範圍，重大事件的管理，還有事件、問題和變更的界面與關係。在這篇博文裏，希望你能找到答案。
首先解讀事件的定義。
事件的定義
事件(Incident)：服務的意外中斷或服務質量的降低。與ITIL V3相比，ITIL 4給出的定義更清晰。ITIL 3中把事件定義爲“任何可被發現或辨別的事情，此類事情對於基礎設施的管理或IT服務的交付有重要意義，以及有助於評估可能導致服務出現的偏差。”
事件管理的目的是“確保將計劃外服務不可用或降級的時間減至最少，從而減少對用戶的負面影響。”也就是說，讓服務快速恢復。實現這一點的主要因素有兩個：早期事件檢測和快速恢復服務正常運行。ITIL 4強調了早期事件檢測，也就是更主動的進行異常管理，並在故障還未造成業務影響時儘快處理。
事件模型(Incident Model)：一種可重複的方法來管理特定類型的事件。
ITIL 4在快速恢復服務的正常運行方面，提出了“事件模型”的概念，意思是對於某些特定類型的事件，如經常發生的，可以定義事件模型，包括解決方案，團隊，人員。那麼事件模型的解決方案可以使用知識管理實踐。
重大事件(Major Incident)：具有重大業務影響的事件，需要立即協調解決。
重大事件的管理流程往往在大型企業中，獨立於一般事件管理流程，因爲事件影響巨大，需要上報領導，也有可能上報監管部門。這類事件發生時，組織需要協調資源馬上解決，同時事後需要寫報告，開回顧會等等，比一般的事件做的工作多。建議針對重大事件，制定獨立的流程去管理。但是這裏的難點在於如何區分重大事件和普通事件？
變通方案（Workaround)：減少或消除尚未完全解決的事件或問題的影響的解決方案。
技術債：通過選擇變通方案而不是需要長時間的系統解決方案而累積的總返工積壓。
往往變通方案的聚焦帶來了技術債務，可以通過“問題流程”來制定徹底的解決方案，消除技術債務。
事件管理的範圍
事件管理的範圍包括：
- 檢測和記錄事件
- 診斷和調查事故
- 將受影響的服務和CI恢復到商定的質量
- 管理事件記錄
- 在整個事件生命週期內與相關利益相關者溝通
- 審查事件，並在解決後開始改進服務和事件管理實踐
當我們提及範圍的時候需要將將事件管理和其他管理實踐的界面。
1. 事件和變更
變更的管理範圍是”對服務產生直接或間接影響的任何東西的添加、修改或刪除“，也就是說當對服務或產品進行增、刪、改時，我們應該使用變更管理。變更管理解決的是兩個問題：第一， 是否應該做，這是變更之前的評估和分析，第二，是否做的正確，這是變更實施時的管控。如果變更完成後，發生問題，應該開事件工單，快速修復，同時關聯事件和變更的工單。
有人會說，這樣管理很麻煩，工單開來開去。但是這樣的好處是界面清晰，不需要區分各種場景。我們通過事件和變更流程界面的清晰分割，也可以對於變更的成功率進行一定的統計。有人會問，如果應用的變更失敗了，發生故障，不需要開事件工單，直接回滾變更就可以，這樣應用的變更成功率一樣可以統計。確實，但是我們不好統一事件裏面有多少是變更造成的，甚至在事件發生時，我們不確定是否是變更造成的。
從流程制定的角度來考慮，流程儘可能不去區分應用的場景，進行場景細分的流程其設計太複雜，在實際執行過程中容易混淆，造成混亂，最後的統計報表就是不準確的。所以，
2. 事件和服務請求：
服務請求是”由用戶或用戶授權代表提出的發起服務行動的請求，該服務行動已被視爲服務交付的正常部分“。在企業中，服務請求大部分被應用於桌面支持，如安裝軟件，申請辦公設備。對於生成系統的服務請求多用於查詢。如果發生更改，需要變更流程的支持。
3. 事件與問題：
事件管理的範圍是快速恢復服務，問題管理的範圍是找根因。往往故障發生後，服務恢復完畢，想知道確切的原因或者徹底的解決方案，用問題管理流程會更合適。
有的企業把事件管理和問題管理混爲一談，服務恢復後，業務部門不希望IT部分關閉事件工單，找到根本原因纔可以。這樣做的結果是，有很多故障，服務已經恢復正常運行，但是事件工單開了很久，事件的統計報表不能真實反映生成環境服務的狀況。
客戶想知道故障發生的根本原因，這是合理的要求。IT可以用問題流程來找根因，建議有專門的問題經理來追蹤。這一點我寫問題管理實踐的時候再詳細描述。
4. 事件和服務檯：
服務檯是IT運維部門的窗口，服務檯的管理更偏向與溝通，話術等。
5. 事件和“監控與事態”：
事件管理是Incident Management, ITIL 4裏把監控和事態（event)寫到了另一個practice裏。監控和事態實踐的範圍是監控的範圍，監控規則和閾值的設定，Event(事態）的分類分級，確定事件的聯動規則。
事件實踐管理的成功因素
事件管理需要關注以下兩點：
1. 及早發現：
及早發現的落地實現實現需要強大的監控工具支持，流程管理上更多依賴與”監控和事態“管理。
2. 快速恢復
快速恢復的實現手段包括
1)集中會診（Swarming)：尤其是出現重大故障時，技術專家要聚集起來，集中解決故障，恢復服務。
2）事件模型（Incident Model）：對於經常發生的問題，可以定義事件模型進行記錄。
3）定義好事件的優先級：事件的優先級時事件流程在實施過程中的一個難點。一般從”緊急情況“和”影響範圍“兩個維度來定義事件的優先級，可是這兩個維度大部分情況下也是感性認知，很難用明確的Criteria來定義。所以實施的過程中，客戶也IT部門經常會爲優先級爭執。這一點需要根據企業的實際情況來討論，制定解決辦法。
事件管理的流程
ITIL 4把事件管理的流程分爲”事件處理流程“和”事件定期回顧流程“，強調了事件的事後回顧。
1. 事件處理流程圖見下：
主要活動爲：
事件檢測：分爲用戶彙報或者工具自動檢測
事件登記：服務檯代理執行事件註冊，或者技術工具自動註冊事件
事件分類：進行類別分類並分派工單，也分爲手動和自動
事件診斷：如果分類不能提供對解決方案的理解，技術專家團隊將執行事件診斷。這可能涉及團隊之間事件的升級，或聯合技術，例如集中診斷。如果分類錯誤是因爲CI分配不正確，要將此信息傳達給負責配置控制的人員。這裏注意：事件可以關聯CI項。
事件解決：如果解決方案不正確，需要再次回到事件診斷。
事件關閉：事件成功解決後，可能需要一些正式的關閉程序：
●用戶確認服務恢復
●處置成本計算和報告
●解決價格計算和開票
●問題調查啓動
●事件回顧。
2. 事件定期回顧：
事件的指標
ITIL 4列了一些指標示例，比較常用的是黑體標出的部分：
關鍵成功因素 |
重要指標 |
及早發現事故 |
事件發生與檢測之間的時間 通過監控和事件管理檢測到的事件百分比 |
快速有效地解決事件 |
事件檢測和診斷驗收之間的時間 診斷時間 重新分配次數 等待時間佔總事件處理時間的百分比 首次解決率 滿足商定的解決時間 用戶對事件處理和解決的滿意度 自動解決的事件百分比（如果實行了“故障自愈”的自動化處理手段） 在用戶報告之前已解決的事件的百分比 |
持續改進事件管理方法 |
使用先前確定和記錄的解決方案解決事故的百分比 使用事件模型解決的事件百分比隨着時間的推移關鍵實踐指標的改進 事件解決的速度和有效性指標之間的平衡 |
角色和文化
ITIL 4 在事件管理流程中強調了角色和文化。
事件經理（Incident Manager）:
Incident Manager最好由專人負責，主要工作包括：
- 根據組織設計，協調組織內或特定區域內的事件處理，如區域、產品和技術
- 協調人工作業與事故，尤其是涉及多個團隊的事故
- 監督和審查處理和解決事故的團隊的工作
- 確保在整個組織內充分了解事件及其狀態
- 定期進行事件審查，並開始改進事件管理實踐、事件模型和事件處理程序
- 發展組織在事故管理實踐過程和方法方面的專業知識
事件經理在某些組織下會擔任重大事件協調員的角色，這也是合理的，也可以和兼任問題經理的角色。
文化：
ITIL 4強調了集體責任和無指責文化，這點借鑑了devops。爲了解決”解決方案緩慢或根本沒有，士氣下降，缺乏動力，以及進入工作場所的競爭力不健康。此外，團隊成員之間的信任也會瓦解。“的問題，ITIL 4主張用DevOps和集中診斷（Swarming）等方法，顯示鼓勵積極文化所需的一些特徵。
最後不要忘記”持續學習“，無論是mindset還是technical skills.
總結，事件管理實踐主要就講解這些。建議大家從網上下載我翻譯的”ITIL 4 事件管理最佳實踐“，去了解更詳細的內容。下載鏈接見下：
https://download.csdn.net/download/yazi0127/15049262
最後，喜歡就點個贊吧。如果想持續瞭解ITIL 4和IT諮詢的方法論和知識體系，關注我的博客！的可能性。少或消除尚未完全解決的事件或問題的影響的解決方案。一些變通方案降低了發生事故的可能
時性。
一種可重複的方法來管理特定類型的事故。
IT服務的意外中一種可重複的方法來管理特定類型的事故。
事件模型 (Incident Model)
服務的意外中斷或服務質量的降低
斷質量的降低務的斷或服務質量的降低務的意外服務服務的意外中斷或服務質量的降低的意外中
事件模型 (Incident Model)
服務的意外中斷或服務質量的降低
斷或服務質量的降低中斷或服務的意外中斷或服務質量的降低服務質量的降低