在企業(yè)的運維管理過程中，很多時候會有變更產(chǎn)生。這些變更通常來源于基礎設施的升級，容量管理、可用性管理、軟件更新、新服務的推出，服務級別目標的變化等等。這些變更在執(zhí)行中常 常會引發(fā)以下一系列的負面影響。

1. 一個小小的變更引起了一個重大的故障。 

2. 一個變更進行中發(fā)現(xiàn)沒有足夠的資源可被使用來繼續(xù)完成此變更。 

3. 緊急變更數(shù)量太大，導致團隊成員疲于應付。 

4. 在業(yè)務窗口時間執(zhí)行變更，導致業(yè)務時間段內業(yè)務中斷。 

5. 一個變更未能在規(guī)定時間內完成或是雖然變更已完成，卻效果不佳。此時發(fā)現(xiàn)此變更無法回滾。

場景一：合理的變更分類的意義

場景描述：

某個 IT 服務提供商已經(jīng)實現(xiàn)了變更管理流程，在運營一段時間后，經(jīng)常有客戶抱怨說，他們提交的 變更審批得很慢，特別是一些緊急情況下的變更。更讓客戶難以接受的是，對于那些簡單的低風險 的變更也同樣也需要等待很長時間才能夠被正式受理和審批。我們如何來改進這種現(xiàn)狀呢？

解決方法：

作為變更管理最主要的目的是讓企業(yè)的 IT 服務穩(wěn)定性提高并控制風險，但這需要在穩(wěn)定性和靈活性 之間做一個平衡。場景中的情形就是缺乏靈活性的表現(xiàn)。為了提高該企業(yè)的變更受理與執(zhí)行的效率， 通常變更管理實施的第一步是先對變更請求進行分類，在風險和效率之間達到一種權衡，從而提高 執(zhí)行變更的靈活性，最終達到提高客戶滿意度目的。 

對于那些風險低的，影響度低的，而且是經(jīng)常會發(fā)生的變更，如：新入職員工開設系統(tǒng)賬號、為 他們開通郵件服務等。我們可以定義為標準變更：此類變更跳過繁瑣的審批與評估過程，把變更的受理與執(zhí)行權預先授予某一個職能單元，如：服務臺。這樣提高了此類變更執(zhí)行的效率，必定 會提升客戶對于此類變更執(zhí)行的滿意度。 

對于那些非常緊急的變更，由于時間上不允許有過多的拖延，并且不可能有太多的時間用于審批 甚至是測試，我們定義為緊急變更。對于這些變更我們直接直接由專家來執(zhí)行，優(yōu)先級設成最高 級，馬上召開 CAB/EC（緊急變更顧問委員會）進行評估和直接獲得最高級授權，直接獲得變更執(zhí) 行的相關資源，有效減少變更掛起的時長。從時間上縮短了受理與審批的周期。 

對于兼顧風險和效率的變更我們定義為正常變更，并根據(jù)影其響度劃分為不同的等級（如：Minor、 Significant、Major 等）。對于 Minor 類型的變更直接由變更經(jīng)理審批，而不需要由 CAB 會議審 批，Significant 類型分配給周期性的 CAB 會議，定義為 Major 類型的通常是高風險、高影響度 的，直接由管理層來進行審批和評估。通過這樣的分類能有效地進行風險控制，從而達到提高變 更成功率的目的。

總結：由于有了一系列的分類，針對不同的變更給予不同的處理過程，避免了之前的所有變更都采 用相同的處理方式。實行一段時間后，客戶滿意度將有顯著的提高。

場景二：變更導致故障

場景描述：

某企業(yè)在周一業(yè)務繁忙時段上線了一個新的應用——客戶關系管理系統(tǒng)，此系統(tǒng)安裝在某一臺主機 上，此主機之前一直正常運行著另一套系統(tǒng)——備件采購管理系統(tǒng)。升級完以后發(fā)現(xiàn)客戶關系管理 系統(tǒng)能夠正常服務，但原有的備件采購管理系統(tǒng)無法登錄，導致當天上午采購管理系統(tǒng)這個應用癱 瘓。IT 技術團隊經(jīng)過一個上午的努力排除了故障，找出了原因，并恢復了服務。但業(yè)務部門對 IT 卻提出了嚴重指責，從管理的角度來思考，你更關注那個方面呢？問題何在？

解決辦法： 

從技術的角度上來說，是由于之前主機上安裝了一套采購管理系統(tǒng)，使用的是 SQL Server 數(shù)據(jù)庫， 并且默認都是用 sa 帳號登錄。新的應用同樣使用 SQLServer 數(shù)據(jù)庫，新系統(tǒng)使用的數(shù)據(jù)庫也是 SQLServer 數(shù)據(jù)庫，并且后臺登錄用戶名也是使用了和采購管理系統(tǒng)相同的用戶名 sa，但密碼不同， 在安裝新應用的過程中修改了原先的 sa 密碼，所以導致原有的備件采購管理系統(tǒng)無法正常啟動。 

從管理的角度上來說，變更的執(zhí)行需要在適當?shù)臅r間做，也就是說我們要選擇一個變更窗口，在這 個時間內這樣就不會影響到業(yè)務或是對業(yè)務影響最小。變更窗口設在什么時間段呢？很容易想到就 是下班后或是雙休日，絕對不會是像周一這樣的業(yè)務繁忙時段。這個新應用的安裝最多也就在 2 小 時內可以完成，可選的時間段非常多。所以以上企業(yè)的問題是在非變更窗口時間執(zhí)行變更，導致現(xiàn) 有的服務受到影響而中斷。所以每一個正常變更在評估變更時就要考慮到變更的影響度，預先設定 好變更窗口。這樣才能保證業(yè)務的正常運作。

場景三：把緊急變更比例控制在合理的區(qū)間

場景描述：

某個制造企業(yè)緊急變更的數(shù)量占變更總數(shù)量的 80%。很多情況下由于緊急變更沒有足夠的時間來進 行評估與測試，數(shù)量多的話會導致 IT 的穩(wěn)定性降低。所以應該嚴格控制緊急變更的數(shù)量和比例，從 而減少變更的不確定因素。對于此種現(xiàn)狀，如何應對和改善？

解決辦法： 

緊急變更 80%明顯高得離譜。首先找到這類緊急變更的具體原因是什么，案例中發(fā)現(xiàn)，這些緊急變 更都來源于同一個分類，都是關于一個生產(chǎn)管理系統(tǒng)的軟硬件的緊急變更。很多人認為此生產(chǎn)管理 系統(tǒng)非常重要，如果存在問題執(zhí)行一系列的緊急變更也是沒有辦法。但誰又能保證如此多的緊急變 更能真正解決現(xiàn)有的故障率呢？緊急變更量大反而會使得系統(tǒng)更不穩(wěn)定。就好比是拆東墻補西墻。  

對于每一個重大變更都做好充分的評估與測試工作，這樣可以避免在重大變更發(fā)布后，再跟進很多 修補的緊急變更。 

在重大變更時設定一段試運行期，如果試運行評價報告不夠好，或是不滿足當初評估的預期，可以 考慮回滾，只有評估滿足預期并穩(wěn)定運行的變更，才會被變更。 

總結：需要對緊急變更的數(shù)量和比例做好嚴格的控制，從而保證變更的穩(wěn)定性。