七、确定配置结构：

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

　　问题：
　　配置基准线在技术上如何实现呢？《指南》中没有进一步阐述，但这才是很关键的地方。有待进一步的研究。 似乎和CC一类的版本管理工具实现原理类似？ 不知道HP有没有这方面的实践？