CMDB模型设计 - 图文 下载本文

这几年以来,CMDB的模型每隔段时间在脑子里就会折腾一番,近期有一点小小突破,一直没有时间跟心情沉下来记录,到现在我仍然认为目前的CMDB的产品层的设计与实施层的建模思想都存在问题,可惜没有资源去验证自已的整个想法,我设计的模型如果有任何个人或公司在此之上做产品实现,我都是乐意的,甚至可以考虑提供免费的咨询支持,一个想法不断冲击你的大脑,你却无法看到它的实现与验证,这实在是一件让人沮丧的事情。

将这篇文章的标题写成CMDB模型设计仅仅是为了符合大家的认知与兴趣,我对CMDB这个狭义的名称越来越不感冒了,因为它与一个完整的ITSM系统有着某种二元对立之嫌,同时它又让大家忘记CMS是什么,所以接下来我讲的模型其实有两个层面,一个是基于CI级的模型,一个基于服务的模型,前者面对服务对象,后者面向服务本身,如果这两个模型是稳健的,它将一个ITSM的系统架构做了最底层的约束,或者说形成了这个ITSM系统的骨架或灵魂,基于这两个模型可以做许多延伸与分析,就我个人而言,我觉得它有一定的突破意义,对于外界或行业方面,只能在未来观察了。

首先要介绍的CI本身的构建模型,见下图

与面向对象的思想一样,用类的方式来构建CI,一个类有三个方面的特性,它与其它的类有什么样的关系,它有哪一些属性,它可以有哪一些动作,首先类、关系、属性、动作都需要结构化,且不能强制做分层数,即你不能要求CI分类全部要三层,你也不能要求关系只能做一层,这样等于形成四个树状的结构,以类为中心连接点,它可以与其它三个树形中的任何节点发生关系,拥有一个节点,则拥有其所有子节点,这会

极大的灵活日后的维护,,下面分别讲解一下这几个纬度的意义: 1. 分类:

即把IT架构中所有的元素进行分类别名。在这一个数据集中,只记录存着分类本身的树形结构,或者说是所有服务对象的分类结构,所以此处是不会出现虚拟CI的概念的,即类似组织、人员、地点、服务这类信息是不会成为某一种分类的,所以在这个模型之中,是建立IT架构本身的投影,尽可能真实的表达出真实架构的情况,在分类方面可以利用现有的资产清单,并做一次所有部门的服务对象调查,这样汇总后,做一次分析整理,做到完全穷尽,相互独立。理论上,如果两个分类它的关系、属性、动作全部一样,则不需要分成两个类,但在实施时我发现,不要吝啬分类的设计,许多人觉得属性一样时,就合并类,比如将刀片、PC服务器、小型机都置成一个类,叫服务器,这其实并不合适,因为问题是出在了属性设计上,而不出在类上,你不能因为A病了,让B去吃药。类能在、模型表达、动作、关系、统计分析上带无可比拟的方便性,它可以让你的一切都只需要基于类级做控制即可,如果只是在类上加一个属性叫“服务器类型”,这样的结果是你的系统功能变得非常复杂,你可能需要实现根据属性去过滤你的模型,需要考虑属性去计算业务影响,以及你的所有的报表统计。类的数据是整个CMDB的基础的基础,一定要严格做公司级的评审,当我们定清楚所有类的属性、关系、动作、生命周期时(注生命周期需要根据类去做不同的定义设计),事实上,我们就定义了变更的最小范围。为了让最终模型美观,可以根据类来设置不同的图例图片,来代表这个类,这样在模型时就可以显示

依赖这个图片来表达显示。 2. 关系:

在以前我一直希望抽象最精简的关系类型出来,慢慢的我感觉到这个路是不太可行的,可能有更简洁的方法去作业,我们在帮助一个客户实现CMDB时,我们可能根本不需要去提前帮客户抽象有哪几种关系类型,原因很简单,当我们定义出所有的类后,只要我们做一件事情,问问每一个类与其它所有的类会有怎样的关系,当我们把这个数据调查到之后,就会得到一个CMDB的蓝图,这个蓝图就是这个公司自已的CMDB模型,这样当在构建CI时,根本不需要用户再去决定填哪一种关系,因为关系是由类决定的,不是由CI决定的,当用户知道这个CI跟哪一个CI有关系时,模型层会自动添加上正确的关系类型,每个类跟哪一些类有怎样的关系,不能跟哪一些类有哪一些关系就在系统层做了控制,也就是说用户永远无法构建出错误的模型,他只能构建出错误的数据,每一个关系的数据,最后在实体CI填充时,类似属性一样,可以填写一个值,这个值即是“关系说明”,我们以前在模型层只画一根线,表达两者有一种连接关系,这种表达有时是不够的,尤其在应用程序之间的关系上,比如你在模型上看两个应用程序有依赖关系,当你鼠标停留在此关系上时,系统会调用关系说明的值,显示出“A程序需要每隔1小时调取B程序的库存数据”。类与类之间的关系蓝图是比较花气力一件事,同时它又非常重要,同样需要公司级的严格评审,一旦通过后,CMDB的模型就稳固了。关系的数据越细,日后的影响分析计算与模型表达就越精准,CMDB在实施时,以往存在的一个问题是,我们代替太

多业务部门做太多的思考与决定了,当我们清楚每一个类时,每一个类与其它类有怎样的关系,其实业务部门最清楚,可以用一个很简单的调查表就实现盘点与收集,然后汇总评审,我发现这项工作太少人做了,其实只需要有几家公司认真去做一次,就完全可以总结出一个整个IT行业的关系蓝图,此时就可以做产品数据预制了。为了最终模型的美观,还可以定义不同的关系类型的线条粗细、颜色、箭头方向。

3. 属性:

属性与以前的CMDB设计基本类似,不同之处在于,属性需要实现结