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的集合