1、中國移動業(yè)務支撐網(wǎng)網(wǎng)管系統(tǒng)規(guī)范服務管理流程分冊中國移動通信集團公司2004 年 4 月目錄1 綜述 32 運維管理流程詳述 42.1 事件管理 42.1.1 事件管理描述 42.1.2 事件管理目的 42.1.3 事件管理范圍 52.1.4 相關定義 62.1.5 流程職責/角色 112.1.6 主要內(nèi)容 122.1.7 流程衡量標準 132.1.8 流程圖舉例 162.1.9 事件信息項 182.2問題管理 192.2.1 問題管理描述 192.2.2 問題管理目的 212.2.3 問題管理范圍 212.2.4 相關定義 212.2.5 職責/角色 252.2.6 主要內(nèi)容 252.2.7

2、流程衡量標準 262.2.8 流程圖舉例 282.2.9 問題信息項 312.3變更管理 322.3.1 描述 322.3.2 目的 332.3.3 范圍 332.3.4 相關定義 332.3.5 職責/角色 382.3.6 主要內(nèi)容 392.3.7 流程衡量標準 412.3.8 流程圖舉例 442.3.9 變更請求信息項 462.4配置管理 472.4.1 描述 472.4.2 目的 482.4.3 范圍 482.4.4 相關定義 482.4.5 職責/角色 522.4.6 主要內(nèi)容 532.4.7流程衡量標準 542.4.8 流程圖舉例 552.4.9 常見配置元素屬性表 573 運維管理

3、流程關系和運維支持體系 673.1運維流程相互關系 673.2整體運維支持體系 694 附錄 714.1ITIL 國際規(guī)范簡介 714.1.1ITIL 國際規(guī)范簡介 714.1.2分階段實施方法 734.2名詞解釋 761 綜述本文作為中國移動業(yè)務支撐網(wǎng)網(wǎng)管規(guī)范附件之一，將詳細描述本期中國移動 業(yè)務支撐網(wǎng)網(wǎng)管的四大管理功能，及四大管理功能之關的關系，并借助于流程圖的實例 進行詳細說明。運維管理流程包括：事件管理、問題管理、變更管理、配置管理，本附件將分別 對其進行定義和描述，包括：管理目的、管理范圍、主要內(nèi)容、職責/角色規(guī)劃、流程示例等。在本附件最后，還簡單介紹 ITIL 的相關內(nèi)容和實施方法

4、。2 運維管理流程詳述根據(jù)本期業(yè)務支撐網(wǎng)網(wǎng)管系統(tǒng)建設目標，本期運維管理主要實現(xiàn)事件管理、問題管理、變更管理和配置管理，而管理流程是運維管理的主線，它將整個運維管理工作有 機地聯(lián)接起來，下面將對每個流程的內(nèi)容及其實際應用做一個詳細介紹。2.1 事件管理2.1.1 事件管理描述事件管理流程是為 IT 用戶盡快回到正常工作狀態(tài)而設計，其關心的重點是快速響 應、快速恢復，使故障對業(yè)務的影響最小化。事件管理流程受事件觸發(fā)和驅動，所謂事件，是指發(fā)生了非常規(guī)的運作情況，包 括系統(tǒng)崩潰、軟件故障、任何影響用戶業(yè)務操作和系統(tǒng)正常運作的事情、以及影響業(yè)務 流程或違背服務水平協(xié)議的情況。事件也包括一個用戶的請求，如

5、，重設用戶密碼。不 是所有的事件都由用戶產(chǎn)生，監(jiān)控管理平臺產(chǎn)生的告警也可引發(fā)事件。通常由幫助臺負責記錄事件相關信息，向用戶提供對已知問題的處理方法，報告 事件和盡快恢復服務，目的是在事件管理階段獲得盡可能高的事件解決率。所有的事件應該基于相關配置元素的關鍵等級和影響度進行優(yōu)先級分類。事件管理的責任是記錄、分類、調查 / 診斷、解決已知問題、監(jiān)控跟蹤事件、與 用戶和問題管理流程交流、最終解決事件。2.1.2 事件管理目的事件管理流程的主要功能是盡快解決環(huán)境中出現(xiàn)的事件，保持 IT 環(huán)境的穩(wěn)定 性，其目的包括：? 在成本允許的范圍內(nèi)盡快恢復服務? 快速響應系統(tǒng)監(jiān)控產(chǎn)生的故障或用戶的電話請求? 在線

6、獲得幫助? 溝通問題解決的狀態(tài) ? 進行事件控制? 記錄事件? 就事件的優(yōu)先級、緊急性和嚴重性進行分類? 分析、診斷，必要時進行升級? 監(jiān)視，并結束事件? 支持業(yè)務運行? 對業(yè)務應用提供二級支持? 解答有關如何使用的問題? 記錄關于新服務的需求? 記錄關于改變的請求? 提供一個與業(yè)務部門的日常接口? 提供關于服務狀態(tài)的信息更新? 新服務的報告? 關于即將到來的新服務或事件的通知? 進行事后回顧? 提供 IT 管理信息? 人力利用情況? 服務可用性? 產(chǎn)品質量? 支持效率? 供應商服務情況2.1.3 事件管理范圍在BOS系統(tǒng)運維范圍內(nèi)所指的事件，包括所有與IT基礎架構和業(yè)務相關的如下事 件：?

