CMDB模型设计.docx

CMDB模型设计.docx

《CMDB模型设计.docx》由会员分享，可在线阅读，更多相关《CMDB模型设计.docx（14页珍藏版）》请在冰豆网上搜索。

CMDB模型设计

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服务得,业务影响得分析结果就显示易见了,剩下得只就是展示得问题,因为数据结果已然存在,模型展示只就是数据得表达。

对于一个服务而言,需要明确四个方面得问题,服务得对象就是哪一些ＣＩ,服务得主体就是哪一些单位或个人,服务得体制就是哪一些单位与个人,这个服务到底要做些什么。

同样得这会形成一个四面魔方,每一个面都由一个树形结构所构成,由服务对象得任何一个节点与其它三个面做任意节点连接,见下图、

说明:

1。

服务对象:

无论就是业务服务还就是ＩT服务,都就是面向服务,我一直认为在IT服务或IＴ管理行业中说得业务服务就是一种狭义得业务服务,业务服务与ＩＴ服务得区别不在于就是不就是面向服务,而在于ＩＴ服务将一切分成IT与非IＴ得,业务服务将一切分成业务与非业务得,由此带来范围与视角得绝大不同,要定义清楚什么就是业务,每一个业务环节中哪一就是业务得作业内容,哪一些就是非作业需要服务得内容,将业务得重点放在核心上,剩余得外包一切,非业务得就就是业务服务,业务服务可以包括物业服务、餐饮服务、IT服务等等,我相信业务服务不就是ＩT行业可以玩得转得,而需要在目前得企业管理运营层面发生革命性得转折才有可能。

但对于模型层面而言,两者其实并无二致,无论就是基于业务服务还就是IＴ服务,上述得模型均可容纳,我认可服务可以分解得思路,一个服务可能由若干个子服务构成,但我不认同在CMDB模型层对CＩ进行层层分解得思路,在CMDB得世界里就是没有聚合之物得,一切只就是单一对象,如果把人比作CI,那么我认为家庭不应该就是CI,您得CMDB模型里不能既有家庭又有个人,这样得关系构建逻辑就会有问题,当我们定义清楚每个人得关系时,每一个家庭得关系其实就自然出来了,在这里,我们可以把家庭理解成服务,把个人理解成CI,所以在模型设计时,服务得定义与一个服务有哪一些对象得定义,我就是不会放到CＭDB之中得,而就是在IＴSM系统之中,也就就是虚拟CI解决方式、不管我们就是做网络维护、桌面维护、系统维护,还就是物业服务,事实只有我们理清楚对象就是什么,我们得服务得灰色地带才有可能清理清楚,当一个服务没有独立得对象支撑时,我认为定义它已经没有实质意义,就也就就是为什么我一直反对将一个应用系统进行得拆分得原因,在实施CMDB时,许多人会把一个系统分解成若干个子功能或子服务,这除了结构好瞧些外,并没有会任何好处,反而有坏处,我们要深刻理解软件即服务得意思,这里面得一个难题在于,我们还没有找到一个非常稳键得概念定义清楚,什么就是一个系统、在实际管理中,我们会把许多关系紧密得系统交给一个团队或一个人管理,然后习惯得叫它XＸＸ系统,其余此时就是因为我们在现实业务中没有定义清楚什么就是一个系统,如果我认真审视,我们负责得所有系统清单,我们会发现,其实许多系统只就是概念性得聚合之物,它属于某种业务领域或单元得概念,如果我们不定义清楚什么就是一个系统,而用原有得概念去做ＣMＤB得建模时,我们会发现就需要把一个所谓得系统拆成若干个子系统,从而引发建模思想与标准得问题。

如果我们足够聪明,我认为我们就是完全可以梳理出一个公司得所有业务及所有IＴ服务得关系图得,然后再定义每一个IT服务拥有哪一些对象（ＣI）,此时业务世界与IT世界才真正得结合起来了,此时展现得模型已经超出了CMDＢ得世界,也就就是说我们现在要达到得业务影响分析,就是基于ITSM系统得,而不就是仅仅基于CMDB得。

２.　服务主体:

在做业务影响分析时,我们经常想知道到底会引影响哪一些人或部门,事实上服务主体得数据非常重要,我们需要把跟我们服务相关得所有公司得组织与人员数据全部置入ＩTSＭ系统之中,这就就是我们得客户数据中心,当们把IT服务与服务主体建立关系时,会通过CI得故障计算出服务得故障,因此会计算出哪一些人员会受影响,需要注意得就是,将IT服务与个人数据直接发生关系并不就是一种好得方式,因为会带来维护得极大麻烦（新来一个人,离开一个人,您都需要手工维护更新）,最好得方式就是通过部门或岗位信息进行互联,这样只要维护组织数据得人员保障服务主体得正确就行了、也许有人会问,一个系统得某一个报表模块只有A部门会用,如要系统功能不往下拆分,那怎么能实现当报表模块坏时,只有A部门会受影响得结果呢？

