1、中國移動業務支撐網網管系統規范服務管理流程分冊中國移動通信集團公司2004年4月1綜述32運維管理流程詳述42.1事件管理 42.1.1事件管理描述 42.1.2事件管理目的 42.1.3事件管理范圍 52.1.4相關定義 62.1.5流程職責/角色 112.1.6主要內容 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主要內容 252.2.7流程衡量標準 262.2.8流程圖舉例 282.2.

2、9問題信息項 312.3變更管理 322.3.1描述 322.3.2目的 332.3.3范圍 332.3.4相關定義 332.3.5職責/角色 382.3.6主要內容 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主要內容 532.4.7流程衡量標準 542.4.8流程圖舉例 552.4.9常見配置元素屬性表 573運維管理流程關系和運維支持體系673.1運維流程相互關系 673.2整體運維支持體系 694附錄71

3、4.1ITIL 國際規范簡介 714.1.1ITIL 國際規范簡介 714.1.2分階段實施方法 734.2名詞解釋 761綜述本文作為中國移動業務支撐網網管規范附件之一，將詳細描述本期中國移動業務支撐網網管的四大管理功能，及四大管理功能之關的關系，并借助于流程圖的實例進行詳細說明。運維管理流程包括：事件管理、問題管理、變更管理、配置管理，本附件將分別對其進行定義和描述，包括：管理目的、管理范圍、主要內容、職責/角色規劃、流程示例等。在本附件最后，還簡單介紹 ITILITIL 的相關內容和實施方法。2運維管理流程詳述根據本期業務支撐網網管系統建設目標，本期運維管理主要實現事件管理、問題管理、變

4、更管理和配置管理，而管理流程是運維管理的主線，它將整個運維管理工作有機地聯接起來，下面將對每個流程的內容及其實際應用做一個詳細介紹。2.2 事件管理2.2.1 事件管理描述事件管理流程是為 ITIT 用戶盡快回到正常工作狀態而設計，其關心的重點是快速響應、快速恢復，使故障對業務的影響最小化。事件管理流程受事件觸發和驅動，所謂事件，是指發生了非常規的運作情況，包括系統崩潰、軟件故障、任何影響用戶業務操作和系統正常運作的事情、以及影響業務流程或違背服務水平協議的情況。事件也包括一個用戶的請求，如，重設用戶密碼。不是所有的事件都由用戶產生，監控管理平臺產生的告警也可引發事件。通常由幫助臺負責記錄事件

5、相關信息，向用戶提供對已知問題的處理方法，報告事件和盡快恢復服務，目的是在事件管理階段獲得盡可能高的事件解決率。所有的事件應該基于相關配置元素的關鍵等級和影響度進行優先級分類。事件管理的責任是記錄、分類、調查/診斷、解決已知問題、監控跟蹤事件、與用戶和問題管理流程交流、最終解決事件。2.2.2 事件管理目的事件管理流程的主要功能是盡快解決環境中出現的事件，保持 ITIT 環境的穩定性，其目的包括：?在成本允許的范圍內盡快恢復服務?快速響應系統監控產生的故障或用戶的電話請求?在線獲得幫助?溝通問題解決的狀態?進行事件控制?記錄事件?就事件的優先級、緊急性和嚴重性進行分類?分析、診斷，必要時進行升

6、級?監視，并結束事件?支持業務運行?對業務應用提供二級支持?解答有關如何使用的問題?記錄關于新服務的需求?記錄關于改變的請求?提供一個與業務部門的日常接口?提供關于服務狀態的信息更新?新服務的報告?關于即將到來的新服務或事件的通知?進行事后回顧? ?提供 ITIT 管理信息?人力利用情況?服務可用性?產品質量?支持效率?供應商服務情況2.2.3 事件管理范圍在 BOSSBOSS 統運維范圍內所指的事件，包括所有與 ITIT 基礎架構和業務相關的如下事件：?中告?故障?咨詢?業務處理?維護作業工科事件的產生有兩類：?由監控管理平臺自動發現并產生的告警事件? ?由用戶/IT/IT 維護人員報告的事

7、件但不包括：?外部用戶匯報的事件?在開發和測試環境中的設備或系統產生的事件“事件管理”流程不一定必須找到問題發生的根本原因，其重點在于如何在盡量短的時間內，恢復已經中斷的 ITIT 服務，提高服務的可用性。2.1.4 相關定義?重分配規則事件的及時、正確分配和接手處理是確保事件在解決時限內解決的關鍵因素。一線和二線技術人員可以拒絕并根據重分配原則重新分配不屬于自己運維范圍的事件。?事件性質根據移動的業務要求和管理要求，按照事件性質定義如下六類事件:性質描述中告針對 BOSBOS 繇統的 ITIT 用戶投訴故障指因 BOSSBOSS 系統錯誤或非正常因素由監控管理平臺發現的告警事件咨詢指對系統操

8、作、業務流程等方面的求助和詢問業務處理指需要運維人員進行后臺數據處理的要求維護作業指運維人員的日常維護作業或臨時進行的維護作業其他其他性質的事件。?事件來源當接到一個問題時，幫助臺人員需要記錄事件來源的類型。幫助臺的事件來源可以包括以下:來源描述用戶來自 IT 用戶的事件可以有以下幾種記錄方式：電話/郵件/傳真-來自用戶/IT 維護人員報告的事件自助開單-用戶/支持人員發現問題，直接在服務臺系統客戶端開單客服平臺-來自客服平臺的事件其他-其他方式進入幫助臺的事件監控管理監控管理平臺發現的告警事件，通過與服務管理平臺接口發送告警信息平臺到服務管理系統中?事件優先級優先級是事件管理的一個關鍵要素，

