IT運維支持和通訊服務項目項目管理制度

IT運維支持和通訊服務項目

項目管理制度

1.1事件管理

LL1總則

1）各項目根據(jù)事件的影響和緊急程度確定事件處理優(yōu)先級別，并基于優(yōu)先級別確定解決

事件的目標。其中應包括：

?接收請求、記錄、優(yōu)先級分配、分類。

?一線事件解決或轉(zhuǎn)移。

?考慮安全事件。

?事件跟蹤和生命周期管理。

?事件驗證和關閉。

?一線客戶聯(lián)系。

?事件升級原則及方式。

?事件通知規(guī)則

2）事件報告方式包括電話、拜訪、傳真或者電子郵件，所有事件應在服務臺正式記錄，

并可檢索和分析。

3）二線人員對升級的事件提供解決方案，協(xié)助一線關閉事件。

4）項目應建立事件知識庫，以確保項目成員可訪問經(jīng)常更新的知識庫。知識庫中包括技

術專家、以前事件、相關問題、已知錯誤、配置管理數(shù)據(jù)庫（CMDBX檢查清單等

有助于恢復服務的各種信息。

5）應制定重大事件處理流程，確保重大事件能夠得到迅速解決。

6）應在證實事件已經(jīng)解決并且服務已經(jīng)恢復的時候，事件才能最終關閉。

7）制定事件升級和通知規(guī)則，確保各種事件能夠得到處理和告知相關干系人。

8）在事件處理過程中,應將處理過程情況及時向本項目及客戶及時進行告知、請示、確

認。

1.1.2事件分類

事件類別說明備注

UPS故障：影響數(shù)據(jù)中心生產(chǎn)運行的UPS故障的現(xiàn)象

空調(diào)故障：影響數(shù)據(jù)中心生產(chǎn)運行的空調(diào)故障的現(xiàn)象

消防設備：影響雌中心生產(chǎn)運行的消防設備故障的現(xiàn)象

電池組：影響數(shù)據(jù)中心生產(chǎn)運行的電池組故障的現(xiàn)象

柴油機：影響數(shù)據(jù)中心生產(chǎn)運行的柴油機故障的現(xiàn)象

監(jiān)控系統(tǒng)：影響數(shù)據(jù)中心生產(chǎn)運行的監(jiān)控系統(tǒng)故障的現(xiàn)象

通信設備：影響數(shù)據(jù)中心生產(chǎn)運行的通信設備故障的現(xiàn)象

智能配電柜：影響數(shù)據(jù)中心生產(chǎn)運行的智能配電柜故障的現(xiàn)象

網(wǎng)絡故障：所有可能會影響到用戶網(wǎng)絡連接的現(xiàn)象

可能會影響到用戶n■生軟化水裝置：影響數(shù)據(jù)中心生產(chǎn)運行的軟化水裝置故障的現(xiàn)象

故障產(chǎn)運行或產(chǎn)生負面影響變壓器故障:影響數(shù)據(jù)中心生產(chǎn)運行的變壓器故障的現(xiàn)象

的的現(xiàn)象門禁系統(tǒng)：影響數(shù)據(jù)中心生產(chǎn)運行的門禁系統(tǒng)故障的現(xiàn)象

操作系統(tǒng)：影響基礎應用系統(tǒng)的操作系統(tǒng)故障的現(xiàn)象

網(wǎng)絡與安全：影響網(wǎng)絡與安全的故障現(xiàn)象

服務器：影響基礎應用系統(tǒng)的服務器硬件故障的現(xiàn)象

軟件：影響軟件的故障現(xiàn)象

桌面.影響PC終端的故障現(xiàn)象

IP電話：影響IP電話的故障現(xiàn)象

衛(wèi)星：影響衛(wèi)星通訊的故障現(xiàn)象

視頻會議：影響視頻會議的故障現(xiàn)象

從服務臺接收到的業(yè)務

業(yè)務支持、信息咨詢、

處理信息、場地設備技

服務請求

術支持以及辦公軟硬件

輔助配合、文檔需求

資料供應

包括非授權訪問、信息

泄密、拒絕服務、病毒保密協(xié)議、外來人員管理、門禁卡申請、設備移入移出、不安全操作、拒

安全事件

攻擊、惡意入侵、其他絕服務

入侵

投訴與建議，非本部門