7、申告? 故障?咨詢?業(yè)務處理?維護作業(yè)工科事件的產(chǎn)生有兩類：?由監(jiān)控管理平臺自動發(fā)現(xiàn)并產(chǎn)生的告警事件?由用戶/IT維護人員報告的事件但不包括：?外部用戶匯報的事件?在開發(fā)和測試環(huán)境中的設備或系統(tǒng)產(chǎn)生的事件“事件管理”流程不一定必須找到問題發(fā)生的根本原因，其重點在于如何在盡量短的時 間內(nèi)，恢復已經(jīng)中斷的IT服務，提高服務的可用性。2.1.4相關定義?重分配規(guī)則事件的及時、正確分配和接手處理是確保事件在解決時限內(nèi)解決的關鍵因素。一線和二線技術人員可以拒絕并根據(jù)重分配原則重新分配不屬于自己運維范圍的 事件。?事件性質根據(jù)移動的業(yè)務要求和管理要求，按照事件性質定義如下六類事件:性質描述申告針對BOSS

8、系統(tǒng)的IT用戶投訴故障指因BOSS系統(tǒng)錯誤或非正常因素由監(jiān)控管理平臺 發(fā)現(xiàn)的告警事件咨詢指對系統(tǒng)操作、業(yè)務流程等方面的求助和詢問業(yè)務處理指需要運維人員進行后臺數(shù)據(jù)處理的要求維護作業(yè)指運維人員的日常維護作業(yè)或臨時進行的維護作業(yè)其他其他性質的事件。?事件來源當接到一個問題時，幫助臺人員需要記錄事件來源的類型。幫助臺的事件來源可以包括以下:來源描述用戶來自IT用戶的事件可以有以下幾種記錄方式：電話/郵件/傳真-來自用戶/IT維護人員報告的事件自助開單-用戶/支持人員發(fā)現(xiàn)問題，直接在服務臺系統(tǒng)客戶端開 單客服平臺-來自客服平臺的事件其他-其他方式進入幫助臺的事件監(jiān)控管理平臺監(jiān)控管理平臺發(fā)現(xiàn)的告警事件，

9、通過與服務管理平臺接口發(fā)送告警信息 到服務管理系統(tǒng)中?事件優(yōu)先級優(yōu)先級是事件管理的一個關鍵要素，優(yōu)先級決定處理事件的順序及所需的資源, 事件優(yōu)先級可分為四級，如下表所示：編號優(yōu)先級1緊急2高3中4低事件的優(yōu)先級分兩個層面來定義和確認：幫助臺幫助臺在接到來自監(jiān)控管理平臺的告警事件或 IT用戶報告的事件時，迅速根據(jù)事 件相關的業(yè)務/子業(yè)務或IT系統(tǒng)/設備的關鍵級別及事件的性質，定義該事件的優(yōu)先級 別。如果為緊急事件，立即升級到一線。對于監(jiān)控管理平臺上傳的報警事件，應包含該事件相關聯(lián)的配置元素的搜索代 碼，幫助臺人員據(jù)此確定配置元素及其關鍵級別。幫助臺人員可參考下表確定事件優(yōu)先級：事件優(yōu)先級本次事件

10、所對應CI的關鍵級別123事件 性質故障1緊急高中2緊急中低3高低低申告高中低咨詢/業(yè)務處 理/維護作業(yè)中低低一線一線人員在接受到幫助臺升級上來的事件后，根據(jù)該事件相關的業(yè)務或IT系統(tǒng)/設備的實際故障情況，并結合其他相關因素，再次確定事件優(yōu)先級，如確實為緊急事 件，則啟動升級機制。確定事件優(yōu)先級后，即可以確定事件的處理時限，優(yōu)先級對應的事件解決時限參 考下表：優(yōu)先級緊急高中低解決時限（小時）482448?事件的升級事件升級的目的是確?；谑录膬?yōu)先級等級及時通知有關技術人員和領導，引 起更多的重視，提供合適的資源，從而快速找到解決事件的方案?？筛鶕?jù)所要求的處理時間定義事件優(yōu)先級升級規(guī)則，包括不

11、同等級的事件在不同 的時間被升級到不同級別的人員：時間 優(yōu)先級即時響應+15分鐘處理時限30%處理時限40%處理時限緊急ABD E F-高ABcDE中ABC-D低AB:C-升級組群：A 幫助臺B 一線支持人員C二線支持人員D事件經(jīng)理E管理層F集團公司各省可以根據(jù)業(yè)務的實際情況調整升級標準?事件分類根據(jù)移動目前的事件種類，事件的分類層次設計不超過三層，第一級分類，稱之 為“類別”，第二級分類，稱之為”子類”，第三級分類，稱之為”條目”。本規(guī)范給 出第一級、第二級分類。各省市根據(jù)自己的情況決定是否要定義到第三層。F表為事件分類表舉例:類別子類條目基礎架構網(wǎng)絡通訊系統(tǒng)服務器存儲系統(tǒng)系統(tǒng)軟件操作系統(tǒng)數(shù)

12、據(jù)庫中間件雙機熱備軟件系統(tǒng)監(jiān)控軟件業(yè)務采集計費結算客服業(yè)務管理賬務管理賬務處理一級 BOSS撥測其他配套設施空調UPS機柜照明溫濕度傳感器外設其他?事件狀態(tài)代碼事件狀態(tài)代碼表明事件所處的處理狀態(tài)，本規(guī)范規(guī)定的事件狀態(tài)如下:事件狀態(tài)代碼描述新建新開事件記錄分配事件在幫助臺一線處理一線支持人員已接手處理事件二線處理二線支持人員已接手處理事件供應商處理由供應商處理已解決事件已找到解決方案關閉確認解決方案，事件得以關閉?事件結束代碼事件結束代碼說明了事件是在何種情況下關閉的，本規(guī)范規(guī)定的結束代碼如下:事件結束代碼描述暫時解決用變通辦法暫時解決已解決幫助臺由幫助臺人員成功解決一線解決由一線人員成功解決二

