事件管理流程設計樣例

1、信息中心事件管理流程業(yè)務需求文檔日期:2012-11-26文檔版本: V 0.1 目錄事件管理流程業(yè)務需求文檔11. 介紹1.1. 文檔簡介本文介紹XXXX信息中心事件管理流程和對工具的業(yè)務需求，供參與信息中心IT運維管理系統(tǒng)事件管理流程模塊的開發(fā)和測試人員使用。1.2. 文檔目的為了保證即將建設的“IT運維管理系統(tǒng)”符合XXXX信息中心建設全省一體化協(xié)同運維體系的要求，本文對“IT運維管理系統(tǒng)”中的事件管理模塊的業(yè)務需求進行細化。事件管理流程以確保在故障發(fā)生后盡快地恢復服務，減小對業(yè)務的影響。事件管理流程關注快速地解決故障現(xiàn)象而非查找故障背后的根本原因。1.3. 前提與假設讀者應該了解ITI

2、L，并對事件管理流程具有基本的技能。1.4. 文檔結構本文由以下幾個章節(jié)組成：第一章，“介紹”，描述了本文的適用對象、組織，以及相關術語。第二章， 介紹“事件管理流程”的業(yè)務邏輯，定義了總體流程，詳細流程，流程步驟、角色及職責、業(yè)務規(guī)則、事件單代碼、流程衡量指標。第三章，介紹“事件管理流程”的工具功能需求以實現(xiàn)其業(yè)務邏輯，從工具用戶特點、工單流程、與其他流程關系和流程評估和改進四個方面闡述。第四章， 介紹服務臺結構，省市服務臺邏輯及聯(lián)動模式，及為實現(xiàn)該種模式服務臺業(yè)務邏輯的工具功能需求。1.5. 術語為方便相關人員對事件管理流程的理解，下表對事件管理流程中涉及的術語進行解釋。名詞解釋ITIL(

3、IT Infrastructure Library)是英國政府在1987年制定的有關IT服務管理的最佳實踐，現(xiàn)已成為事實上的IT管理標準。事件管理流程ITIL流程之一，事件管理負責處理IT事件和用戶請求。它的目的是盡快恢復被中斷或受到影響的IT服務，是以快速解決故障現(xiàn)象為目的，而不在于查找根本原因。IT服務XXXX省局信息中心和地市信息科提供給全省稅務系統(tǒng)業(yè)務部門的IT支持服務內容。事件不包含在標準服務操作之內，導致或可能導致服務中斷或服務質量降低的事件。范圍包括XXXX信息中心維護范圍內的所有與IT基礎架構和應用系統(tǒng)相關的故障、咨詢和服務請求。事件單事件在流程管理系統(tǒng)中的數(shù)據(jù)記錄。解決方案是

4、指針對某一個或某一類已找到根本原因的問題，提出的解決問題的最終方案。變通方法（也稱臨時措施）是指解決事件的臨時修復方法或技術，目的是使用替代措施暫時恢復SLA約定的服務，避免事件繼續(xù)對客戶的業(yè)務產生影響，該事件的永久解決措施有賴于對該事件潛在問題的最終解決。IT用戶XXXX省局信息中心和地市信息科的服務對象。監(jiān)控服務臺監(jiān)控服務臺是信息中心為用戶提供服務的唯一接口，是全省一體化協(xié)同運維體系中的重要組成部分。監(jiān)控服務臺的主要工作內容是記錄和受理事件內容，通過知識庫提供初始支持，或通過功能型升級到對應的運維組幫助用戶恢復到正常工作狀態(tài)。事件分析員進行事件處理的支持人員，通常對應信息中心的二線或三線支

5、持人員。事件經理負責協(xié)調和管理事件管理流程的各項活動。運維辦事件經理流程所有者，負責對流程的審計和評估，持續(xù)改進該流程。CIConfiguration item 配置項RFCRequest for change 變更請求單CMDB配置管理數(shù)據(jù)庫2. 事件管理流程2.1. 流程概述XXXX事件管理流程包括地市事件處理和省局信息中心事件處理兩個部分。整個流程、執(zhí)行步驟和各步驟執(zhí)行的順序參見流程概覽圖。這個流程旨在確保全省所有與省級集中信息系統(tǒng)相關的事件得到有效記錄和跟蹤，使事件能在最短的時間內得到解決，并為問題管理等其它服務管理流程提供相關信息。要達到這個目標的重點在于：l 各地市信息科首先對事件

6、進行有效記錄和過濾，如果本級不能處理，則確保升級至省局的事件單信息完整和準確；l 地市和省局信息中心服務臺準確分類分級事件；l 準確的將故障單分派給后臺技術支持組或人員；l 確保用戶對于事件的解決方案是滿意的。事件管理流程由事件驅動，關注事件的響應速度以盡快恢復業(yè)務運營。2.2. 流程步驟描述2.2.1. 事件記錄（地市）2.2.1.1. 描述:事件的記錄是事件管理流程的起點。所有用戶報告或系統(tǒng)產生的IT事件都必須從這個步驟開始。該步驟的目的是快速、準確地探測和捕捉到在IT生產環(huán)境中發(fā)生的錯誤。除此以外，該活動也是其它用戶相關請求的入口，諸如信息咨詢、服務請求。本步驟的重點是準確、完整地采集創(chuàng)

7、建一個事件單所需的必要信息。2.2.1.2. 流程主要內容:輸入：任務：輸出：· 事件驅動輸入： 來自于用戶的請求（提交方式：電話、郵件、Web） 運維人員主動發(fā)起的事件0.11發(fā)起請求0.12識別并驗證用戶信息0.13信息充分性判斷0.14進一步提供信息0.15新事件判斷0.16更新相關事件單0.17記錄新事件單· 已創(chuàng)建的事件單· 已更新的事件單2.2.1.3. 過程環(huán)節(jié):0.11發(fā)起請求執(zhí)行者：用戶· 用戶向所在地市信息科服務臺提交事件請求。· 用戶提交事件請求的方式可以有多種：- 通過電話向服務臺提交請求；- 通過web 網(wǎng)頁形式向運行