答案就是,如果在IT架构中,没有任何一个元素来独立支撑报表模块,那么这种故障传导得结果就是不会发生得,因为只要应用程序或数据实体发生问题,会直接导致所有用户受影响,这种问题也就是一个在CMDＢ实施时常见到得倾向,一切似乎就是围绕着业务影响分析得目得进行得,我得瞧法就是,以目前得ＣMDB发展情况而言,就是无法支撑一个精确得分析结果得,根本原因就是一个ＣＩ得状态在分析时只有0与1得取舍,这在客观上就违背了现实世界得复杂性,用权重百分比之类得做法,也只就是在一定程度上缓解这个问题,但因此引发得定义与判断得成本,甚至要远远超过丢掉它,来直接瞧现实世界得成本,这些做法仅仅就是为了满足不掌握信息得管理者们,实在就是无奈之举,这好比大家都一直觉得在变更管理中,CMDB可以发挥很大得作用一样,事实上绝大多数变更就是根本不需要利用CＭＤＢ影响分析得,因为这些提交与分析及实施变更得人就是最了解情况得,所以出现得荒唐现象就是,当一个变更就是要个修改数据库中得一个客户数据时,根据现在得业务影响分析就是整个公司得业务受到影响,因为整个公司业务中依赖此系统,此系统依赖数据,当领导们审批此变更时,发现这影响不对啊,于就是大家细化模型,工程师们花更大得力气维护数据,但我们一直不敢做一个更简单决定,让那些不掌握信息得行政领导们不参与变更审批环节,把一个技术决策扭曲成一个行政决策,除了编制太多得材料以传递信息与知识外,还使得各种角色不能归位去承担应有得责任。

4.服务体制:

要清楚规划设计出每一个服务得作业体制,即服务经理、一二三线得支持人员,更庞大得服务需要更复杂得体制来应对,要清楚定义就是由哪一些角色及人员来完成交付与支持服务,服务体制得数据取自行政组织得数据,行政组织多半以专业为划分,这样就形成服务与专业得两个层面,有得公司会更复杂,会有技能组类似得概念,不管组织数据如何复杂,都需要将这些人员映射到服务体制得某个角色之中,最后一个服务体制中得人员可能会包括多个不同公司得不同岗位得人员。

在ITSM系统中,一个明确得服务体制会帮助我们控制权限（无论就是工单还就是CI）与派单,同时还会帮助我们了解在一个变更时,需要哪一些人员参与,从正常情况来瞧,一个变更单如果只涉及其服务内部得专属CI,则变更经理由相应得服务经理担任,如果变更涉及到得ＣI上支撑着多个服务时,此时需要进行联合审批,即通过变更关联CI得上层所有服务得服务体制来判别、

5.服务目录:

对于服务目录得理解,我认为许多人其实就是似就是而非得,就象我以前讲得菜单与菜谱得例子一样,当然这就是ITＩL理论不清晰所造成得,对于这个问题得理解,如果站在一个专业得IT服务商得角度会相对容易些,菜单其实就是服务产品,菜谱其实就是服务目录,客户需要理解得就是菜单,IT服务商需要理解得就是服务目录,服务目录层层折解下来后,最底层得作业一定就是跟CI类对接得,所以其实理论上我们可以定义每一个CI类得动作序列或服务目录,一个类,或者说一个配置项,可能有怎样得维护或操作动作,这事实上属于服务标准化得过程,这也就是目前整个IT服务行业最滞后得地方,每一名ＩT服务人员到底会做哪一些动作,每一种设备对应得维护动作有哪一些,最终每一种维护动作需要做多少次,需要多少时间成本,这对服务分析与服务管理就是非常有意义得,它甚至可以解决能力成长与技能提升得问题,如果足够标准化,最后每一类设备得每一种动作形成一个手册,一个人就是否能维护这一类设备,取决于她就是否掌握这段上设备存在得所有动作,如果将一个设备得动作分解决了不同层次,那么一线与二线及三线得职能切分也就清楚了,因为大家得动作范围不一样,这又会带来派单处理得便利性,一个服务得内容有多少,事实上就是由这个服务有多少个对象,这个对象有多少动作来决定得,这才就是真正得服务目录。

全年下来时,整个IT组织知道了每一种动作得平均时长就是多少,全年操作次数就是多少,哪一些人做哪一些动作就是最多得,可以想象这种层面得分析,完全可以让我们得管理水平与分析水平发生质得改变。