13、線解決由二線人員成功解決第二方解決由第二方成功解決其他包括消失，誤操作，可忽略等?處理是否超時事件超時代碼描述未超時事件最后時限范圍內(nèi)結束超時事件未能在最后時限范圍內(nèi)結束2.1.5流程職責/角色事件管理流程主要分為以下幾個職責/角色，分別簡述如下：? 事件經(jīng)理?作為事件流程的負責人，負責制定流程的規(guī)則、策略、步驟?調度資源，協(xié)調解決跨小組、部門的事件?指導日常操作，確保流程的執(zhí)行符合預定的要求和規(guī)則?建立流程的衡量指標和報表?與用戶、服務商和管理層交流流程的使用情況?確認和實施對流程的變更/改進計劃? 幫助臺人員?在指定的響應時間內(nèi)響應所有幫助臺熱線電話、郵件、傳真等事件報告?完整記錄所有接收

14、的事件信息，包括：記錄事件報告人的詳細聯(lián)系方式、事件特 征表現(xiàn)、描述、發(fā)生時間等?為事件進行適當?shù)姆诸悺槭录峙鋬?yōu)先級等屬性?嘗試使用工具、初步診斷、分析相關信息等方式解決問題?如果幫助臺不能解決這個事件，應當將事件分配給最合適的一線支持小組/人員來處理?檢查事件記錄的處理進度，保持與事件報告人的聯(lián)系，適時通知事件處理進展?與用戶確認事件解決方案，關閉事件 ? 一線支持人員 一線支持人員負責提供對幫助臺無法解決的事件進行快速有效的分析并提出解決方案以 盡快恢復服務，并在必要時提供現(xiàn)場支持? 驗證事件的描述和信息，進一步收集相關信息? 決定需要采取何種措施恢復服務并實施有效的行動? 必要時提供

15、現(xiàn)場支持? 根據(jù)優(yōu)先級提供有效的解決方案? 已解決的事件轉回幫助臺，由幫助臺關閉事件? 實施事件解決方案? 更新事件解決信息，已解決的事件轉回幫助臺，由幫助臺關閉事件? 如果一線不能解決這個事件，應當決定選擇最合適的二線支持小組/ 人員來處理? 二線支持人員 二線支持人員是相關問題領域的專家。負責提供對一線支持人員無法解決的問題進一步 進行調研，找出解決方案并盡快恢復服務。各省可以考慮按照所維護的應用、系統(tǒng)進行 分組，如，網(wǎng)絡組、主機組等。? 進行事件的深入調查研究? 根據(jù)經(jīng)驗和專業(yè)技能，決定需要采取何種措施恢復服務并實施有效的行動? 必要時引入供應商的支持? 在系統(tǒng)中更新事件根源和最終解決方

16、案? 更新事件記錄，確保事件狀態(tài)代碼真實反映事件狀態(tài)。? 及時提供有效解決方案? 與其他小組合作，確定解決方案? 已解決的事件轉回幫助臺，由幫助臺關閉事件? 如果二線不能在解決時限內(nèi)解決這個事件，應當將事件進行升級2.1.6 主要內(nèi)容事件管理流程始于事件的探測和報告，結束于事件的解決。該流程包含下述主要內(nèi)容：? 事件接收和記錄這個環(huán)節(jié)是事件管理流程的起點。所有用戶或系統(tǒng)報告的 IT 事件必須由此步驟開始。此步驟的目的是在事件發(fā)生時快速準確地發(fā)現(xiàn)，以協(xié)助事件的診斷和解決并通知相關人員。在此步驟中將會收集創(chuàng)建事件記錄所需的信息。 該環(huán)節(jié)的關鍵是信息的準確性和完整性。? 分類和在線支持 事件可以是一

17、個服務請求、信息請求或服務故障，對于每個事件，需要確立優(yōu)先級、 影響度、和分類。若沒有現(xiàn)成的解決方案或臨時解決措施，該事件將分配給合適的支持 人員對此進行調查。該環(huán)節(jié)的關鍵是需要知識庫支持和正確的事件分派。? 調查和診斷 若在線支持人員無法解決事件，可運用自身技能、知識庫、診斷工具等進行更加深入 的分析以找到恢復服務的臨時措施，必要時將使用多名技術員以尋求解決措施。? 解決和恢復技術人員實施事件的解決方案，并將解決完畢的事件轉回幫助臺，由幫助臺通知用戶 解決的結果，并得到用戶的確認。? 緊急事件和事件升級 對于緊急事件，幫助臺應立即提交給一線人員，由一線人員判斷，上報給事件經(jīng)理， 并同時上報給