8、部提交請求；- 通過電子郵件提交請求；0.12識別并驗證用戶信息執(zhí)行者：地市服務臺 · 接受用戶的事件報告。提示：· 建議通過統(tǒng)一工作平臺用戶管理，建立客戶信息庫以提高識別和驗證效率；· 可使用電話號碼等作為用戶的唯一識別；· 在發(fā)現(xiàn)現(xiàn)有客戶信息庫不完整時，服務臺需要及時更新；· 對用戶信息進行識別和驗證，服務臺需要盡量多地獲取用戶基本信息，諸如：- 用戶姓名（必填）- 用戶標識（是否為VIP用戶）- 電話號碼（手機）（二者必填一項）- 分機號碼- 員工當前所在地點- 所屬部門/所屬辦稅服務廳- 地址· 檢查該用戶是否屬于服務對象的范

9、圍。· 如有必要，更新用戶資料，如聯(lián)系方式。0.13信息充分性判斷執(zhí)行者：地市服務臺 · 對于事件請求，服務臺需要判斷用戶提供的信息是否足夠用于后續(xù)提供支持，快速恢復服務。 - 如果足夠，則進入環(huán)節(jié)“0.15 新事件判斷”· 如果不夠充分，則進入環(huán)節(jié)“0.14 進一步提供信息”0.14進一步提供信息執(zhí)行者：用戶· 用戶按照服務臺要求補充相關信息；0.15新事件判斷執(zhí)行者：地市服務臺 · 根據(jù)用戶提供的事件描述信息，判斷請求是否為新的事件。- 新的事件，進入環(huán)節(jié)“0.17記錄新事件單”- 原有的事件，進入環(huán)節(jié)“0.16更新相關事件單”0.16更新

10、相關事件單執(zhí)行者：地市服務臺 · 對于原有的請求，根據(jù)用戶所提供的描述信息，對之前由該服務請求所產生的工單進行進一步補充。· 補充后的工單仍按原有工單流程進行處理。0.17記錄新事件單執(zhí)行者：地市服務臺 · 創(chuàng)建事件請求，生成事件單，進入后續(xù)流程。· 在事件單中至少需要錄入以下事件信息，以下信息需要詳細而準確： - 事件單號（系統(tǒng)自動產生）- 事件的標題- 事件的詳細信息，包括事件可能造成的服務影響，影響部門等。- 可能的描述事件現(xiàn)象的附件- 事件發(fā)生的時間- 事件單創(chuàng)建時間（系統(tǒng)自動產生）- 事件來源- 事件報告人信息· 事件單如果是來自用戶

11、，則需要填寫用戶信息，至少包含以下內容：- 用戶姓名 - 用戶標識（是否為VIP用戶）- 聯(lián)系電話/手機- 所屬部門/所屬辦稅服務廳· 如果該事件單是由運維人員主動發(fā)起，運維人員作為事件提交者其相關信息由系統(tǒng)自動填寫，至少包含以下內容：- 運維人員帳號或姓名- 運維人員聯(lián)系電話2.2.2. 事件分類分級與初步支持（地市）2.2.2.1. 描述：該步驟的目的是判斷事件級別和分類，隨即在現(xiàn)存的解決方案中查詢與該事件相匹配的方案，或根據(jù)個人經驗嘗試在線對事件進行處理。若沒有找到合適的解決方案或變通方法或需要離線對事件進行處理，該事件需要分配給二線具有合適技術技能的事件分析員。該步驟的重點是

12、正確地分配事件，以避免后面對時間的浪費。2.2.2.2. 流程主要內容:輸入：任務：輸出：· 來自于步驟0.17新記錄的事件單0.21 分類分級0.22 初步支持0.23 能否解決問題0.24 服務臺分派事件單3.25 判斷是否接受事件單3.26 受理事件單· 已分派的事件單表格 21受理與初步分析內容2.2.2.3. 過程環(huán)節(jié):0.21分類分級執(zhí)行者：地市服務臺· 確定事件等級；（具體請參見2.4.7）· 根據(jù)事件影響度和緊急度，確定優(yōu)先級。（具體請參見2.4.8 “優(yōu)先級規(guī)則”）。· 確定CTI分類（具體請參見2.5.4 “事件分類”）。&

13、#183; 如果是省級集中信息系統(tǒng)類事件單，則需標注。0.22 初步支持執(zhí)行者：地市服務臺· 在事件管理中查詢已經存在的解決方案/變通方法，或進行知識庫有效知識的匹配進行在線事件解決；· 根據(jù)事件記錄人員所擁有的技能嘗試確定“解決方案或變通方法”，進行在線事件解決；· 如果可以解決，轉至步驟IM-05“事件單關閉”中的步驟0.51。如果不能解決，轉至步驟0.24“分派事件”。0.24分派事件單執(zhí)行者：地市服務臺· 根據(jù)事件分類不同，把事件分派給合適的事件分析員；· 若地市二線技術人員認為事件單派轉不合理，則事件重新進入“分派事件”環(huán)節(jié)。0.25

14、 二線受理事件單判斷 執(zhí)行者：地市二線· 地市二線事件分析員接到事件后，判斷事件是否分派正確，即是否本人的工作職責和技能范圍。如果是，則轉步驟0.26。如果不是，說明理由，并須考慮是否需要對事件進行重新分類，以幫助服務臺在下一次分派時更準確派單。流程返回步驟 0.24“分派事件”。3.7受理事件單 執(zhí)行者：地市二線· 如果被分派的事件分析員確認該事件單分派正確，則接受該事件單，進入步驟0.31“故障分析”。2.2.3. 二線受理與診斷（地市）2.2.3.1. 描述: 這個步驟的目標是對事件進行分析以便提出解決方案，不同技術領域的事件分析員將會參與到該步驟中以尋求一個事件解決