其他工作范圍發(fā)生的但對客備件入庫、接受投訴及建議

戶造成影響的故障

?二級事件分類請參照附件《BGPITCJTSMT-INGOOl事件分類分級說明》

1.1.3事件分級

1.1.3.1影響程度分類

事件優(yōu)先級別的判斷通常要考慮事件影響程度和事件的緊急程度，SLA的等級也應納

入考慮之中。

對事件的影響程度分為四個等級：1級事件，II級事件，in級事件和IV級事件。事

件影響程度的劃分主要考慮兩個維度：事件的影響面積和事件的影響深度。

1.1級事件：

I級事件是指導致特別重大影響或破壞的事件，包括以下情況：

a）造成業(yè)務大面積癱瘓，使其喪失業(yè)務處理能力，恢復業(yè)務正常運行和消除事件負

面影響所需付出的代價十分巨大；

b）產(chǎn)生的影響會波及到一個或多個區(qū)域的大部分地區(qū)，嚴重損害所有或大部分客戶

的利益。

2.II級事件：

II級事件是指導致重大影響或破壞的事件，包括以下情況：

a）造成業(yè)務長時間中斷或局部癱瘓，關鍵業(yè)務無法進行，使其業(yè)務處理能力受到極

大影響，恢復系統(tǒng)正常運行和消除事件負面影響所需付出的代價巨大；

b）產(chǎn)生的影響波及到一個或多個區(qū)域的大部分地區(qū)，損害到大部分客戶的利益。

3.III級事件:

III級事件是指導致較大影響或者破壞的事件，包括以下情況：

a）使關鍵業(yè)務造成較大的損失，即造成業(yè)務中斷，影響業(yè)務處理能力，恢復系統(tǒng)正

常運行和消除安全事件負面影響所需付出的代價較大；

b）產(chǎn)生的影響波及到一個或多個區(qū)域的部分地區(qū)，影響到部分客戶的利益。

4.IV級事件：

IV級事件是指導致較小影響或者破壞的事件，包括以下情況：

a）造成業(yè)務短暫中斷，影響業(yè)務處理能力，恢復業(yè)務正常運行和消除事件負

面影響所需付出的代價較??；

b）產(chǎn)生的影響波及到一個區(qū)域的部分區(qū)域，影響到部分或個別客戶的利益。

1.1.3.2緊急度分類

考慮到事件的相關要素，將事件的緊急度劃分為特別緊急，緊急，一般。

1.特別緊急

a）時效性極強，要求在很短時間內(nèi)恢復的事件；

b）要求服務臺響應E寸限為5分鐘，工程師解決時限為2小時。

2.緊急

a）時效性強，要求在較短的時間內(nèi)恢復的事件；

b）要求服務臺響應時限為10分鐘，工程師解決時限為6小時。

3.一般

a）時效性一般，對恢復時間要求不高；

要求服務臺響應時限為20分鐘，工程師解決時限為48小時。

1.13.3事件分級

根據(jù)事件影響程度和緊急度事件分級如下：

事件優(yōu)先級影響程服務恢是否為重

緊急度詳細定義

豳分類度復時間大事件

*指導致特別重大影響或破壞的事件，時效性極

強，要求在很短時間內(nèi)恢復的事件，包括以下情況：

a）如電力系統(tǒng)故障要求在30分鐘內(nèi)進行處理。

特別緊<30-60b）如設備多臺故障，造成全部業(yè)務中斷，使其喪失

1級非常高I級是

急分鐘業(yè)務處理能力，恢復業(yè)務正常運行和消除事件負面

影響所需付出的代價十分巨大

c）產(chǎn)生的影響會波及到一個或多個區(qū)域的大部分

地區(qū)，嚴重損害所有或大部分客戶的利益。

*指導致重大影響或破壞的事件，時效性強，要求

在較短的時間內(nèi)恢復的事件，包括以下情況：

a汝口設備故障造成客戶設備長時間中斷或局部癱

<120分瘓，關鍵業(yè)務無法進行，使其業(yè)務處理能力受到極

2級高n級緊急否

鐘大影響，恢復系統(tǒng)正常運行和消除事件負面影響所

需付出的代價巨大；

b）產(chǎn)生的影響波及到一個或多個區(qū)域的大部分地

區(qū)，損害到大部分客戶的利益。

*指導致較大影響或者破壞的事件，時效性一般，

