CMDB模型设计_计算机软件及应用_IT计算机_专业资料

《CMDB模型设计_计算机软件及应用_IT计算机_专业资料》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、CMDB模型设计这儿年以来，CMDB的模型每隔段时间在脑子里就会折腾一番，近期有一点小小突破，一直没有时间跟心情沉下來记录，到现在我仍然认为目前的CMDB的产品层的设计与实施层的建模思想都存在问题可惜没有资源去验证自已的整个想法，我设计的模型如果有任何个人或公司在此之上做产品实现，我都是乐意的，甚至可以考虑提供免费的咨询支持，一个想法不断冲击你的大脑，你却无法看到它的实现与验证，这实在是一件让人沮丧的事情。将这篇文章的标题写成CMDB模型设计仅仅是为了符合大家的认知与兴趣我对CMDB这个狭义的名称越来越不感冒了，因为

2、它与一个完整的ITSM系统有着某种二元对立之嫌，同时它又让大家忘记CMS是什么，所以接下来我讲的模型其实有两个层而，一•个是基于CI级的模型，一个基于服务的模型，前者而对服务对象，后者面向服务本身，如果这两个模型是稳健的，它将一个ITSM的系统架构做了最底层的约朿，或者说形成了这个ITSM系统的骨架或灵魂，基于这两个模型可以做许多延伸与分析,就我个人而言,我觉得它有一定的突破意义对于外界或行业方面，只能在未來观察了。首先要介绍的CI本身的构建模型，见下图分类配置分类配置分类配置分类11巴置警11配置分类应用软件■1关

3、系1■类型关一关系关系关系类型关系类型11类型-■II服■■■■I服"1与面向对象的思想一样，用类的方式来构建CI,一个类有二个方面的特性，它与其它的类有什么样的关系，它冇哪一些屈性，首先类、关系、屈性都需要结构化，且不能强制做分层数，即你不能要求CI分类全部要三层，你也不能要求关系只能做一层，这样等于形成几个树状的结构，以类为屮心连接点，它可以与其它三个树形中的任何节点发生关系，拥冇一个节点，则拥冇其所冇子节点，这会极大的灵活日后的维护，，卜•血分别讲解一卜•这几个纬度的意义：1.分类：即把IT架构中所有的元素进行

4、分类别名。在这一个数拯集中，只记录存着分类木身的树形结构，或者说是所有服务对象的分类结构，所以此处是不会击现虚拟CI的概念的，即类似组织、人员、地点、服务这类信息是不会成为某一种分类的，所以在这个模型Z中，是建立IT架构木身的投影，尽可能真实的表达出真实架构的情况，在分类方而可以利用现冇的资产清单，并做一次所冇部门的服务对彖调查，这样汇总后，做一次分析整理，做到完全穷尽，相互独立。理论上，如果两个分类它的关系、属性、动作全部一样，则不需要分成两个类，但在实施时我发现，不要吝啬分类的设计，许多人觉得属性一样时，就合并类

5、，比如将刀片、PC服务器、小型机都置成一个类，叫服务器，这其实并不合适，因为问题是出在了屈性设计上，而不出在类上，你不能因为A病了，让B去吃药。类能在、模型表达、动作、关系、统计分析上带无可比拟的方便性，它可以让你的一切都只需要基于类级做控制即可，如果只是在类上加一个属性叫“服务器类型”，这样的结果是你的系统功能变得非常复杂，你口J能需要实现根据属性去过滤你的模型，需耍考虑屈性去计算业务影响，以及你的所有的报表统计。类的数据是整个CMDB的基础的基础，一定要严格做公司级的评审，当我们定清楚所有类的属性、关系、动作、生

6、命周期时（注生命周期需要根拯类去做不同的定义设计），事实上，我们就定义了变更的最小范围。为了让最终模型美观，可以根据类來设置不同的图例图片，來代表这个类，这样在模型时就可以显示依赖这个图片來表达显示。2.关系：在以前我一直希望抽彖最精简的关系类型出来，慢慢的我感觉到这个路是不太可行的，可能有更简洁的方法去作业，我们在帮助一个客户实现CMDB吋，我们口J能根本不需要去提前帮客户抽象冇哪几种关系类型，原因很简单，当我们定义出所有的类后，只要我们做一件事情，问问每一个类与其它所有的类会有怎样的关系，当我们把这个数据调查到Z

7、后，就会得到一个CMDB的蓝图，这个蓝图就是这个公司口己的CMDB模型，这样当在构建CI时，根本不需要用户再去决定填哪一种关系，因为关系是由类决定的，不是由CI决定的，当用户知道这个CI跟哪一个CI有关系时，模型层会自动添加上正确的关系类型，每个类跟哪一些类有怎样的关系，不能跟哪一些类有哪一些关系就在系统层做了控制，也就是说用户永远无法构建出错误的模型，他只能构建出错误的数据，每一个关系的数据，最后在实体CI填充时，类似属性一样，可以填写一个值，这个值即是“关系说明”，我们以前在模型层只画一根线，表达两者有一种连接关

8、系，这种表达冇时是不够的，尤其在应用程序之间的关系上，比如你在模型上看两个应用程序有依赖关系，当你鼠标停留在此关系上时，系统会调用关系说明的值，显示出“A程序需要每隔1小时调取B程序的库存数据”。类与类Z间的关系蓝图是比较花气力一件事，同时它乂非常重要，同样需要公司级的严格评审，一旦通过后，CMDB的模型就稳固了。关系的数据越细，日后的影响分析