我在这家公司工作了三年，很少象这样需要开动所有脑力去思考一件工作，配置是一个很重要的基础，同时也是让我耗费脑力最多的一块，所以先把它写下来。

　　先介绍一下我们的业务情况，我们公司的运维项目较多，有网络、系统的、桌面的、软件的，而且这些项目用到的设备都存在共用的情况，比如一个段线路，会属于多个项目使用，一台客户的电脑，也可能装有多个管理软件，同时它又是属于桌面运维的，这些我们的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，项目由于是我们公司很重要的一个“单位”，它与结算、人员、组织、服务目录这些都会存在关联，所以后续会经常提到它。

[1] [2] [3] [4] [5] 下一页