對恢復時間要求不高，包括以下情況：

<180分

3級中m級f否產(chǎn)生的影響波及到一個或多個區(qū)域的部分地區(qū)，影

鐘

響到部分客戶的利益.包括機房場地等方面，如門

禁系統(tǒng)出現(xiàn)故障

<240分*故障處理中程度比較簡易，時效性一般，對恢復

4級低IV級否

鐘時間要求不高，如：攝像頭故障、防火門故障

各項目根據(jù)自身情況制定相應的上報和處理流程

1.1.4事件狀態(tài)

為方便事件狀態(tài)的跟蹤和查詢，對事件狀態(tài)定義如下。

編號狀態(tài)描述

1待處理已在系統(tǒng)中記錄，未派單給工程師

2已派單已分配至工程師，工程師未處理

3處理中工程師正在處理過程中，事件未關閉

4掛起工程師正在處理，調(diào)用三線廠商支持或送外修，尚未完畢

編號狀態(tài)描述

5暫停工程師正在處理，因客戶原因暫時無法處理

6待審核事件已關閉，等待項目經(jīng)理審核

7已歸檔服務臺已審核歸檔，服務臺回訪客戶結束。

1.1.5事件上報流程

部門事件上報流程統(tǒng)一參考如下：

1.1.6事件處理流程

在事件處理過程中要根據(jù)事件影響程度和嚴重程度將時間處理過程告知受影響的客

戶和相應客戶主管領導及公司質(zhì)控中心。

1?1?6?1一級事件處理流程

一級事件上報流程統(tǒng)一參考如下：

1.1.6.2二級事件處理流程

二級事件上報流程統(tǒng)一參考如下:

1.L6.3三級、四級事件處理流程

三、四級事件上報流程統(tǒng)一參考如下：

1.1.7事件升級流程

如果事件未能及時按照預定的時間得以解決或技術能力不足，未能滿足用戶要求，或

者需要管理層參與，以提供更多資源，則進行事件升級。

1.按照問題的解決時間進度設置升級的時間段，如果在預定時間段，問題沒有解決，

需要進行事件升級。在設定預定時間段時，應考慮留有足夠的時間以進行管理升

級采取必要措施（如引入第三方支持工

2.在事件解決過程中，由于操作失誤導致更高等級事件的發(fā)生時，需要將事件及時

升級。

3.因為技能或經(jīng)驗的缺乏，需要尋求部門二線專家支持，可以通過服務臺或支持工

程師進行人工要求進行事件升級。

1.1.8二線技術支持申請流程

部門設立統(tǒng)一的二線支持電話：xxxxxxxx，當一線工程師無法處理事件需要尋求部

門二級專家支持時，統(tǒng)一通過此支持電話申請。流程如下

1.2周期類服務

現(xiàn)場工程師定期去伊拉克哈法亞機房巡檢，巡檢機房內(nèi)的網(wǎng)絡設備（路由器、交

換機、防火墻等）和服務器。具體流程如下所示：

1）現(xiàn)場工程師每天對伊拉克哈法亞機房進行例行巡檢。填寫《附錄2.3運維檢查

表》。

2）如果機房巡檢一切正常，填寫《附錄2.3運維檢查表》，關閉事件，完成巡檢。

3）如果機房巡檢出現(xiàn)異常，由伊拉克哈法亞現(xiàn)場工程師判斷問題或事件是否屬于

重大事件。如果屬于一般類事件則參見操作手冊對事件進行處理。伊拉克哈法亞現(xiàn)場

工程師無法解決則升級到二線工程師共同解決。

4）如果屬于重大問題或事件則需要制定重大事件解決方案，并告知甲方領導方案

實施的事件、地點、風險和相應的應對方案，得到甲方領導書面確認后方可實施。實施完

畢后工程師提交《重大故障報告單》并關閉事件。

1.3問題管理

1.3.1目的

主動識別、處置對IT服務造成影響的因素或潛在原因以減少對IT服務運營的影響。

1.3.2總則

1）各項目應制定相應問題管理制度對問題原因的預先識別、分析、管理直至關閉，以減

少對業(yè)務的影響。

2）項目一線人員根據(jù)日常檢查、測試、事故數(shù)量?口類型的趨勢分析等糾正措施，識別潛

在問題。所有被識別的問題都應該得到記錄。

