【正文】 ? 記錄變更的 PIR 結(jié)果。 ? 變更 實施者 將變更狀態(tài)標(biāo)識為“ 發(fā)布 中” 。 ? 變更經(jīng)理將變更狀態(tài)標(biāo)識為“已排程” 。 ? 若無需組織 CAB，則由變更經(jīng)理獨立進行評審。 是否與已實施的變更關(guān)聯(lián) 變更經(jīng)理、變更實施 者 ? 與現(xiàn)有變更進行關(guān)聯(lián)，如果是已在實施的變更則進入 進行實施后評審與關(guān)閉。 2 變更評估與審批 實施者 變更審批者 ? 變更計劃和實施負(fù)責(zé)人 復(fù)核 RFC，并制定初步 計劃 。它將被用作對變更進行分組的第二層。 變更計劃 包括變更的實施計劃、測試計劃、回滾計劃等，以及變更任務(wù)分配給哪些實施者 變更日程安排 變更實施的時間安排 變更實施情況 由變更實施人填寫，用于描述實施時的現(xiàn)場情況 變更測試情況 描述測試的情況、測試結(jié)果 變更觀察情況 描述變更結(jié)束后，觀察期間的情況 變更關(guān)閉狀態(tài) □完全成功 □部分成功 □取消 □拒絕 關(guān)閉時間 變更關(guān)閉的時間 關(guān)閉人 關(guān)閉人的姓名 變更管理流程設(shè)計說明書 14 變更狀態(tài)代碼 下列狀態(tài)碼表示變更請求單的生命周期中的不同階段： 表 36 變更狀態(tài)代碼 變更狀態(tài) 狀態(tài)說明 草擬中 編寫 RFC(變更請求 ) 已提交 已向變更管理提交 RFC 已審核變 更請求 RFC 通過合規(guī)性審核 已排程 審批優(yōu)先級排程 已審批 RFC 通過審批 計劃中 制定變更計劃 測試中 開發(fā)中 , 測試中 , 構(gòu)建中 發(fā)布中 回滾中 , 文檔中 , 檢測中 已掛起 管理人員介入 , 供應(yīng)商采購 , 進一步改進中 ,支持團隊溝通中 , 任務(wù)評估中 被拒絕 信息不完整、進度沖突 已完成 等待回顧 已關(guān)閉 成功 , 成功帶有問題 , 不成功 , 取消 已取消 不再要求 , 資源缺乏 , 需要重新安排 變更類型 變更類型決定了變更執(zhí)行的審批路徑，可分為緊急變更、重大變更、一般變更（重要變更和簡 單變更）和標(biāo)準(zhǔn)變更四類。按照得分，則可以定義出變更的類型，確定其風(fēng)險。 ? 變更管理負(fù)責(zé)對系統(tǒng)的變更進行管理，以控制變更所帶來的風(fēng)險。為了防止出現(xiàn)緊急問題時來不及召集所有變更顧問委員會成員的情況出現(xiàn)，有時候也在變更顧問委員會中設(shè)立應(yīng)急委員會（ Emergency Committee）。 ? 發(fā)布管理 ITIL 流程， 是負(fù)責(zé)對應(yīng)用系統(tǒng)上線過程的全局管理和控制。作為 xxxx 本次 IT 服務(wù)管理項目中的重要流程之一 ， 變更管理流程旨在 通過規(guī)范的控制和管理， 增加變更 過程的可控性， 減少或者消除在執(zhí)行變更工作任務(wù)時對生產(chǎn) 環(huán)境 帶來的風(fēng)險和影響。它的目的是 主動防御，找出根本原因并對其根除 ，所以它 與 配置 管理流程有顯著的不同，以“治本”為最終目標(biāo)。 變更請求（ Request for Change） 是指用于記錄變更請求的書 面文檔或電子文檔。 同時，對變更整體執(zhí)行過程從技術(shù)、業(yè)務(wù)和管理等方面進行回顧，對于其中發(fā)現(xiàn)的問題予以分析和討論 ，以便對流程運行質(zhì)量進行持續(xù)改進和優(yōu)化 。 ? 業(yè)務(wù)影響范圍（按用戶數(shù)量和部門來確定）； ? 準(zhǔn)備 /實施所必須的資源； ? 變更成功的可能性； ? 變更規(guī)劃時間； ? 變更實施時間； ? 回退時間； ? 系統(tǒng)業(yè)務(wù)等級。變更回退是為了滿足所承諾的服務(wù)水平。它將被用作對變更進行分組的第一層。 職責(zé)定義： ? 確保按時實施變更 ? 按照指導(dǎo)方針執(zhí)行回退計劃 變更管理流程設(shè)計說明書 20 ? 盡量解決在實施過程中出現(xiàn)的問題 ? 如果變更實施失敗，執(zhí)行恢復(fù)計劃 ? 必要時更新操作手冊或運行操作規(guī)程 ? 如果變更實施失敗，需要創(chuàng)建相應(yīng)的變更事件故障單 ? 更新變更記錄單狀態(tài) ? 通知操作人員 /服 務(wù)臺關(guān)于變更處理的狀態(tài) ? 更新配置管理中 CI 的狀態(tài) 專業(yè)技能： ? 熟悉公司的 IT 政策，流程和標(biāo)準(zhǔn) ? 了解變更管理流程 ? 了解用戶業(yè)務(wù)及其 IT 基礎(chǔ)架構(gòu)環(huán)境 ? 具備某技術(shù)領(lǐng)域良好的專業(yè)技能 ? 理解服務(wù)水平承諾 處事技能： ? 出色的執(zhí)行能力 ? 良好的溝通和協(xié)調(diào)能力 角色映射 表 312 信息中心 變更管理 角色映射 流程中定義的角色 信息中心 對應(yīng)人員 變更流程負(fù)責(zé)人 /變更經(jīng)理 變更請求者 變更變更實施員 CAB 變更管理流程設(shè)計說明書 21 流程概要設(shè)計 流程概要設(shè)計是從邏輯層面對變更管理流程進行的描述總結(jié)，結(jié)合 信息中心具體情況，給出如下流程 設(shè)計： ＝子 流程 /活動 ＝ 判斷 ＝結(jié)束或節(jié)點 ＝其他 流程 ＝文檔 下圖展示了 信息中心 變更管理流程的概要流程： I T 服 務(wù) 管 理 變 更 管 理 流 程 圖 概 覽CAB/ECAB變更實施員變更經(jīng)理其它服務(wù)支持/提供流程變更提交者1變 更 啟 動和 記 錄3變 更 計 劃和 排 程5變 更 完 成和 關(guān) 閉配 置 管 理問 題 管 理 事 件 管 理4變 更 實 施2評 估 amp。 ? 如果該變更請求需要立項，則進入項目分部由項目管理控制；如果不需立項，則 進入 . 關(guān)聯(lián)相關(guān) CI 變更請求者、變更經(jīng)理、變更實施 者 ? 根據(jù)變更請求的信息來判斷關(guān)聯(lián)此項變更的相關(guān)配置項信息 風(fēng)險評估 變更請求者、變更經(jīng)理、變更實施 者 ? 變更經(jīng)理、變更 實施者 與變更請求者 根據(jù)《 風(fēng)險評估表 》結(jié)合變更信息 判斷該變更是 哪種類型的變更。 ? 需要則進入 ，組織 CAB評審。 完善任務(wù)計劃 變更實施員 ? 接受變更經(jīng)理分派任務(wù)，對變更請求中的變更方案和回退計劃、上線計劃等進行完善，并確定實施日程。 ? 如果測試 不成功，則 進入 構(gòu)建變更。 更新 審批 記錄 變更經(jīng)理 ? 將實施成功的變更 評審 信息 更新到變 更單中 。 變更經(jīng)理將變更狀態(tài)調(diào)整為“已關(guān)閉”，關(guān)閉變更單。 ? 變更 實施者 通知相關(guān)事件經(jīng)理和問題管理可以關(guān)閉相應(yīng)的因變更掛起的事件和問題。 ? 變更 實施者 制定回退計劃，以便在變更實施失敗時進行回退 。 ? 如果批準(zhǔn)，轉(zhuǎn)入 “ 更新審批記錄 ” 。 確定分類 變更經(jīng)理、變更請求者、變更實施員 ? 變更經(jīng)理 審核 確認(rèn) RFC 的分類 是否 正確，如果有必要可連同變更主管和變更請求者共同確認(rèn)。 ? 變更經(jīng)理 將變更計劃排程任務(wù)分派給變更 者 協(xié)同完成。優(yōu)先級可分為高、中、低三個級別 在 確定變更優(yōu)先級時需要考慮兩個因素：影響度和緊急度。 ? 標(biāo)準(zhǔn)變更 標(biāo)準(zhǔn)變更指的是日常發(fā)生、影響范圍小、有標(biāo)準(zhǔn)操作流程、實施風(fēng)險?。ú粫碇卮蠛蠊┑念A(yù)授權(quán)的變更 ,在 信息中心 內(nèi)是指符合標(biāo)準(zhǔn)變更定義范圍內(nèi)變更管理流程設(shè)計說明書 15 的變更。 下表描述了變更的執(zhí)行途徑及相應(yīng)的審批人員。 ? 通過變更管理會議對變更活動進行跟蹤、溝通和協(xié)調(diào)。 流程范圍 xxxx 信息中心 變更管理流程范圍包括 xxxx 所有的已有 IT 基礎(chǔ)架構(gòu)與 IT 服務(wù)中產(chǎn)生的變更需求，也包括項目分部就項目建設(shè)定向提出的變更請求。這些設(shè)備和系統(tǒng)被稱為配置元素 （ CI） 。 本文作為 xxxx 信息中心 實行變更管理流程的參考， 讀者對象為 xxxx 信息 中心 內(nèi) 參與變更管理流程的人員和相關(guān) 的 管理層。 ? 事件 管理 ITIL 流程，是負(fù)責(zé)解決所有的 IT 事件、問題和用戶請求等的 管理 流程。 非標(biāo)準(zhǔn)變更（ Nonstandard Change） 是指除標(biāo)準(zhǔn)變更外的所有其它變更。 變更管理流程設(shè)計說明書 8 ? 發(fā)布構(gòu)建與實施 該步驟負(fù)責(zé)對變更進行測試環(huán)境和發(fā)布包的構(gòu)建，同時創(chuàng)建發(fā)布計劃、測試計劃和回退計劃，最后在執(zhí)行測試成功之后提交上線計劃。 ? 相關(guān)性原則 指和此變更利益相關(guān)者必須參與原則； 涉及產(chǎn)品和服務(wù)采購的變更審批應(yīng)有回避制度。前導(dǎo)時間是基于變更路徑而定的。對于重大變更，建議由變更經(jīng)理總體負(fù)責(zé)，通過與各相關(guān)方面協(xié)同，采取多種手段（例如 CAB 會議），嚴(yán)格管理其計劃實施。通常是某 幾 個直接參與變更或受到變更影響的部門負(fù)責(zé)人或代表 共同 組成 ，在 xxxx 信息中心內(nèi)部 可能是三個運維組的負(fù)責(zé)人共同組成 。 ? 變更請求者 收集必要的變更信息以創(chuàng)建一個變更請求，例如變更對象、變更描述等 。 ? 變更請求者可針對 意見對 RFC 進行修改，修改完畢 后重新提交 新的 RFC。 任務(wù)計劃是否需要相關(guān)人員協(xié)助？ 變更 經(jīng)理、變更實施員 ? 變更經(jīng)理 判斷并與相關(guān)人員協(xié)調(diào)確認(rèn)是否需要相關(guān)人員介入制定變更計劃和排程。 測試 變更實施員 ? 變更 實施者 指導(dǎo) 變更實施者 進行變更的測試工作 。 更新變更 /任務(wù)執(zhí)行 記錄 變更 實施 員 ? 變更 實施者 更新變更執(zhí)行記錄 (包括回退的執(zhí)行記錄 )。 ? 變更完成后產(chǎn)生配置修改信息列表，提供給配置管理。 評審變更實施結(jié)果 變 更 經(jīng)理 、CAB ? 評審變更結(jié)果能否接受，參與人員原則上應(yīng)與此項變更請求評審人員相同，但可由變更經(jīng)理根據(jù)實際情況做相應(yīng)調(diào)整，必要時可召集 CAB。 是否需 要立項 變更實施員 ? 變更 實施者 根據(jù)變更所需要的條件判斷該變更是否需要立項。 ? 如果需要則轉(zhuǎn)入 “修改后重新提交，否則就關(guān)閉變更。 確定變 更路徑和審批者 變更經(jīng)理、變更實施員 ? 變更經(jīng)理與變更實施員確定該 RFC 的變更路徑和審批者。 ? 變更實施人執(zhí)行 變更任務(wù)，并當(dāng)變更失敗時按計劃執(zhí)行回退方案。 信息中心 變更緊急度判定規(guī)則如下： 表 39 變更緊急度 緊急度 要求實施時間 高 兩天內(nèi)需要執(zhí)行的變更 中 七天內(nèi)需要執(zhí)行的變更 低 可在七天后執(zhí)行的變更 ? 優(yōu)先級 根 據(jù)變更影響度和緊急度兩個要素，確定變更優(yōu)先級如下表所示： 表 310 變更優(yōu)先級 優(yōu)先級 影響度 L1高 L2中 L3低 緊急度 L1高 1 1 2 L2中 1 2 3 L3低 2 3 3 （注：變更優(yōu) 先級可在試運行一段時間后按需進行調(diào)整） 變更關(guān)閉代碼 變更結(jié)束代碼用來表示變更實施的結(jié)果，如下表所示： 表 311 變更關(guān)閉代碼 結(jié)束代碼 描述 變更管理流程設(shè)計說明書 17 成功 變更成功實施完畢 部分成功 變更部分成功，有問題 未成功 變更實施失敗 取消（ Back Out） 在實施前取消了變更 流程角色和 職責(zé)定義 變更 流程 經(jīng)理 變更 管理流程 經(jīng)理 從宏觀上監(jiān)控流程，確保 變更 流程 在 信息中心運維 團隊范圍 內(nèi)被正確的執(zhí)行。標(biāo)準(zhǔn)變更產(chǎn)生方法有兩種：列舉法、規(guī)則定義法。 表 32 變更通知 策略對應(yīng)表 變更狀態(tài) 根據(jù)角色通知 變更發(fā)起人 變更經(jīng)理 主任 /副主任 變更實施員 草擬 請求變更 計劃中 已排程評審 已排程審批 已排程 實施中 等待 已否決 已完成 已關(guān)閉 已回退 已取消 詳細的變更通知矩陣表見附件。 CAB/ECAB 建立原則 CAB 組建是為了保證變更被正確的審核從而保證變更的風(fēng)險和成本支出都符合組織的需求。 變更管理流程包括以下 工作活動 ： ? 變更啟動和記錄 該步驟是變更管理流程的起點，包括 收集 變更請求的 相關(guān) 信息， 發(fā)起并 創(chuàng)建請求 單 ，并 初步確定變更類型以決定后