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