9、 優先級決定處理事件的順序及所需的資源,事件優先級可分為四級，如下表所示：編 R優先級1緊急2高3中4低事件的優先級分兩個層面來定義和確認：幫助臺幫助臺在接到來自監控管理平臺的告警事件或 ITIT 用戶報告的事件時，迅速根據事件相關的業務/子業務或 ITIT 系統/設備的關鍵級別及事件的性質，定義該事件的優先級別。如果為緊急事件，立即升級到一線。對于監控管理平臺上傳的報警事件，應包含該事件相關聯的配置元素的搜索代碼，幫助臺人員據此確定配置元素及其關鍵級別。幫助臺人員可參考下表確定事件優先級：事件優先級本次事件所對應 CI 的關鍵級別123事件性質故障1緊急高中2緊急中低3高低低高中低咨詢/業務

10、處理/維護作業中低低一線一線人員在接受到幫助臺升級上來的事件后，根據該事件相關的業務或 ITIT 系統/ /設備的實際故障情況，并結合其他相關因素，再次確定事件優先級，如確實為緊急事件，則啟動升級機制。確定事件優先級后，即可以確定事件的處理時限，優先級對應的事件解決時限參考下表：優先級緊急高中低解決時限（小時）482448?事件的升級事件升級的目的是確保基于事件的優先級等級及時通知有關技術人員和領導，引起更多的重視，提供合適的資源，從而快速找到解決事件的方案。可根據所要求的處理時間定義事件優先級升級規則，包括不同等級的事件在不同的時間被升級到不同級別的人員：間優先級、即時響應+15 分鐘處理時

11、限 30%處理時限 40%處理時限緊急ABDEF-高AB0DE中ABC-D低AB:C-升級組群：A A 幫助臺B B 一線支持人員C C 二線支持人員D D 事件經理E E 管理層F F 集團公司各省可以根據業務的實際情況調整升級標準。?事件分類根據移動目前的事件種類，事件的分類層次設計不超過三層，第一級分類，稱之為“類別”，第二級分類，稱之為“子類，第三級分類，稱之為“條目”。本規范給出第一級、第二級分類。各省市根據自己的情況決定是否要定義到第三層。卜表為事件分類表舉例:類別子類條目基礎架構網絡通訊系統服務器存儲系統系統軟件操作系統數據庫中間件雙機熱備軟件系統監控軟件業務采集皿結算客服業務管

12、理業務管理賬務管理賬務處理一級 BOSS1撥測其他配套設施空調UPS機柜照明溫濕度傳感器外設其他?事件狀態代碼事件狀態代碼表明事件所處的處理狀態，本規范規定的事件狀態如下:事件狀態代碼描述新建新開事件記錄分配事件在幫助臺一線處理一線支持人員已接手處理事件二線處理二線支持人員已接手處理事件供應商處理由供應商處理已解決事件已找到解決方案關閉確認解決方案，事件得以關閉?事件結束代碼事件結束代碼說明了事件是在何種情況下關閉的，本規范規定的結束代碼如下:事件結束代碼描述暫時解決用變通辦法暫時解決已解決幫助臺由幫助臺人員成功解決一線解決由一線人員成功解決二線解決由二線人員成功解決第二方解決由第二方成功解決

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

14、式、事件特征表現、描述、發生時間等?為事件進行適當的分類、為事件分配優先級等屬性?嘗試使用工具、初步診斷、分析相關信息等方式解決問題?如果幫助臺不能解決這個事件，應當將事件分配給最合適的一線支持小組/人員來處理?檢查事件記錄的處理進度，保持與事件報告人的聯系，適時通知事件處理進展?與用戶確認事件解決方案，關閉事件? ?一線支持人員一線支持人員負責提供對幫助臺無法解決的事件進行快速有效的分析并提出解決方案以盡快恢復服務，并在必要時提供現場支持。?驗證事件的描述和信息，進一步收集相關信息?決定需要采取何種措施恢復服務并實施有效的行動?必要時提供現場支持?根據優先級提供有效的解決方案?已解決的事件轉

15、回幫助臺，由幫助臺關閉事件?實施事件解決方案?更新事件解決信息，已解決的事件轉回幫助臺，由幫助臺關閉事件?如果一線不能解決這個事件，應當決定選擇最合適的二線支持小組/人員來處理? ?二線支持人員二線支持人員是相關問題領域的專家。負責提供對一線支持人員無法解決的問題進一步進行調研，找出解決方案并盡快恢復服務。各省可以考慮按照所維護的應用、系統進行分組，如，網絡組、主機組等。?進行事件的深入調查研究?根據經驗和專業技能，決定需要采取何種措施恢復服務并實施有效的行動?必要時引入供應商的支持?在系統中更新事件根源和最終解決方案?更新事件記錄，確保事件狀態代碼真實反映事件狀態。?及時提供有效解決方案?與

16、其他小組合作，確定解決方案?已解決的事件轉回幫助臺，由幫助臺關閉事件?如果二線不能在解決時限內解決這個事件，應當將事件進行升級1.2主要內容事件管理流程始于事件的探測和報告，結束于事件的解決。該流程包含下述主要內容：? ?事件接收和記錄這個環節是事件管理流程的起點。所有用戶或系統報告的 ITIT 事件必須由此步驟開始。此步驟的目的是在事件發生時快速準確地發現，以協助事件的診斷和解決并通知相關人員。在此步驟中將會收集創建事件記錄所需的信息。該環節的關鍵是信息的準確性和完整性。?分類和在線支持事件可以是一個服務請求、信息請求或服務故障，對于每個事件，需要確立優先級、影響度、和分類。若沒有現成的解決