15、方案，在有必要時會升級至省局信息中心以便快速解決恢復事件影響。2.2.3.2. 流程主要內容:輸入：任務：輸出：· 來自于步驟“0.26受理事件單” 0.31收集相關信息0.32是否重復事件0.33 關聯(lián)至主事件單0.34進行事件分析0.35找到解決方案0.36升級至省局信息中心· 針對該事件的解決方案· 升級至省局信息中心的事件單2.2.3.3. 過程環(huán)節(jié):0.31收集相關信息執(zhí)行者：地市二線· 二線對事件進行處理，并查找可能對事件處理有效的相關信息。· 該處理過程一線往往脫離開流程系統(tǒng)進行，在得到相關信息后，重新登錄到流程系統(tǒng)，并將相關信息

16、記錄在事件單中。0.32是否重復事件執(zhí)行者：地市二線· 尋找有相似癥狀(即由同一原因造成)的事件:- 如找到類似的事件，即進入步驟0.33“關聯(lián)事件到主事件”，如果在事件診斷過程中發(fā)現(xiàn)匹配錯誤，可以取消此關聯(lián)。- 如果沒有找到，進入步驟0.34“事件單分析”0.33關聯(lián)到主事件單執(zhí)行者：地市二線· 判斷當前事件單所描述的現(xiàn)象與之前未解決的事件是否有相似：- 如果確認是重復工單或主事件驅動工單，將新的事件單關聯(lián)到原主事件單- 原有事件單被標識為“主事件單”- 原有事件單關聯(lián)事件單數(shù)加一- 新建事件單出現(xiàn)在原有事件單重復工單列表中· 新事件單狀態(tài)將隨原有事件單狀態(tài)的更

17、新而更新，不單獨進行處理。0.34 事件單分析執(zhí)行者：地市二線· 檢索知識庫查詢可能的解決方案，查找的途徑包括但不限于：- 通過對已記錄激活和未激活知識記錄進行查詢- 通過以往已關閉事件單中的解決方案或處理過程進行查詢- 通過其它公共的資料信息進行查詢· 根據(jù)專業(yè)技術經驗尋找解決方案或者變更方法。· 經分析如發(fā)現(xiàn)解決方案，轉到步驟“0.41解決和恢復” · 如未發(fā)現(xiàn)解決方案，在轉到步驟“0.36升級至省局信息中心”。· 如果在事件恢復和解決階段未能恢復業(yè)務，或者在事件關閉階段用戶不滿意解決方案，則需返回“0.34 事件單分析”，由同一名事件分析

18、員繼續(xù)進行處理。5.8升級至省局信息中心執(zhí)行者：地市二線· 如果當前地市事件分析員由于某些原因不能解決該事件，需要將事件升級至省局信息中心監(jiān)控服務臺。（只限于省級集中信息系統(tǒng)類事件單）2.2.4. 解決和恢復（地市）2.2.4.1. 描述:該步驟嘗試使用解決方案和變通方法來解決事件。某些情況下，需引入變更管理來批準評估實施步驟。對于某些事件，即使得到了解決，仍然需要創(chuàng)建問題單以進一步尋找其根源。2.2.4.2. 流程主要內容:輸入：任務：輸出：· 來自于步驟“0.35找到解決方案”0.41采取恢復操作0.42驗證解決方案0.43服務是否恢復0.44是否進行根源問題分析0.4

19、5創(chuàng)建新的問題并與事件關聯(lián)· 恢復受影響的服務· 創(chuàng)建根本解決該事件單的問題單2.2.4.3. 過程環(huán)節(jié):0.41采取恢復操作 執(zhí)行者：地市二線· 由二線工程師負責實施以確定的解決方案，以恢復受影響的服務。0.42驗證解決方案&0.43服務是否恢復 執(zhí)行者：地市二線· 驗證解決方案的實施是否有效：- 對于方案無效的情況，轉到子流程“0.34進行事件單分析”。- 對于方案有效的情況，轉到子流程“0.51事件關閉”以及活動“0.44是否進行根源問題分析”0.44是否進行根源問題分析&0.45創(chuàng)建新的問題并與事件關聯(lián) 執(zhí)行者：一線·

20、判斷是需要對以解決的事件進行根源問題分析：- 對于需要分析的情況，轉到活動“0.45創(chuàng)建新的問題并與事件關聯(lián)”，針對該事件單新建一個問題單或關聯(lián)到已有的問題單上。- 對于不需要分析的情況，轉到步驟“0.51事件關閉”2.2.5. 事件關閉（地市）2.2.5.1. 描述: 這個步驟確保用戶對事件的處理情況感到滿意。事件單的信息是正確、完整的，以便于以后生成報表。2.2.5.2. 流程主要內容:輸入：任務：輸出：· 來自于步驟“0.43業(yè)務恢復”0.51檢查事件記錄0.52是否需要與用戶確認0.53與用戶溝通0.54提供反饋信息0.54用戶確認事件是否解決0.56關閉事件單·

21、已關閉的事件單2.2.5.3. 過程環(huán)節(jié):0.51檢查事件記錄 執(zhí)行者：地市服務臺· 對于用戶報告的事件單，服務臺檢查系統(tǒng)中事件單記錄的完整性，對于不完整的記錄進行補充。0.52是否需要與客戶確認&0.53與客戶溝通 執(zhí)行者：地市服務臺· 服務臺根據(jù)事件性質，判斷是否需要與用戶溝通事件的處理結果，以便確認事件的真正解決。- 如確認需要告知用戶事件處理結果的情況，轉入活動“0.53與用戶溝通”，溝通形式包括但不限于：系統(tǒng)通告，短信告知，郵件通知，電話通知等方式。- 如確認不需要告知用戶事件處理結果，轉入活動“0.56關閉事件單”0.54提供反饋信息 執(zhí)行者：用戶

