變更控制

基礎要點

確保經歷評估風險、授權變更和管理變更計劃的流程。

組織變更管理涉及的是人員方面；變更控制通常側重于產品和服務的變化。

應由能夠了解風險和預期收益的人員進行評估，不應引入不必要的延誤。

標準變更：屬低風險的、預授權的變更，易于理解與記錄。初創(chuàng)變更時，應全面評估風險、并完成授權，之后不必重復。

一般變更：應根據(jù)類型與既定模型來確定需要評估和授權的角色。可手動創(chuàng)建請求，也可由CI/CD 管道進行自動化加速。

緊急變更：如解決事件或部署安全補丁。應盡可能經歷與一般變更相同的測試、評估、以及授權環(huán)節(jié)，實施前可酌情推遲相關文件。由于時間受限，測試較少，因此需要由了解業(yè)務風險的高級管理人員授權。

需要傳達有關變更的信息，以確保在變更前，涉事人員做好了充分準備。

解讀

由于系統(tǒng)與服務的變更往往會引起一段時間的中斷，因此在變更請求（Request for Change，RFC）提交的過程中，我們需要圍繞著：變更什么？何時變更？變更影響？這三類問題展開。其中包括：

1.需求程度：標準、一般或緊急。

2.變更類型：操作系統(tǒng)、應用軟件、硬件設備、網絡組件、通信線路、文檔目錄、配置項、安全相關。

3.風險預判：低、中、高。

4.影響預判：單個應用系統(tǒng)、部分用戶群、職能部門范圍、多個分支站點、整個企業(yè)。

5.變更時間：提議開始的時間、目標完成的時間與耗時。

6.變更內容：當前狀態(tài)、更改內容、預期目標。

7.回滾計劃、事前與事后的測試方案等。

為了對產品和服務的變更進行有效的管理，在規(guī)范的企業(yè)中，變更請求一定要通過變更管理委員（Change Control Board，CCB）的審查與批準。該委員會的成員一般包括：企業(yè)業(yè)務部門、IT管理層、技術專業(yè)職能部門、以及外包/供應商等的代表。當然，除了固定人員角色之外，某些具體人員可根據(jù)實際變更請求的特點來動態(tài)調整。

在接到變更請求后，變更管理委員會需要有針對性地對單個請求進行風險評估。主要內容包括：提出人員的角色、變更的合理性、時間安排、變更回報、所需資源以及對其他產品與服務的影響等方面。經過集思廣益與討論磋商之后，委員會做出批準還是拒絕的結論。

在得到變更批準以后，實施人員應當從安全的角度出發(fā)，在實施之前確立好目標系統(tǒng)的基準線，也就是俗稱的：給系統(tǒng)的當前狀態(tài)“拍快照”。該基線既可以作為變更后參考比對的依據(jù)，又能夠成為回滾操作的目標。

而在變更完成后，實施人員既要及時更新配置管理數(shù)據(jù)庫（Configuration Management Data Base）里可能涉及到的配置項（CI），又要做好相應的文檔記錄，以被后期審計。

值得一提的是，如今由于虛擬化和云服務的調整所引發(fā)的變更，與傳統(tǒng)的變更管理有著不同之處，我們應當?shù)饺缦路矫妫?/p>

圖4 風險矩陣表

對于鏡像與配置模板的修改、云存儲空間池的配額、以及虛擬CPU/內存資源的增減等方面，都應做好相應的計劃與記錄工作。

對于各種事故或故障所導致的被動變更，應當根據(jù)既定的協(xié)議，與云服務商事先明確好各自的職責。

例如，在何種情況下云服務商有權先采取必要的變更、再通知租戶；在何種情況下我們的自行變更需要備案、甚至要得到服務商的批準，以免傷及其他的租戶。

實務

根據(jù)上述解讀中所提到的注意事項，我們企業(yè)在管理各項產品與服務的變更時，著重對于請求的如下方面做出了要求：

1.分清變更發(fā)起人與實施人，有時候發(fā)起變更請求的不一定是真正實施的人員。

2.根據(jù)波及范圍與緊急程度的不同，我們事先規(guī)定好了不同的顏色代碼。這樣不但方便管理委員會能夠從龐雜的記錄中一眼認出或者篩選出重大的變更需求，而且也方便引起可能涉及到的技術人員或用戶的警覺。

3.請求附件：可以附上必要的截圖、郵件或者文檔，讓變更管理者更為深入和全面地了解到該變更的來龍去脈。如果涉及到比較復雜或者大型的變更，我們還應該適當?shù)嘏渖夏荏w現(xiàn)出變更步驟以及涉及范圍的流程圖。這樣，不但有助于我們理清變更的思路和波及面，還能夠在變更后或是出現(xiàn)其他問題時，提供必要的參考與審計。

圖5 變更流程管理順序

而在變更管理委員會方面，我們踐行了如下要點：

1.為了避免頻繁的變更請求打擾、甚至拖累委員會成員的日常工作，同時也為了避免重要的變更被長期積壓，進而給服務執(zhí)行團隊造成壓力，我們在評估與審批頻率上規(guī)定為：一周舉行兩次審批例會，并分別設置在周二與周四的中午。

2.委員會成員之間共享一張“事件匯總日歷”，以方便他們全局性地根據(jù)請求的時間，來判定當日的忙閑程度，從而既能夠對請求實施的時間進行微調，又能夠及時地將新批準的變更，加入到總日歷的對應時間段之中。

3.運用現(xiàn)成的模板，向變更將要波及到的人群發(fā)送服務中斷與變更實施的相關通知。在此，我們同樣沿用在請求里規(guī)定好了不同的顏色代碼。

4.針對在實施后報告上來的變更失敗，按需引入事故或問題管理流程。

我們企業(yè)的變更管理委員會在具體審批過程中，時常會借助如圖4 的風險矩陣表。

總的說來，我們在實際操作中，參考了如圖5 的變更流程管理順序。