18、集團公司，由事件經(jīng)理決定緊急處理的方式，確保其得到最快速的解決。當事件處理超過預期時限，將自動升級或由運維人員升級，以引起相關人員和管理人 員的重視和參與。? 結束事件 當用戶確認事件解決后，此時可結束該事件，并在必要時更新知識庫。若用戶對此解 決方案不滿意，則對該事件繼續(xù)進行處理，不能關閉。2.1.7 流程衡量標準事件管理流程的主要衡量指標如下：? 事件記錄數(shù)量，可按照部門、事件分類等分別統(tǒng)計? 事件關閉的數(shù)量，可以按照優(yōu)先級，或者按照分類分別統(tǒng)計? 事件成功關閉的數(shù)量? 規(guī)定時間內(nèi)解決的事件數(shù)量 / 百分比? 幫助臺解決率?事件解決的平均時間，可以按照事件分類統(tǒng)計?超時的事件數(shù)量，可以按人

19、員、組別統(tǒng)計 統(tǒng)計報表?事件記錄的數(shù)量，可按照事件分類、事件性質、事件優(yōu)先級等分別按月、周、日匯總統(tǒng)計該時間段內(nèi)創(chuàng)建的事件記錄數(shù)量故障申告咨詢業(yè)務處理維護作業(yè)其他緊急高中高中低中低中低中低緊急高中低網(wǎng)絡設備服務器存儲系統(tǒng)計費結算客服?處于各狀態(tài)的事件數(shù)量，可按事件來源、事件分類、事件狀態(tài)實時匯總事件記錄 數(shù)量新建分配一線處理二線處理供應商處理已解決關閉網(wǎng)絡設備服務器存儲系統(tǒng)計費結算客服?事件關閉的數(shù)量，可按事件來源、事件分類、事件結束代碼等分別按月、周、日 匯總統(tǒng)計該時間段內(nèi)創(chuàng)建的事件記錄的關閉數(shù)量成功解決可忽略事件后續(xù)操作解決部分解決部門1監(jiān)控系統(tǒng)1成功解決可忽略事件后續(xù)操作解決部分解決網(wǎng)絡

20、設備服務器存儲系統(tǒng)?按時、超時解決的事件數(shù)量/百分比，可按事件來源、事件分類、處理角色等分 別按月、周、日匯總統(tǒng)計該時間段內(nèi)創(chuàng)建的事件記錄的解決數(shù)量幫助臺一線二線第三方按時超時按時超時按時超時按時超時數(shù)量百分比數(shù)量百分比數(shù)量百分比數(shù)量百分比數(shù)量百分比數(shù)量百分比數(shù)量百分比數(shù)量百分比部門1監(jiān)控系統(tǒng)1幫助臺一線二線第三方按時超時按時超時按時超時按時超時數(shù)量百分比數(shù)量百分比數(shù)量百分比數(shù)量百分比數(shù)量百分比數(shù)量百分比數(shù)量百分比數(shù)量百分比網(wǎng)絡設備服務器存儲系統(tǒng)?各角色事件解決率，可按事件來源、事件分類、處理角色等分別按月、周、日匯 總統(tǒng)計該時間段內(nèi)創(chuàng)建的事件記錄的解決率幫助臺一線二線第三方部門1監(jiān)控系統(tǒng)1幫

21、助臺一線二線第三方網(wǎng)絡設備服務器存儲系統(tǒng)2.1.8流程圖舉例如下是事件管理的邏輯示意圖:流程說明序號步驟名稱責任人輸入說明輸出100.1創(chuàng)建事件記錄 并分類幫助臺事件特 征描述接受從IT用戶或監(jiān)控管理平臺報告的事件，在幫 助臺系統(tǒng)中產(chǎn)生新服務記錄，填入相關信息。并對事件進行分類，根據(jù)設定標準進行分類和分優(yōu) 先級，設置相關屬性。事件記 錄100.2優(yōu)先級最高？幫助臺事件記 錄根據(jù)事件相關的配置兀素 CI的關鍵級別。 確定事件的優(yōu)先級是否最高，如是立即升級到一線 支持人員，否則嘗試解決。優(yōu)先級 確定結 果100.3確認優(yōu)先級別一線事件記 錄一線支持人員根據(jù)事件相關配置兀素和其他相關信 息確定該事件

22、是否確屬優(yōu)先級最高已確定 優(yōu)先級 的事件 記錄100.4優(yōu)先級最高？一線已確定 優(yōu)先級 的事件 記錄如果優(yōu)先級確實最高，則立即升級到事件經(jīng)理，并 通報集團公司，并立即開始處理，如不是，則返回 幫助臺N/A通知事件經(jīng)理事件經(jīng) 理事件記 錄最高優(yōu)先級事件必須立即通知事件經(jīng)理，由事件經(jīng) 理決定是否由原處理人按照原流程執(zhí)行，還是需要 采取必要手段干預（例如：啟動危機處理流程、會緊急解 決方案議等）。上報集團集團事件記 錄緊急事件必須上報集團公司（并在事件處理過程中的 每個狀態(tài)變化點將最新事件記錄上傳到集團公司 ）緊急事 件100.5嘗試解決幫助臺事件記 錄通過查詢知識庫，嘗試電話支持解決方 案100.

23、6解決了嗎？幫助臺N/A如果解決了，則進入 100.16，確認并關閉事件； 如果不能解決，進入 100.7，轉發(fā)至一線。N/A100.7事件轉發(fā)至一 線幫助臺事件記 錄選擇適當?shù)囊痪€人員，將事件轉發(fā)轉發(fā)的事件100.8檢查事件并解 決一線事件記 錄檢查事件信息，尋求解決方案解決方 案100.9解決了嗎？一線N/A如果解決，則將解決方案記入事件記錄，并發(fā)還幫 助臺，進入100.16；如果不能解決，則需在事件記錄中說明原因，轉發(fā) 二線N/A100.10事件轉發(fā)至二 線一線事件記 錄選擇適當?shù)亩€人員，將事件轉發(fā)轉發(fā)的事件100.11調查診斷并解 決二線事件記 錄進行進一步調查分析，找出解決方案解決