22、83; 用戶在接受服務臺通知后，向服務臺提供著呢對事件處理結果的反饋信息。0.55用戶確認事件是否解決 執(zhí)行者：地市服務臺· 服務臺根據(jù)用戶反饋確定事件是否被成功解決：- 如確認事件未解決的情況，轉入子流程“0.34進行事件單分析”，重新查找事件原因。- 如確認事件已解決的情況，轉入活動“0.56關閉事件單”0.56關閉事件單 執(zhí)行者：地市服務臺· 按照關單原則對事件單進行關閉。2.2.6. 事件受理和記錄2.2.6.1. 描述:這個步驟是XXXX省局信息中心事件管理流程的起點。所有地市升級至省局信息中心、IT工程師主動報告或監(jiān)控平臺產生的IT事件都必須從這個步驟開始。該步

23、驟的目的是快速、準確地探測和捕捉到在IT生產環(huán)境中發(fā)生的錯誤。本步驟的重點是準確、完整地采集創(chuàng)建一個事件單所需的必要信息。 2.2.6.2. 流程主要內容:輸入：任務：輸出：· 事件驅動輸入： 來自于地市信息科升級的事件單 工程師主動發(fā)起的事件 通過監(jiān)控平臺發(fā)現(xiàn)的告警事件· 其他信息來源 來自失敗的變更實施1.1識別并驗證事件單信息1.2信息充分性判斷1.3進一步提供信息1.4新事件判斷1.5更新相關事件單1.6監(jiān)控告警1.7記錄新事件單· 已創(chuàng)建的事件單· 已更新的事件單表格 22記錄事件環(huán)節(jié)的內容2.2.6.3. 過程環(huán)節(jié):1.1識別并驗證事件單信息

24、&事件單信息充分性判斷執(zhí)行者：省局監(jiān)控服務臺 · 對地市升級的事件單信息進行識別和驗證，重點關注如下幾點：- 用戶基本信息是否完備；- 事件描述是否清晰，是否提供截圖；- 事件分類分級是否合理；- 是否有對應“內部呈批表或加蓋公章”；- 要求維護參數(shù)表代碼表，確認是否有提供EXCEL格式的內容。· 監(jiān)控服務臺需要判斷地市升級的事件單信息是否足夠用于后續(xù)提供支持，快速恢復服務。 - 如果足夠，則進入環(huán)節(jié)“1.4 新事件判斷”· 如果不夠充分，則進入環(huán)節(jié)“1.3 進一步提供信息”1.3進一步提供信息執(zhí)行者：用戶· 用戶按照服務臺要求補充相關信息；1.

25、4新事件判斷執(zhí)行者：監(jiān)控服務臺 · 根據(jù)地市升級的事件單描述信息，判斷請求是否為新的事件。- 新的事件，進入環(huán)節(jié)“1.7受理新事件單”- 原有的請求，進入環(huán)節(jié)“1.5更新相關事件單”1.5更新相關事件單執(zhí)行者：監(jiān)控服務臺 · 將該事件單關聯(lián)到原有事件單。可對主事件單進行進一步補充相關信息。· 關聯(lián)后的工單仍按原有工單流程進行處理。1.6監(jiān)控告警執(zhí)行者：監(jiān)控工具/工程師· 監(jiān)控平臺自動觸發(fā)的，事件告警信息是通過系統(tǒng)接口自動載入的事件。由工程師主動發(fā)起，并在系統(tǒng)上自助填寫事件單，并轉監(jiān)控服務臺受理。1.7受理或記錄記錄新事件單執(zhí)行者：監(jiān)控服務臺 ·

26、 受理或記錄新事件單請求，進入后續(xù)流程。2.2.7. 初步支持2.2.7.1. 描述：該步驟的目的是監(jiān)控服務臺在現(xiàn)存的解決方案中查詢與該事件相匹配的方案，或根據(jù)個人經驗嘗試在線對事件進行處理。若沒有找到合適的解決方案或變通方法，將事件分配給一個具有合適技術技能的運維組。該步驟的重點是正確地分配事件，以避免后面對時間的浪費。2.2.7.2. 流程主要內容:輸入：任務：輸出：· 來自于步驟1.7“受理或者記錄新事件單”2.1確定事件分類分級2.2重大事件判斷2.3 提供初步支持2.4 能否解決事件單2.5 分派事件單2.6接受事件單分派判斷2.7 說明理由，返回服務臺重新分派事件單2.8

27、報告事件至中心領導層· 已分派的事件單· 管理升級的信息表格 23受理與初步分析內容2.2.7.3. 過程環(huán)節(jié):2.1確定事件分類分級&2.2重大事件判斷執(zhí)行者：監(jiān)控服務臺· 確定事件等級是否正確（具體請參見2.4.7 “事件等級”），如果是重大事件則進行（管理升級）· 確定事件分類是否正確（具體請參見2.5.4 “事件分類”）。· 根據(jù)事件等級和緊急度，確定優(yōu)先級。（具體請參見2.4.8 “優(yōu)先級規(guī)則”）。- 如果不是重大事件則進入步驟 “2.3提供初步支持”。2.3提供初步支持&2.4 能否解決事件單執(zhí)行者：監(jiān)控服務臺

28、83; 在事件管理中查詢已經存在的解決方案/變通方法，或進行知識庫有效知識的匹配進行在線事件解決；· 根據(jù)監(jiān)控服務臺人員所擁有的技能嘗試確定“解決方案或變通方法”，進行事件解決；· 如果可以解決，轉至步驟IM-06“事件單關閉”中的步驟6.1。如果不能解決，轉至步驟2.5“分派事件”。2.5分派事件單執(zhí)行者：監(jiān)控服務臺提示：· 在此環(huán)節(jié)，如果是分派到組，則該運維項目組必須制定負責人，由負責人負責對事件單的組內分派。組員也可主動認領未組內分派的事件單。· 根據(jù)事件所屬系統(tǒng)和類型，將事件單分派到對應運維人員或者運維項目組。2.6是否接受事件單分派&2