3）在問題得到解決后，應將相關信息應加入問題知識庫，同時應升級所有相關文件，如

用戶指南和系統(tǒng)文件。

4）記錄對服務或問題管理流程的改進，完善已知錯誤數(shù)據(jù)集形成知識庫，并作為服務改

進計劃的輸入和為知識分享提供資料。

1.3.3術語

1）問題：引發(fā)一個或多個事件的未知因素。

問題通常具有如下特征：

?一組具有一定關系的已結束的事件

?一個重大事件

問題的根本原因找出后即成為已知錯誤；許多事件往往是有一個問題引起的。

問題管理流程的輸出有：

?變更請求

?臨時解決措施

?預防性措施

2）已知錯誤：查明事件原因并且已有臨時、應急處理措施的問題。

3)主動問題管理：

?通過改進基礎設施以及提出變更請求來阻止可避免事件的發(fā)生。

?通過找出基礎設施中的薄弱環(huán)節(jié)來阻止事件的再次發(fā)生，以及提出消除這些薄弱環(huán)節(jié)

的建議。分析基礎設施的運行趨勢并找出那些潛在事件以防止其發(fā)生。

1.3.4問題分類分級

問題的分類分級原則上于事件的分類分級一致。

1.3.5問題狀態(tài)

為方便問題狀態(tài)的跟蹤和查詢，對問題狀態(tài)定義如下。

編號狀態(tài)描述

1處理中問題正任處理過程中

2拒絕問題分派被拒絕

3已知錯誤問題根本原因已找出

4RFC已提交變更請求(RFC)

5關閉關閉

6沒有解決問題沒有解決

1.3.6問題處理流程

1.相關人員根據(jù)各類分析報告進行趨勢分析發(fā)現(xiàn)潛在問題，并創(chuàng)建問題申請單；或接收

到已知錯誤，更新和發(fā)布已知錯誤數(shù)據(jù)集，以便于其他管理程序和相關人員及時了

解相關信息。

流程說明;

序號流程編號流程描述成果物負責人參與人

1.開始流程的起始節(jié)點

PRO-1-01

分析各類報問題支持

?依據(jù)制發(fā)問題的條件定期對各類報告

2.

告，識別問進行趨勢分析,發(fā)現(xiàn)潛在問題。團隊/人員

想

PRO-1-02?若查明某問題的根本原因形成已知錯

誤后，或在發(fā)布管理流程中產(chǎn)生的已問題支持

3.更新已知錦已知錯誤

知錯誤，將這些已知錯誤更新至已知團隊/人員

誤數(shù)據(jù)集

錯誤數(shù)據(jù)集-

PRO-1-03

發(fā)布更新后的已知情誤數(shù)據(jù)集,通知問題支持

4.發(fā)布已知錯已知錯誤

相關人員。團隊/人員

誤數(shù)據(jù)集

PRO-1-04

創(chuàng)建問題申請單,并對問題信息進行問題支持

5.創(chuàng)建問題申問題申請單

記錄與描述.團隊/人員

請單

6.結束流程結束他點

2.團隊/項目負責人接到問題申清后，在對問題進行初步分類和優(yōu)先級判斷后協(xié)調(diào)相關團

隊/人員分析問題產(chǎn)生的原因，查找可行的問題解決方案并解決問題。

流程說明:

序號流程編號流程描述成果物負責人參與人

1.開始流程的起始節(jié)點

PRO-II-O1?記錄主動顯現(xiàn)所HJH和^動叁現(xiàn)的問

的as支rr

