ITIL实战之配置管理解决方案

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项纳入管理，在此作业开展前，我制作了一个作业计划，主要分几个阶段。

1) CI分类规划

2) CI属性设计

3) CI命名规划

4) CI模版制作

5) 配置数据收集

细节的作业进程就不一一介绍了，在做这个计划与真正执行时，发现一些很有意思的现象，也算是经验了，这些点我会在下面逐一介绍到，下面将我们的整体的配置模型做一个介绍，示意1

说明：

Ø 客户组织：指我们的客户的组织及用户信息

Ø 运维组织：指我们内部的服务机构及员工信息

Ø 服务目录：不作名词解释了

Ø 运维对象：常态上说的配置管理，即CI的集合

这四个纬度构成我们需要关注的所有配置信息，每一个纬度都是一个结构独立的树状目录，它可以多层级多节点的细分下去（这一点非常重要），在CMDB中我只会放入运维对象的所有信息（结构与关系），而运维对象与其它三个面的关系，也是会存放在CMDB中的，当客户组织、服务目录、运维组织都与运维对象发生关联时，这时，运维组织与客户组织（一个服务人员服务的客户是哪一些，或一个客户对应的服务人员是谁），客户组织与服务目录（一个客户享用哪一些服务，或一个服务哪一些客户），运维组织与服务目录（一个服务人员可以提供哪一些服务，某个服务哪一些服务人员可以提供），这些都可以通过虚拟连接起来，这种模型的建立，会带来日后无比便利的统计分析与查询汇总，同时也会解决我们现在许多管理上的症结。

为了后续交流的方便，我还需要对项目这个名词做一个定义，我是把它当成一个CI的集合，它是运维对象的一个节点，你也可以理解一个项目就是一个CI，这个CI是一个虚拟CI，它可以展开许多子节点，每一个节点都是CI，项目由于是我们公司很重要的一个“单位”，它与结算、人员、组织、服务目录这些都会存在关联，所以后续会经常提到它。

整体模型