29、.7解釋理由并返回服務臺執(zhí)行者：運維項目組· 運維項目組/人接到事件后，判斷事件是否分派正確，即是否本組/人的工作職責和技能范圍。- 如果不是，則須在事件單上解釋理由，將事件單返回服務臺進行重新分派。- 如果接受，則轉步驟 2.5“分派事件”。2.8報告事件至中心領導層執(zhí)行者：監(jiān)控服務臺· 如果事件是重大事件，則立刻向信息中心管理層報告事件。· 信息中心管理層需要考慮和決策是否需要啟動重大應急流程或災備流程。2.2.8. 管理升級2.2.8.1. 描述：該步驟的重點是明確默認的管理升級機制及事件處理過程中正確的進行事件信息通知。2.2.8.2. 流程主要內容:輸入

30、：任務：輸出：· 來自于步驟“IM-2.受理與初步分析”中確定為對事件單級別的判斷· 來自于步驟“IM-5.事件分析”中確定為對事件處理時間的預估3.1開始管理升級3.2/3.5/3.8/3.11重要性判斷3.3/3.6/3.9是否升級3.4/3.7/3.10/3.12持續(xù)關注3.13 事件進展通報3.14是否啟動緊急狀態(tài)判斷· 中心領導層宣布緊急狀態(tài)· 管理層對事件處理指導與批示· 管理層對事件處理持續(xù)關注2.2.8.3. 過程環(huán)節(jié):3.1開始管理升級 執(zhí)行者：運維工程師· 運維工程師根據(jù)事件等級和性質對事件信息進行恰當?shù)纳?。默認

31、的升級規(guī)則見圖中管理升級中默認升級機制· 根據(jù)預定義的通知規(guī)則進行升級通知，通知的形式可能包括諸如：- 通過系統(tǒng)傳遞信息；- 電話，郵件或者短信；· 升級之后進入環(huán)節(jié)“3.2重要性判斷”，判斷是否有必要繼續(xù)升級。3.2/3.5/3.8/3.11重要性判斷&3.4/3.7/3.10/3.12持續(xù)關注執(zhí)行者：各升級環(huán)節(jié)的負責人提示：· 事件管理升級應首先按照等級自動升級；在事件重要性發(fā)生變化時，可由適當級別的負責人進行人工升級· 根據(jù)下級人員提供的事件描述信息，判斷是否應將事件單信息向上級升級。- 如果確定事件單應繼續(xù)升級，轉入下一升級環(huán)節(jié)。 - 如

32、果不需繼續(xù)升級，轉入“持續(xù)關注”環(huán)節(jié)。在“3.4/3.7/3.10/3.12持續(xù)關注”環(huán)節(jié)中，本環(huán)節(jié)負責人應及時收聽或查看與事件處理相關的報告或匯報，確保對事件進展的持續(xù)關注。3.13實時進展匯報執(zhí)行者： 運維工程師由事件的處理工程師向各級領導實施匯報事件的處理進展與當前的影響范圍。3.14 是否啟動緊急狀態(tài)執(zhí)行者：中心領導層· 由中心領導層對事件的影響度及處置情況進行綜合評估，判斷是否將當前事件升級為重大緊急狀態(tài)：- 如果確定是緊急狀態(tài)，轉至 “IM-7 重大緊急事件”子流程- 如果認為暫不構成緊急狀態(tài)，轉至 “持續(xù)關注”環(huán)節(jié)密切關注事件的進展和處置情況。2.2.9. 故障分析2.

33、2.9.1. 描述: 這個步驟的目標是對事件進行分析以便提出解決方案，不同技術領域的事件分析員將會參與到該步驟中以尋求一個事件解決方案，在有必要時會升級至三線或者原廠開發(fā)商以便快速解決恢復事件影響。2.2.9.2. 流程主要內容:輸入：任務：輸出：· 來自于步驟“2.6受理事件單” 4.1收集相關信息4.2是否重復事件4.3 關聯(lián)至主事件單4.4進行事件分析4.5預估解決時間所需時間4.6判斷是否找到解決方案4.7轉派事件單（技術升級）4.8判斷是否受理事件單4.9說明拒絕原因4.10提出解決方案· 針對該事件的解決方案· 管理升級信息2.2.9.3. 過程環(huán)節(jié):

34、4.1收集相關信息執(zhí)行者：二線· 二線對事件進行處理，并查找可能對事件處理有效的相關信息。· 該處理過程一線往往脫離開流程系統(tǒng)進行，在得到相關信息后，重新登錄到流程系統(tǒng)，并將相關信息記錄在事件單中。4.2是否重復事件執(zhí)行者：二線· 尋找有相似癥狀(即由同一原因造成)的事件:- 如找到類似的事件，即進入步驟4.3“關聯(lián)事件到主事件”，如果在事件診斷過程中發(fā)現(xiàn)匹配錯誤，可以取消此關聯(lián)。- 如果沒有找到，進入步驟4.4“事件單分析”4.3關聯(lián)到主事件單執(zhí)行者：二線· 判斷當前事件單所描述的現(xiàn)象與之前未解決的事件是否有相似：- 如果確認是重復工單或主事件驅動工單

35、，將新的事件單關聯(lián)到原主事件單- 原有事件單被標識為“主事件單”- 原有事件單關聯(lián)事件單數(shù)加一- 新建事件單出現(xiàn)在原有事件單重復工單列表中· 事件單狀態(tài)將隨原有事件單狀態(tài)的更新而更新，不單獨進行處理。4.4 事件單分析執(zhí)行者：二線· 檢索知識庫查詢可能的解決方案，查找的途徑包括但不限于：- 通過對已記錄激活和未激活知識記錄進行查詢- 通過以往已關閉事件單中的解決方案或處理過程進行查詢- 通過其它公共的資料信息進行查詢· 根據(jù)專業(yè)技術經驗尋找解決方案或者變更方法。4.5預估解決時間所需時間執(zhí)行者：二線· 二線對事件處理所需的資源和時間進行預判，并將結果通過

