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