24、方 案100.12解決了嗎？二線N/A如果”是”，則將解決方案記入事件記錄，發(fā)還幫 助臺，進入100.16；如果”否”，則轉入 100.13。需要供應商支持？N/A100.13需要第三方支持？二線N/A判斷是否需要引入第三方（第三方包括廠商和其他部 門的支持人員）：“是”，轉入 100.15 ；“否”，轉入100.14N/A100.14超出時限？二線N/A如果超出處理時限，必須及時通知事件經(jīng)理r n/a通知事件經(jīng)理事件經(jīng)理N/A事件經(jīng)理應當特別關注超時的事件，并幫助協(xié)調資 源，監(jiān)督事件盡快解決N/A100.15技術支持供應商支持請 求供應商得到通知后，應參與事件的解決，并提出解 決方案，由二線

25、人員監(jiān)控供應商的響應速度和處理 速度。解決方 案100.16確認并關閉事 件幫助臺已解決 的事件幫助臺應與用戶確認是否接受解決方案，如果用戶 認可，則可關閉事件，如果用戶不能接受，則發(fā)還 處理人員，繼續(xù)處理。關閉的 事件記 錄2.1.9事件信息項本規(guī)范規(guī)定事件管理流程必須包含如下事件信息項信息項說明填寫方式事件流水號工單號碼系統(tǒng)生成報告人信息本次事件報告人的聯(lián)絡信息，包括：姓名省/分公司部門根據(jù)報告人的搜索 代碼，自動獲取 CMDE中報告人信息電子郵件 辦公電話 手機/BP生成時間在幫助臺生成事件記錄的時間系統(tǒng)生成地點事件發(fā)生的地點-發(fā)生時間事件發(fā)生的實際時間-事件性質從事件所屬性質的角度來確

26、定其處理流程，如申告、故 障、求助、業(yè)務處理、維護作業(yè)等。事件來源指事件工單產(chǎn)生的途徑，有人工產(chǎn)生、系統(tǒng)自動產(chǎn)生兩 類。由監(jiān)控管理平臺自 動產(chǎn)生的，可自動 填寫事件優(yōu)先級事件優(yōu)先級決定了事件的解決時限和處理次序，通過綜合 衡量配置元素的關鍵級別和其他相關信息得出。事件分類從事件從屬的系統(tǒng)或技術架構的類型來進行分類，如數(shù)據(jù) 庫，服務器等。事件標題事件的標題由監(jiān)控管理平臺自 動產(chǎn)生的，可自動 填寫事件描述對于整個事件內(nèi)容的詳細描述由監(jiān)控管理平臺自 動產(chǎn)生的，可自動 填寫事件解決確認人在幫助臺得到用戶確認的有關人員-事件狀態(tài)在事件整個生命周期中的不同狀態(tài)系統(tǒng)生成分配對象被分配的技術支持組和人員-事件

27、日志反映事件處理過程中的事件處理信息，包括人員，時間等 信息-是否超時事件處理時間是否超出解決時限系統(tǒng)生成解決時間事件得到解決的時間-解決方案描述事件解決方案的描述-事件結束代碼根據(jù)事件結束的不冋方式賦予不冋的結束代碼-2.2問題管理221問題管理描述問題是一個或幾個已暫時處理但根本原因尚不明確的事件，許多事件往往是由同一個問題引起的。問題的來源主要有以下幾種：已經(jīng)關閉的事件，經(jīng)過回顧分析后，可能形成一個問題；重大事件，雖然經(jīng)過緊急處理恢復服務，但未找到根本原因，也形成一個問題； 對于趨勢性事件的分析，形成問題。問題管理流程的根本目的是消除或減少事件的發(fā)生， 將 BOSS 系統(tǒng)內(nèi)部缺陷導致的

28、業(yè)務事件或問題的負面影響降到最低限度，此流程分析發(fā)生在生產(chǎn)環(huán)境的事件（常常是已關閉的事件記錄 ），確定最常發(fā)生或具有最大影響的事件，找出根本原因，然后生成 變更請求（RFC）、變通方法或建議的預防性措施來防止事件的再次發(fā)生。所以問題管理 流程需要和變更管理流程一起來實施找出的解決方案以從根本上解決問題。問題通常具有以下特征中的一個或全部：? 一組具有一定關系的已結束的事件? 一個重大或緊急事件 （事件處理結束后定義為問題，由問題管理找出根本解決方案）問題管理與事件管理之間的差異問題管理與事件管理并不相同，它的主要目的是查明事件的潛在原因，并制定隨 后的解決方案和預防方法。在大多情況下，此目的與

29、事件管理目的之間有一定沖突，因 為事件管理的目的是盡快地恢復客戶服務，通常是通過實施替代方案，而非確定一個永 久性的解決方案（例如為了盡可能地預防未來可能出現(xiàn)的事件，尋求改善信息技術基礎 架構的結構）。就問題管理而言，對潛在原因的調查可能需要一定的時間，找到解決方 案的速度是次要的考慮因素，但是預防了問題的再次發(fā)生。問題管理流程可以按照不同領域的問題（如網(wǎng)絡問題，或應用問題等）由相關組的技 術支持專家來執(zhí)行，原則上這些專家可以是事件管理的二線支持專家，他們在負責接受 來自一線支持人員（幫助臺員工）的支持請求的同時，也負責對以往事件進行分析，找 出事件產(chǎn)生的根本原因，從而確定解決方案，消除這些根