36、 “IM-3 管理升級”向管理層及時通報。4.6判斷是否找到解決方案執(zhí)行者：二線· 經分析如發(fā)現(xiàn)解決方案，轉到步驟“5.1解決和恢復” · 如未發(fā)現(xiàn)解決方案，或者需要其他系統(tǒng)運維項目組配合解決，則轉到步驟“4.7轉派事件單（技術升級）”。4.7轉派事件單（技術升級）執(zhí)行者：二線· 如果當前事件分析員由于某些原因不能解決該事件，需要將事件轉派給其他系統(tǒng)運維項目組。· 被分派事件的事件分析員進入步驟4.8“是否接受事件”。5.8判斷是否受理事件單&5.9說明拒絕原因執(zhí)行者：二線、三線· 運維項目組/人接到轉派的事件后，判斷事件是否分派正確，

37、即是否本組/人的工作職責和技能范圍。- 如果不是，則須解釋理由，將事件單返回原事件處理人員。- 如果接受，則轉步驟 2.5“分派事件”。· 轉派超過3次，則事件單自動到事件經理進行協(xié)調。5.10提出解決方案執(zhí)行者：二線、三線· 二、三線工程師根據(jù)事件描述狀況以及所掌握的相關信息，對事件著手進行處理，并嘗試找到解決方案或者應急方案。找到方案后，轉IM5.1 “事件解決和恢復”2.2.10. 解決與恢復2.2.10.1. 描述：這個步驟嘗試使用解決方案和變通方法來解決事件。對于某些事件，即使得到了解決，仍然需要創(chuàng)建問題單以進一步尋找其根源。另外，處理過程中的經驗能夠得到記錄以形

38、成可重用的知識圖 28 解決與恢復2.2.10.2. 流程主要內容:輸入：任務：輸出：· 來自于步驟4.5&4.10 “找到解決方案”5.1是否需要變更5.2采取恢復操作5.3驗證解決方案5.4服務是否恢復5.5是否進行根源問題分析5.6創(chuàng)建新的問題并與事件關聯(lián)· 恢復受影響的服務· 針對該事件的需要根源解決的問題單2.2.10.3. 過程環(huán)節(jié):5.1判斷是否需要變更 執(zhí)行者：二線、三線· 首先判斷解決方案/變通方法是否需要啟動變更管理流程- 如果需要，則進入步驟4.2“創(chuàng)建變更單”，通過變更流程實施； - 如果不需要，則可以直接執(zhí)行，進入步驟5

39、.2“采取恢復操作”5.2采取恢復操作 執(zhí)行者：二線、三線· 實施已確定的解決方案，以恢復受影響的服務。5.3驗證解決方案&5.4服務是否恢復 執(zhí)行者：二線、三線· 驗證解決方案的實施是否有效：- 對于方案無效的情況，轉到步驟4.4“故障分析”。- 對于方案有效的情況，同步轉到步驟6.1“事件關閉”以及步驟“5.5是否進行根源問題分析”5.5是否進行根源問題分析&5.6創(chuàng)建新的問題并與事件關聯(lián) 執(zhí)行者：二線、三線· 判斷是需要對已解決的事件進行根源問題分析：- 對于需要分析的情況，轉到活動“5.6創(chuàng)建新的問題并與事件關聯(lián)”，針對該事件單新建一個問題

40、單或關聯(lián)到已有的問題單上。- 對于不需要分析的情況，轉到子流程6.1 “事件關閉”2.2.11. 事件關閉2.2.11.1. 描述：這個步驟確保用戶對事件的處理情況感到滿意。事件單的信息是正確、完整的，以便于以后生成報表。2.2.11.2. 流程主要內容:輸入：任務：輸出：· 來自于步驟“IM-5.4 業(yè)務已恢復”已解決的事件單6.1檢查事件記錄6.2是否需要與用戶確認6.3與用戶溝通6.4提供反饋信息6.5用戶確認事件是否解決 6.6關閉事件單· 已關閉的事件單2.2.11.3. 過程環(huán)節(jié):6.1檢查事件記錄 執(zhí)行者：監(jiān)控服務臺· 對于用戶報告的事件單，服務臺檢

41、查系統(tǒng)中事件單記錄的完整性，對于不完整的記錄進行補充。6.2是否需要與用戶確認&6.3與用戶溝通 執(zhí)行者：監(jiān)控服務臺· 服務臺根據(jù)事件性質，判斷是否需要與用戶溝通事件的處理結果，以便確認事件的真正解決。- 如確認需要告知用戶事件處理結果的情況，轉入活動“6.3與用戶溝通”，溝通形式包括但不限于：系統(tǒng)通告，短信告知，郵件通知，電話通知等方式。- 如確認不需要告知用戶事件處理結果，轉入活動“6.6關閉事件單”6.4提供反饋信息 執(zhí)行者：用戶· 用戶在接受服務臺通知后，向服務臺提供著呢對事件處理結果的反饋信息。6.5用戶確認事件是否解決 執(zhí)行者：監(jiān)控服務臺· 服

42、務臺根據(jù)用戶反饋確定事件是否被成功解決：- 如確認事件未解決的情況，轉入子流程“IM-5故障分析”，重新查找事件原因。- 如確認事件已解決的情況，轉入活動“6.6關閉事件單”6.6關閉事件單 執(zhí)行者：監(jiān)控服務臺· 按照關單原則對事件單進行關閉。2.2.12. 緊急狀態(tài)2.2.12.1. 描述：這個步驟是針對重大緊急事件的子流程，該流程的啟用必須通過管理升級決定。2.2.12.2. 流程主要內容:輸入：任務：輸出：· 來自于步驟“IM-3管理升級”中確定是緊急狀態(tài)的事件7.1指定緊急應對小組的負責人7.2成立緊急應對小組7.3收集相關信息進行事件分析7.4初步分析結果匯報7.

43、5是否協(xié)調更多資源7.6是否有應急處置預案7.7提出緊急恢復方案7.8提交ECAB審批7.9實施方案7.10方案是否有效· 緊急恢復受影響的服務·2.2.12.3. 過程環(huán)節(jié):7.1指定緊急應對小組的負責人 執(zhí)行者：中心領導· 通過管理升級確定為重大緊急事件后，由信息中心領導制定一名負責人作為緊急應對小組的負責人，對緊急情況進行指揮和處理。· 如果啟動緊急應急狀態(tài)，則事件單轉到該負責人，由該負責人對事件單進行分派。7.2成立緊急應對小組 執(zhí)行者：緊急應對小組· 由緊急應對小組的負責人，選取適當?shù)募夹g和業(yè)務人員成立緊急應對小組，對緊急事件進行處理

