配置管理篇.docVIP

ITSM系统构建及ITIL实施笔记 之 配置管理篇 这里就不对配置管理的一些基本知识做解释了，类似的文章挺多，这里直面配置管理深入一些的内容，我在这家公司工作了三年，很少象这样需要开动所有脑力去思考一件工作，配置是一个很重要的基础，同时也是让我耗费脑力最多的一块，所以先把它写下来。 先介绍一下我们的业务情况，我们公司的运维项目较多，有网络、系统的、桌面的、软件的，而且这些项目用到的设备都存在共用的情况，比如一个段线路，会属于多个项目使用，一台客户的电脑，也可能装有多个管理软件，同时它又是属于桌面运维的，这些我们的IT组件一是数量多（光是需要桌面运维的电脑台数在5000台以上），二是相互的关系复杂。 我现在所讲的，是经过很多思考与折腾后，所整理出来的，我对配置管理的出发点，是从软件实现方面考虑的，这可能与其它的公司有一些不一样，一开始，在思考整个配置的模型，也是CMDB的业务层面逻辑，很长一段时间，在CI的结构与关系方面，我一直无法理清楚，因为当CI的结构是怎样，关系是怎样不确定前，整个模型根本无从建立。最开始首先确定的是，我决定把CI的结构与关系分离，即结构是结构，关系是关系，两者不互为影响，作用也各自不同，这个想法应该是比较大胆的，而且这是在我对ITIL不熟悉的情况做出的决定，如果这个做法错误，后续的很多工作都会受到影响。 决定后，剩下来就是攻破结构与关系了。在那段时间的思考中，CI的结构是首先想通的，可能是因为以前是做ERP实施的关系，也可能是因为客户是汽车制造商的关系，最终我发现将CI组装时，它的呈现很象ERP中的BOM结构，这是个父子结构，它可展开任意的节点，这种结构具有很大的扩展空间，也解决了配置管理颗粒度大小变化的问题，经过几天的思考后，我已非常确定这个思路可以解决我们的CI结构问题。 剩下的关系是花的时间比较久的，查了不少资料，我一直想确定到底CI之间有哪几种关系，这本身我一直觉得这个ITIL的推广组织本身需要制定或想通的，而不应该由我来思考，我也看了常态下象IBM他们的做法，但他们关系与结构是互为一体的，而且他们对关系的定义简单了些，所以最后没有采用。在思考CI的关系时，我甚至上升到哲学的层面，去思考人与人之间的关系有哪一些，事物与事物之间的关系有哪一些，看是否能对得出CI之间的关系有一些启发作用，也在网上查了很多关于事物关系的说明，可惜没有找到有用的说明资料。 最终找到一个解决方法，是一个周五下午快下班的时候，当时正在画一个示意图，想向领导表达，日后如果我们完成配置的结构与关系构建后，呈现给我们的是一个怎样的东西，当时只把CI抽象成几个集合，CI是用一个圆圈图示代替，在画了几个图示后，突然有一点灵光闪过，我发现当把几十万个CI用这样方式串联起来时，象一个个灯泡一样，有的亮有的不亮，通过关系将这数量庞大的灯泡连接起来时，这种情况好象电路图，每一个CI位于一个复杂的线路中，形成我们公司自已的配置地图，而且这是一个三维的图形，多个项目形成一个面，每个项目的根据结构展开的所有CI形成一个面，而每个CI之间的关系又形成一个面，脑子里当时形成了这图象（这个三维的图形后来尝试了好几次用VISIO或PPT画出来，一直没有成功），想到这一点当时很兴奋，终于看到了一道门。于在是周末休息时，去书店把数字电路的书找来看了一些篇章，最终确定引入门电路的概念来解决关系的问题。 上面介绍的是思考过程，在完成这个思考过程后，在项目启动会上，汇报了此构想，得到领导认可，同时为了验证可行性，我找了一个公司典型的项目做了一次试验，看一下这样的模型是否存在问题。这里要说明一下，我们把结构与关系分离，一是考虑结构与关系是互不对等的，二是可以让其独立作用在不现的地方，这样分离之后，结构与关系本身更加严谨，我们将结构用于事件定位，关系用于故障推演，一个着眼于现在，一个着眼于未来。下面将展开细节说明 配置管理规划 由于以前实施REMEDY时，我们积累了一定的经验与知识，也具备一些配置管理的概念，所以规划方面，相对单纯一些，我们以管理科为主导，各业务领域的主管为成员，目标是所有项目的CI项纳入管理，在此作业开展前，我制作了一个作业计划，主要分几个阶段。 CI分类规划 CI属性设计 CI命名规划 CI模版制作 配置数据收集 细节的作业进程就不一一介绍了，在做这个计划与真正执行时，发现一些很有意思的现象，也算是经验了，这些点我会在下面逐一介绍到，下面将我们的整体的配置模型做一个介绍， 示意1 说明： 客户组织：指我们的客户的组织及用户信息 运维组织：指我们内部的服务机构及员工信息 服务目录：不作名词解释了 运维对象：常态上说的配置管理，即CI的集合 这四个纬度构成我们需要关注的所有配置信息，每一个纬度都是一个结构独