配置管理中几个的误区

Reading time ~1 minute

配置管理的项目可以从CMDB的建设开始,也可以从配置管理的流程建设开始。我在一些配置管理的项目中发现了一些用户容易犯的错误有很多。先说说配置管理,做ITSM的项目,往往CMDB的建设,或者配置管理流程大多不会非常重视,往往作为一种辅助性的环节在项目中得到实施。例如ITSM项目一上来就做服务台,然后是变更管理流程和其他流程;在一些后续的资产管理的项目中CMDB的到重视并建设。其实配置管理流程和CMDB是ITSM项目中非常重要的一环,它建设的效果对整体效果有乘法放大的效果。CMDB的主要功能我认为有两点:


  1. 提供唯一、精确的配置信息库,让所有IT团队的人都明确IT管理配置项范围,有了它所有人都起码能清楚“我管理的东西是什么有哪些?”。都说ITIL的语言是IT管理的共同语言,那么配置信息就是这个语言的主语和宾语;从这里可以看到,如果我们没有这样一个准确的配置信息库,我们彼此之间的沟通会出现多大的误解和迷惑。我在用户现场做项目的时间比较多,耳闻目睹很多沟通障碍;这些障碍不是沟通方式和技术造成的,而是大家没有能从一开始就说清楚“谈论的CI对象到底是什么”
  2. 实现一定程度上的业务影响分析。往往都是有IT部门牵头做CMDB,后期也主要是IT部门用。有效的业务影响分析能力,可以彻底提高事件管理的有效性。一般用户可能会有一个集中Event Console,从这个console中事件一般是以生成的时间先后顺序查看和处理的。最差的事件管理方式就是这种“先进先出”的处理应对方式。如果你能说清楚,发生事件的对象(配置项)对业务系统的影响程度,那么你就能够做到按照这些事件的优先级别来处理;事件的优先级就是该事件对业务系统所造成的影响的严重程度。需要做到业务影响分析,就必须做业务模型梳理。每一个业务服务和业务流程也是配置项,IT的人也需要能理解业务。



    下面列出一些常见错误,这些错误发生在企业做ITSM项目的前后都有可能,不过多是在实施ITSM项目之前,或者上CMDB工具之前,或者过程中。

    1)目标不明确,实施结果无法衡量      Goal


    所谓目标不明确,并不是说没有目标,而是说:目标定的不太合理。不合理的原因有一下几种:目标过大、目标过于模糊、过于教条、拘泥于ITIL的书本、和实际的工作联系不紧密、没有衡量和控制的方式。在一定的项目时间周期内,总结之前配置管理的问题,作出一个切实可行的配置管理数据库建立目标应该不难,主要以使用为主,不要拘泥于细节。

    2)配置项信息混乱,信息结构无序    Scope


    这里的“信息结构”是说CMDB的CI配置项信息查看应该是立体的有结构的很直观的数据信息。在访谈的过程中,有些用户在讨论过程中认为配置项组成的信息结构应该是网状的。其实现实中的IT基础架构组件的确是以网状的形式相关联的,这种想法非常实际。不过人们都太偏重IT了,遗忘了IT部门的最终使命“为企业交付各种业务服务”。业务服务就是CMDB数据金字塔的顶端部分。从IT部门提供的业务服务开始来梳理和建立CMDB配置库是一种“自顶向下”有效方式,是IT部门做CMDB配置管理过程中,与业务部门沟通的“翻译机”。自顶向下的方式需要业务部门的配合,或者IT部门内有精通业务的强人。通过这种方式做出了的CMDB,CI之间的构成方式,从宏观上看:屏幕的投影是树根型的,立体的看是金字塔形的,业务系统模型是树根的根部,是金字塔的顶端部分。微观上看,局部可能是网状的,或者是星型的。没有业务服务作为头部,很难说出CMDB的scope究竟是多大,很难说清楚哪些CI可能会在CMDB中出现。

    3)配置信息随意堆积,纠缠于过多的CI属性     Level

    每一个CI都可能具有非常多的属性,成功选择的标准是:够用就好,精简是王。很多用户都存在的误区就是“复杂比简单好,越复杂越放心”;大多数用户在项目初期的需求整理的时候都觉得,需求提的越全面,越好,越保险。这种心情是可以理解的,毕竟ITSM项目的周期和投入通常都是非常多的。不过对于配置管理来说却,万万不能有这种想法;否则,CMDB的维护和审计的工作量将非常巨大。一个信息量过载的CMDB,就是一个不可用的配置库。一个只有10个属性的CI和有50个属性的CI展现在你面前的时候;你找到你所关心的信息花的时间上看,前者是后者的1/5时间。属性一定要精简,特别是CMDB从零开始的用户。在设计的初期一定预留属性扩展的可能性。

    4)疏于配置信息的准确性和实时性 ** update

    CMDB一旦建立了之后,所有用户一定要对CMDB使用起来,要为CMDB提供反馈。最终使用配置信息的人,如果发现信息不准确,需要及时报告配置经理。配置经理需要及时维护。配置经理最重要的职责是,确保每一个大小变更实施完毕之后对要对相关CI做更新。你可以没有正规的变更流程系统去跑变更单,不过我所看到的是很多企业即使没有实施ITSM项目,其实他们手工变更单的流程跑的有板有眼,一点都不差。美中不足的是,变更后的结果没有地方更新和反馈。而CMDB就是这样一个变更结果反馈和汇集的目的地。在大家都频繁使用CMDB,并且每一个大小变更都更新CMDB的完美情况下,CMDB中的信息会随之时间的流逝,愈来愈精确,愈来愈完善。

    5)拘泥于工具的功能,忽略了最终目标   Tool**

    我看到的最多的工具是MS Excel,也有使用自开发系统的,可有自开发系统最终丁不住在转向商业工具的 :( 无论何种工具,假如在一个正确的事实和使用的策略下,我觉得都是可以获得CMDB建设的成功的。一个好的工具还是有必要的。在选择一个成品工具或者开发一个CMDB工具时,需要考虑工具的几个方面。工具应该参考或者借鉴某种国际标准,这里的标准是指某种通用模型标准 Common Data Model (CDM),例如DTMF的 Common Information Model (CIM),或者WMI等。好的工具需要能和其他ITSM流程紧密结合,特别是事件管理、问题管理和配置管理者三个流程。如果这三个流程是建立在某种工具平台之上的,那么CMDB的信息最好能无缝的整合的流程的处理过程中。

互联网规模的超融合平台

什么是互联网规模?什么是web scale风格?看下Nutanix的亮点。 阅读全文

2017DevOps采用和趋势现状-信息图

Published on February 11, 2017