配置管理的主要活動

配置管理的主要活動

配置管理的主要活動有12個：

一、配置管理計劃

1. 配置管理的目標和範圍
2. 與特定的支持小組相關的政策，標準和程序
3. 配置管理角色和責任安排
4. 配置項命名規則
5. 實施配置管理活動的日程安排和程序
6. 與第三方（如變更管理，供應商等）的接口控制
7. 配置管理系統的設計，包括CMDB，配置管理數據的存放地點，配置項運行的受控環境，與其他服務管理系統的聯繫和接口，構建和安裝等支持工具
8. 配置管理的內務工作，包括許可證控制，配置項的存檔等
9. 計劃的配置基準線，重大發布，里程碑，以及針對以後每個期間的工作量計劃和資源計劃

二、配置標識

確定CI的範圍，屬性，標識符，基準線，以及配置結構和命名規範。

三、確定配置管理範圍

包括用於構建、發佈、驗證、安裝、分發、維護、恢復和移除CI的硬件和軟件及相關文檔（這句話感覺很費解，是否翻譯得有問題？）。
我的理解是，配置管理的範圍是：所有CI的管理。
這些CI包括被識別爲CI的硬件，軟件以及相關文檔。
而對這些CI的管理則包括構建，發佈，驗證，安裝，發佈，維護，刪除，恢復等操作。

四、確認和記錄配置項屬性

一般包括名稱，編號，類別，版本號，責任人，來源，提供日期，許可證號，目前狀態，父配置項關聯，子配置項關聯，事故號，問題號，變更請求號，變更號，備註等內容。

五、爲配置項定義標識符

• 對於硬件CI，可貼上或刻上物理標記或通過條形碼。
• 對於軟件CI可將軟件拷貝進入DSL（最終軟件庫）時製作一個包含CI名稱和版本號的標籤。
• 對於文檔CI，可以通過在文檔命名中加入有效日期和更新日期加以標識。

六、確定配置基準線

配置基準線（Configuration Baseline）是對某個特定時點上一組配置項的描述。
應包括的內容：

• 1. 過去的、當前的和計劃中的發佈信息
• 2. 過去的、當前的和計劃中的變更信息
• 3. 批准和實施變更時系統的狀態和有關文檔
• 4. 實施發佈時系統的狀態和有文檔
• 5. 按標準規範配置的硬件和軟件

七、確定配置結構

確定IT基礎架構的配置結構，由此識別和記錄各CI關係。

八、確定配置項命名規則

配置管理應建立所有CI和控制形式（如RFCs）的命名規則。規則應考慮CI名稱的延續性，易記性可擴展性。

九、配置項控制

指在正式建立配置文檔後對CI變更進行控制的各種活動，包括對變更的評價、協調、批准或否決等活動。
確保CMDB中只記錄那些得到批准和可識別的CI，確保CI的增加，修改，替換，刪除是根據適當的控制文檔進行的。

具體的活動有：

• 1. 註冊新CI及其版本
• 2. 更新CI
• 3. 許可證管理
• 4. 撤消或刪除CI時將相關記錄存檔
• 5. 保護各種CI的完整性
• 6. 定期檢查CI以確保CI是否實際存在及是否合規，並更新CMDB。

十、配置狀態報告

針對所有受控CI的當前版本和變更記錄定期製作配置狀態報告。
通過狀態報告，配置管理人員就可以瞭解CI以前，當前及計劃的狀態，可以跟蹤基準線和發佈版本之間的變動情況。

內容：

• 1. 基準線和發佈標識符
• 2. 爲構建系統或應用所使用的軟件的最新版本
• 3. 對系統進行的變更次數
• 4. 基準線和發佈版本的數量
• 5. CI的使用和變動情況
• 6. 對基準線和發佈版本的比較結果

十一、配置審驗

配置管理人員對CI和CMDB進行審驗，確保CMDB中的配置信息能真實反映IT基礎架構中CI的存在和變更情況。

審驗的時機：

• 1. 實施新的CMDB後
• 2. 對IT基礎架構實施重大變更前後
• 3. 在一項軟件發佈和安裝被導入實際動作環境之前
• 4. 災難恢復後或事故恢復正常後
• 5. 發現未經授權的CI後
• 6. 任何其他必須的時候（等於沒說）

提示：一些常規的配置審驗操作可由審計軟件完成。但審計軟件即使發現不一致，也禁止自動更新CMDB，必須由有關小組調查後再更新。

十二、CMDB備份，存檔和保管

爲了應付災難的發生，建議將CMDB備份到一個較偏遠的地方。
備份頻率和保管政策需根據IT基礎架構的規模和變動情況來確定。