Tag Archives: cmdb
CMDB实施的几种误区
上面是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则是主语或者宾语，您觉得没有主语或者缺少宾语的句子，会传递怎么的信息呢？
Stop to build CMDB for your IT – CMS是怎样炼成的？
ITIL在国内的实施也有8年之久，就我看过和做过的项目中：service desk是最多实施的工具，它包括IM/PM；还有Change Management；用户们还可能会常常认为，Release Management可以和变更流程可以混在一起搞。服务台一般先上，有的变更流程先上，服务台的共同特点还有PM一般形同虚设。就我所见所闻的项目和用户来说，CMDB没有那家能建的好用的好；CMDB的建设的缺失似乎成了所有ITIL用户的通病，应该也是想重点突破的瓶颈。 ITIL v3发布后，CMDB成了CMS中的一个数据库；而且，CMS中包括不止像CMDB这样的配置信息数据库，其实任何保存配置信息的数据库都算在CMS系统内。既然是一个系统，所以它就不光包含数据还包含一套配套工具集合，通过这套工具，维护和使用配置信息。CMS为其他所有ITIL流程提供基础的配置信息。它的结构如下图所示： 如果说上面这幅图比较还是比较抽象的话，那么请见下图： 从上图中我们看到，CMS系统一共可以分为四层。上三层是核心CMDB数据库和相关配套工具，最低层Data层则是是所有配置信息的基础来源。从ITIL v3的角度来说，只建设一个集中的CMDB数据库来存储所有的CI信息是不够的，CMS系统中必须能够包含和处理所有企业已有的各个系统中的配置数据。换言之，CMDB建设的局限性在于，它只是配置信息数据化，或者说电子化的第一步。 当前依然有很多企业雄心勃勃的上马CMDB项目，不过切记在规划时，一定先好好阅读一下ITIL v3中和CMS相关的内容，适当调整项目的目标和预期总是好的，也可以规避一些项目风险。 CMDB不只是一个数据库那么简单，更不可能在服务台的数据库中建立几张表就可以搞定。从企业IT管理的全局出发，按照ITIL v3的规范，建设CMS应该是所有ITIL项目的当务之急。CMS系统决不能遗忘过去，必须有效整个现有的各个配置信息数据源，无论其以何种形式存在。它必须是一个开放的平台，能过最大限度的和其他任何配置信息的消费者（ITIL流程，以及任何需要获取配置信息的任何应用）整合， 以上的一些是我对CMS建设的一些认识。如果要落地到项目上还不许经过一个痛苦的过程，那就是产品选型。选项的过程中可以注重一下几点： 可视化：配置项和之间的关系按拓扑形式展现 标准化：软件、硬件配置项都有完整标准的CTI信息 归一化：与现有各种配置管理系统核心共存同时CMS保持一份完整的户口记录，任何CI都有ID 集成化：CMS中的数据以图形或者裸数据等形式供其他相关消费者流程或者人员使用 联邦化：CMS核心数据库中不保存动态变化的配置信息（DB的最大连接数，网络设备所使用的syslog服务器地址），这些信息通过联邦管理让用户从其他相关的工具系统中查看到最新的数据。 最近可能还会接触一下CMDB的项目，其他经验总结待续。
配置管理中几个的误区
配置管理的项目可以从CMDB的建设开始，也可以从配置管理的流程建设开始。我在一些配置管理的项目中发现了一些用户容易犯的错误有很多。先说说配置管理，做ITSM的项目，往往CMDB的建设，或者配置管理流程大多不会非常重视，往往作为一种辅助性的环节在项目中得到实施。例如ITSM项目一上来就做服务台，然后是变更管理流程和其他流程；在一些后续的资产管理的项目中CMDB的到重视并建设。其实配置管理流程和CMDB是ITSM项目中非常重要的一环，它建设的效果对整体效果有乘法放大的效果。CMDB的主要功能我认为有两点： 提供唯一、精确的配置信息库，让所有IT团队的人都明确IT管理配置项范围，有了它所有人都起码能清楚“我管理的东西是什么有哪些？”。都说ITIL的语言是IT管理的共同语言，那么配置信息就是这个语言的主语和宾语；从这里可以看到，如果我们没有这样一个准确的配置信息库，我们彼此之间的沟通会出现多大的误解和迷惑。我在用户现场做项目的时间比较多，耳闻目睹很多沟通障碍；这些障碍不是沟通方式和技术造成的，而是大家没有能从一开始就说清楚“谈论的CI对象到底是什么” 实现一定程度上的业务影响分析。往往都是有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的信息最好能无缝的整合的流程的处理过程中。