2.id錄與分類e(

?根IttlHIH所《?頓城當打分光.71r睛1隊，人員

問也

判斷向MS的優(yōu)先級.

■同胃依友人*r新建的HJS進行小核.

R"唾仇*人確定觸JSS是否有效、是苦

是手里同整.優(yōu)先級的分國足與A■適.

的期佑總項填”虻公先修：

PRO-II-02?如果1詞理確認無效.則關即網(wǎng)IS.并

同祖

3.審批與分掘如Ini寺求才；

?根據(jù)阿鹿的分類.忙1；”也外派匕；相卜"ei寅人

1句fig

向1S文打閑隊/人員.如何尊上抬4不隊

/人出發(fā)現(xiàn)問膻應透山44他。尿分■所

M決，就把發(fā)J可同期”1m人.注

磯拒絕理由并推存共他*jeg支持?陽隊

/A?.

?胸JS2支內(nèi)團隊/人兄接受問電.更新問

題狀W及id泉實標升蛇診斷可問：

?加制共他團隊雙人員協(xié)助分析、詮斷?

則通知例現(xiàn)以友人.由向SSS.近人協(xié)

訓留源.成立可1?分析?云:組.舉行

同《4根本原閑分析研i才會i義.確定向

PRO-II-03

色的泄在日兇.提供政史新問世變他MJJS支師

4分析與診斷方法，以陵低向電在根本M決ffir對業(yè)

M1KK/AM

問吆務產(chǎn)生的，響：

?曲間也產(chǎn)生小本原內(nèi)及變通方■法及時

更新到問題id錄中：

?格問《s根冷近閃及變域方法通如何電

負責人,

?31%何地支用⑷隊/人MJL/找利向

86的根4而LM.及時iffi報同Jffitft雷人。

?對十一經(jīng)拄劑根本燎內(nèi)的同as.m

酹定解決方案.以便水久解決何必：

?A■找并2m板小ttx決方?案.確保萬

案能徹底M決問跑.更新問迎記錄中

的女配衿斷”.slfir+fnit

?劉斷實施上還解決方案/變儂方”、柜

蘇需彩通過其他流程（如變曳流程

等,，

-如需歿.提文列相應的流程.并

PRO-11-04交史請求同圖文時

5.和諉流叫人員保持溝通.rx同

修決何這<RFO團隊/人員

AS的M決狀況：

-如不需變變更.計劃并組織女的

桿決方案以N決問電1

?加5R1B案第三方介入.則阿圖士用閉

隊/人出負聲與第：方的協(xié)四：

?如朱阿咫支將團隊/人員便計無法找

列根本解決方案成圾有解決方案但門

前無法實施（如文岫的代價大太），i6

報MIS伏賁人.

向分機報

??認同咫是杳被正*用?*決.ftiJRci

PRO-II-05儂“二硫觸決.問as負赤人通知問at立告MS

6.

關閉網(wǎng)睡舟團隊/人GX閉問題；己如錚誤我貢人

■更新己知怙設饗。同*s記錄m

7.緯來流程結束予，%

?如果問題的解決涉及到用戶的變更，則及時與客戶溝通協(xié)商解決方法。

1.4變更管理

1.1.1目的

規(guī)范所有IT變更，從而保證由于變更而引起的對生產(chǎn)的影響降到最小，提高IT系統(tǒng)

和服務的質(zhì)量，為業(yè)務的快速發(fā)展提供更優(yōu)質(zhì)的IT服務

1.1.2總則

1）部門及各項目根據(jù)公司業(yè)務需要或客戶需求，制訂相應變更管理流程。

2）部門及項目組在組織、開展變更時，應對一下要素進行說明：發(fā)起、記錄和分類、評

估變更對服務、客戶和發(fā)布計劃的影響、緊急程度、成本、收益和風險、如果沒有成

功時可以恢復或修訂、備案，如變更請求與受影響的配置項、更新后的實施和發(fā)布計

劃版本、根據(jù)變更的類型、大小和風險，得到變更負責方的認可或拒絕、由負責變更

組件的團隊負責人進行實施、測試、驗證、取消、結束和評審、時間安排、監(jiān)控和報

告、與事件、問題、其它變更和配置項記錄聯(lián)系。

3）部門及項目組應將要進行的變更的時間信息及時提供給與變更有關的人員，變更狀態(tài)

和安排的實施時間應作為變更和發(fā)布時間安排的依據(jù)。

4）部門及項目組應在變更實施后組織對其效果和改進記錄進行評審，評審結果應妥善保

管并作為服務改進計劃的輸入。實施后評審應檢直：變更是否滿足目標、客戶對結果

是否滿意、沒有預期之外的負面影響。

5）部門及項目組對變更分析結果和結論采取相應的糾正、預防措施，并保存相關的記錄。

1.1.3變更分類

變更分類原則根據(jù)事件分類原則保持一致。

1.1.4變更上報

1,重大變更必須提交你提交變更委員會審批，變更事實結束后將變更執(zhí)行結果上報至變

更委員會備案；

2,變更委員會負責審批高風險的變更，風險高、影響范圍大時，變更負責人需要將變更

影響上報至公司和客戶；

3,緊急變更委員會負責審批時間緊迫、風險等級高的變更。

1.1.5變更通知

1.對現(xiàn)有業(yè)務系統(tǒng)產(chǎn)生影響的變更，例如因?qū)嵤┳兏枰C或者中止業(yè)務，均需在

