ITIL 4 講解：Event，Incident 和 Crisis, 流程如何界定？

這個話題源自客戶的提問：若是監控報告發生了異常，

1. 運維團隊處理了，這算是Even仍是Incident管理流程?

2. 若是沒有處理，異常愈來愈嚴重（固然處理的時候也有可能問題愈來愈嚴重）,發生了危機，是屬於Incident的管理流程仍是須要創建一個新的流程（Crisis Management)？

其實這一場景的管理，在ITIL 4中，劃分爲三個實踐:　監控和事態管理（Monitoring and Event Management ），事件管理（Incident Management）和服務連續性管理（Service Continuity Management)。在回答這個問題以前，咱們先看看這三個實踐的範圍和流程。這裏先要說明，因爲翻譯的問題，Incident Management從ITIL V3，一直翻譯成事件管理，其實我認爲翻譯成故障管理更合適。爲了不歧義和不糾結翻譯的問題，下文都用英語單詞Event, Incident描述。

---

區分三個關鍵詞語

事態 Event: 對服務或其餘配置項（CI）的管理具備重要意義的任何狀態更改

事件 Incidnet: 服務的意外中斷或服務質量的下降

災難 Disaster: 對組織形成重大損失或重大損失的突發性意外事件。要將事件歸類爲災難，該事件必須符合組織預約義的某些業務影響標準

從ITIL 4給出的定義來看，他們之間的關係應該是：

Event是由監控系統反映出來的關於CI項的狀態變化，產生的信息有多是一個通知，有多是潛在故障，須要咱們關注，有多是故障，也有多是重大故障或者災難。對於Event的管理，須要咱們去定義Event的類型，告警的閾值，Event的優先級和Incident優先級的對應，以及什麼時候觸發Incident Management。

Incident就是咱們理解的故障，生產系統的異常狀況，有可能產生中斷，也有可能未產生中斷。

Disaster是災難，好比數據中心所有中斷服務，業務系統大面積癱瘓。企業須要提早制定危機工做小組，以及肯定溝通計劃，好比上報監管機構，開展企業危機公關處理程序等等。

---

對比三個實踐的範圍和流程

實踐	目的	範圍
監控和事態管理	目的是系統地觀察服務和服務組件，並記錄和報告肯定爲事態狀態變化。此實踐可識別基礎設施、服務、業務流程和信息安全事件並肯定其優先級，並創建對這些事件的適當響應，包括對可能致使潛在故障或事件的狀況做出響應。	涵蓋了組織服務管理的全部方面，這些方面須要控制而且能夠自動化。這包括： ●肯定和優化監控範圍 ●實施和維護持續監控 ●創建和維護事件識別、分類和處理規則 ●實施流程和自動化工具，以實施規定的事件管理規則 ●根據商定和實施的規則和流程持續處理事件 ●以商定的形式向相關利益相關者提供有關受監控服務和資源的當前和歷史狀態的信息。
事件管理	事件管理實踐的目的是經過儘快恢復正常的服務操做，將事件的負面影響降至最低。	事件管理實踐的範圍包括： ●檢測和登記事件 ●診斷和調查事故 ●將受影響的服務和CI恢復到商定的質量 ●管理事件記錄 ●在事件生命週期內與相關利益相關者溝通 ●審查事件，並在解決後開始改進服務和事件管理實踐。
服務連續性管理	服務連續性管理作法的目的是確保在發生災難時，服務的可用性和性能保持在足夠的水平。該實踐提供了一個創建組織彈性的框架，該框架可以產生有效的響應，保護關鍵利益相關者的利益以及組織的聲譽、品牌和價值創造活動。	服務連續性管理實踐包括如下方面： ●執行BIA，量化服務的不可用對服務提供商和服務消費者的影響 ●制定服務連續性戰略（若是相關，將其歸入業務連續性管理戰略）。這應包括風險緩解措施的要素以及選擇適當、全面的恢復方案 ●制定和管理服務連續性計劃（若是相關，爲業務連續性計劃提供清晰的接口） ●進行演習並測試災難狀況下的服務連續性計劃調用。

對比完目的和範圍後就會發現，Monitoring and Event management關注的是監控範圍，肯定要維護的信息和產生信息的處理規則，閾值的肯定和報告（目前監控管理面臨的痛點是信息太多，應該如何提煉有價值的信息），Incident Management關注的是儘快恢復服務，而連續性管理關注的是若是識別風險，制定措施和計劃，保證系統的連續服務，並按期演練連續性計劃。

---

三個實踐的接口和關聯

在企業實踐的運維過程當中，不少事情都是連續的，可是咱們很難用一個流程把全部的事情活動都肯定下來。因而ITIL對於流程進行了適當的分割，對於流程的範圍也作出了界定，雖然這必定程度上不太符合目前DevOps提倡的端到端，事實上這是目前企業IT運維的現狀。

ITIL４有進步的一點是，每一個practice都寫明瞭和其餘practice的接口，也強調了「ITIL實踐只是價值流環境中使用的工具的集合；它們應該根據狀況在必要時進行組合。」 這三個實踐的接口部分是：

1. 須要定義從Event到Incident的關聯場景。

2. 須要定義從Incident到Disaster的關聯場景。

若是咱們要作流程的切割，那麼根據ITIL的最佳實踐，建議：

1. Incident的早期發現、診斷、故障自愈：應屬於Monitoring and Event Management。

2. 來自監控系統的Event，產生了業務中斷，或者有潛在業務影響和風險，Event要按照Incident的處理流程，做爲Incident來處理。

3. 制定服務連續性計劃並將其與Incident Management管理活動分開管理時，應該有一個明確的觸發服務連續性程序的標準。在評估故障的業務影響時，運維專家應肯定重大故障是否可能致使災難，並通知危機管理小組，以便他們可以作出決定。

---

最後總結

根據以上的解釋，若是監控報告發生了異常，

1. 運維團隊處理了，這算是Even仍是Incident管理流程?

【答】：運維團隊進行處理了，應該遵循Incident管理流程，去除異常，恢復服務。

2. 若是沒有處理，異常愈來愈嚴重（固然處理的時候也有可能問題愈來愈嚴重）,發生了危機，是屬於Incident的管理流程仍是須要創建一個新的流程（Crisis Management)？

【答】：若是尚未升級成爲災難，須要上報危機工做小組的話，仍是按照Incident管理流程。若是須要，Incident 管理流程中，能夠創建Major Incident子流程（重大故障管理流程），進行區別對待處理，包括激活24*7團隊，過後要生產重大故障報告，管理問題管理流程分析緣由等等。

寫在最後，ITIL的最佳實踐和流程能夠組合應用，尤爲是在企業大規模運維業務中，流程的邊界分割能夠依據企業狀況靈活使用。

但願本文能夠就Event, Incident和Crisis（Disaster）給你們一點啓發。

附：服務連續性：http://www.javashuo.com/article/p-zfckmcvb-nv.html

監控和Event: http://www.javashuo.com/article/p-ddqakpqf-ny.html