在企業的運維管理過程中，很多時候會有變更產生。這些變更通常來源于基礎設施的升級，容量管理、可用性管理、軟件更新、新服務的推出，服務級別目標的變化等等。這些變更在執行中常常會引發以下一系列的負面影響。
- 一個小小的變更引起了一個重大的故障。
- 一個變更進行中發現沒有足夠的資源可被使用來繼續完成此變更。
- 緊急變更數量太大，導致團隊成員疲于應付
- 在業務窗口時間執行變更，導致業務時間段內業務中斷
- 一個變更未能在規定時間內完成或是雖然變更已完成，卻效果不佳。此時發現此變更無法回滾。
場景一： 合理的變更分類的意義
場景描述：
某個IT服務提供商已經實現了變更管理流程，在運營一段時間后，經常有客戶抱怨說，他們提交的變更審批得很慢，特別是一些緊急情況下的變更。更讓客戶難以接受的是，對于那些簡單的低風險的變更也同樣也需要等待很長時間才能夠被正式受理和審批。我們如何來改進這種現狀呢？
解決方法：
作為變更管理最主要的目的是讓企業的IT服務穩定性提高并控制風險，但這需要在穩定性和靈活性之間做一個平衡。場景中的情形就是缺乏靈活性的表現。為了提高該企業的變更受理與執行的效率，通常變更管理實施的第一步是先對變更請求進行分類，在風險和效率之間達到一種權衡，從而提高執行變更的靈活性，最終達到提高客戶滿意度目的。
- 對于那些風險低的，影響度低的，而且是經常會發生的變更，如：新入職員工開設系統賬號、為他們開通郵件服務等。我們可以定義為標準變更：此類變更跳過繁瑣的審批與評估過程，把變更的受理與執行權預先授予某一個職能單元，如：服務臺。這樣提高了此類變更執行的效率，必定會提升客戶對于此類變更執行的滿意度。
- 對于那些非常緊急的變更，由于時間上不允許有過多的拖延，并且不可能有太多的時間用于審批甚至是測試，我們定義為緊急變更。對于這些變更我們直接直接由專家來執行，優先級設成最高級，馬上召開CAB/EC（緊急變更顧問委員會）進行評估和直接獲得最高級授權，直接獲得變更執行的相關資源，有效減少變更掛起的時長。從時間上縮短了受理與審批的周期。
- 對于兼顧風險和效率的變更我們定義為正常變更，并根據影其響度劃分為不同的等級（如：Minor、Significant、Major等）。對于Minor類型的變更直接由變更經理審批，而不需要由CAB會議審批，Significant類型分配給周期性的CAB會議，定義為Major類型的通常是高風險、高影響度的，直接由管理層來進行審批和評估。通過這樣的分類能有效地進行風險控制，從而達到提高變更成功率的目的。
總結：由于有了一系列的分類，針對不同的變更給予不同的處理過程，避免了之前的所有變更都采用相同的處理方式。實行一段時間后，客戶滿意度將有顯著的提高。
場景二： 變更導致故障
場景描述：
某企業在周一業務繁忙時段上線了一個新的應用——客戶關系管理系統，此系統安裝在某一臺主機上，此主機之前一直正常運行著另一套系統——備件采購管理系統。升級完以后發現客戶關系管理系統能夠正常服務，但原有的備件采購管理系統無法登錄，導致當天上午采購管理系統這個應用癱瘓。IT技術團隊經過一個上午的努力排除了故障，找出了原因，并恢復了服務。但業務部門對IT卻提出了嚴重指責，從管理的角度來思考，你更關注那個方面呢？問題何在？
解決辦法：
從技術的角度上來說，是由于之前主機上安裝了一套采購管理系統，使用的是SQL Server數據庫，并且默認都是用sa帳號登錄。新的應用同樣使用SQLServer數據庫，新系統使用的數據庫也是SQLServer數據庫，并且后臺登錄用戶名也是使用了和采購管理系統相同的用戶名sa，但密碼不同，在安裝新應用的過程中修改了原先的sa密碼，所以導致原有的備件采購管理系統無法正常啟動。
從管理的角度上來說，變更的執行需要在適當的時間做，也就是說我們要選擇一個變更窗口，在這個時間內這樣就不會影響到業務或是對業務影響最小。變更窗口設在什么時間段呢？很容易想到就是下班后或是雙休日，絕對不會是像周一這樣的業務繁忙時段。這個新應用的安裝最多也就在2小時內可以完成，可選的時間段非常多。所以以上企業的問題是在非變更窗口時間執行變更，導致現有的服務受到影響而中斷。所以每一個正常變更在評估變更時就要考慮到變更的影響度，預先設定好變更窗口。這樣才能保證業務的正常運作。
場景三： 把緊急變更比例控制在合理的區間
場景描述：
某個制造企業緊急變更的數量占變更總數量的80%。很多情況下由于緊急變更沒有足夠的時間來進行評估與測試，數量多的話會導致IT的穩定性降低。所以應該嚴格控制緊急變更的數量和比例，從而減少變更的不確定因素。對于此種現狀，如何應對和改善？
解決辦法：
緊急變更80%明顯高得離譜。首先找到這類緊急變更的具體原因是什么，案例中發現，這些緊急變更都來源于同一個分類，都是關于一個生產管理系統的軟硬件的緊急變更。很多人認為此生產管理系統非常重要，如果存在問題執行一系列的緊急變更也是沒有辦法。但誰又能保證如此多的緊急變更能真正解決現有的故障率呢？緊急變更量大反而會使得系統更不穩定。就好比是拆東墻補西墻。
對于每一個重大變更都做好充分的評估與測試工作，這樣可以避免在重大變更發布后，再跟進很多修補的緊急變更。
在重大變更時設定一段試運行期，如果試運行評價報告不夠好，或是不滿足當初評估的預期，可以考慮回滾，只有評估滿足預期并穩定運行的變更，才會被變更。
總結：需要對緊急變更的數量和比例做好嚴格的控制，從而保證變更的穩定性。