17、方案或臨時解決措施，該事件將分配給合適的支持人員對此進行調查。該環節的關鍵是需要知識庫支持和正確的事件分派。?調查和診斷若在線支持人員無法解決事件，可運用自身技能、知識庫、診斷工具等進行更加深入的分析以找到恢復服務的臨時措施，必要時將使用多名技術員以尋求解決措施。?解決和恢復技術人員實施事件的解決方案，并將解決完畢的事件轉回幫助臺，由幫助臺通知用戶解決的結果，并得到用戶的確認。?緊急事件和事件升級對于緊急事件，幫助臺應立即提交給一線人員，由一線人員判斷，上報給事件經理，并同時上報給集團公司，由事件經理決定緊急處理的方式，確保其得到最快速的解決。當事件處理超過預期時限，將自動升級或由運維人員升級

18、，以引起相關人員和管理人員的重視和參與。?結束事件當用戶確認事件解決后，此時可結束該事件，并在必要時更新知識庫。若用戶對此解決方案不滿意，則對該事件繼續進行處理，不能關閉。1.2流程衡量標準事件管理流程的主要衡量指標如下：?事件記錄數量，可按照部門、事件分類等分別統計?事件關閉的數量，可以按照優先級，或者按照分類分別統計?事件成功關閉的數量?規定時間內解決的事件數量/百分比?幫助臺解決率?事件解決的平均時間，可以按照事件分類統計?超時的事件數量，可以按人員、組別統計統計報表?事件記錄的數量，可按照事件分類、事件性質、事件優先級等分別按月、周、日匯總統計該時間段內創建的事件記錄數量故障咨詢業務處

19、理維護作業其他緊急高中高中低中低中低中低緊急高中低網絡設備服務器存儲系統mt結算客服?處于各狀態的事件數量，可按事件來源、事件分類、事件狀態實時匯總事件記錄數量新建分配一線處理二線處理供應商處理已解決關閉網絡設備服務器存儲系統mt結算客服?事件關閉的數量，可按事件來源、事件分類、事件結束代碼等分別按月、周、日匯總統計該時間段內創建的事件記錄的關閉數量成功解決可忽略事件后續操作解決部分解決部門 1監控系統 1成功解決可忽略事件后續操作解決部分解決網絡設備服務器存儲系統?按時、超時解決的事件數量/百分比，可按事件來源、事件分類、處理角色等分別按月、周、日匯總統計該時間段內創建的事件記錄的解決數量幫

20、助臺一線二線第三方按時超時按時超時按時超時按時超時數量百分比數量百分比數量百分比數量百分比數量百分比數量百分比數量百分比數量百分比部門 1監控系統 1幫助臺一線二線第三方按時超時按時超時按時超時按時超時數量百分比數量百分比數量百分比數量百分比數量百分比數量百分比數量百分比數量百分比網絡設備服務器存儲系統?各角色事件解決率，可按事件來源、事件分類、處理角色等分別按月、周、日匯總統計該時間段內創建的事件記錄的解決率幫助臺一線二線第三方部門 1監控系統 1幫助臺一線二線第三方網絡設備服務器存儲系統1.2流程圖舉例如下是事件管理的邏輯示意圖:流程說明序號步驟名稱一責任人輸入說明輸出100.1創建事件記

21、錄并分類幫助臺事件特征描述接受從 IT 用戶或監控管理平臺報告的事件，在幫助臺系統中產生新服務記錄，填入相關信息。并對事件進行分類，根據設定標準進行分類和分優先級，設置相關屬性。事件記錄100.2優先級最高？幫助臺事件記錄 根據事件相關的配置兀素 CI 的關鍵級別。確定事件的優先級是否最高，如是立即升級到一線支持人員，否則嘗試解決。優先級確定結果100.3確認優先級別一線事件記錄一線支持人員根據事件相關配置兀素和其他相關信息確定該事件是否確屬優先級最高已確定優先級的事件記錄100.4優先級最高？一線已確定優先級的事件記錄如果優先級確實最高，則立即升級到事件經理，并通報集團公司，并立即開始處理，

22、如不是，則返回幫助臺N/A通知事件經理事件經理事件記錄 最高優先級事件必須立即通知事件經理， 由事件經理決定是否由原處理人按照原流程執行， 還是需要采取必要手段十預（例如：啟動危機處理流程、會緊急解決方案集團公司/上報、 （集團省公司 IT 用戶100.1 創建事件記錄并分類幫助臺一線支持二線支持強知事、 件經理事件經理第三方事件管理邏輯流程100.5能嘗試解決.-100.6決了嗎右N:100.16確認并叫關閉事/件Y-N|,.-100.14N超出時限1100.15.技術支持1/100.9T 解決了100.10事件轉/發至二/線100.7 事件轉發至一線100.2優先級最高丫事息決查信解檢件并

23、100.11調 看 診斷 并 解決事件N100.13。需要第三方、,支持 J議等）。上報集團集團事件記錄緊急事件必須上報集團公司（開仕事件處埋過程中的每個狀態變化點將最新事件記錄上傳到集團公司）緊急事件100.5嘗試解決幫助臺事件記錄通過查詢知識庫，嘗試電話支持解決方案100.6解決了嗎？幫助臺N/A如果解決了，則進入 100.16,確認并關閉事件；如果不能解決，進入 100.7,轉發至一線。N/A100.7事件轉發至一線幫助臺事件記錄選擇適當的一線人員，將事件轉發轉發的事件100.8檢查事件并解決一線事件記錄檢查事件信息，尋求解決方案解決方案100.9解決了嗎？一線N/A如果解決，則將解決方