44、。7.3收集相關信息進行事件分析 執(zhí)行者：緊急應對小組· 由緊急應對小組對事件的現(xiàn)象、相關CI、影響范圍、技術相關領域的信息進行收集，以供分析診斷。7.4初步分析結果匯報&7.5是否協(xié)調更多資源 執(zhí)行者：緊急應對小組· 根據(jù)上一步驟收集的信息對重大緊急事件作出初步分析判斷，并及時提交報告至中心領導審批，由中心領導決定是否需要向緊急應對小組提供更多資源以便加快處理流程。- 如需要協(xié)調資源，轉入活動“7.3收集相關信息進行事件分析”。- 如確認不要協(xié)調資源，轉入活動“7.6是否有應急處置預案”7.6是否有應急處置預案&7.7提出緊急恢復方案 執(zhí)行者：緊急應對小組

45、· 緊急應對小組查詢已有資源，包括但不限于：可持續(xù)性計劃、事件記錄、知識庫等，確定是否有可以應用于本事件的應急預案：- 如有應急預案，轉入活動“7.8提交審批”。- 如確認沒有應急預案，轉入活動“7.7提出緊急恢復方案”，由緊急應對小組審計編寫應急方案，之后轉入活動“7.8提交審批”。7.8提交審批 執(zhí)行者：ECAB· 應急負責人組織中心領導和對緊急應對小組提交的解決方案進行審批：- 如審批通過，轉入活動“7.9實施方案”。- 如確審批未通過，轉入活動“7.7提出緊急恢復方案”，由緊急應對小組審計重新編寫應急方案。7.9實施方案 執(zhí)行者：緊急應對小組· 緊急應對小

46、組實施以審批的解決方案。· 如果解決方案需要啟動變更管理流程，則需在事件恢復后補錄緊急變更單。7.10方案是否有效 執(zhí)行者：緊急應對小組· 緊急應對小組檢測事件解決方案的實施效果：- 如服務已恢復，轉入子流程“IM-6.1事件關閉”。· 如服務未恢復，轉入活動“7.7提出緊急恢復方案”，由緊急應對小組審計重新編寫應急方案。2.3. 角色與職責本章節(jié)描述省局信息中心有關人員在參與執(zhí)行和管理事件管理方案時的角色和責任。市局參與事件管理的角色可以參照省局對應角色進行設置。一個角色不等于對應一個人員，一個人員可以擔任多個角色。例如，可以由同一個人員擔任事件管理和問題管理負

47、責人的角色。以下為事件管理流程中必須具有的角色：2.4.1 事件管理流程負責人事件管理流程負責人作為事件管理流程的責任人，對于整個流程執(zhí)行的結果負責，并有一定的權力管理流程。事件管理流程負責人的職責包括：· 全面負責流程的效率和成果· 建立考核和目標，以提升流程的有效性和效率· 為保障流程的有效性，需爭取高級管理層承諾投入足夠的資源· 鑒別和管理關鍵的流程成功要素· 控制和帶領流程的改進 · 批準和拒絕偏離流程的請求· 定義事件管理的角色、責任和應負的責任· 定義目標、流程、工作流、政策和規(guī)則，并與相關人員進行溝通

48、· 強制事件管理流程的執(zhí)行· 確保對流程的使用者提供適當?shù)慕逃?#183; 對其他流程負責人和管理層匯報流程的狀況和進度 · 對事件管理流程的有效性和效率進行監(jiān)控，在需要的時候作出改進· 召開和主持對事件管理流程改進的季度會議 · 審計事件管理流程的執(zhí)行· 作為事件管理流程對外的代表2.4.2 事件經理事件經理負責協(xié)調事件管理的日常操作步驟，并管理工作的時間安排。事件經理的責任包括：· 協(xié)調事件管理的日常操作· 確定和執(zhí)行流程本身的變更· 鑒別流程執(zhí)行過程中的例外和異常情況，并進行管理· 傳達流

49、程的新政策和更新的政策· 確保流程標準和步驟得到遵循· 作出資源的承諾和分配· 鑒別和實施流程的改進建議· 產生和分派流程管理的報表· 對事件管理流程的負責人提出改進的建議 · 作為流程的集中聯(lián)絡點，負責與用戶、服務供應商、管理層之間的溝通· 組織解決需要跨越職能部門或項目組的問題，如有需要，應升級匯報· 對于不遵守流程的情形進行處理· 在需要的時候，按照升級政策中所定義的途徑進行升級· 對不遵從事件管理流程的參與者作出通告· 執(zhí)行日常的流程管理· 出席會議并傳達和協(xié)調有關事

50、件和問題· 準備和分析報表· 從事件管理流程的開始到結束進行跟蹤2.4.3 事件分析員事件分析員，主要是省局信息中心作為二線、三線的專業(yè)支持人員，具有某個領域的技術技能。負責提供良好的事件分析和/或者是提供一個方案，來快速恢復受到干擾的服務。省局信息中心的事件分析員按技能或者系統(tǒng)劃分為運維項目組，例如應用運維項目組，大集中征管系統(tǒng)維保項目組等。事件分析員的責任包括：· 分析事件信息· 關聯(lián)受事件影響的CI（配置項）· 確認事件的優(yōu)先級· 查找相同的癥狀的事件，并進行關聯(lián)· 決定恢復服務所需要的必要條件，并啟動適當?shù)男袆?#1

