來源：https://www.linkedin.com/pulse/relationship-between-release-change-configuration-abhishek-srivastava
https://www.bmc.com/blogs/itil-asset-configuration-management/
https://www.bmc.com/blogs/asset-management-vs-configuration-management/
發(fā)布管理與變更和配置管理緊密結(jié)合。人們需要清楚地了解這三者之間的關(guān)系，這樣才能了解整體情況。
一、什么是發(fā)布管理?
發(fā)布管理是一個軟件管理過程，它指導(dǎo)從代碼開發(fā)到測試再到生產(chǎn)的技術(shù)工作，專注于協(xié)調(diào)各種產(chǎn)品的可交付件，這些可交付件必須作為一個集成的解決方案和結(jié)果一起工作，從而有效地交付業(yè)務(wù)所需的新的和增強(qiáng)的IT服務(wù)/功能，同時保護(hù)現(xiàn)有服務(wù)的完整性。
二、什么是變更管理?
變更管理是一個用于管理對配置管理數(shù)據(jù)庫(或CMDB中的“CIs”)中所有配置項進(jìn)行變更的計劃部署的過程，這些配置項是業(yè)務(wù)的活動(“生產(chǎn)”)環(huán)境的一部分。變更管理的目標(biāo)是確保采用標(biāo)準(zhǔn)化的方法和程序，以有效和迅速地處理所有變更，以控制IT基礎(chǔ)設(shè)施，以盡量減少任何相關(guān)事件對服務(wù)的數(shù)量和影響。
三、什么是配置管理?
配置管理(CM)是一種由標(biāo)準(zhǔn)過程和技術(shù)組成的軟件工程規(guī)程，組織經(jīng)常使用這些標(biāo)準(zhǔn)過程和技術(shù)來管理引入到其軟件產(chǎn)品中的變更。配置管理有助于識別單個元素和配置，跟蹤變更，以及版本選擇、控制和基線。它精確地回答了配置管理數(shù)據(jù)庫(或CMDB中的“CIs”)中所有配置項configuration items的誰、什么、什么時候和為什么。
四、這些學(xué)科是如何相互關(guān)聯(lián)的?
變更管理Change management 提供授權(quán)和跟蹤機(jī)制(變更請求(RFC)、變更日志和評審)，以確保只部署已批準(zhǔn)的變更。
配置管理Configuration management 為變更日志、rfc、權(quán)威軟件庫(DSL)、權(quán)威硬件存儲(DHS)、發(fā)布包和所有CIs提供了一個托管數(shù)據(jù)庫(CMDB)。
發(fā)布管理Release management為部署到生產(chǎn)中的所有變更提供了一個打包的發(fā)布。
這種相互依存關(guān)系可以清楚地理解為:
1、變更管理
（1）需要配置管理來評估變更對所有潛在CI的影響。
（2）需要發(fā)布管理來打包變更，以便在對生產(chǎn)造成最小干擾的情況下成功部署。
２、配置管理
（１）需要變更管理，以確保只部署已批準(zhǔn)的變更，并完成對授權(quán)過程的所有跟蹤。
（２）需要發(fā)布管理來在部署后使用發(fā)布包更新CMDB。
３、發(fā)布管理
（１）需要變更管理來批準(zhǔn)變更，并在整個發(fā)布過程中跟蹤變更。
（２）需要配置管理來評估變更對ci的影響，并為發(fā)布包提供一個確定的存儲。
變更管理角色和職責(zé)
來源：https://www.greycampus.com/blog/it-service-management/itil-change-management-roles-and-responsibilities
變更管理是以受控的方式訪問、批準(zhǔn)、實施和審查變更的一組。每個角色負(fù)責(zé)完成特定的任務(wù)。在變更管理中確定的角色是：
一、變更經(jīng)理Change Manager
變更經(jīng)理作為一個促進(jìn)者，負(fù)責(zé)整個變更管理過程。他的主要職責(zé)是：
（1）授權(quán)和批準(zhǔn)小的/低 minor/low的變更；
（2）與變更顧問委員會(CAB)協(xié)調(diào)并組織會議，討論高風(fēng)險變更；
（3）實施或拒絕變更的權(quán)力；
（4）確保所有為實施變更而設(shè)計的活動都符合標(biāo)準(zhǔn)。政策和程序應(yīng)得到很好的定義、承認(rèn)和審查；
（5）準(zhǔn)備變更摘要表，總結(jié)所有RFC的變更。此表幫助CAB團(tuán)隊理解和評估所提議的變更。
二、變更咨詢委員會Change Advisory Board (CAB)
它是一組個人，作為一個顧問委員會的變化被分類為主要或重要的。CAB，與變更經(jīng)理一起負(fù)責(zé)最終評審;他們有權(quán)重新評估風(fēng)險級別或影響級別。他們可以在批準(zhǔn)變更前要求提供額外的信息，也可以根據(jù)需要拒絕變更。
三、緊急變更咨詢委員會Emergency Change Advisory Board (CAB/EC)
CAB的一個子集，作為緊急變更的決策者。緊急變更需要立即批準(zhǔn)和授權(quán)。
四、變更請求者或變更啟動者Change Requestor or Change Initiator
提出改變或要求改變的人。變更請求者需要為變更提供所有必要的信息和理由。除此之外，他的其他職責(zé)還包括組織和計劃變更活動。
（1）向變更的所有者提供必要的信息
（2）參加CAB會議并提供必要的信息
（3）評審和記錄變更計劃
（4）解決與變更相關(guān)的問題
（5）使用變更活動更新用戶
（6）支持并參與變更實施前后的測試活動
五、變更受讓人/測試人員/實現(xiàn)者Change Assignee/Tester/Implementer
變更的所有者——如果變更請求者是其他人。他的職責(zé)包括:
（1）就業(yè)務(wù)和技術(shù)問題與變更請求者保持聯(lián)系
（2）創(chuàng)建一個RFC(變更請求)，并在需要時更新它的狀態(tài)。檢查并確定實現(xiàn)日期，確保它不會與其他活動沖突
（3）評估和管理相關(guān)的風(fēng)險
（4）測試并實現(xiàn)變更
（5）在提交變更之前，與其他受影響的團(tuán)隊進(jìn)行協(xié)調(diào)和溝通
（6）一旦變更被批準(zhǔn)，為計劃的變更創(chuàng)建一個補(bǔ)救案例。按照預(yù)定的日期和時間執(zhí)行更改。更新補(bǔ)救案例
（7）成功完成后提供關(guān)閉狀態(tài)
（8）變更程序?qū)嵤┖蟮奈募涗?/p>
六、變更批準(zhǔn)人Change Approver
在RFC進(jìn)入CAB評審之前，向RFC提供第一級批準(zhǔn)的經(jīng)理。他的職責(zé)包括:
（1）審查變更受讓人提交的所有RFC
（2）確保所有必要的溝通;文件編制和測試在批準(zhǔn)之前完成
（3）請求技術(shù)同行進(jìn)行評審，以確保所有技術(shù)步驟都是正確的
（4）批準(zhǔn)或拒絕RFC
（5）變更是通過變更管理系統(tǒng)來維護(hù)和控制的，這是一種用來跟蹤和記錄與擬議變更相關(guān)的所有活動(初始化、批準(zhǔn)、更新、關(guān)閉)的工具。