24、案記入事件記錄，并發還幫助臺，進入 100.16;如果不能解決，則需在事件記錄中說明原因，轉發二線N/A100.10事件轉發至二線一線事件記錄選擇適當的二線人員，將事件轉發轉發的事件100.11調查診斷并解決二線事件記錄進行進一步調查分析，找出解決方案解決方案100.12 解決了嗎？二線N/A如果“是“，則將解決方案記入事件記錄，發還幫助臺，進入 100.16;如果“否”，則轉入 100.13。需要供應商支持？N/A100.13需要第一方支持？二線N/A判斷是否需要引入第二方 （第二方包括廠商和其他部門的支持人員）：“是”，轉入 100.15;“否”,轉入 100.14N/A100.14 超出

25、時限？二線N/A如果超出處理時限，必須及時通知事件經理rN/A通知事件經理事件經理N/A事件經理應當特別關注超時的事件，并幫助協調資源，監督事件盡快解決N/A100.15 技術支持供應商支持請求供應商得到通知后，應參與事件的解決，并提出解決方案,由一線人貝監控供應商的響應速度和處理速度。解決方案100.16 確認并關閉事件幫助臺已解決的事件幫助臺應與用戶確認是否接受解決方案，如果用戶認可，則可關閉事件，如果用戶不能接受，則發還處理人員，繼續處理。關閉的事件記錄2.1.9 事件信息項本規范規定事件管理流程必須包含如下事件信息項信息項說明填寫方式事件流水號工單號碼系統生成報告人信息本次事件報告人的

26、聯絡信息，包括：姓名省/分公司部門根據報告人的搜索代碼，自動獲取 CMD 中報告人信息電子郵件辦公電話手機/BP生成時間在幫助臺生成事件記錄的時間系統生成地點事件發生的地點-發生時間事件發生的實際時間-事件性質從事件所屬性質的角度來確定其處理流程，如申告、故障、求助、業務處理、維護作業等。-事件來源指事件工單產生的途徑，有人工產生、系統自動產生兩類。由監控管理平臺自動產生的，可自動填寫事件優先級事件優先級決定 J 事件的解決時限和處理次序， 通過綜合衡量配置元素的關鍵級別和其他相關信息得出。-事件分類從事件從屬的系統或技術架構的類型來進行分類， 如數據庫， 服務器等。-事件標題事件的標題由監控

27、管理平臺自動產生的，可自動填寫事件描述對于整個事件內容的詳細描述由監控管理平臺自動產生的，可自動填寫事件解決確認人在幫助臺得到用戶確認的有關人員-事件狀態住事件整個生命周期中的不同狀態系統生成分配對象被分配的技術支持組和人員-事件日志反映事件處理過程中的事件處理信息，包括人員，時間等信息-是否超時事件處理時間是否超出解決時限系統生成解決時間事件得到解決的時間-解決方案描述事件解決方案的描述-事件結束代碼根據事件結束的不同方式賦予不同的結束代碼-2.2 問題管理ecbba775%99b-Numbered_1c93f357-4596-4b36-95c4-11706f31問題管理描述問題是一個或幾個

28、已暫時處理但根本原因尚不明確的事件，許多事件往往是由同一個問題引起的。問題的來源主要有以下幾種：已經關閉的事件，經過回顧分析后，可能形成一個問題；重大事件，雖然經過緊急處理恢復服務，但未找到根本原因，也形成一個問題；對于趨勢性事件的分析，形成問題。問題管理流程的根本目的是消除或減少事件的發生，將 BOSSBOSS 系統內部缺陷導致的業務事件或問題的負面影響降到最低限度，此流程分析發生在生產環境的事件（常常是已關閉的事件記錄），確定最常發生或具有最大影響的事件，找出根本原因，然后生成變更請求（RFCRFC） 、變通方法或建議的預防性措施來防止事件的再次發生。所以問題管理流程需要和變更管理流程一起

29、來實施找出的解決方案以從根本上解決問題。問題通常具有以下特征中的一個或全部：? ?一組具有一定關系的已結束的事件? ?一個重大或緊急事件（事件處理結束后定義為問題，由問題管理找出根本解決方案）問題管理與事件管理之間的差異問題管理與事件管理并不相同，它的主要目的是查明事件的潛在原因，并制定隨后的解決方案和預防方法。在大多情況下，此目的與事件管理目的之間有一定沖突，因為事件管理的目的是盡快地恢復客戶服務，通常是通過實施替代方案，而非確定一個永久性的解決方案（例如為了盡可能地預防未來可能出現的事件，尋求改善信息技術基礎架構的結構）。就問題管理而言，對潛在原因的調查可能需要一定的時間，找到解決方案的速

30、度是次要的考慮因素，但是預防了問題的再次發生。問題管理流程可以按照不同領域的問題（如網絡問題，或應用問題等）由相關組的技術支持專家來執行，原則上這些專家可以是事件管理的二線支持專家，他們在負責接受來自一線支持人員（幫助臺員工）的支持請求的同時，也負責對以往事件進行分析，找出事件產生的根本原因，從而確定解決方案，消除這些根本原因，最終使此類事件不再發生；同時，也要從發生的事件中找出事件的發展趨勢或潛在可能發生的問題，從而預先采取措施，保證 ITIT 服務的正常化。問題的根本原因找出后即成為已知錯誤，對已知錯誤實施解決方案，從而解決問題。所以問題管理流程的輸出有：?變更請求?變通方法?根本解決方案

31、?預防性措施?已知錯誤2.2.2 問題管理目的問題管理流程在 ITIT 部門設立的主要目的是分析已被列為問題的事件（一組或個）的根本原因，然后找出解決方案。包括：?分析并確定事件的根本原因，以防止再次發生?主動提供預防性措施? ?提高 ITIT 服務的可靠性? ?降低 ITIT 支持成本? ?提高 ITIT 部門的整體形象和名譽問題管理范圍問題管理范圍是對所有 ITIT 生產環境中未根本解決的問題和已知錯誤進行管理，并采取主動性預防措施來降低事件數量，重大或緊急事件在處理完后也被定義為問題以分析其產生的根本原因。一般對ITIT 服務影響最大或最占用支持人員資源的事件優先進行分析。問題管理范圍不

32、包括處于開發或測試環境的系統和應用。相關定義優先級需要確定解決方案的緊急程度，本規范定義如下問題優先級:編號優先級代碼解釋1 1緊急關鍵級別為 1 1 的業務中斷或將中斷，影響一個以上關鍵地區或半數以上地區2 2高關鍵級別為 1 1 的業務中斷或將中斷，影響一個以上地區但未達到緊急標準3 3二中關鍵級別為 1 1 的子業務或半數以上子業務中斷或將中斷4 4低未達到以上標準問題狀態代碼問題在整個生命周期中的不同狀態。本規范定義如下問題狀態:編號代碼描述1 1已登記問題登錄到系統中2 2處理中問題正在處理過程中3 3拒絕問題分派被拒絕4 4已知錯誤問題根本原因已找出5 5已有解決方案解決方案已找到

33、6 6RFCRFC已提交 RFCRFC7 7結束問題已結束8 8回顧問題已做回顧問題分類(classification)(classification)從問題從屬的系統或技術架構的類型來進行分類。本規范定義如下問題分類:類別子類條目基礎架構網絡通訊系統服務器存儲系統系統軟件操作系統數據庫中間件雙機熱備軟件系統監控軟件1采集1結算1業務客服業務管理賬務管理1賬務處理一級 BOSSBOSS撥測其他配套設施空調UPSUPS機柜照明溫濕度傳感器外設其他問題性質根據問題的不同來源進行分類。本規范定義如下問題性質:編號代碼備注1 1升級事件從事件管理中升級的事件2 2系統構架問題技術專家提出的問題3 3n

34、 n主動防范性分析事件記錄找出的問題問題結束代碼問題結束代碼：根據事件結束的不同方式賦予不同的結束代碼。本規范定義如下問題結束代碼:編號代碼說明i i根本解決找出問題的根本原因，并得到解決方案，成功解決2 2變通方法未找出根本原因，但有臨時解決方案作為變通方法3 3 沒有解決問題無法解決4 4消失問題尢法再現職責/角色問題管理流程主要分為如下幾個職責角色，分別簡述如下：問題經理?整體上對流程負責，確保流程的有效執行?定期評估流程，制定流程改進計劃? ?確定或定義問題，并確保有效協調資源?監視問題的診斷，分析和處理過程?提出實施解決方案的變更請求? ?定期制定 ITIT 問題報表，提供正確決策信

35、息問題分析專家?接受問題經理分派過來的問題?分析和診斷問題，確定根本原因?確定和測試解決方案?協助事件支持人員進行重大或緊急事件的處理主要內容問題管理流程著重于消除事件或減少事件發生，確定事件的根本原因。主要活動包括分析事件、找出問題、分派問題、確定根本原因、找出解決方案以消除事件或在其發生時降低對用戶或業務的影響。其主要內容如下：. .分析事件定期分析事件，找出潛在問題. .生成問題記錄?在系統中生成問題記錄并把所有相關事件與此記錄關聯起來?重大或緊急事件處理完后定義為問題?技術支持專家在日常運維中發現的問題?主動性防范. .分派根據問題內容將問題記錄分派給適當的技術小組。. .根本原因分析

36、被分派的小組人員將調查問題以期找出其原因，制定解決方案、變通方法或提出預防性措施，以消除產生原因，或在重發時使其影響力最小化。. .更新已知錯誤問題記錄必須被更新以反映它是已知錯誤狀態，并且把任何變通方法、避免或最小化負面影響的動作行為也記錄下來（如果需要添加到知識庫中）。. .提出變更請求對問題的解決方案進行評估，通過提出變更請求（RFCRFC）以對該方案進行測試和實施。如果RFCRFC 沒有被批準，問題記錄保持為已知錯誤，它們可以被事件支持人員在事件再次發生時參考借鑒。. .關閉一旦找出問題根本原因，并實施了解決方案，確認已解決了問題，問題記錄可以關閉。. .事后回顧問題必須進行回顧以找出

37、改進機會或總結預防性措施。包括改進事件監測、找出技能差距和文檔資料改進等。2.2.7 流程衡量標準問題管理流程的主要衡量指標如下：?每一階段內的已知錯誤數量?在每一階段內未結的問題記錄? ?每一階段內未了結的由問題引發的 RFCRFC 數量? ?在 ITIT 環境中存在的臨時性變通辦法數量統計報表問題的數量，可按問題分類、問題性質、優先級、影響度等分別按月、周、日匯總統計該時間段內創建的問題記錄數量優先級影響程度緊急高中低高中低無網絡設備服務器存儲系統優先級影響程度緊急高中低高中低無升級事件系統構架問題主動防范性處于各狀態的問題數量，可按問題分類、問題性質、問題狀態分類實時匯總已登記處理中拒絕

38、已知錯誤已有解決力殺RFCRFC結束回顧網絡設備服務器存儲系統已登記處理中拒絕已知錯誤已有解決力殺RFCRFC結束回顧升級事件系統構架問題主動防范性?問題關閉的數量，可按問題分類、問題事件、問題結束代碼等分別按月、周、日匯總統計該時間段內創建的問題記錄的關閉數量根本解決變通方法沒有解決消失網絡設備服務器存儲系統根本解決變通方法沒有解決消失升級事件系統構架問題主動防范性2.2.8 流程圖舉例如下是問題管理的邏輯示意圖舉例:關于該邏輯流程的簡單描述如下:序號步驟名稱責任人輸入說明輸出300.1分析事件問題經理事件記錄定期分析回顧事件，主動發現潛在問題。分析事件的頻度和嚴重度， 和其他的相關因素進行

