CMＤＢ模型设计
这几年以来,ＣMDB得模型每隔段时间在脑子里就会折腾一番,近期有一点小小突破,一直没有时间跟心情沉下来记录,到现在我仍然认为目前得ＣMDB得产品层得设计与实施层得建模思想都存在问题,可惜没有资源去验证自已得整个想法,我设计得模型如果有任何个人或公司在此之上做产品实现,我都就是乐意得,甚至可以考虑提供免费得咨询支持,一个想法不断冲击您得大脑,您却无法瞧到它得实现与验证,这实在就是一件让人沮丧得事情、
将这篇文章得标题写成ＣMDB模型设计仅仅就是为了符合大家得认知与兴趣,我对CMDB这个狭义得名称越来越不感冒了,因为它与一个完整得ＩTＳM系统有着某种二元对立之嫌,同时它又让大家忘记CMS就是什么,所以接下来我讲得模型其实有两个层面,一个就是基于CI级得模型,一个基于服务得模型,前者面对服务对象,后者面向服务本身,如果这两个模型就是稳健得,它将一个ITSＭ得系统架构做了最底层得约束,或者说形成了这个ＩＴＳM系统得骨架或灵魂,基于这两个模型可以做许多延伸与分析,就我个人而言,我觉得它有一定得突破意义,对于外界或行业方面,只能在未来观察了、
首先要介绍得CI本身得构建模型,见下图
与面向对象得思想一样,用类得方式来构建CI,一个类有二个方面得特性,它与其它得类有什么样得关系,它有哪一些属性,首先类、关系、属性都需要结构化,且不能强制做分层数,即您不能要求ＣI分类全部要三层,您也不能要求关系只能做一层,这样等于形成几个树状得结构,以类为中心连接点,它可以与其它三个树形中得任何节点发生关系,拥有一个节点,则拥有其所有子节点,这会极大得灵活日后得维护,,下面分别讲解一下这几个纬度得意义: 1. 分类:
即把IＴ架构中所有得元素进行分类别名、在这一个数据集中,只记录存着分类本身得树形结构,或者说就是所有服务对象得分类结构,所以此处就是不会出现虚拟CI得概念得,即类似组织、人员、地点、服务这类信息就是不会成为某一种分类得,所以在这个模型之中,就是建立IＴ架构本身得投影,尽可能真实得表达出真实架构得情况,在分类方面可以利用现有得资产清单,并做一次所有部门得服务对象调查,这样汇总后,做一次分析整理,做到完全穷尽,相互独立、理论上,如果两个分类它得关系、属性、动作全部一样,则不需要分成两个类,但在实施时我发现,不要吝啬分类得设计,许多人觉得属性一样时,就合并类,比如将刀片、ＰC服务器、小型机都置成一个类,叫服务器,这其实并不合适,因为问题就是出在了属性设计上,而不出在类上,您不能因为A病了,让B去吃药、类能在、模型表达、动作、关系、统计分析上带无可比拟得方便性,它可以让您得一切都只需要基于类级做控制即可,如果只就是在类上加一个属性叫“服务器类型\这样得结果就是您得系统功能变得非常复杂,您可能需要实现根据属性去过滤您得模型,需要考虑属性去计算业务影响,以及您得所有得报表统计。类得数据就是整个CＭＤB得基础得基础,一定要严格做公司级得评审,当我们定清楚所有类得属性、关系、动作、生命周期时(注生命周期需要根据类去做不同得定义设计),事实上,我们就定义了变更得最小范围。为了让最终模型美观,可以根据类来设置不同得图例图片,来代表这个类,这样在模型时就可以显示依赖这个图片来表达显示。 2. 关系:
在以前我一直希望抽象最精简得关系类型出来,慢慢得我感觉到这个路就是不太可行得,可能有更简洁得方法去作业,我们在帮助一个客户实现ＣＭDB时,我们可能根本不需要去提前帮客户抽象有哪几种关系类型,原因很简单,当我们定义出所有得类后,只要我们做一件事情,问问每一个类与其它所有得类会有怎样得关系,当我们把这个数据调查到之后,就会得到一个CMＤＢ得蓝图,这个蓝图就就是这个公司自已得CMDB模型,这样当在构建ＣＩ时,根本不需要用户再去决定填哪一种关系,因为关系就是由类决定得,不就是由CI决定得,当用户知道这个ＣI跟哪一个CI有关系时,模型层会自动添加上正确得关系类型,每个类跟哪一些类有怎样得关系,不能跟哪一些类有哪一些关系就在系统层做了控制,也就就是说用户永远无法构建出错误得模型,她只能构建出错误得数据,每一个关系得数据,最后在实体CＩ填充时,类似属性一样,可以填写一个值,这个值即就是“关系说明”,我们以前在模型层只画一根线,表达两者有一种连接关系,这种表达有时就是不够得,尤其在应用程序之间得关系上,比如您在模型上瞧两个应用程序有依赖关系,当您鼠标停留在此关系上时,系统会调用关系说明得值,显示出“A程序需要每隔１小时调取B程序得库存数据”。类与类之间得关系蓝图就是比较花气力一件事,同时它又非常重要,同样需要公司级得严格评审,一旦通过后,CＭDB得模型就稳固了、关系得数据越细,日后得影响分析计算与模型表达就越精准,CMDB在实施时,以往存在得一个问题就是,我们代替太多业务部门做太多得思考与决定了,
当我们清楚每一个类时,每一个类与其它类有怎样得关系,其实业务部门最清楚,可以用一个很简单得调查表就实现盘点与收集,然后汇总评审,我发现这项工作太少人做了,其实只需要有几家公司认真去做一次,就完全可以总结出一个整个IＴ行业得关系蓝图,此时就可以做产品数据预制了。为了最终模型得美观,还可以定义不同得关系类型得线条粗细、颜色、箭头方向。
３。 属性:
属性与以前得CＭDB设计基本类似,不同之处在于,属性需要实现结构化,结构化得好处在于更加容易实现与类得关系建构,当一个类有一个属性子集(节点)时,自动拥有其下所有得属性,日后这个子集增加属性时,与它有关系得所有得类会自动增加此属性,同时更加容易让别人理解一个类得属性信息情况,单一得平面直列出数十个属性,会让人抓不住重点,以前如果要实现同性质得属性集中显示又需要进行界面定制开发,这成了一个两难得局面,一个简单些得逻辑就是,将属性进行结构化,每一个节点形成一个单独得标签页,一个CI分类有几个节点就有几个标签页,同时每个标签页得属性显示可以做排序设定,这样可以达到既无须定制开发,又可以实现属性有效显示得效果。属性得填写方式需要进行控制,它如果就是由用户选择,则需要定义它得数据源,比如地点信息,或者状态,如果就是手工输入,则需要提供填写示例或说明得栏位,如果数值型,则需要考虑提供单位得选取等等,目前由于属性得值基本都就是纳入了静态得信息,而且许多就是不可变更得,在未来要考虑属性值得数据接入需要动态,比如象CPＵ资源等,这样就真正可以丰富在一个平台掌握架构得状况,同时可以基于一个平台来做性能分析。对于属性得定义,虽然长远上我感觉它过于平面单一,但短期内仍然没有更好得解决方案,
什么就是属性,到底就是将一个对象得不同得特性作为它得属性,还就是将这个对象得可以配置改变得项次作为属性呢,又还就是属性只就是作为一个描述信息一样,好比字典里得每一个字,将它们组装成一句话、一篇文章,来描述说明一个对象呢,直觉上,我觉得就是第二种,但如果这样思考得话,整个CMDB得理解与设计及定位,需要完全进行解构,那也就就是我以前所思考得一种终极得模型,我没有继续按那种路线思考下去,除非有哪一天有一家公司会专业做这个,请我去做专门研究才有可能了、 3. 业务:
在以前实施CMDＢ时,我们会把ＣＩ得属性与关系一次性构建出来,按现在模型得思路,则需要进行分步作业,先不构建具体得CI,而就是先定义业务,然后再定义IT服务,按目前中国大多数得公司情况,估计只需要定义IT服务即可,我们要理解、规划、定义我们到底有多少个IT服务在作业,把它们得层次结构刻画出来,这就构建成了所谓得业务架构,有了这个业务架构之后,再来梳理IT世界,也就就是CＭDB本身得CI信息,构建ＣI信息同样需要分步走,先不要关心属性,先关心三个问题:我们有多少个ＣI？每一个CI跟哪一些CI有什么关系？每一个CI属于哪一个ＩT服务？,回答了这三个问题,我们就完成了CMDＢ所有模型得构建,而且把业务架构与IT架构做了对接,此时一栋大厦已经建立完成了,剩下得只就是精装修了,也就就是把每一个CI得属性进行填充,这种思路有些像先搭建出整个骨架,不把属性收集放在前面得原因就是,发起属性得采集就是难度最大得,一旦收集了属性,变更必然跟进,不然数据会失真,这样调整数据得难度很大,我们先只花很小得力气把整个ＣＭDB得效果展现出来,不过这一关就不许展开属性得填充工作,其实我们会发现最后对CMDB争议最大得往往就是在这一个环节,要把这一个环节做得专业与严谨些,此时得模型效果会全部出来了,每一个系统得模型,甚至ＣＩO瞧得公司级得模型全部可以展现,这会建立一个很有效得正面剌激,为后面收集属性建立良好得决策基础,把眉毛胡子一把抓最后很容易出问题,而且出问题难以调整,切记这一点:业务为先IT为后,关系为先属性为后、
在产品设计时,需要把基础数据维护与基础数据间得关系设置一分为二,以方便相互独立维护作业与权限控制,所以这里应该会产生7个功能点,必须可以由最终用户来实现CMＤB得基础数据维护与发展。需要依赖开发力量来增加类与属性或关系,这就是一种僵化得系统设计。基于上面得模型,当一个CI构建时,它会继续这个类得所有关系与属性,在下图中就是ＣI实例得模型示意。
根据前面得模型,新创建一个CI时,首先要决定它就是哪一个类,确定后,就自动继承这个类所有关系、属性、动作,需要提供一些比较方便得功能,比如一个CI构建时可以进行克隆另一个CI得数据,如果日后技术上做一些发展,实现在图例操作,即直接在模型图上编辑关系与属性,这些都会带来一些全然不同得操作体验。当所有ＣI构建完成后,此时真正意义上得ＣＭDB已经构建完成,此时得ＣMDB得数据完全就是ＩT架构得数据,这些CI得关系组织在一起,会形成一张网,没有边缘也没有尽头,此时做影响分析,就是基于IT层得,如果算法正确,我们会发现当ＣI发生故障时,它得故障路线就是如何一步步发展得,当您知道IＴ架构得CI哪一些存在问题,又知道这些CI就是从属于哪一些IT服务得,业务影响得分析结果就显示易见了,剩下得只就是展示得问题,因为数据结果已然存在,模型展示只就是数据得表达。
对于一个服务而言,需要明确四个方面得问题,服务得对象就是哪一些ＣＩ,服务得主体就是哪一些单位或个人,服务得体制就是哪一些单位与个人,这个服务到底要做些什么。同样得这会形成一个四面魔方,每一个面都由一个树形结构所构
成,由服务对象得任何一个节点与其它三个面做任意节点连接,见下图、
CMDB模型设计