變更執(zhí)行前提前通知有關人員做好業(yè)務調(diào)整，減少對業(yè)務的影響，待實施完成后再次

通告；

2.如變更影響到客戶使用業(yè)務系統(tǒng)，需要以不同的方式通知客戶。

1.1.6變更類型

變更類型用于區(qū)分變更，提高變更處理的效率。

編號代碼描述

指頻繁發(fā)生、影響范圍較小、緊急程度較低、實施風險較?。ú粫碇卮蠛蠊鸤

1簡單變更

實施較簡單的變更，如庫表大小的改動，crontab時間的修改，文件的刪除等。

指涉及影響范圍較大（影響客戶、業(yè)務部門、分公司或者社會影響較大\實施風

2標準變更險較大、實施按復雜的變更。這些變更可以進行充分的計劃和測試。如業(yè)務割接、

機房搬遷、軟件升級等。（需求審批；上線審批）

指如果不進行變更，會立即或正在嚴重影響業(yè)務運行、導致嚴重影響服務等級或者

3緊急變更帶來重大影響的變更，應當?shù)玫奖M可能快速的處理,減少流程的復雜性，但是又要

有良好的控制。如緊急事件引發(fā)的緊急變更。

1.1.7變更風險等級

除簡單變更外，項目經(jīng)理、變更委員會/緊急變更委員會對標準變更和緊急變更根據(jù)下

表所列的衡量因素來量化評估實施變更可能帶來的風險，該評估結果用于決定是否批準變

更，是否需要更高級別的審批，以及實施完成后的觀察期。該評估由項目進行初步評定,

再由變更經(jīng)理或變更委員會進行最終確定。

風險等級量化評估表如下：

衡量因素條件得分

影響全部用戶和全部業(yè)務1

影響部門用戶和部分業(yè)務2

地區(qū)n用戶數(shù)量（受到

實施或取消的影響）影響全部用戶3

影響部分用戶4

3個或更多支持小組1

2個支持小組2

準備/實施必需的資源

超過1人，相同的支持小組3

1人4

無法測試，變更失敗可能性很高1

能支現(xiàn)部分則試，變更失敗可能性較高2

變更成功的可能性

有成熟的變更方案，變更失敗可能低3

無需測試，變更失敗可能性沒有4

6天或更長1

2-6天2

變更規(guī)劃時間

1-2天3

小于1天4

超過2小時或在線/服務斷供期1

1-2小時2

變更實施時間

不到1小時3

不到30分鐘4

衡量因素條件得分

回退時間超過2小時1

回退難度中等以上（1-2小時）2

回退時間

回退難度適中（1小時或更短）3

易于回退（30分鐘或更短）4

根據(jù)上表對每個變更進行評估，最終得出風險等級。風險分為四個等級：重大、高、

中、低。不同的風險等級分別有對應的審批級別和實施完成后的觀察期，具體定義如下表:

總得分對應風險等級對應審批級別實施完后的觀察周期

6-9重大變更委員會、部門經(jīng)理5-7天

10-13高變更委員會4-5天

14-17中項目經(jīng)理2-3天

18+低項目經(jīng)理1天

1.1.8流程主要內(nèi)容

變更管理流程始于變更的接收，結束于變更的實施和回顧。該流程包含下述主要內(nèi)容：

?提出變更請求（RFC\評估、分類

變更申請人提出變更請求（RFC）,由項目經(jīng)理負責檢查和完善其內(nèi)容，通過查詢配

置管理數(shù)據(jù)庫，進行風險等級的初步評估；并盡量提出可能與業(yè)務發(fā)生的關聯(lián)的影響，

已供決策參考。變更土管井對變更進行分類；如為緊急變更，則需要各項目制定緊急變

更流程并按照緊急變更流程執(zhí)行；如為簡單變更,直接制定變更計劃，經(jīng)變更委員會審

批通過后并安排實施。

?項目經(jīng)理評估、審批

項目經(jīng)理接受變更請求（RFC）,如果確定是緊急變更，則快速完成評估、審批。對

標準變更，確定變更風險等級，審閱變更實施計劃、測試報告、回退計劃和配置項更新

