CMDB实施的几种误区

itilv3model 上面是 ITIL v3 的定义,CMDB 的定义和 v2 没有变化。可以看出 CMDB 是一个存储配置记录的数据库,非常多的用户一拍脑门“不就是一个数据库么!我们也可以自己开发一个的。”。这样的情况下,IT 组织的不同部门都可能会各自立门户,开发自己的配置管理信息库;例如:资产管理、终端分发和管理、机房管理等等。数据重复、数据不一致、配置信息不对称;无法得到跨部门和系统的报告。所以 V3 提出了 CMS 系统,它是 CMDB 系统的下一代管理系统。CMS 系统需要 具有对现有信息资料的兼容性,CMS 的建立不能忘记过去;一定要集成已有配置信息。 错误一:配置信息是一个独立的配置管理系统,由专人负责数据的更新和维护,手工的管理和维护所有数据。 错误二:最配置管理就是要做的细,我要管理到机房中的每一根网线,CI 的属性需要设计的非常多,越细致越好。 错误三:我们自己有开发人员,我们有 CMDB 的需求,那就开始做吧,先看法着看看,不就是一个数据的增删改查么!!配置管理或者说 CMDB 的建设可以说是目前,国内 ITIL 用户共同的瓶颈。ITIL 项目中实施最多的三个流程是:Incident Management、Problem Management 和 Change Management。已经实施完毕以上三个流程的用户问的最多的一个问题是:一个故障单、问题单或者变更单一定要和 CI 想关联么?在解决处理的时候寻找目标 CI 或者根源 CI 是必须的么?如果 ITIL 是一种公共语言的话,那么 Incident Management、Problem Management 和 Change Management 等所有流程都是句式或者时态。而 CI 则是主语或者宾语,您觉得没有主语或者缺少宾语的句子,会传递怎么的信息呢?

署名-非商业性使用-禁止演绎 4.0 (CC BY-NC-ND 4.0)
comments powered by Disqus
本博客始于 2007 年
Built with Hugo
主题 StackJimmy 设计