事件管理流程是ITIL主要流程之一，它的主要目標是盡快解決日常工作環境中出現的事件，保持IT服務的穩定性，監控事件的發展，并在事件得到解決之后將其關閉。
事件流程我們需要了解一常見術語：
術語 | 定義 | |
1 | 事件 | 服務的意外中斷或服務質量的下降。尚未影響服務的配置項失效也是事件，例如鏡像組中一塊磁盤的失效。 |
2 | 服務請求 | 用戶對信息、建議、標準變更或服務訪問的請求。例如重置密碼、為新用戶提供標準的服務。服務請求通常由服務臺處理。 |
3 | 重大事件 | 對業務有重大影響的事件，重大事件將導致重要業務的中斷。一般事件影響度或優先級為1級的事件默認定義為重大事件。 |
4 | 升級 | 在需要時獲得額外資源，以達到服務級別目標或客戶期望的活動。任何服務管理流程內部都可以升級，但是升級常常與事件管理、問題管理和有關客戶投訴的管理有關聯。主要有兩種類型的升級：技術升級和管理升級。 |
5 | 管理升級 | 通知更多的高級管理人員或使他們參與解決疑難問題升級。 |
6 | 技術升級 | 將事件、問題或變更轉給具有更高技術的小組，以便進行疑難問題升級。 |
7 | 響應時間 | 一種衡量完成運營或交易所需時間的指標，在性能管理中一般用于測量 IT 基礎架構的性能，但在事件管理中主要用于測量接起電話或開始診斷的時間。 |
8 | 目標解決時間 | 為了更好的控制事件、變更等流程的整個處理過程，將處理過程被劃分成幾個階段，并對每個階段的完成時限設定了目標，即目標解決時間。 |
9 | 緊急度 | 測量事件、問題或變更多久會對業務產生重大的影響。例如，如果事件到年底才會影響業務，則影響大的事件可能緊急程度較低。指定優先級時要考慮到影響度和緊急度。 |
10 | 影響度 | 事件、問題或變更對業務流程影響的一種測量，影響度通常基于服務級別會如何受影響。指定優先級時要考慮到影響度和緊急度。 |
11 | 優先級 | 用于確定事件、問題或變更的相對重要性的類別。優先級的依據是影響度和緊急度，用它來確定采取行動所需的時間。例如 SLA 可以規定：優先級 2 的事件必須在 12 小時內解決。 |
12 | 掛起 | 事件、變更等流程可能因非技術原因而無法進行下去，此時可以暫停計算流程處理時間，掛起的目的在于更加公正的統計流程處理時間等與流程處理人員相關的指標。 |
13 | 臨時措施 | 也稱“變通方案”，在還沒有完全的解決方法時，減少或消除事件或問題的影響。例如重新啟動發生事件的配置項。 |
14 | 知識管理 | 負責收集、分析、保存和共享組織內部的知識和信息的流程。知識管理的主要目的是通過減少重新發現知識的需要，從而提高效率。 |
15 | 知識庫 | 一個邏輯數據庫，其中包含了服務知識管理系統使用的數據。 |
事件流程中的主要角色和職責的說明：
角色 | 職責描述 | 對應崗位 |
報障人 | l 向服務臺提交所發現的需要處理的事件。 l 與服務臺確認事件處理結果。 | 所有可以發起事件的人 |
服務臺 | l 接聽熱線電話，響應用戶報障需求，對用戶進行初步相應的指導解決。 l 響應用戶通過郵件、微信以及手機APP等方式的報障需求。 l 快速響應報障需求，為用戶提供高效的遠程服務。 l 及時聯系現場工程師為用戶提供服務。 l 及時聯系二線支持人員為用戶解決問題。 l 在ITSM平臺中準確并及時錄入事件信息。 l 對事件進行全程跟進，直到解決。 l 負責在事件解決后生成問題單或錄入知識庫（FAQ）。 | 客服 |
二線指派工程師 | l 響應服務臺派出的事件單，提供現場服務，包括備件更換安裝服務。 l 在ITSM平臺中準確并及時錄入事件處理詳細信息。 l 需要時發起服務請求單或變更單。 l 負責升級必要的事件到三線工程師或者供應商。 l 負責在事件解決后生成問題單或錄入知識庫。 | |
三線指派工程師 | l 響應二線工程師升級的工單，提供現場服務，包括備件更換安裝服務，系統支持服務，工程服務等。 l 在ITSM平臺中準確并及時錄入事件處理詳細信息。 l 需要時發起變更單。 l 負責在事件解決后生成問題單或錄入知識庫。 | |
供應商 | l 負責響應由二線或三線升級的事件單。 l 對事件單信息進行分析，并提供相應的解決方案。 | 外部設備供應商與服務提供商。 |
事件經理 | l 設計和改進事件管理流程。 l 設定事件管理的績效指標并考核指標完成程度。 l 跟蹤、監控各事件流轉狀態，抽查事件記錄。 l 收集匯總流程信息，編制管理報告，反映存在問題，提出改進建議，制定改進計劃。 | |
分管領導 | l 接收事件經理升級的重大事件。 l 必要時與事件經理共同跟進重大事件，協調資源。 l 審批重大事件報告。 | |
整體流程總共三大階段：識別記錄、調查診斷、解決關閉，各階段詳細說明如下：
一、事件識別與記錄
步驟名稱 | 責任人 | 說明 | |
1.1 | 提交事件 | 報障人 | 報障人通過電話、微信、郵件或手機APP來進行報障。 |
1.2 | 識別和記錄 | 服務臺 | 服務臺在ITSM平臺中進行事件信息的記錄，包括用戶聯系方式、事件描述、事件分類分級等； 若用戶通過非電話的方式進行報障，服務臺工程師可電話聯系用戶進行更多信息的確認和收集。 |
1.3 | 通知事件經理 | 服務臺 事件經理 | 若事件級別判斷為一、二級事件，需要升級至事件經理需要跟進事件的處理過程； 同時事件經理需要上報分管領導。 |
二、事件調查與診斷
步驟名稱 | 責任人 | 說明 | |
2.1 | 初步處理 | 服務臺 | 服務臺對事件進行初步處理，進行遠程調試或指導。 |
2.2 | 是否可以解決？ | 服務臺 | 若可以解決，則直接處理解決，并進入3.2，與用戶確認是否恢復； 若無法解決，則進入2.3尋求二線支持。 |
2.3 | 二線支持團隊調查診斷，尋找解決方案 | 二線工程師 | 二線支持團隊接受服務臺升級的事件，并判斷是否需要進行內部轉派，如需要則說明轉派理由，并進行轉派，如不需要則對事件進行分析和處理，處理過程需要及時更新到平臺中； 若需要執行變更，則觸發變更管理。 |
2.4 | 是否找到解決方案？ | 二線工程師 | 若是，則進入2.5 是否需要發起服務請求管理； 若否，則進入2.6尋求三線支持； 若否，則進入2.8 尋求供應商支持。 |
2.5 | 是否需要發起服務請求管理 | 二線工程師 | 找到解決方案后，是否需要繼續發起服務請求管理，尋求徹底解決： 若需要執行服務請求，則發出服務請求管理 若不需要，則進入3.1 事件解決。 |
2.6 | 三線支持團隊調查診斷，尋找解決方案 | 三線工程師 | 三線支持團隊接受二線升級的事件，對事件進行分析和處理，處理過程需要及時更新到平臺中； 若需要執行變更，則觸發變更管理。 |
2.7 | 是否找到解決方案 | 三線工程師 | 若是，則進入3.1 事件解決； 若否，則進入2.8尋求供應商支持。 |
2.8 | 供應商團隊診斷調查，尋找解決方案 | 供應商 | 供應商接收來自二線和三線對的事件，并對事件進行分析診斷，給出最終解決方案。 |
2.9 | 提交解決方案 | 供應商 | 供應商將解決方案提交給相應的升級人員，由其去解決事件，并進入3.1 事件解決 |
三、事件解決與關閉
步驟名稱 | 責任人 | 說明 | |
3.1 | 事件解決 | 二線工程師、三線工程師 | 將事件的解決結果及時更新至平臺中，并標記解決，必要時發起問題工單進一步分析，或發起服務請求單完成臨時解決后尚需進一步完善的遺留狀態，或將事件總結生成知識庫條目。 |
3.2 | 是否恢復？ | 服務臺 | 服務臺與用戶確認事件的恢復結果。 |
3.3 | 填寫用戶反饋和滿意度 | 服務臺 | 將用戶反饋和滿意度調查情況更新至平臺中，并關閉工單。 |
