在思考CI的关系时

作者:官方彩票手机投注网站-服务器运维

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

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

...

本文由彩票投注软件发布,转载请注明来源

关键词: