【正文】 ........................................................................................ 33 流程衡量指標 ................................................................................................................. 33 流程衡量報表 ................................................................................................................. 34 第 4 章 附錄 ....................................................................................................................................... 34 變更管理流程設計說明書 4 第 1章 文檔介紹 文檔簡介 本文檔『 xxxxIT 服務管理 變更管理流程設計手冊』，是 xxxx 信息中心 （以下簡稱 信息中心 ） 運維 團隊和 xxxx（以下簡稱 xxxx）一起制定的變更 管理流程文檔。作為 xxxx 本次 IT 服務管理項目中的重要流程之一 ， 變更管理流程旨在 通過規(guī)范的控制和管理， 增加變更 過程的可控性， 減少或者消除在執(zhí)行變更工作任務時對生產(chǎn) 環(huán)境 帶來的風險和影響。 文檔用途 本文檔既是本次 IT 服務管理項目變更管理流程的交付物 ,也 是 xxxx 信息中心 進一步改進變更管理流程的藍本。 本文檔所描述的流程在 IT 服務管理中有如下作用 ： ? 處理變更請求 ,完成對生產(chǎn)環(huán)境中基礎架構及應用系統(tǒng)的更改； ? 對變更進行分類，并明確相應審批路徑； ? 對變更操作可能帶來的風險和影響進行充分評估和預測； ? 對變更進行妥善計劃，明確變更實施過程，降低實施風險； ? 向管理層提供流程相關管理信息。在該章節(jié)中，首先對變更管理流程的相關執(zhí)行原則和代碼進行了描述；其次，對變更管理流程相關角色的職責和技能要 求進行了說明；基于流程原則和角色定義，進而對變更管理的概要設計流程及詳細設計流程進行了充分定義，并給出了變更管理流程的關鍵衡量指標，通過報表提供管理信息，保證對流程運行的監(jiān)控、變更管理流程設計說明書 5 管理和改進。此項功能常常通 過集中的服務臺 進行體現(xiàn) 。 ? 事件 管理 ITIL 流程，是負責解決所有的 IT 事件、問題和用戶請求等的 管理 流程。 ? 問題管理 ITIL 流程，是負責 對事件進行深入分析，找出根本原因并提供解決方案的管理流程 。 ? 變更管理 ITIL 流程， 是負責對生產(chǎn)環(huán)境中支持 IT 服務的各種基礎架構設備和應用系統(tǒng)的 變更 操作進行記錄、分類、評估、計劃和協(xié)調的流程。 ? 發(fā)布管理 ITIL 流程， 是負責對應用系統(tǒng)上線過程的全局管理和控制。 ? 配置管理 ITIL 流程，配置管理負責描述，跟蹤和匯報所有 IT 基礎架構中的每一個設備或系統(tǒng)的管理流程。每一個 CI 必須有效管理，跟蹤和控制以支持 IT服務和基礎設施成功運行。 第 2章 變更管理流程簡介 流程基本概念 變更管理是指采用標準統(tǒng)一的方法和步驟來管理、控制所有對 IT 生產(chǎn)環(huán)境有影響的變更活動。 變更管理流程中 幾個相關的名次解釋 如下： 變更（ Change） 是指對生產(chǎn)環(huán)境中的配置項所作的增加、修改或移除，這些配置項（ CIs）包括主機、網(wǎng)絡、軟件、應用、環(huán)境及相關文檔。 非標準變更（ Nonstandard Change） 是指除標準變更外的所有其它變更。但如果情況嚴重且不允許延遲，可能需要啟動緊急變更請求（ RFC）程序。 變更顧問委員會（ Change Advisory Board） 指一組在實施變更時能夠為變更管理提供專業(yè)意見的人。為了防止出現(xiàn)緊急問題時來不及召集所有變更顧問委員會成員的情況出現(xiàn)，有時候也在變更顧問委員會中設立應急委員會（ Emergency Committee）。具體而言，變更管理流程的目的有以下幾點： ? 確保所有的變更活動都遵循標準的 方法、程序和規(guī)則； ? 確保所有的變更活動都有明確的記錄可追蹤； ? 確保所有的變更活動都能快捷有效地進行； ? 確保所有的變更活動可能導致的負面影響和風險都能被正確的識別和評估； ? 降低變更活動可能引發(fā)事件對 IT 服務質量的影響。但不包括以下范圍： ? 大型的技術改造項目 (區(qū)別是否大型在于看是否立項 )； ? 新建項目在正式驗收之前，產(chǎn)生的變更請求 (有項目管理控制 )。 變更管理流程包括以下 工作活動 ： ? 變更啟動和記錄 該步驟是變更管理流程的起點，包括 收集 變更請求的 相關 信息， 發(fā)起并 創(chuàng)建請求 單 ，并 初步確定變更類型以決定后續(xù) 執(zhí)行請求的 路徑。 ? 變更計劃和排程 該步驟始于 變更通過 審批，結束于確定的 變更 日程 計劃和安排 。 變更管理流程設計說明書 8 ? 發(fā)布構建與實施 該步驟負責對變更進行測試環(huán)境和發(fā)布包的構建，同時創(chuàng)建發(fā)布計劃、測試計劃和回退計劃，最后在執(zhí)行測試成功之后提交上線計劃。 ? 變更完成和關閉 通過本步驟，確認變更實施結果 是否達到了預期的 目的 。 流程業(yè)務價值 變更管理流程對 xxxx 信息中心 具有以下業(yè)務價值 ： ? 通過變更的記錄和流轉，提高變更各環(huán)節(jié)、人員的溝通效率和變更的可視性； ? 通過對變更的評估和審批，將變更可能引入的風險和影響降至最低； ? 更加關注變更效果，只有能夠提升業(yè)務收益的變更才能被批準； ? 變更按照不同優(yōu)先級合理計劃及排程，避免沖突； ? 提高變更回退能力，增強 IT 環(huán)境的穩(wěn)定性，降低變更失敗可能帶來的負面影響； 第 3章 變更管理流程設計 流程執(zhí)行原則 流程常規(guī)原則 ? xxxx 信息中心 生產(chǎn)環(huán)境中的各類非標準變更，將采用 統(tǒng)一的變更管理流程處理。 ? 變更管理負責對系統(tǒng)的變更進行管理，以控制變更所帶來的風險。 變更管理流程設計說明書 9 ? xxxx 信息中心 應遵循管理流程的原則、操作步驟和操作規(guī)程。 ? 應定期（每月）產(chǎn)生管理報表并進行檢查。 CAB/ECAB 建立原則 CAB 組建是為了保證變更被正確的審核從而保證變更的風險和成本支出都符合組織的需求。 ? 奇數(shù)原則 有效投票人數(shù)為奇數(shù)原則 。 ? 相關性原則 指和此變更利益相關者必須參與原則； 涉及產(chǎn)品和服務采購的變更審批應有回避制度。 風險評估原則 變更管理是在風險和效率之間保持平衡的一個流程，在 xxxx 信息中心 內評估風險可以從以下幾點考慮，并定期根據(jù)實際情況來修正相關表格。 由以上幾個角度可以編寫風險等級評估表。按照得分，則可以定義出變更的類型，確定其風險。 審批原則 所有 RFC 必須經(jīng)過審批之后方可實施 ，但不同類型的變更對應的執(zhí)行路徑和審批人員不盡相同。 表 31 變更審批路徑 變更請求核查 評審（含變更計劃） 實施后評審 緊急變更 變更經(jīng)理 ECAB 變更經(jīng)理 重大變更 變更經(jīng)理 CAB 變更經(jīng)理 一般 變更 變更經(jīng)理 變更經(jīng)理 變更經(jīng)理 標準變更 NA NA NA 當有多個審批人員時，排定其審批的先后次序按照行政級別自下而上逐層審批，前一級別的管理人員若未完成審批，則不轉給高一級管理人員審批。 表 32 變更通知 策略對應表 變更狀態(tài) 根據(jù)角色通知 變更發(fā)起人 變更經(jīng)理 主任 /副主任 變更實施員 草擬 請求變更 計劃中 已排程評審 已排程審批 已排程 實施中 等待 已否決 已完成 已關閉 已回退 已取消 詳細的變更通知矩陣表見附件。目標時間政策規(guī)定了幾個關鍵步驟所應該完成的時間。前導時間是基于變更路徑而定的。 前導時間設置 見表 34： 表 34 變更前導時間政策 變更類型 最少前導時間 緊急變更 30 分鐘 重大變更 15 天 重要變更 10 天 簡單變更 3 天 標準變更 NA 回退原則 當變更實施失敗或者無法在規(guī)定的時間內完成，則需要進行回退。任何回退的變更將作為變更失敗而關閉，在下一次實施前，變更發(fā)起人必須重新提交新的 變更請求單 (RFC)，以便重新進行審批。 變更計劃 包括變更的實施計劃、測試計劃、回滾計劃等，以及變更任務分配給哪些實施者 變更日程安排 變更實施的時間安排 變更實施情況 由變更實施人填寫，用于描述實施時的現(xiàn)場情況 變更測試情況 描述測試的情況、測試結果 變更觀察情況 描述變更結束后，觀察期間的情況 變更關閉狀態(tài) □完全成功 □部分成功 □取消 □拒絕 關閉時間 變更關閉的時間 關閉人 關閉人的姓名 變更管理流程設計說明書 14 變更狀態(tài)代碼 下列狀態(tài)碼表示變更請求單的生命周期中的不同階段： 表 36 變更狀態(tài)代碼 變更狀態(tài) 狀態(tài)說明 草擬中 編寫 RFC(變更請求 ) 已提交 已向變更管理提交 RFC 已審核變 更請求 RFC 通過合規(guī)性審核 已排程 審批優(yōu)先級排程 已審批 RFC 通過審批 計劃中 制定變更計劃 測試中 開發(fā)中 , 測試中 , 構建中 發(fā)布中 回滾中 , 文檔中 , 檢測中 已掛起 管理人員介入 , 供應商采購 , 進一步改進中 ,支持團隊溝通中 , 任務評估中 被拒絕 信息不完整、進度沖突 已完成 等待回顧 已關閉 成功 , 成功帶有問題 , 不成功 , 取消 已取消 不再要求 , 資源缺乏 , 需要重新安排 變更類型 變更類型決定了變更執(zhí)行的審批路徑，可分為緊急變更、重大變更、一般變更（重要變更和簡 單變更）和標準變更四類。這些變更需要通過快速路徑來迅速執(zhí)行變更（通常是非常緊急又特別重要的變更，但要注意限制性原則）。這些變更很容易執(zhí)行，失敗的風險很小。標準變更產(chǎn)生方法有兩種：列舉法、規(guī)則定義法。 規(guī)則定義法指的是將所有可以納入 標準變更的工作 匯總作為日常 實施人員的工作目錄。對于重大變更，建議由變更經(jīng)理總體負責，通過與各相關方面協(xié)同，采取多種手段（例如 CAB 會議），嚴格管理其計劃實施。 變更分類 在本項目中，將使用 二 級 分類來對變更進行分類： ? 類別（ Category） 類別是 第一級類別 。例如：硬件、系統(tǒng)軟件、網(wǎng)絡、應用軟件、數(shù)據(jù)庫。它將被用作對變更進行分組的第二層。 變更優(yōu)先級 變更優(yōu)先級代表了變更實施的不同順序。這兩個因素的定義分別如下： ? 影響度 影響度是指如果不實施變更可能對于 IT 服務的影響。 信息中心 變更緊急度判定規(guī)則如下： 表 39 變更緊急度 緊急度 要求實施時間 高 兩天內需要執(zhí)行的變更 中 七天內需要執(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) 先級可在試運行一段時間后按需進行調整） 變更關閉代碼 變更結束代碼用來表示變更實施的結果，如下表所示： 表 311 變更關閉代碼 結束代碼 描述 變更管理流程設計說明書 17 成功 變更成功實施完畢 部分成功