如果日后人类得作业行为更加标准化,这个模型还可以发展,因为动作与关系与属性其实存在关联,理论层面则言,一个属性得改变或一个关系得改变,一定就是由于某个动作所导致得,这又会直接引生成新得变更控制思想,更疯狂得就是,任何对象得事件与变更就是可预见得,如果抽象出来后,我们还会发现,某一种现象得事件或某一种类型得变更,它一定会由某一种动作来实现完成,此时自动判断用什么动作来处理事件或变更就成为了可能,但这一步,估计目前就是做不到得,需要做全方面得提高后,才能可能成为现实、

根据服务模型,当我们真正在做服务作业时,假设一个ITＳＭ系统开始作业,我们转变一下思路,用面向对象得方式去问问每一个工单,我们会发现事件、问题、变更、发布、监控、备份、灾备等等全部就是基于对象得,我们在作业时需要思考就是与哪一个对象相关,以前我们在填写单据时,只就是写我们做了什么,而不会说基于哪一个对象,改变这种行为,让CMDB得数据与流程对接,我们会发生一个广阔得天地会展现在我们眼前,原来我们得管理模式与服务分析可以有那么大得空间供我们驰骋。

下图模型就是一个此思路得表达。

有了这几个模型后,真正把它们实现在ITＳM中时,我们只需要两层监控,一个就是监控服务,即我们常态理解得服务台,接受服务受理,另一层监控就是监控IT架构,如果就是一个用户报事件,我们就会知道与她相关得服务会有哪几个,每一个服务又会有哪一些对象,每个对象又需要就是谁负责去管理,如果就是一个监控软件发生告警,我们会知道这个CＩ就是从属于哪一些服务,它又就是谁进行管理。

在做业务影响分析时,由于ＣMDＢ中得CI关系就是网状得,存在着一个无法截止得问题,所以任何试图做业务影响分析时,必须先确定分析得范围或发起点,在展现一个服务得内部结构时,可以通过确定一个服务得所有对象（CI）,加上与这些对象存在关系得临近一层得ＣI,通过关系数据将它们得图例组合出来,这个视图应非常稳固,要找到一个模型排列得算法,比如首先判断有多少个CI（根据查询条件先计出需要输出得总数）,将屏幕得面积切分为N份长宽相等得位格,图例占一位格,线条占一位格,需要找出CI数与位格数得函数关系（排列规则:

哪种关系得哪种ＣI排在出发ＣI得上下左右,当CI数少时,模型较大,CI数多时,模型较小。

可定义衡定格位输出,将屏幕切分为宽多少,高多少得模型,或者提列手动拖拽调整保存视图得功能,这个视图要在ITSM系统中很方便调出,当事件发生时,不管它就是服务层还就是IＴ层,用户可以直接在此视图上,标记其状态,这样图例就改变颜色,在事件处时结束时,再将此状态改为正常,这样我们在任何时刻查瞧一个完整得架构图时,在视觉上就知道整个架构中有哪一些得热点,也会知道哪一些服务在受影响,这个全局视图得设计才就是打动高层领导得关键,让她们随时监控掌握IT得现状与服务得现状,这个全局视图要可以过滤哪一些类显示或哪一类不显示,也可以设置在模型中显示得CI标识就是哪一个属性（比如显示ＩP地址或型号）,理论上我们应该可以找到一个算法,当第一个ＣＩ与第二个ＣI有关系,第二个CI与第三个CI有关系时,我们可以计算出第一个CI与第三个CI得关系,这样得话就可以解决一个困扰已久得问题,即模型得抽象问题,虽然将所有CI列在模型之上就是真实得,但有得人只想瞧到主机这个层面得关系,有得人只想瞧到软件得关系,这样当她们在模型之中过滤不显示一些类得CI时,第一个CI与第三个CI就无法通过关系连接了,从而使整个模型断开,这其中得算法就好比人得人际关系一样,如果我得老婆就是黄蓉,黄蓉得老爸就是黄药师,这种条件下,黄药师跟我就就是岳父与女婿得关系,如果黄药师再有儿子,我也有儿子,理论上她们两者间得关系也就是可以计算知道得,如果这个定义得问题解决（我认为就是完全现实得）,通过一个真实描述IT架构得CMDB,可以生成各种不同得模型视图来满足不同人群得需要,不需要从影响分析得角度或其它得角度去构建CMDB,这样得局限性就是先天存在得,从单一得视角出来做CＭDB建模,就否定了其它一切得视角,因为事物需要通过多种视角才能表达清楚,这也就就是我一直不厌其烦得说,只有真实就是最合理及稳键,也就是最有利于整体需求得原因。