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