39、關聯， 如 CI 位置、 宕機時間、特定用戶、硬件平臺、軟件版本和一天中發生的時間等。具體的做法可以是一周開一次由主要事件支持人員參加的例會，討論上周發生的 IT 事件。分析結果300.2創建問問題分析結把找出的問題記錄到系統中去，并進行詳細說明問題記問題管理邏輯流程司公團集管司層公理省員人員人理管更變理管件事理經題問需要變家專析分題問上報集團公司在必要口寸.f3300.3問題優先級和300.4分派給工作組/,監視1I300.9提交變更請求/監視變更實施300.8安排實施解決方案,嗎？-300.10關閉問/300.11“題廠一回顧記錄300.7推薦解/ 決方案/，、變通方L法題記錄經理果錄30

40、0.3問題優先級及分類問題經理問題記錄根據問題的實際情況，給其分派一個優先級代碼和影響度代碼（必要時進行升級，如優先級最高時），并根據擬定的分類原則給問題賦予適當的類別代碼并根據問題具體情況設定一個解決時限。已分類問題優先級最高嗎？問題經理已分類問題如果問題優先級為最高，由問題經理立即把該問題上報到集團公司，并把該問題升級到管理層N/A300.4分派給工作組/監視問題經理問題記錄初步判斷問題的可能原因，把問題分派給相應工作組或個人，并監視問題的解決過程，如有必要（如超過解決時限）啟動升級流程已分派問題在必要時升級問題經理N/A問題經理在監視問題解決的過程中，根據具體情況可把該問題升級到管理層，

41、如問題超出解決時限時N/A判斷是否接受？問題分析專家N/A問題分析專家對問題進行初步分析，以決定接受與否。如拒絕轉向 300。6 繼續，如接受轉向 300。7繼續。N/A300.5拒絕問題問題分析專家已分派問題問題分析專家根據判斷發現問題應該由其他組分析解決，就把問題發回問題經理，注明拒絕理由并推薦組名。轉向 300。4 繼續。已拒絕問題300.6分析根本原因問題分析專家已接受問題如果問題確應由本人或本小組解決，接受分派的問題，然后調查診斷問題，如有必要成立問題分析小組，舉行問題根本原因分析研討會議并確定問題的潛在原因。必要時更新問題狀態。問題根本原因300.7推薦解決方案 / 變 通 方法問

42、題分析專家問題記錄、問題根本原因找出問題的根本原因后，根據實際情況制定變通方法或根本性解決方案，并確保這些方法或方案將降低或消除事件的發生率或影響度，更新問題記錄。問題解決方案問題變通方法300.8安排實施解決力殺問題經理問題解決方案問題變通方法根據問題專家提供的解決方案或變通方法，計劃并實施解決方案以解決問題解決方案實施計劃判斷是否需要問題經理N/A判斷實施上述解決方案是否需要進行變更，如小需要艾更轉向 300。10 繼續，如需要變更轉向 300。9N/A變更？以提出變更請求。300.9提交變更請求問題經理解決方案實施計劃根據問題分析專家制定的解決方案或變通辦法，提出變更請求，填寫變更請求單

43、，遞父到變更管理流程，并監視變更的實施過程，和變更管理保持溝通。變更請求 RFC300.10關閉問題記錄問題經理已解決的問題變更結束后，確認問題已經解決，選擇相應的結束代碼，更新問題狀態，關閉問題記錄。已關閉的問題300.11回顧問題經理已關閉的問題對所有已關閉問題都進行回顧，找出可能改進的機會，包括問題的解決方案和管理流程方面，如改進升級規則、改進事件監測、找出技能差距和文檔資料改進等；回顧之后更新問題狀態。已回顧的問題2.2.9 問題信息項本規范規定問題管理流程必須包含如下問題信息項:信息項說明問題流水號系統自動生成的工單號碼生成時間生成問題記錄的時間地點可題發生的地點問題性質指問題的來源

44、問題優先級可題優先級決定找到解決方案的緊急程度影響程度可題對 IT 環境的影響程度問題分類從問題從屬的系統或技術架構的類型來進行分類，如數據庫，服務器等。問題標題可題的標題問題描述對于整個問題內容的詳細描述問題狀態在問題整個生命周期中的不同狀態問題日志反映問題處理過程中的問題處理信息，包括人員，時間等信息解決時間可題得到解決的時間解決方案描述可題解決方案的描述問題結束代碼根據問題結束的不向方式賦予不同的結束代碼2.3 變更管理寸苗述變更管理通過一個單一的職能流程來控制和管理整個 ITIT 運行環境中的一切變更，并和配置管理建立接口。變更管理應該由管理工具來支持，管理的范圍可包括軟件，硬件，網絡

45、設備和文檔等的變更。變更請求通常由于問題的解決方案中需要對生產環境進行某些改變而產生。需成立一個變更顧問委員會（ChangeAdvisoryBoardChangeAdvisoryBoard, ,以下簡稱 CABCAB）來幫助和支持變更經理，根據變更內容來決定 CABCAB 的成員，可以包括客戶代表、運維支持人員、應用開發和供應商等跟變更有關的人員。CAB!CAB!過開會討論等手段來評估變更請求（RFCRFC）的：潛在風險和影響實施變更需要的資源是否批準變更如果批準，什么時間實施CACA 班負責變更實施后的回顧以考察：變更是否成功？是否產生其他副作用？實際所用的資源和預期的是否一致？批準后，變更