計戈!1,批準或駁回變更申請，如需要更高級別管理層的審批，則根據(jù)不同風險級別報批。

?變更委員會（CAB）/緊急變更委員會（EC）評估、審批

項目經(jīng)理將根據(jù)特定的變更請求成立特定的變更委員會（CAB）/EC,成員包括對該

變更的評估和批準提供應有附加價值的技術人員和管理人員，審閱工作包括變更的風險、

對現(xiàn)有服務的影響、實施計劃、回退計劃和配置項更新計劃等，并做出批準與否的決定。

如為緊急變更，則快速完成以上評估、審批。

?管理層審批

對于風險等級為“重大"的變更，在變更委員會審批通過后，必須再由項目經(jīng)理報請

至部門管理層審批。

?項目經(jīng)理負責組織制定變更計劃、測試

項目經(jīng)理安排并協(xié)調(diào)相應資源制定變更計劃，包括實施計劃、測試計劃、回退計劃、

配置項更新計劃等。應安排對實施計劃和回退計劃進行測試，隨后將測試結果、實施計

劃、回退計劃、配置項更新計劃等提交給上級領導審核。

?協(xié)調(diào)變更實施

項目經(jīng)理負責協(xié)調(diào)資源，準備實施前相關工作,組織人員按計劃實施變更，變更主管

監(jiān)控實施過程和結果，井在必要時進行協(xié)調(diào)或做出決定。在這階段可能需要變更經(jīng)理和

變更委員會成員的幫助。

?回顧和關閉

實施變更后項目經(jīng)理確保配置項及時得到更新，并協(xié)同變更經(jīng)理負責從技術、管理、

業(yè)務角度去回顧變更，確保變更請求（RFC）得到了預期效果，并尋找改進機會或行動

計劃，在回顧過程中可能會需要得到變更委員會中相關領域的技術人員的幫助，隨后更

新變更記錄并關閉變更請求（RFC\

1.1.9緊急變更流程

流程說明:

序號活動/子流程描述成果物負責人參與人

1.開始流程開始流程的起始節(jié)點。

L2.1

?變更負責人接收緊急交更申請

2.接受緊急變更申變更負責人

單，分析緊急變更單內(nèi)容.

請單

?變更負責人接收緊急變更單后，

L2.2判斷變更是否為緊急變更：

3.變更負責人

是否案急變更?變更負責人有權ift過或拒也緊

急變更申請.

L2.3?變更負貴人判斷是否需要ECAB

4.是否需要ECAB參參與評估審核緊急變更申請單：變更負責人ECAB

與評審?如果需要變更負責人將與ECAB

其他成員共同評估審核緊急變

史申請單??

?如果變史UJECAB共同.

估審批緊急變更申請單，將由雙

L2.4方共同調(diào)配緊急變更所而責-h

5.?如果變更負責人判斷不，變更負責人ECAB

分配資源

ECAB參與評估審批緊急變更，

將由變更負責人能獨調(diào)配緊急

變更所需資源。

?變更負貢人接收來自變更執(zhí)行

人的緊急變更申請電實俺完紫

急變更后通知變更負責人：

?變更負責人對緊急變更結果進評估結果反

L2.5變更執(zhí)行

6.行評估,審核其是否達到預期結驚、發(fā)布申變更負責人

實施后評估人

果：請單

?變加負責人根據(jù)評估結果反饋

判斷比次緊急變更是否會引起

新的事件、問題或發(fā)布.

L2.6?緊急變史實能結束由

7.變更負責人

補充相關單據(jù)貢人指導完成相關m據(jù)說明.

?緊急變更如果涉及到發(fā)布管理.

將在變更實施成功后通知發(fā)布

L2.7變更執(zhí)行

8.管理進行處理：變更負責人

提交發(fā)布人

?此it作可由變更￡'史更

執(zhí)行人中的任意角色承擔。

?變更執(zhí)行人接收來自緊急變更

負責人的通知,實施緊急變更：

L1.1變更負責

9.?緊急變更實施完成后，變更執(zhí)行變更執(zhí)行人

實施緊急變更人

人更新緊急變更申請的，提交變

更負責人分析.

L3.1

?如果交火負責人判斷需要ECAB

參與評估審批緊變更負責

10.參與評估審批緊急變更，雙方將ECAB

急變更