30、本原因，最終使此類事件不再 發(fā)生；同時，也要從發(fā)生的事件中找出事件的發(fā)展趨勢或潛在可能發(fā)生的問題，從而預 先采取措施，保證 IT 服務的正常化。問題的根本原因找出后即成為已知錯誤， 對已知錯誤實施解決方案， 從而解決問題。所以問題管理流程的輸出有：? 變更請求? 變通方法? 根本解決方案? 預防性措施? 已知錯誤222問題管理目的問題管理流程在IT部門設立的主要目的是分析已被列為問題的事件（一組或 個）的根本原因，然后找出解決方案。包括：?分析并確定事件的根本原因，以防止再次發(fā)生?主動提供預防性措施?提高IT服務的可靠性?降低IT支持成本?提高IT部門的整體形象和名譽2.2.3問題管理范圍問題

31、管理范圍是對所有IT生產(chǎn)環(huán)境中未根本解決的問題和已知錯誤進行管理， 并采取主動性預防措施來降低事件數(shù)量，重大或緊急事件在處理完后也被定義為問題以 分析其產(chǎn)生的根本原因。一般對IT服務影響最大或最占用支持人員資源的事件優(yōu)先進行分析。問題管理范圍不包括處于開發(fā)或測試環(huán)境的系統(tǒng)和應用2.2.4相關定義優(yōu)先級需要確定解決方案的緊急程度，本規(guī)范定義如下問題優(yōu)先級:編號優(yōu)先級 代碼解釋1緊急關鍵級別為1的業(yè)務中斷或將中斷，影響一個以上關鍵 地區(qū)或半數(shù)以上地區(qū)2高關鍵級別為1的業(yè)務中斷或將中斷，影響一個以上地區(qū) 但未達到緊急標準3中關鍵級別為1的子業(yè)務或半數(shù)以上子業(yè)務中斷或將中斷4低未達到以上標準問題狀態(tài)代

32、碼問題在整個生命周期中的不同狀態(tài)。本規(guī)范定義如下問題狀態(tài):編號代碼描述1已登記問題登錄到系統(tǒng)中2處理中問題正在處理過程中3拒絕問題分派被拒絕4已知錯誤問題根本原因已找出5已有解決方案解決方案已找到6RFC已提交RFC7結束問題已結束8回顧問題已做回顧問題分類(classification)從問題從屬的系統(tǒng)或技術架構的類型來進行分類。本規(guī)范定義如下問題分類:類別子類條目基礎架構網(wǎng)絡通訊系統(tǒng)服務器存儲系統(tǒng)系統(tǒng)軟件操作系統(tǒng)數(shù)據(jù)庫中間件雙機熱備軟件系統(tǒng)監(jiān)控軟件業(yè)務采集計費結算客服業(yè)務管理賬務管理賬務處理一級 BOSS撥測其他配套設施空調UPS機柜照明溫濕度傳感器外設其他問題性質根據(jù)問題的不同來源進行分

33、類。本規(guī)范定義如下問題性質:編號代碼備注1升級事件從事件管理中升級的事件:2系統(tǒng)構架問題技術專家提出的問題3 n主動防范性分析事件記錄找出的問題冋題結束代碼問題結束代碼：根據(jù)事件結束的不同方式賦予不同的結束代碼。本規(guī)范定義如下問題結束代碼:編號代碼說明1根本解決找出冋題的根本原因，并得到解決方案，成功 解決2變通方法未找出根本原因，但有臨時解決方案作為變通 方法3 沒有解決問題無法解決4消失問題無法再現(xiàn)225職責/角色問題管理流程主要分為如下幾個職責角色，分別簡述如下: 問題經(jīng)理?整體上對流程負責，確保流程的有效執(zhí)行?定期評估流程，制定流程改進計劃? 確定或定義問題，并確保有效協(xié)調資源?監(jiān)視問

34、題的診斷，分析和處理過程?提出實施解決方案的變更請求?定期制定IT問題報表，提供正確決策信息問題分析專家?接受問題經(jīng)理分派過來的問題?分析和診斷問題，確定根本原因?確定和測試解決方案?協(xié)助事件支持人員進行重大或緊急事件的處理2.2.6主要內(nèi)容問題管理流程著重于消除事件或減少事件發(fā)生，確定事件的根本原因。主要活動 包括分析事件、找出問題、分派問題、確定根本原因、找出解決方案以消除事件或在其 發(fā)生時降低對用戶或業(yè)務的影響。其主要內(nèi)容如下：1. 分析事件定期分析事件，找出潛在問題2. 生成問題記錄?在系統(tǒng)中生成問題記錄并把所有相關事件與此記錄關聯(lián)起來?重大或緊急事件處理完后定義為問題?技術支持專家在