46、將進入計劃，測試/構建和實施階段。計劃/構建階段也包括開發一個回退計劃（FallbackPlanFallbackPlan）, ,用以在實施階段出現問題或緊急狀況時需要把變更回退回去。變更管理流程也負責緊急變更，在此種情況下，變更的評估、計劃、測試和實施階段都將快速進行。2.3.2 目的變更管理流程將通過標準統一的方法和步驟來管理和控制所有對 ITIT 生產環境有影響的變更。主要的目的包括：? ?ITIT 部門可以管理和引導用戶變更需求? ?通過對所有變更的正確評估，可以維護 ITIT 生產環境的完整性?變更和變更實施得到正確記錄，并提供審核統計? ?減少或消除由于變更實施準備不當等原因出現的對

47、 ITIT 環境的破壞作用?提高資源使用率范圍變更管理流程涵蓋生產環境的所有變更。一般不包括：?尚處于開發和測試階段的系統和應用的變更? ?不需要 ITIT 部門介入的、由用戶控制的行為動作相關定義優先級優先級用來說明變更需要得到實施的緊急程度:廳 P優先級說明1 1緊急要求變更在提出申請后二天內完成2 2正常除了常規和緊急之外的變更3 3常規預先定義的日常類變更風險等級除了常規變更，還需通過下表所列的衡量因素來評估實施變更可能帶來的風險衡量因素條小上二得分衡量因素條件得分地市/區域 ITIT 用戶數量（受到實施或取消的影響）影響一個以上關鍵地區或半數以上地區1 1影響一個以上地區但未達到半數

48、，并沒有關鍵地區受影響2 2影響一個地區的全部用戶3 3影響一個地區的部分用戶4 4準備/實施必需的資源3 3 個或更多支持小組1 12 2 個支持小組2 2超過 1 1 人，相同的支持小組3 31 1 人變更成功的可能性無法測試，變更失敗可能性很高1 1能實現部分測試，變更失敗可能性較局2 2有成熟的變更方案，變更失敗可能低3 3無需測試，變更失敗可能性沒有4 4變更規劃時間6 6 天或更長1 12-62-6 天2 21-21-2 天p p小于 1 1天天4 4變更實施時間超過 2 2 小時或在線/服務斷供期1 11-21-2 小時I I不至 I I1 1 小時3 3/、到 3030 分鐘4

49、 4回退時間回退時間超過 2 2 小時r r1 1回退難度中等以上（1-21-2 小時）2 2回退難度適中（1 1 小時或更短）3 3易于回退（3030 分鐘或更短）4 4注：緊急變更的實際規劃時間很短，但評估時應按照該變更正常處理情況下所需的規劃時間來評估。根據上表，對每個變更進行評估，最終得分為各分項得分的總和，再根據總分確定對應的風險等級和實施完成后的觀察期：總得分風險等級實施完后的觀察周期6-96-9重大6-76-7 天1010- -1313較大4-54-5 天1414- -1717中等2-32-3 天18+18+較小小于等于 1 1天天以上風險等級由變更主管進行初步評定，再由 CAB

50、CAB 進行最終確定狀態變更請求從提出、實施到結束的整個生命周期中的不同狀態:廳 P狀態說明1 1已登記變更請求已登入系統2 2已評估變更請求已得到 CABCAB 評估3 3已授權變更請求已得到 CABCAB 授權4 4已計劃變更實施計劃已由變更經理收集并確定可執行5 5進行中變更實施過程中6 6已結束:變更已結束7 7觀察中變更實施結束后處于觀察狀態7 7已回顧變更已得到回顧8 8關閉變更請求已關閉結束代碼根據結束變更的不同方式賦予不同代碼:廳 P代碼說明1 1完全成功完全達到變更目的2 2部分成功部分達到變更目的3 3取消變更實施過程中被取消4 4拒絕變更請求被 CABCAB 拒絕類另(

51、(Category)Category)根據中國移動目前的變更種類，變更的分類層次設計不超過三層。第一級分類，稱之為“類別，第二級分類，稱之為“子類，第三級分類，稱之為“條目”。本規范給出第一級、第二級分類，各省市根據自己的情況決定是否要定義到第三層。卜表為變更分類表舉例:類別子類條目網絡通訊系統基礎架構服務器存儲系統1操作系統數據庫系統軟件中間件雙機熱備軟件系統監控軟件采集業務“費1結算客服1業務管理1賬務管理1賬務處理一級 BOSSBOSS1撥測1其他1配套設施空調UPSUPS機柜照明溫濕度傳感器外設其他職責/角色變更管理流程主要分為如下幾個職責角色，分別簡述如下：變更請求者?發現或獲取變更

52、需求?確定并分析變更需求和內容?填寫變更請求單并提交給相關相應變更主管變更經理?整體上對流程負責，確保流程的有效執行?確保變更請求得到有效評估，授權和實施確保只有授權和必要的變更才被實行，并使該種變更影響最小化?定期召開變更會議，回顧/制定下階段變更規劃?定期評估流程，制定流程改進計劃?定期制定變更管理報表，提供正確決策信息變更顧問委員會 CABCAB?針對具體變更請求，評估并分派相應資源? ?回顧所有提交的 RFC,RFC,并確保它們的潛在影響和風險得到評估?回顧所有已執行的變更，確保滿足變更目的? ?參加 CABCAB 會議和緊急 CABCAB 會議?協助變更經理確定變更優先級及變更規劃?

53、 ?一般根據不同變更內容有不同人員組成變更豐管?由與變更請求內容相關的具體技術領域的負責人（如組長）擔任? ?檢查由變更申請人提交的變更請求 RFC,RFC,并完善或調整 RFCRFC 信息， 必要時拒絕無關或無法實施或沒有必要的變更請求?作為具體變更的項目經理，負責領導變更的構建/測試，實施和參與回顧?制定變更項目計劃和時間規劃等?確保變更在預定的時間，資源和成本內完成? ?在必要時，確保回退計劃(FallbackPlan)FallbackPlan)得以正確實施變更實施人員?根據變更主管制定的變更實施計劃?執行分派的任務以推進變更項目?向變更主管匯報工作進程?現場負責變更實施主要內容變更管理

