ITIL实施记实之配置管理经验谈(1)

ITIL实施记实之配置管理经验谈(1)

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

先介绍一下我们的业务情况，我们公司的运维项目较多，有网络、系统的、桌面的、软件的，而且这些项目用到的设备都存在共用的情况，比如一个段线路，会属于多个项目使用，一台客户的电脑，也可能装有多个管理软件，同时它又是属于桌面运维的，这些我们的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后，我们有足够的时间去收集试验，同时还可以同步更新。