CMMI 配置管理关键过程域

配置管理的所有活动都应该遵从CMMI 的相关标准活动，一下列出CMMI的相关关键域：

 

CMMI 2级过程域：配置管理（CM）
SG1	Establish Baselines建立基线
	SP 1.1	Identify Configuration Items识别配置项
	SP 1.2	Establish a Configuration Management System建立配置管理系统
	SP 1.3	Create or Release Baselines创建或发布基线
SG2	Track and Control Changes跟踪并控制变更
	SP 2.1	Track Change Requests跟踪变更请求
	SP 2.2	Control Configuration Items控制变更
SG3	Establish Integrity建立完整性
	SP 3.1	Establish Configuration Management Records建立配置管理记录
	SP 3.2	Perform Configuration Audits执行配置审计

 

 

上面的关键过程域对应了配置管理的下面各种活动：

配置管理的主要活动有12个：

一、配置管理计划

二、配置标识

三、确定配置管理范围

四、确认和记录配置项属性

五、为配置项定义标识符

六、确定配置基准线

七、确定配置结构

八、确定配置项命名规则

九、配置项控制

十、配置状态报告

十一、配置审验

十二、CMDB备份，存档和保管

下面详述：

一、配置管理计划：

内容应包括：

1.配置管理的目标和范围

2.与特定的支持小组相关的政策，标准和程序

3.配置管理角色和责任安排

4.配置项命名规则

5.实施配置管理活动的日程安排和程序

6.与第三方（如变更管理，供应商等）的接口控制

7.配置管理系统的设计，包括CMDB，配置管理数据的存放地点，配置项运行的受控环境，与其他服务管理系统的联系和接口，构建和安装等支持工具

8.配置管理的内务工作，包括许可证控制，配置项的存档等

9.计划的配置基准线，重大发布，里程碑，以及针对以后每个期间的工作量计划和资源计划

二、配置标识：

确定CI的范围，属性，标识符，基准线，以及配置结构和命名规范。

三、确定配置管理范围：

包括用于构建、发布、验证、安装、分发、维护、恢复和移除CI的硬件和软件及相关文档（这句话感觉很费解，是否翻译得有问题？）。

我的理解是，配置管理的范围是：所有CI的管理。

这些CI包括被识别为CI的硬件，软件以及相关文档。

而对这些CI的管理则包括构建，发布，验证，安装，发布，维护，删除，恢复等操作。

四、确认和记录CI属性：

一般包括名称，编号，类别，版本号，责任人，来源，提供日期，许可证号，目前状态，父配置项关联，子配置项关联，事故号，问题号，变更请求号，变更号，备注等内容。

五、为配置项定义标识符：

对于硬件CI，可贴上或刻上物理标记或通过条形码。

对于软件CI可将软件拷贝进入DSL（最终软件库）时制作一个包含CI名称和版本号的标签。

对于文档CI，可以通过在文档命名中加入有效日期和更新日期加以标识。

六、确定配置基准线：

配置基准线（Configuration Baseline）是对某个特定时点上一组配置项的描述。

应包括的内容：

1.过去的、当前的和计划中的发布信息

2.过去的、当前的和计划中的变更信息

3.批准和实施变更时系统的状态和有关文档

4.实施发布时系统的状态和有文档

5.按标准规范配置的硬件和软件

七、确定配置结构：

确定IT基础架构的配置结构，由此识别和记录各CI关系。

八、确定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基础架构的规模和变动情况来确定。