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，项目由于是我们公司很重要的一个“单位”，它与结算、人员、组织、服务目录这些都会存在关联，所以后续会经常提到它。
整体模型上面介绍的都是规划阶段的事情，这时具体的配置工作还没有真正展开，上面的整体模型相当于战略，也是一个重要的基石，它决定了后续许多的事物构造，比如后续要介绍的内容，同时这种模型如此规划时，它如何在其它的流程中作用（比如事件管理、变更等）中发挥作用，也是做了考虑的。
说到这个就有一个建议了：在构建ITSM系统时，我的建议是首先从配置管理开始，而不是通常人们建议的从事件管理开始，配置管理决定地你们的运维管理的精细度与作业方向，它如何规划设计，会直接影响流程，你的绝大多数的数据质量也是由配置管理所决定的，在这个基石没有想清楚与确定前，展开事件及其它流程，最后整个作业可能是松散的，甚至可能是错误的，你的配置管理越精细，它对你的事件流程及变更流程，都是会产生影响的，配置管理颗粒度越细，它对我们的服务人员的作业行为要求就越高，引发的变更控制措施也就越多。
在我的想象中，配置管理是一个服务平台的最底层建筑，它也是一个约束整个服务机制的重要所在。
所以在项目的最初期，我一直是想先开发CMDB的，先把CDMB搞出来，然后灌数据，直接维护，不用事件管理，也不要变更管理，而是光光的CMDB，到时我想看看所有的CI信息进去后，整个运维地图是如何的，故障的推演是否能实现，如果这些都是稳固的，再在这个基础上构建其它的应用模块。
CMDB先开发出来还有一个好处，解决了配置数据收集维护问题，我们的配置数据届时会非常庞大，如果先收集，那在系统还未上线前，只能用电子表格维护，考虑到关系、结构的复杂，这基本上是不现实，每天有事件发生，无法做到同步的更新，不先收集，要等到系统上线的准确时间点，完成数据收集，这个难度又太大。
（做过ERP的朋友，应该知道在系统上线时，仓库盘点数据导入的难度，只要业务不停，数据总是一个动态的，而我们的配置数据远比这种数据复杂），有了CMDB后，我们有足够的时间去收集试验，同时还可以同步更新。
二、配置模型设计1) CI结构在CI的结构定义中，我们的思路中，有两个关键词，“树状目录”和“父子节点”及“虚拟CI”，基本的理念中，根据BOM的原理去构建我们的配置结构，最终形成的，整个公司的所有CI最终会挂在一个目录之下，象一棵枝叶茂密的大树，一个项目相当于一根树枝，一个CI 相当于树枝上面的一片树叶，树干是父，树枝是子，树枝是父，树叶是子，父与子是一个相对的概念，用一个实例来说明，比如我们一个桌面项目，有2000多台电脑维护，每个电脑由显示屏、主机、电源之类的组成，这个项目就是父节点，每一个台电脑就是子节点，但当颗粒度到更细时，一个电脑由显示屏及主机组成，这时，相对于显示屏、主机而言，电脑是父节点，而主机是子节点了，如果颗粒度再精细时，把硬盘、内存、主板、CPU作为CI管理时，此时主机又是父节点了。
这里还有一个现实问题，一个桌面项目，它的子节点就是2000多台电脑，这样的目录，可能会太长了，不利于管理，这时为了统计或管理的方便，我们可以构建几个虚拟CI，比如按厂区，如果这2000多个台电脑是分布在十几个厂区内的，我们可以将这十几个厂区，也作为节点管理，这时，桌面项目下面的子节点就只有十几个了（厂区），每一个子节点下面的节点只有100多台电脑了，这样更富于结构，也便于查询定位，这是虚拟CI的概念，它是由于管理的需要产生的，这里面要尤其注意一个问题，当厂区已经作为属性管理时，是不能再为之构建虚拟节点的，因为你的一切管理需求已经在属性中考虑了，所以结构的设计是一个智慧的事情，你要考虑到分类、属性设计的空间问题，不然到时有许多要素重叠，这样一是不效率，二是可能导致数据冲突。
对于偏硬件的项目而言，它的CI结构规划是相对简单的，真正复杂的是软件类的项目，比如象我们的DMS（经销商管理系统）类项目，它是汽车制造商为了管理它的分销商而产生的，一般大型的汽车制造商的分销商（4S店）有200-400家左右，甚至更多。
每一家分销商的店内都有一台服务器，安装有DMS的服务端，店内还有许多电脑安装有客户端，而汽车制造商本身也有服务器，它与每一家分销商的服务器对话，交流数据。
这种项目涉及网络，数据接口，几百个的数据库，众多的服务器与工作站，这时的配置规划就有一定难度了，但基本上我还是发现存在一定的规律，在项目下面的一级节点中，按应用服务器、数据库服务器、接口服务器、程序、接口程序、数据库、专用设备、相关组件、相关网络等这样的思种去规划，再逐个细化，就可以理清整个项目的CI结构，这里需要注意的事情是共用CI的问题，当一个CI的运维权在某个项目时，这个CI的所有内部信息，别的项目只能调用，不能对其进行解释，比如上面说的DMS项目中会用到相关网络（A网路），A网络内部的所有结构与关系信息，都是由网络领域的团队进行规划设计的，DMS项目只能调用A网络本身这一个组件，这一个理念会非常重要，因为当项目众多，组件复杂庞大时，整个公司级的配置结构是难以合作同时构建的，这时需要制定相应的游戏规划，教每个团队按规则去绘制自已的整个树枝，最后会自动组装成一个参天大树，把最专业的事情交给最专业的人，用一种比较简单的逻辑，最后形成一个复杂的东西，象计算机的二进制是如此，象我们的整体模型也是如此，每一个纬度只需要与一个续度建立关系，最后所有纬度会相互关联。