51、83; 根據(jù)事件的優(yōu)先級提供有效的解決方案/應急預案· 如有需要，與廠家和其他小組人員協(xié)同合作· 確定恰當?shù)姆峙?(例如轉派到組內其他事件分析員或者其他組事件分析員)· 根據(jù)事件等級進行恰當管理升級· 識別解決方案或者變通方法是否需要提交變更申請· 記錄解決方案/應急預案· 鑒別成為問題的事件，如需要找出問題的根源，創(chuàng)建問題單（待問題管理實施后需履行此職責）· 向服務臺提供事件單處理進度· 有權限訪問相關已知錯誤、問題解決方法和配置管理數(shù)據(jù)庫(CMDB)2.4.4 監(jiān)控服務臺監(jiān)控服務臺作為省局信息中心的一線的支持人

52、員，是用戶、各地市信息科和省局信息中心的主要聯(lián)系人。作為是事件的負責人，負責受理或創(chuàng)建事件單、跟蹤、協(xié)調事件的解決。監(jiān)控服務臺的責任包括：· 接受用戶或者地市信息科的事件報告或者事件升級請求· 驗證用戶的基本信息，如有需要，更新用戶的資料· 創(chuàng)建或者更新事件單· 收集與事件處理相關信息，并確保信息的完整（尤其是相關審批表）· 分析故障報告信息· 初步評估事件的優(yōu)先級· 確定適當?shù)姆峙?#183; 基于知識庫，初步解決事件· 對于不能解決的事件，分派給合適的事件分析組或人員· 若用戶要求了解事件狀態(tài)，則將事

53、件的當前狀況通知用戶· 與用戶確認事件的狀況和解決方案· 更新和關閉事件單2.4.5 角色映射角色省局信息中心崗位映射監(jiān)控服務臺監(jiān)控服務臺崗事件分析員（二線）應用運維項目組、系統(tǒng)平臺運維項目組、安全及網(wǎng)絡運維項目組事件分析員（三線）各信息系統(tǒng)運維項目組，例如：大集中征管系統(tǒng)維保項目組、發(fā)票在線系統(tǒng)項目組、納服整合平臺項目組等事件經理監(jiān)控服務臺臺長事件流程負責人運維辦事件經理2.4. 業(yè)務規(guī)則2.4.1. 總體業(yè)務規(guī)則· XXXX信息部門（包括省局信息中心和各地市信息科）支持的信息系統(tǒng)和網(wǎng)絡環(huán)境中，所有對服務的正常提供有影響的事件都會通過事件管理流程處理；將通過流程

54、中定義的標準、政策和指導進行管理。· 所有報告事件的部門將會參與統(tǒng)一的事件管理流程，不應該有任何例外。· 確保各地市服務臺作為各地市信息科事件的統(tǒng)一入口，省局監(jiān)控服務臺作為省局信息中心事件的統(tǒng)一入口，從而保證所有的事件都能夠記錄和跟蹤。· 故障處理人員如果因為時間緊迫沒有對所有發(fā)現(xiàn)的故障進行記錄，直接解決故障的話，應事后補單。（補單情況應通過管理來盡量避免）· 需要定期抽查事件單填寫的質量，確保內容足夠明確、詳細。· 應該定期產生和回顧事件管理報表。對沒有解決的問題，應該舉行定期的事件管理會議對這些事件進行評估。· 應該定期對流程進行

55、回顧，以改進事件管理流程。2.4.2. 責任人業(yè)務規(guī)則有效的管理事件的重要因素是定義一個責任人業(yè)務規(guī)則，以確保每個事件在任何時段都有適當?shù)娜藛T負責。當一個事件由地市服務臺創(chuàng)建后且未升級至省局信息中心，地市服務臺作為事件單的責任人，在事件單的全部生命周期內負責推進事件的處理進度。如果事件單升級至省局信息中心，則事件單的負責人是省局監(jiān)控服務臺，但是地市服務臺繼續(xù)跟蹤該事件單的進度。如果事件單是由省局監(jiān)控服務臺或者工程師創(chuàng)建，則省局監(jiān)控服務臺是事件責任人，在事件單的全部生命周期內負責推進事件的處理進度。當事件單被分派后，接受事件單的事件分析員是此事件單的當前負責人；但是分派方（作出分派的服務臺或是作

56、出轉派的事件分析員）有責任通知被分派的事件分析員并要求他接受或是拒絕此事件單。如果需要向用戶通知處理情況，由事件單的當前責任人或服務臺負責。2.4.3. 分派和受理業(yè)務規(guī)則監(jiān)控服務臺可以直接分派事件到運維項目組或人。各運維項目組可以指定組長對分派到該組的事件單進行轉派。在運維項目組組長未及時進行轉派的情況下，組內任何成員均可主動受理此工單。事件處理人員在收到工單指派通知后應盡快做出響應。注:每個運維項目組都需設定一名組長角色。2.4.4. 轉派業(yè)務規(guī)則轉派指監(jiān)控服務臺或者運維項目組組長分派后，被分派對象將事件單轉給組內或者其他組的事件分析員（服務臺分派事件不屬于事件轉派）。轉派業(yè)務規(guī)則確保事件

57、單不被過于頻繁的相互轉派，以至于無法在規(guī)定時間內得到解決。· 事件單可以由事件分析員轉派給本組或其他組的事件分析員。· 事件轉派超過3次（含3次），事件單將升級給事件經理。· 服務臺和事件分析員，由于某些原因（例如出差，休假，培訓等）離開本崗位時，必須確保將未處理完畢的事件單轉派到本崗位其他事件分析員。服務臺或者工具管理員可以手工干預對其單進行組內轉派（不會影響一次分派成功率）· 組內轉派不影響KPI“首次分派成功率”的計算，有兩種情況： 服務臺下單后分派到服務臺組，此種分派不算作第一次分派，不影響一次分派成功率的計算，及后若繼續(xù)在服務臺組內轉派，同樣不影響一次分派成功率的計算。 服務臺派單到后臺各個分析員組后，事件分析員在其組內轉派，也不影響首次分派成功率的計算，若其須轉派到其它組，則需先退回到服務臺，再由服務臺作轉派。此時則算作首次分派不成功，對一次分派成功率的計算有影響。· 事件單轉派時，按第一次狀態(tài)變?yōu)椤?/p>