54、流程通常將包括如下內容：提出 RFCRFC變更申請人提出 RFCRFC 由變更主管負責檢查和完善其內容，并進行風險等級、優先級的初步評估。接受 RFCRFC變更經理接受 RFCRFC變更請求分類和升級通過分類，確定是否為重大變更、緊急變更，如果是常規變更請求，則由相應變更主管安排實施；如果風險等級為“重大”的變更請求，應上報省公司管理層和集團公司；緊急變更適用同一流程但將得到快速批準和實施。變更顧問委員會(CAB)(CAB)評估變更經理將根據特定的變更請求成立特定的 CABCAB, ,成員包括對該變更的評估和批準提供應有附加價值的技術人員和管理人員.評估工作包括技術可行性，對容量的影響，對現有

55、服務的影響，資源需求等.批準 RFCRFC變更經理確定對該 RFCRFC 有批準權的人員參加 CAB,CAB,必要時參與評估.評估后 CABCAB 根據判斷決定是否批準 RFCRFC建立變更實施計劃/測試結果，并批準實施變更請求得到評估和批準后，變更主管安排相應資源進行變更的構建/開發、測試,并制定實施計劃。隨后提交計劃和測試結果給變更經理以獲得批準。規劃 RFCRFC實施計劃一旦獲得批準，變更主管必須根據資源和其他情況進行規劃，確定實施時間表，分配相應資源，并通知請求人。協調變更實施一切就緒后，可以實施變更.相應小組實施變更，變更主管監視實施過程，并在必要時進行協調.更新變更狀態在整個變更過

56、程中，變更的狀態從登記，評估，回顧到最后關閉是不同的.變更經理負責更新預先定義好的變更狀態.回顧和關閉實施變更后，CABCAB 負責從技術和流程角度去回顧變更，確保 RFCRFC 得到了預期效果，并尋找流程的改進機會。隨后，變更經理負責關閉 RFCRFC。總結匯報向管理層提供流程報表，提供變更的用價值的信息，定期向相關小組/部門根據流程衡量標準匯報。變更會議變更經理負責定期或不定期召開變更會議，與 ITIT 內部成員和用戶溝通，傳遞將要實施的變更等信息，以及對變更流程的反饋和建議等。變更流程回顧建議定期回顧變更管理流程以提高效率和效能，在實施變更流程不久之后，可以進行第一次回顧， 以確保流程得

57、到正確實施并起到預期目的。 對發現的問題必須追根溯源并盡快解決.之后，可以定期舉行正式的回顧，如每六個月回顧一次。流程衡量標準變更管理流程的主要衡量指標如下:?每一類型的變更數量? ?執行回退計劃(Fallbackplan)(Fallbackplan)的變更數量?變更實施的成功率?緊急變更所占的比率? ?被拒絕的 RFCRFC 的數量或比例?每一類優先級的變更數量統計報表RFCRFC 數量，按優先級、風險等級、變更類別、申請人部門/歸屬小組等分別按月、周、部門 1 1小組 1 1處于各狀態的 RFCRFC 數量，可按優先級、風險等級、變更類別、申請人部門/歸屬小組、狀態實時匯總優先級風險等級緊

58、急正常常規重大高中低已登記已評估已授權已計劃進行中已結束觀察中已回顧關閉已登記已評估已授權已計劃進行中已結束觀察中已回顧關閉網絡設備服務器存儲系統已登記已評估已授權已計劃進行中已結束觀察中已回顧關閉部門 1 1小組 1 1RFCRFC 關閉的數量，可按優先級、風險等級、變更類別、關閉代碼等分別按月、周、日匯總統計該時間段內創建的 RFCRFC 的關閉數量優先級風險等級緊急正常常規重大高中低完全成功部分成功取消拒絕完全成功部分成功取消拒絕網絡設備服務器存儲系統完全成功部分成功取消拒絕部門 1 1小組 1 12.3.8 流程圖舉例如下是變更管理的邏輯示意圖舉例:變更管理邏輯流程關于該邏輯流程的簡單

59、描述如下:序號步驟名稱責任人輸入說明輸出400。1提交變更請求變更請出石變更需求及相關信息請求者發現或接到變更請求，跟相關部門或用戶確認，然后填寫變更請求并提交給相關艾更主管初始 RFC400。2檢查/完善變更請求變更主管初始 RFC相關變更主管負責對變更請求者提交的 RFC進行檢查，確定變更優先級和風險等級,如有必要則對 RFC 相關信息完善或更正,以保證 RFC的正確性和完整性經 過 完 善 的RFC,包含所有必需的正確信息400。3接受變更請求變更經理經過完善的 RFC接受變更請求，檢查變更請求的完整性和正確性，確定相關艾更顧問委員會 CAB 成員RFC 登錄進變更管理系者求請更變400

60、.3接受理經更變-U400.11結束1BACV會員委問顧更變400.5評估風險/影響400.N10回顧/管主更變400.2檢查/完善變 L 更請求I400.4協調CAB-相關活動400.6制定測試/實施計劃/400.8；制定具體計劃&協調溝通員人施實更變0/1交更球40提變請LllN400.7不，總體變更計劃-需要集團公司審批嗎？*規類變更一變更嗎：請求）?/緊急流程400.9實施統常規變更？變更經理判斷所提交的變更是否為常規變更，如果是，直接由變更主營負責該變更的計劃和執行;如不是常規類變更，則繼續重大變更？變更經理風險等級為重大的變更請求， 變更經理應立即上報至集團和省公司管理層緊急變更？變更經理判斷是