去年做的省公司IT服务流程中设计了了一个“不可用CI”报告的功能，同时配置管理流程里面针对配置变更有“配置变更申请”功能，同事对这两个功能不能理解。因为在实际开发过程中，开发人员将“不可用CI”报告的功能最后操作定义成了直接更新CMDB，不需要走流程，而将“配置变更申请”功能需要走“CMDB控制和维护”流程。同事的疑问不可用CI是否会破坏流程性及用户误操作。我的意见是这两个功能都不可缺失。

配置管理员是配置管理流程中主要工作承担者，其职责为：通过手工或自动化操作增加及更改配置项，保证所负责的关键CI的关键属性、关键CI间的关键关系完整、准确。实际工作中由各专业技术人员分别担任配置管理员，维护各自所管的设备或应用。配置管理员可以按照基础架构的分类划分，也可以按照所属业务的类别进行划分。也就是说实际过程中配置管理员数量会是1+个。

配置管理和其他流程关联原则

• 配置管理和变更管理的关联
  • 变更主管在变更计划阶段必须制定配置项更新计划，对计划修改的配置项进行说明
  • 变更实施完后，由变更主管汇总相应的配置项修改的情况，并通知相应的配置管理员，配置管理员接收到配置项修改请求后，与CI实体进行核对，核对无误后方可修改CI属性以及关系
  • 对于风险等级为高和重大的变更，CAB中应该包括配置经理，以确保对CMDB的适当控制
  • CI应与变更记录建立关联，从而对CI的变化情况进行记录
• 和事件管理、问题管理的关联
  • CI应与事件记录、问题记录建立关联，从而确保对CI维护工作的统计和分析

从配置管理和其他流程关联关系来看，配置变更主要由变更管理流程发起，也就是需要提供“配置变更申请”功能给变更流程作为流程接入点，但是在实际中配置管理员需要对CMDB中数据准确性负责，然而在事件流程、问题流程或者其他流程过程中发现CMDB中记录的CI实例值更实际情况不符合（例如：CMDB中记录Sever1连接Switch1的23端口，但实际却是连接Switch2的3端口），这种情况怎么办呢？发起变更流程？工程师没有变更任何东西呀。这种情况下应该做出CI例外报告（HP这样的翻译实在不好），就设计了一个功能专门用于报告CI不可用的情况。

两个功能设计如下：

• 不可用CI报告：用于其他流程运维人员提交CMDB中记录有误的情况，用于辅助配置管理员收集错误的CI。配置管理员在收到不可用CI报告时需进一步核实CI情况，以便修改CMDB数据或者发起配置变更申请。
• 配置变更申请：为“CMDB控制和维护”子流程正常入口，用于变更流程或者配置管理员发起CI修改流程

在查看BMC Remedy IT Service Management功能之后，发现BMC中有一个“创建CI不可用性”的功能，名称好近似呀。不过BMC定义：CI 不可用性是指 CI 的实际宕机时间。您可以记录因某事件导致的意外情况引起的 CI 不可用性。看来在引入ITILV3后续流程后需要重新对不可用CI报告重新命名，以免误会。

TFS 还是相当复杂的，包含SharePoint、TFS、ReportServer三个部分，在建立项目时可以同时建立SharePoint站点。公司使用TFS 2008 作为配置管理工具长期以来困扰配置管理员们两个很核心的问题：一是在团队管理器中明明设置了某个用户是reader用户，但文档还是可以被修改、删除，二是CMMI的基线完全没有办法做，做了基线之后文档还是都可以被修改。

分析之后发现完全是一个使用上的误区，配置管理员将项目过程文档全部放到SharePoint中了，而不是TFS中作为版本控制内容。而配置管理员在团队管理器中设置了权限之后，这个权限并没有同步到SharePoint中，这样导致了第一个问题。SharePoint中文档虽然也有版本的概念但是这个是主要给Word、Excel之类用的，目录、文档库并没有版本的概念，这样直接导致了无法做基线的问题。

经过解释，解决了他们的问题。这里就出现了一个使用上的误区和项目文档放在哪里的问题。把文档放在SharePoint的文档库中是最大的一个误区，正确的做法是项目过程文档（特别是需要做基线的），全部放在TFS中通过团队管理器或者Web Access访问，并做好权限控制和基线管理，将项目关联文档（例如：参考资料、文件、法规等）放到SharePoint文档库中。

TFS还是相当不错的一个配置管理工具的。