OneCMDB中文

去年做的省公司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报告重新命名，以免误会。

注：转自Dominic.Xu’s 博客，原文地址：http://web2world.cn/article/2010/07/a146.html

配置管理是ITSM实施的第一步，也是最重要的一步，它是其他流程实施的基础，并且也是整个流程的最重要的架构。配置管理实施成功。

在这篇博客，先描述一下配置管理的效益以及规划中需要注意的地方，案例将会在日后说明。

效益：

1.提供正确的信息和相关的文档。这些信息将支持所有的IT服务流程，例如：发布管理，变更管理，事故管理，问题管理，能力管理和可持续性管理等。

2.方便查询相关资料。例如：某天一台笔记本电脑被盗了，那么，通过配置管理流程可以马上找到相关资料，如电脑型号，配置信息，软件列表，购买日期，责任人，配合财务系统还可以很快找到这台电脑的残值和剩余报废年限等，为下一步的恢复工作提供重要的支持。

3.为高效率支持用户提供保障。如用户打电话进服务台，前线IT人员马上可以查询配置管理，查出用户相关电脑信息，用户信息，账户信息和受限权限分配情况，相关网络状态以及其他可能发生问题的列表等，配合话务台系统，可以限制非授权人员拨入，节省时间，提高效率。

4.配置管理可以提供全面的配置列表。这容易量化各IT设备以及设备部件的维修费用以及版权费用等一系列费用，还可以根据列表查询各套软件版权的续约日期，设备部件更换费用等。可以帮助IT经理以及财务主管安排财务计划。

5.透过IT管理，使IT投资透明化，可以让用户明白数据保护以及恢复所需要的费用，触发数据保护，版权管理等的投资。

6.指导可持续性管理计划。CMDB为日常的IT服务以及灾难过程中的IT服务恢复提供数据支持。

7.支持和提高发布管理质量和效率。通过记录各套软件系统的版本信息，清晰分析出各套软件版本和注意事项。从而支持整个发布管理流程，包括发布过程的开始到发布完成。

8.通过软硬件的版本控制，提高企业内系统的安全性。减少故障，病毒等不安全因素的影响对整个IT系统的影响。

9.可以有效减少未授权软件的使用。未授权软件以及非标准软件的使用不但降低兼容性并增加支持成本并且容易引起法律诉讼，影响企业形象。

10.根据CMDB进行风险分析，高效并安全实施变更安计划，降低因变更而引起得系统环境变化，从而降低实施风险。

11.为问题管理提供趋势分析。例如：对问题管理进行归类，分析，可以对各类问题进行趋势分析，可以作为考虑因素有针对性安排日后的支持计划，以及提供主动性支持服务

可能存在的问题

1.CMDB定义错误使得IT支持人员无法使用，或者配置信息过于详细，IT支持人员不得不花费过量的时间和精力完成不必要的整理工作的无用工作。

2.数据结构没有经过分析和设计，最终结果是，使用的CMDB并不符合企业的需要，没有办法降低企业的运营费用。

3.要实施CMDB一定要有毅力，否则将会是实施ITSM的一个瓶颈。实施过程中一定会遇到很多意料不到的困难，如果过程中不控制实施时间，不明确实施中各IT人员的义务，不能并按时根据实施时间表完成各自的任务，那么CMDB将不可能完成。

4.当变更管理和发布管理开始上线，IT人员应适应新的支持流程，降低旧的流程的影响，避免双重控制点或者控制点过多，影响ITSM的实施效果

5.IT经理与IT成员之间缺少默契，这会难于将ITSM的概念以及流程介绍给这部分IT成员，与此同时，比较差的变更管理和配置管理会误导IT经理的需要和控制要点

6.如果流程感觉太苛刻和过于官僚，个人和组织经常会用这位借口不执行相关流程

7.一些员工将尝试孤立配置管理从而提高反应速度或者有恶意企图。尝试将有可能战胜问题管理，并且可以让IT成员明白配置管理的价值。

8.流程效率过低或者由错误倾向，这会经常引起手工流程的再次发生。通常这些case都可以通过办公自动化解决。

9.不能指望有一个工具可以完成CMDB所有的一切。IT成员以及IT经理期望一个配置管理工具去提供一个整体的解决方法，最终将失败责任推卸给这套工具或者软件的不足。这种行为是不恰当的。

10.选择的工具一定要有一定的弹性。发生问题时需要进行变更时，CMDB可能不能支持所需要的变更。

11. 配置管理可能被独立施行，如果配置管理被独立实施，缺乏与变更管理或者发布管理进行互动，终将使得配置管理效率低下或者无法实施后无法获得相应的价值。

12.配置管理并非项目管理的灵丹妙药，不要指望配置管理可以保证项目可以顺令实施或者项目测试成功。同时，项目管理所需的测试环境，测试结果亦不应记录到配置管理，以免增加相关人员的工作量以及影响CMDB的数据质量。

13.对配置管理增加适当的监控点。例如，监控CMDB中用户安装的软件数量，版本等，以免CMDB与实际使用产生过多的误差，影响CMDB所能带给企业的价值

实施ITSM是一件很漫长的工作，虽然它的效益显著，但实施不当，或者规划出错，那么将直接影响到ITSM的实施效果，更有可能会被中途夭折，所以，实施过程一定要慎重。

注：本文转自思瑶雅居@CSDN博客，原文地址：ITSM的第一步:配置管理