35、日常運維中發(fā)現(xiàn)的問題?主動性防范3. 分派 根據(jù)問題內(nèi)容將問題記錄分派給適當?shù)募夹g小組。4. 根本原因分析 被分派的小組人員將調查問題以期找出其原因，制定解決方案、變 通方法或提出預防性措施，以消除產(chǎn)生原因，或在重發(fā)時使其影響力最小化。5. 更新已知錯誤問題記錄必須被更新以反映它是已知錯誤狀態(tài)，并且把任何變通方 法、避免或最小化負面影響的動作行為也記錄下來（如果需要添加到知識庫中）。6. 提出變更請求 對問題的解決方案進行評估，通過提出變更請求（RFC）以對該方案進行測試和實施。如果 RFC沒有被批準，問題記錄保持為已知錯誤，它們可以被事 件支持人員在事件再次發(fā)生時參考借鑒。7. 關閉 一旦找

36、出問題根本原因，并實施了解決方案，確認已解決了問題，問題記錄 可以關閉。8. 事后回顧 問題必須進行回顧以找出改進機會或總結預防性措施。包括改進事件監(jiān) 測、找出技能差距和文檔資料改進等。2.2.7流程衡量標準問題管理流程的主要衡量指標如下：?每一階段內(nèi)的已知錯誤數(shù)量?在每一階段內(nèi)未結的問題記錄?每一階段內(nèi)未了結的由問題引發(fā)的RFC數(shù)量?在IT環(huán)境中存在的臨時性變通辦法數(shù)量統(tǒng)計報表問題的數(shù)量，可按問題分類、問題性質、優(yōu)先級、影響度等分別按月、周、日匯總統(tǒng)計 該時間段內(nèi)創(chuàng)建的問題記錄數(shù)量優(yōu)先級影響程度緊急高中低高中低無網(wǎng)絡設備服務器存儲系統(tǒng)優(yōu)先級影響程度緊急高中低高中低無升級事件系統(tǒng)構架問題主動防

37、范性處于各狀態(tài)的問題數(shù)量，可按問題分類、問題性質、問題狀態(tài)分類實時匯總已登記處理中拒絕已知錯誤已有解決方案RFC結束回顧網(wǎng)絡設備服務器存儲系統(tǒng)已登記處理中拒絕已知錯誤已有解決方案RFC結束回顧升級事件系統(tǒng)構架問題主動防范性?問題關閉的數(shù)量，可按問題分類、問題事件、問題結束代碼等分別按月、周、日匯總統(tǒng)計該時間段內(nèi)創(chuàng)建的問題記錄的關閉數(shù)量根本解決變通方法沒有解決消失網(wǎng)絡設備服務器存儲系統(tǒng)根本解決變通方法沒有解決消失升級事件系統(tǒng)構架 問題主動防范 性228流程圖舉例如下是問題管理的邏輯示意圖舉例:精選問題管理邏輯流程罰公團集上報集團 公司管 司層 公理 省在必要時升級到管理層理 管員 更人評估/實施

38、變更理 管員 件人 事事件記錄理 經(jīng) 題 問300.3問題 優(yōu)先級和分類300.4分派 ” 給工 作組/監(jiān)視300.9 提交變更 請求/監(jiān)視 變更實施300.8安排 實施 解決 方案嗎？300.10關閉問300.11” 題廠*回顧 記錄需要變家專析分題問300.7推薦解 4決方案/變通方法關于該邏輯流程的簡單描述如下:序號步驟名稱責任人輸入說明輸出300.1分析事件問題經(jīng)理事件記錄定期分析回顧事件，主動發(fā)現(xiàn)潛在問題。分析事件 的頻度和嚴重度，和其他的相關因素進行關聯(lián)，如 CI位置、宕機時間、特定用戶、硬件平臺、軟件版 本和一天中發(fā)生的時間等。具體的做法可以是一周開一次由主要事件支持人員 參加的

39、例會，討論上周發(fā)生的IT事件。分析結果300.2創(chuàng)建問問題分析結把找出的問題記錄到系統(tǒng)中去，并進行詳細說明問題記題記錄經(jīng)理果錄300.3問題優(yōu)先級及分類問題經(jīng)理問題記錄根據(jù)問題的實際情況，給其分派一個優(yōu)先級代碼和影響度代碼（必要時進行升級，如優(yōu)先級最高時），并根據(jù)擬定的分類原則給問題賦予適當?shù)念悇e代碼并根據(jù)問題具體情況設定一個解決時限。已分類問題優(yōu)先級最高嗎？問題經(jīng)理已分類問題如果問題優(yōu)先級為最高，由問題經(jīng)理立即把該問題上報到集團公司，并把該問題升級到管理層N/A300.4分派給工作組/監(jiān)視問題經(jīng)理問題記錄初步判斷問題的可能原因，把問題分派給相應工作組或個人，并監(jiān)視問題的解決過程，如有必要（如

40、超過解決時限）啟動升級流程已分派問題在必要時升級問題經(jīng)理N/A問題經(jīng)理在監(jiān)視問題解決的過程中，根據(jù)具體情況 可把該問題升級到管理層，如問題超出解決時限時N/A判斷是否接受？問題分析專家N/A問題分析專家對問題進行初步分析，以決定接受與否。如拒絕轉向300。 6繼續(xù)，如接受轉向300。 7繼續(xù)。N/A300.5拒絕問題問題分析專家已分派問題問題分析專家根據(jù)判斷發(fā)現(xiàn)問題應該由其他組分析 解決，就把問題發(fā)回問題經(jīng)理，注明拒絕理由并推 薦組名。轉向300。4繼續(xù)。已拒絕問題300.6分析根本原因問題分析專家已接受問題如果冋題確應由本人或本小組解決，接受分派的冋 題，然后調查診斷問題，如有必要成立問題分

