變更控制

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

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

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

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

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

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

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

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

解讀

由于系統(tǒng)與服務(wù)的變更往往會(huì)引起一段時(shí)間的中斷，因此在變更請(qǐng)求（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ì)劃、事前與事后的測試方案等。

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

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

在得到變更批準(zhǔn)以后，實(shí)施人員應(yīng)當(dāng)從安全的角度出發(fā)，在實(shí)施之前確立好目標(biāo)系統(tǒng)的基準(zhǔn)線，也就是俗稱的：給系統(tǒng)的當(dāng)前狀態(tài)“拍快照”。該基線既可以作為變更后參考比對(duì)的依據(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)矩陣表

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

對(duì)于各種事故或故障所導(dǎo)致的被動(dòng)變更，應(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í)，著重對(duì)于請(qǐng)求的如下方面做出了要求：

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

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

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

圖5 變更流程管理順序

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

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

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

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

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

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

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