變更控制

基礎(chǔ)要點(diǎn)

確保經(jīng)歷評估風(fēng)險(xiǎn)、授權(quán)變更和管理變更計(jì)劃的流程。

組織變更管理涉及的是人員方面；變更控制通常側(cè)重于產(chǎn)品和服務(wù)的變化。

應(yīng)由能夠了解風(fēng)險(xiǎn)和預(yù)期收益的人員進(jìn)行評估，不應(yīng)引入不必要的延誤。

標(biāo)準(zhǔn)變更：屬低風(fēng)險(xiǎn)的、預(yù)授權(quán)的變更，易于理解與記錄。初創(chuàng)變更時(shí)，應(yīng)全面評估風(fēng)險(xiǎn)、并完成授權(quán)，之后不必重復(fù)。

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

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

需要傳達(dá)有關(guān)變更的信息，以確保在變更前，涉事人員做好了充分準(zhǔn)備。

解讀

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

1.需求程度：標(biāo)準(zhǔn)、一般或緊急。

2.變更類型：操作系統(tǒng)、應(yīng)用軟件、硬件設(shè)備、網(wǎng)絡(luò)組件、通信線路、文檔目錄、配置項(xiàng)、安全相關(guān)。

3.風(fēng)險(xiǎn)預(yù)判：低、中、高。

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

5.變更時(shí)間：提議開始的時(shí)間、目標(biāo)完成的時(shí)間與耗時(shí)。

6.變更內(nèi)容：當(dāng)前狀態(tài)、更改內(nèi)容、預(yù)期目標(biāo)。

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

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

在接到變更請求后，變更管理委員會需要有針對性地對單個(gè)請求進(jìn)行風(fēng)險(xiǎn)評估。主要內(nèi)容包括：提出人員的角色、變更的合理性、時(shí)間安排、變更回報(bào)、所需資源以及對其他產(chǎn)品與服務(wù)的影響等方面。經(jīng)過集思廣益與討論磋商之后，委員會做出批準(zhǔn)還是拒絕的結(jié)論。

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

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

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

圖4 風(fēng)險(xiǎn)矩陣表

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

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

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

實(shí)務(wù)

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

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

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

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

圖5 變更流程管理順序

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

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

2.委員會成員之間共享一張“事件匯總?cè)諝v”，以方便他們?nèi)中缘馗鶕?jù)請求的時(shí)間，來判定當(dāng)日的忙閑程度，從而既能夠?qū)φ埱髮?shí)施的時(shí)間進(jìn)行微調(diào)，又能夠及時(shí)地將新批準(zhǔn)的變更，加入到總?cè)諝v的對應(yīng)時(shí)間段之中。

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

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

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

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