一、資產(chǎn)和配置管理
資產(chǎn)管理是對購買價格超過一定限額的資產(chǎn)進行監(jiān)控的一套會計核算過程，它記錄了購買價格、折舊、所屬業(yè)務單元和所處位置等信息。一套有效的資產(chǎn)管理系統(tǒng)，應該可以為建立配置管理系統(tǒng)提供基礎。
資產(chǎn)管理流程的管理和控制目標，偏重于從公司財務視角，而非IT管理視角來對資產(chǎn)進行管理。固定資產(chǎn)管理程序包括對固定資產(chǎn)采購計劃、采購申請、安裝調(diào)試、成本計價、折舊計提、在建工程轉(zhuǎn)固定資產(chǎn)、轉(zhuǎn)固定資產(chǎn)驗收、保管維修、維修費用資本化、拆拼和內(nèi)部調(diào)撥、報廢、閑置處理、對外出租出借及會計核算等各項工作的具體管理規(guī)程。
配置管理需要識別和確認系統(tǒng)的配置項記錄和報告配置項狀態(tài)和變更請求、檢驗配置項的正確性和完整性等活動構(gòu)成的服務管理過程。
配置管理超越了資產(chǎn)管理，它保留了有關配置項的技術信息、配置項相互關系的詳細信息，以及配置項的標準化和授權(quán)狀況等方面的信息。
配置管理還監(jiān)控對當前信息的反饋，如IT組件的狀態(tài)、位置，以及對其實施了的變更。資產(chǎn)和配置管理的關鍵點包括：
(1)配置管理的目標。好的配置管理不僅能體現(xiàn)單個個體的屬性信息，而且能夠體現(xiàn)IT組件之間的影響，并且為其他變更管理、事件管理和問題管理等流程提供足夠的基礎信息。1)提供IT基礎架構(gòu)的精確信息。
2)監(jiān)控和維護下列信息，從而實現(xiàn)對基礎架構(gòu)的控制：
·交付服務所需要的所有資源；
·配置項（CI)的狀態(tài)和歷史；
·配置項的關系。
(2)固定資產(chǎn)管理相關流程。固定資產(chǎn)管理的一些需要考慮和定義的關鍵流程如下：
·資產(chǎn)采購；
資產(chǎn)變更；
資產(chǎn)盤點；
資產(chǎn)租入租出；
資產(chǎn)報廢流程。
(3)資產(chǎn)管理相關文件。資產(chǎn)管理的常用文件定義如下：
·固定資產(chǎn)采購申請表；
固定資產(chǎn)采購合同；
固定資產(chǎn)設備簽收單；
數(shù)據(jù)中心固定資產(chǎn)臺賬；
固定資產(chǎn)盤點清單；
閑置固定資產(chǎn)明細表；
固定資產(chǎn)出門記錄；
固定資產(chǎn)盤點報告。
(4)配置管理數(shù)據(jù)庫（CMDB)。配置管理數(shù)據(jù)庫是指包括所有與配置項及其狀態(tài)和相互關系有關的信息的數(shù)據(jù)庫。配置管理數(shù)據(jù)庫對所有組件、組件的不同版本和狀態(tài)，以及組件之間的相互關系進行跟蹤。在其最基本的形式下，一個CMDB可能是由一些紙質(zhì)表格或一套清單組成。
(5)配置管理考慮的因素。對于配置管理廣度和深度的確定，直接決定了配置管理未來的管理控制是否有效。如果廣度太廣，把關鍵資產(chǎn)和非關鍵資產(chǎn)全部納入其中管理，可能會比較難于管理和控制。對于配置管理深度，如果定義太細，如一個設備配置項定義到網(wǎng)卡級別，則未來的管理成本也是極大的。配置管理工具的選擇，如自動發(fā)現(xiàn)等工具，可以有效幫助配置管理工具的上線。同時，實施變更管理中，將配置項目的變化納入其中，確保變更結(jié)束前，配置是被確認更新的，也將有效幫助配置管理的有效落地。下面是一些常見的配置管理考慮的因素：
配置管理的廣度；
配置管理的深度；
配置項之間關聯(lián)關系；
配置管理工具的選擇；
配置管理與變更管理的綁定。
數(shù)據(jù)中心安全管理，是通過對數(shù)據(jù)中心安全管理組織、基礎環(huán)境安全、信息技術安全的制定和實施，來確保數(shù)據(jù)中心的信息安全、技術安全和物理安全。
3)數(shù)據(jù)中心信息技術安全。包括資產(chǎn)安全管理、通信安全管理、網(wǎng)絡安全管理、系統(tǒng)安全管理、數(shù)據(jù)安全管理、軟件開發(fā)安全和數(shù)據(jù)中心權(quán)限安全
10)若人力、資源情況等條件許可，應規(guī)定所有與數(shù)據(jù)中心相關的信息資產(chǎn)的安全級別，并制訂與其安全級別相對應的保護措施。
1)崗位設置。應設立信息安全管理工作的職能部門，設立安全主管、安全管理各個方面的負責人崗位，并定義各負責人的職責；應設立系統(tǒng)管理員、網(wǎng)絡管理員和安全管理員等崗位，并定義各個工作崗位的職責；建立由董事會、高級管理層負責、相關各部門負責人及內(nèi)部專家參與的數(shù)據(jù)中心信息安全領導協(xié)調(diào)機制；應制定文件明確安全管理機構(gòu)各個部門和崗位的職責、分工和技能要求。
2)人員配備。應配備一定數(shù)量的系統(tǒng)管理員、網(wǎng)絡管理員和安全管理員等；應配備專職安全管理員，實行A、B崗制度，不可兼任其他崗位；關鍵事務崗位應配備多人共同管理。
3)授權(quán)和審批。應根據(jù)各個部門和崗位的職責明確授權(quán)審批事項、審批部門和批準人等；應針對系統(tǒng)變更、重要操作、物理訪問和系統(tǒng)接入等事項建立審批程序，按照審批程序執(zhí)行審批過程，對重要活動建立逐級審批制度；應定期審查審批事項，及時更新需授權(quán)和審批的項目、審批部門和審批人等信息；應記錄審批過程并保存審批文檔；用戶應被授予完成所承擔任務所需的最小權(quán)限，重要崗位的員工之間應形成相互制約的關系。權(quán)限變更應執(zhí)行相關審批流程，并有完整的變更記錄；應建立系統(tǒng)用戶及權(quán)限清單，定期對員工權(quán)限進行檢查核對，發(fā)現(xiàn)越權(quán)用戶要查明原因并及時調(diào)整，同時清理過期用戶權(quán)限，做好記錄歸檔。
4)溝通和合作。應加強各類管理人員之間、組織內(nèi)部機構(gòu)之間，以及信息安全職能部門內(nèi)部的合作與溝通，定期或不定期召開協(xié)調(diào)會議，共同協(xié)作處理信息安全問題；應加強與兄弟公司、國家信息安全中心、公安機關、電信和網(wǎng)通等ISP公司的合作溝通以及應急協(xié)調(diào)機制，有效處置網(wǎng)絡與信息安全事件；應加強與供應商、業(yè)界專家、專業(yè)的安全公司及安全組織的合作與溝通，增強日常安全防護、突發(fā)事件處置和故障處理等方面的能力；應建立外聯(lián)公司聯(lián)系列表，包括外聯(lián)公司名稱、合作內(nèi)容、聯(lián)系人和聯(lián)系方式等信息；應關注和參加行業(yè)內(nèi)信息安全研討，學習更新安全知識和理念；應聘請信息安全專家作為常年的安全顧問，指導信息安全建設，參與安全規(guī)劃和安全評審等。
5)審核與檢查。安全管理員應負責定期進行安全檢查，檢查內(nèi)容包括系統(tǒng)日常運行、系統(tǒng)漏洞和數(shù)據(jù)備份等情況；應由內(nèi)部人員或?qū)徲嫻径ㄆ谶M行全面安全檢查，至少每年開展一次數(shù)據(jù)中心全面安全檢查，檢查內(nèi)容包括現(xiàn)有安全技術措施的有效性、安全配置與安全策略的一致性、安全管理制度的執(zhí)行情況等；內(nèi)部審計部門應至少每兩年對數(shù)據(jù)中心開展一次審計，審計內(nèi)容至少包括相關管理制度的完備性及其執(zhí)行的有效性，相關操作流程的合理性與合規(guī)性，信息安全保障體系的完備性和有效性，信息安全風險管理、規(guī)劃實施、信息系統(tǒng)運行的安全性及重要客戶信息和數(shù)據(jù)的安全性、應急管理、外包管理的有效性、SLA執(zhí)行情況，以及其他重要信息安全保障的情況；評估和管理第三方公司或外包項目的安全。
事件管理的目標就是在出現(xiàn)事件時盡可能快地恢復服務的正常運作，避免其造成業(yè)務中斷，把對業(yè)務的負面影響降為最低，以確保服務質(zhì)量和可用性滿足服務等級協(xié)議（Service-Level Agreement，SLA）中定義的正常服務級別。為了實現(xiàn)這個目標，事件管理流程必須最佳地利用資源支持業(yè)務、開發(fā)和維護有效的事件記錄，以及設計和應用統(tǒng)一的事件報告方法。
三、事件管理
所謂事件是指可能會導致服務中斷或服務質(zhì)量下降的，不屬于標準服務的事件。事件不僅包括了與軟件和硬件有關的錯誤，還包括服務請求。
事件管理不是找到引起系統(tǒng)異常的根本原因，而是盡快恢復系統(tǒng)業(yè)務功能，找到異常根本原因是問題管理流程的目的。
事件管理的主要任務是及時識別并跟蹤發(fā)生的事件；對事件進行分類并提供初步支持；對事件進行調(diào)查分析，識別引發(fā)事件的潛在原因；解決事件并恢復服務；跟蹤和監(jiān)督所有事件的解決過程，并隨時進行溝通。因此，研究事件管理對解決目前IT運維中存在的服務問題具有重要的意義，事件管理的時效性將直接影響整個企業(yè)的IT服務質(zhì)量和整體運營狀況。
事件管理的關鍵點包括：
1、事件記錄
事件管理記錄詳細的事件信息，如事件發(fā)生的時間、受事件影響的服務等。這樣做的目的是便于確認事件的影響，問題管理可以根據(jù)這些信息查找事件原因，密切跟蹤事件進展。通過系統(tǒng)監(jiān)測工具在事件數(shù)據(jù)庫中自動生成基本事件記錄是理想的解決方案。相關配置項的表征、基本診斷數(shù)據(jù)以及信息，在診斷以及記錄階段都應該包括在事件記錄中。
在大多數(shù)情況下，事件會由服務臺進行記錄，所有的事件都應該被迅速記錄下來。要避免對同一事件進行重復記錄的情況出現(xiàn)。因此在記錄某一事件時，需要進行一項檢查來確定是否已有相似的記錄。
2、事件分類
事件分類的目的是為了確定事件的來源以便采取相應行動，盡可能快地恢復用戶的正常工作，盡量避免或者減少事件IT服務質(zhì)量的影響。一般來說，許多事件是重復出現(xiàn)的，因此，當某個事件再次出現(xiàn)時，只需要根據(jù)已有的經(jīng)驗和措施采取行動即可。當新的事件出現(xiàn)時，就有一個與其問題和知名錯誤（知識庫）相匹配的過程，如果匹配成功就可直接用已有的方案將其解決，而不需要進一步調(diào)查，否則就要繼續(xù)進行下面提到的其他幾個步驟。
ITIL中通常都將事件采取三級分類機制：分類、子分類及項目?？梢愿鶕?jù)所報告的事件的故障情況，對事件進行分類（為事件指派類型）。根據(jù)事件的類型、狀態(tài)、影響度、緊急度、優(yōu)先級、SLA等來對其進行編碼，由此向用戶提供建議來解決或處理問題，哪怕這些建議僅僅是臨時性的。
3、事件狀態(tài)定義
事件狀態(tài)反映了其在整個生命周期中的當前狀態(tài)，有時候指其在事件工作流中的位置。任何人都應該意識到每個事件的狀態(tài)以及它所代表的含義。通常情況下，事件狀態(tài)的例子有：新建；已接收；已計劃；已分配/已指派給專業(yè)人員；激活狀態(tài)；已暫停；已解決；已終止。
4、事件級別定義
在確定事件的類別后，需要確定事件的優(yōu)先級，以確保支持小組對問題予以足夠的關注。決定事件級別的要素主要有三個，分別是影響度（Impact）、緊急度（Urgency）和處理優(yōu)先級（Priority）。影響度是指就所影響的用戶或業(yè)務數(shù)量而言，事件偏離正常服務級別的程度；緊急度是在解決故障時，對用戶或業(yè)務來說可接受的耽擱時間；優(yōu)先級是根據(jù)影響度和緊急度決定了處理事件和問題的先后順序，優(yōu)先級通常用一個數(shù)字來表示，優(yōu)先級=緊急度×影響度。
5、事件診斷處理
經(jīng)過事件的查明和記錄，對事件進行初步診斷后通過技術或管理手段快速恢復。事件管理的目標首先是快速解決問題，恢復業(yè)務的正常運作，而不是尋找問題的根本原因。對于未出現(xiàn)過的事件，一線人員無法解決，則盡快啟動事件升級，目標依然是快速恢復系統(tǒng)和服務。過程中往往會采用變通的解決方案（Workaround）。對于事件發(fā)生的原因暫時無法找到，該事件需要升級為問題管理，通過問題管理的方式追蹤問題發(fā)生的根本原因（Root Cause）直至問題被徹底解決，不再重復發(fā)生，這部分屬于問題管理范疇。
6、事件升級機制
對于事件不能在規(guī)定的時間內(nèi)由一線支持小組解決，那么更多的有經(jīng)驗的人員和有更高權(quán)限的人員將不得不參與進來，這就是升級。它可能發(fā)生在事件解決過程的任何時間和任何支持級別。升級分為職能升級和管理升級。
（1）職能升級：需要具有更多時間、專業(yè)技能或接入特權(quán)（技術機構(gòu)）的人員來參與事件的解決。這種升級可能會超越部門界限而且可能會包括外部支持者。
（2）管理升級：當經(jīng)授權(quán)的當前級別的機構(gòu)不足以保證事件能及時、滿意的得到解決時，需要更高級別的機構(gòu)參與進來。
7、事件關閉
事件解決和恢復服務后，事件到達關閉階段，這個階段要跟用戶確認事件解決是否成功。在事件解決后，要確保所有的事件信息都得到了更新并準確被記錄；同時根據(jù)事件產(chǎn)生的根本原因?qū)κ录姆诸愡M行調(diào)整；對于根本原因未找到的事件確認是否已經(jīng)轉(zhuǎn)入問題管理。在用戶同意事件解決方案和方案執(zhí)行的最終結(jié)果的基礎上，該事件可以被關閉。
事件管理關鍵點的具體實例如下：
1、數(shù)據(jù)中心事件的分類
數(shù)據(jù)中心運維過程中發(fā)生的事件種類繁多，我們主要根據(jù)故障種類以及事件定級方法，對數(shù)據(jù)中心事件進行分類。從故障角度劃分的事件包括：供配電系統(tǒng)事件、制冷系統(tǒng)事件、物理環(huán)境事件、物理安全事件、監(jiān)控系統(tǒng)、網(wǎng)絡故障、IT系統(tǒng)故障、自然災害等；結(jié)合事件定級因素，將事件分為一級、二級、三級和四級等不同的等級。有的企業(yè)會劃分為三級，有的企業(yè)會劃分為五級。表1是事件分類的一個具體實例。讀者可以參考下面的分類實例，根據(jù)自己的情況進行事件分類的定義和等級劃分。在實際事件分類中，沒有統(tǒng)一的強制標準，是由具體的業(yè)務和管理要求決定的。讀者可以根據(jù)定級的標準，去枚舉所屬數(shù)據(jù)中心的具體分級事件的例子。
表1 數(shù)據(jù)中心事件定級分類實例
級別 | 狀態(tài)描述 |
一級事件 | 關鍵服務中斷，影響SLA的達成 |
二級事件 | 關鍵服務組件出現(xiàn)故障，導致不滿足冗余條件或服務水平下降，有潛在影響SLA的可能性 |
三級事件 | 非關鍵服務組件故障，不影響SLA的達成 |
四級事件 | 非關鍵服務的質(zhì)量下降，造成輕微影響或影響可以忽略 |
一級事件舉例：用戶可以根據(jù)自身數(shù)據(jù)中心的情況，定義具體的事件場景，便于判斷。
（1）供電系統(tǒng)：整套供電系統(tǒng)癱瘓（雙路市電供電中斷、UPS供電中斷及發(fā)電機無法正常啟動），導致電力中斷。
（2）制冷系統(tǒng)：多臺精密空調(diào)服務中斷，導致溫度、濕度超出SLA承諾閾值。
（3）物理環(huán)境：大面積的滲水漏水，導致客戶機房出現(xiàn)嚴重安全隱患。
（4）物理安全：出現(xiàn)恐怖襲擊或者有針對性的破壞而導致客戶服務中斷。
（5）自然災害：數(shù)據(jù)中心無法提供保障數(shù)據(jù)中心正常運營能力的物理指標、地震、洪水、臺風、戰(zhàn)爭等。
2、數(shù)據(jù)中心事件的升級
數(shù)據(jù)中心事件可以根據(jù)處理的不同情況，在不同的運維團隊間進行升級，表2是數(shù)據(jù)中心事件升級定義的一個實例，讀者可以參考下面的升級實例，根據(jù)自己的情況進行升級的定義和劃分，在實際事件升級中，沒有統(tǒng)一的強制標準，是由具體的業(yè)務和管理要求決定的。
表2 數(shù)據(jù)中心事件升級定義實例
| 運維人員 | 三級事件 | 二級事件 | 一級事件 |
現(xiàn)場工程師 | 5min報告現(xiàn)場經(jīng)理 | 5min報告現(xiàn)場經(jīng)理 | 5min報告現(xiàn)場經(jīng)理 |
機房經(jīng)理/客服經(jīng)理 | 10min報告事件管理經(jīng)理、客服經(jīng)理 | 10min報告事件管理經(jīng)理、客服經(jīng)理 | |
事件經(jīng)理 | 15min報告運維總監(jiān) | 15min報告運維總監(jiān) | |
運維總監(jiān) | 30min報告運維總監(jiān) | 15min報告運維副總裁 | |
運維副總裁 | 15min報告運維總監(jiān) |
目標值 | 一級事件 | 二級事件 | 三級事件 | 四級事件 |
響應時間/min | 5 | 5 | 15 | 15 |
派單時間/min | 10 | 15 | 15 | 15 |
接單時間/min | 15 | 60 | 工作時間 | 工作時間 |
管理升級時間 | 5 | 15 | N/A | N/A |
技術升級時間 | 15 | 30 | 12h | 24h |
解決時間 | N/A | N/A | N/A | N/A |
對于超越一級事件的重大影響事件，如對客戶業(yè)務產(chǎn)生重大影響，嚴重影響合約的履行，有重大法律和商務風險的事件，建議高級管理層的參與，公關媒體的參與，與客戶一起做危機處理。
3、數(shù)據(jù)中心事件的記錄
數(shù)據(jù)中心事件的各種相關信息都要被及時記錄下來，一般都應該記錄在后臺系統(tǒng)里面，并且以工單的形式在各處理環(huán)節(jié)中進行傳遞。數(shù)據(jù)中心事件記錄包括很多相關信息，表3是數(shù)據(jù)中心事件記錄的一個實例，讀者可以參考下面的事件記錄實例根據(jù)自己的情況進行事件記錄信息的定義和劃分，在實際事件記錄中，沒有統(tǒng)一的強制標準，是由具體的業(yè)務和管理要求決定的。
表3 數(shù)據(jù)中心事件記錄定義實例
| 項目 | 描述 |
事件名稱 | 事件的名字 |
嚴重級別 | 事件的嚴重級別 |
優(yōu)先級 | 事件的優(yōu)先級別 |
生成時間 | 事件產(chǎn)生的時間 |
重復次數(shù) | 事件發(fā)生的重復次數(shù) |
擁有人 | 事件處理擁有人 |
描述 | 事件的描述 |
開始時間 | 當前事件開始時間 |
結(jié)束時間 | 當前事件結(jié)束時間 |
第一次發(fā)生時間 | 事件第一次發(fā)生時間 |
最后一次發(fā)生時間 | 事件最后一次發(fā)生時間 |
狀態(tài) | 當前事件實際狀態(tài) |
事件ID號 | 事件ID號 |
事件顯示數(shù) | 事件計數(shù) |
計數(shù)器名 | 計數(shù)器名 |
實例名 | 實例名 |
事件數(shù)據(jù) | 事件數(shù)據(jù)內(nèi)容 |
四、數(shù)據(jù)中心問題管理（Problem Management)
問題管理的目標是找出突發(fā)事件產(chǎn)生的根本原因，最小化由于IT基礎架構(gòu)錯誤引起的突發(fā)事件和問題的負面影響，防止與錯誤相關的突發(fā)事件的再次發(fā)生。通過實施主動問題管理，在事件發(fā)生之前發(fā)現(xiàn)問題并解決，從而減少事件發(fā)生的數(shù)量。
問題是導致一個或多個事件的根本原因，而這些根本原因還沒有診斷出來。事件管理強調(diào)在給用戶和公司的正常業(yè)務活動帶來最小影響的情況下，盡快恢復到SLA中定義的正常服務級別。采取任何可能的方法，包括一個臨時解決方案（應急措施）來快速地解決事件，盡可能確保最好的服務質(zhì)量和可用性。與事件管理強調(diào)速度不同，問題管理則注重診斷事件的根源，確定問題的根本原因，從而制定恰當?shù)慕鉀Q方案，從根本上解決問題，防止類似事件的再次發(fā)生。事件管理為了盡可能快地恢復服務，往往會采用臨時解決方案，問題管理比起事件管理則會花費更長的時間。
(1)問題的識別和記錄。原則上，任何一個由未知原因引起的事件都與某個問題有關。問題的識別通常會發(fā)生在以下情況：在事件管理流程中沒有問題或已知錯誤來匹配事件；通過分析發(fā)現(xiàn)該事件又再次發(fā)生了，或者發(fā)生了重大事件；事件不能與現(xiàn)有問題或已知錯誤相匹配；通過對IT基礎設施的分析識別出導致事件的問題。
問題記錄和事件記錄一樣都被記錄在配置管理數(shù)據(jù)庫（Configuration Management Database,CMDB)中，問題記錄會跟所有有關聯(lián)的事件記錄關聯(lián)在一起。事件的解決方案以及臨時解決方案的細節(jié)都應該被記錄在問題記錄中而不是事件記錄中，以便它們可以用于將來有關聯(lián)的事件中。
(2)問題的診斷和處理。通過問題診斷成功獲取問題的根本原因并找到解決途徑后，該問題將轉(zhuǎn)變?yōu)橐粋€已知錯誤。問題調(diào)查除了與事件調(diào)查的目標不同外，其流程類似。事件調(diào)查的主要目的是為了恢復服務的正常運作，而問題管理則是為了確定問題的根源。
在事件調(diào)查期間所采用的任何應急措施，都應該在問題調(diào)查階段考慮，如果有必要的話，在問題記錄中還要更新與已知錯誤、解決方案和應急措施相關的信息。
一旦診斷出配置項中的故障，那么該問題狀態(tài)被轉(zhuǎn)變?yōu)橐阎e誤，然后開始進行錯誤控制。當一個問題被診斷為一個程序錯誤而不是配置項故障時，記錄應該被更新為正確的代碼然后關閉該問題，通常這樣的問題不會轉(zhuǎn)化成已知錯誤。
3)管理角度還可以再細分。如人員問題中可以細分為人員執(zhí)行力問題、人員技能問題、人員責任心問題及職責不清問題等。
問題的分類不是固定的，而是在問題的生命周期內(nèi)可能發(fā)生變化的，問題管理的核心就是將問題多維度、多視角深度剖析，找出管理上、架構(gòu)上的“短板”，從根本上去解決，這樣才可以使得問題管理真正在IT管理或數(shù)據(jù)中心管理中發(fā)揮作用。在數(shù)據(jù)中心的管理中，問題管理通常因為沒有事件管理、變更管理那么直接影響服務的可用性而被忽視，使得遺留下來的問題沒有被及時解決，也會導致事件的重復發(fā)生，從而降低系統(tǒng)和服務的整體可用性。
五、數(shù)據(jù)中心變更管理(ChangeManagement)
數(shù)據(jù)中心的變更管理，是為在最短的中斷時間內(nèi)完成基礎架構(gòu)的任一方面的變更，而對其進行控制的服務管理過程。這里所指的變更，,是指在維護過程中對系統(tǒng)或服務所做的各種改變。包括增補、移除和其他修改。
變更管理的目的，是確保以受控的方式去評估、批準、實施和評審所有變更，確保標準方法和過程可以得到使用。阻止未授權(quán)的變更發(fā)生，使得變更風險可以降至最低，同時將變更相關突發(fā)事件的影響減到最小，并且確保所有變更都必須可跟蹤和可追溯。
變更請求是指對一個或多個特定設備或系統(tǒng)實施變更的正式請求，說明了變更的內(nèi)容及與變更有關的配置項。變更請求只是為了請求對基礎架構(gòu)進行變更的機制，它必須包括變更所需要的必要信息以便評審、批準和創(chuàng)建。由于并不是每一個修改請求都像變更一樣處理，也致使變更可以分為標準變更和非標準變更兩種。
(2)變更顧問委員會。變更委員會定期會合，對較大以上變更進行評估審核，并擬定相應計劃，變更委員會應當從業(yè)務和技術兩個角度充分評估變更的影響，變更委員會不能批準變更請求，只是給出相關意見。其成員是靈活的，這取決于變更請求，可以包括任何從商業(yè)和技術角度來看都能確保變更被充分評估的人員，可以包括:變更經(jīng)理(主席和常任成員)、技術專家/顧問、客戶經(jīng)理和用戶組代表、開發(fā)人員和供應商。
(3)變更種類。變更通常按照兩種方式進行分類:一種是基于變更類型進行分類，該分類的方式類似于事件分類，用于區(qū)分變更的類型；另一種是基于變更的影響程度，來定義變更的級別，用以確認變更的審核矩陣。如重大變更、較大變更、一般變更和標準變更。根據(jù)變更的緊急程度，又分為計劃性變更和緊急變更。
(4)變更審批。不同的變更有不同的審批流程和審核矩陣。對于重大的變更，需要CAB來審核。其中除了技術風險評估，還會涉及到財務和業(yè)務的評估。對于較大變更，可以是變更經(jīng)理和變更相關部門負責人來審核確定。對于一般變更或者標準變更，則可以根據(jù)預先定義好的相關流程進行備案即可。變更的定級和授權(quán)對于變更是否可以在企業(yè)里被很好地執(zhí)行非常相關。如果太多的變更需要走復雜的審批流程，管理成本大，流程效率低下，也會使得變更發(fā)起者不愿意走變更流程，導致變更風險無法被有效管控。
3)業(yè)務審批。確保業(yè)務經(jīng)理同意建議的變更，同時變更對業(yè)務產(chǎn)生的影響能令他們]滿意。
(1)數(shù)據(jù)中心變更的定級。根據(jù)變更風險,的高低，數(shù)據(jù)中心的典型變更級別分為重大變更、較大變更、一般變更及標準變更四個級別。變更定級方法見下表。用戶可以根據(jù)自己的情況進行變更的定級劃分，在實際變更定級中，沒有統(tǒng)一的強制標準，而是由具體的業(yè)務和管理要求決定。
(2)數(shù)據(jù)中心變更的分類。根據(jù)所要變更的基礎架構(gòu)的特點，數(shù)據(jù)中心變更可以分為物理環(huán)境類變更、基礎設施類變更、IT設備類變更、施工類變更、IT系統(tǒng)類變更、網(wǎng)絡線路類變更以及資產(chǎn)類變更幾類。為了在實施中把中斷業(yè)務或服務的時間減少到最小，要對變更請求進行審批，確定變更的優(yōu)先級，再進行變更操作。不同類別的變更參照變更定級標準進行定級。讀者可以根據(jù)自己的情況進行變更分類的劃分，在實際變更分類中，沒有統(tǒng)一的強制標準，而是由具體的業(yè)務和管理要求決定。