41、析小 組，舉行問題根本原因分析研討會議并確定問題的 潛在原因。必要時更新問題狀態(tài)。問題根本原因300.7推薦解 決方案/ 變通方 法問題分析專家問題記錄、問題根本原因找出問題的根本原因后，根據(jù)實際情況制定變通方 法或根本性解決方案，并確保這些方法或方案將降 低或消除事件的發(fā)生率或影響度，更新問題記錄。問題解 決方案問題變 通方法300.8安排實施解決萬案問題經(jīng)理問題解決方案 問題變 通方法根據(jù)問題專家提供的解決方案或變通方法，計劃并實施解決方案以解決問題解決方案實施計劃判斷是否需要問題經(jīng)理N/A判斷實施上述解決方案是否需要進行變更，如不需要變更轉向 300。10繼續(xù)，如需要變更轉向300。9N

42、/A變更？以提出變更請求。300.9提交變更請求問題經(jīng)理解決方案實施計劃根據(jù)冋題分析專豕制疋的解決方案或變通辦法，提 出變更請求，填寫變更請求單，遞交到變更管理流 程，并監(jiān)視變更的實施過程，和變更管理保持溝 通。變更請求RFC300.10關閉問題記錄問題經(jīng)理已解決的問題變更結束后，確認冋題已經(jīng)解決，選擇相應的結束 代碼，更新問題狀態(tài)，關閉問題記錄。已關閉的問題300.11回顧問題經(jīng)理已關閉的問題對所有已關閉問題都進行回顧，找出可能改進的機 會，包括問題的解決方案和管理流程方面，如改進 升級規(guī)則、改進事件監(jiān)測、找出技能差距和文檔資 料改進等；回顧之后更新問題狀態(tài)。已回顧的問題229問題信息項本規(guī)

43、范規(guī)定問題管理流程必須包含如下問題信息項:信息項說明問題流水號系統(tǒng)自動生成的工單號碼生成時間生成問題記錄的時間地點冋題發(fā)生的地點問題性質指問題的來源問題優(yōu)先級可題優(yōu)先級決定找到解決方案的緊急程度影響程度冋題對IT環(huán)境的影響程度問題分類從問題從屬的系統(tǒng)或技術架構的類型來進行分類，如數(shù)據(jù)庫，服務器 等。問題標題冋題的標題問題描述對于整個問題內(nèi)容的詳細描述問題狀態(tài)在冋題整個生命周期中的不同狀態(tài)問題日志反映問題處理過程中的問題處理信息，包括人員，時間等信息解決時間冋題得到解決的時間解決方案描述冋題解決方案的描述冋題結束代碼根據(jù)問題結束的不冋方式賦予不冋的結束代碼2.3 變更管理2.3.1 描述變更管理

44、通過一個單一的職能流程來控制和管理整個 IT 運行環(huán)境中的一切變 更，并和配置管理建立接口。變更管理應該由管理工具來支持，管理的范圍可包括軟 件，硬件，網(wǎng)絡設備和文檔等的變更。變更請求通常由于問題的解決方案中需要對生產(chǎn)環(huán)境進行某些改變而產(chǎn)生。需成立一個變更顧問委員會（Change Advisory Board，以下簡稱 CAB）來幫助和支 持變更經(jīng)理，根據(jù)變更內(nèi)容來決定 CAB 的成員，可以包括客戶代表、運維支持人員、 應用開發(fā)和供應商等跟變更有關的人員。CAB通過開會討論等手段來評估變更請求（RFC）的：潛在風險和影響 實施變更需要的資源 是否批準變更 如果批準，什么時間實施CAB也負責變更

45、實施后的回顧以考察：變更是否成功 ?是否產(chǎn)生其他副作用 ? 實際所用的資源和預期的是否一致 ?批準后，變更將進入計劃，測試 /構建和實施階段。計劃 /構建階段也包括開發(fā)一 個回退計劃（Fallback Plan）,用以在實施階段出現(xiàn)問題或緊急狀況時需要把變更回退回 去。變更管理流程也負責緊急變更，在此種情況下，變更的評估、計劃、測試和實施階 段都將快速進行。232目的變更管理流程將通過標準統(tǒng)一的方法和步驟來管理和控制所有對IT生產(chǎn)環(huán)境有影響的變更。主要的目的包括：? IT部門可以管理和引導用戶變更需求?通過對所有變更的正確評估，可以維護IT生產(chǎn)環(huán)境的完整性?變更和變更實施得到正確記錄，并提供審

46、核統(tǒng)計?減少或消除由于變更實施準備不當?shù)仍虺霈F(xiàn)的對IT環(huán)境的破壞作用?提高資源使用率2.3.3范圍變更管理流程涵蓋生產(chǎn)環(huán)境的所有變更。一般不包括:?尚處于開發(fā)和測試階段的系統(tǒng)和應用的變更?不需要IT部門介入的、由用戶控制的行為動作234相關定義優(yōu)先級優(yōu)先級用來說明變更需要得到實施的緊急程度:序號優(yōu)先級說明1緊急要求變更在提出申請后二天內(nèi)完成2正常除了常規(guī)和緊急之外的變更3常規(guī)預先定義的日常類變更風險等級除了常規(guī)變更，還需通過下表所列的衡量因素來評估實施變更可能帶來的風險衡量因素條件得分衡量因素條件得分地市/區(qū)域IT用戶數(shù)量（受到 實施或取消的影響）影響一個以上關鍵地區(qū)或半數(shù) 以上地區(qū)1影響一個以上地區(qū)但未達到