|
这几年以来，CMDB的模型每隔段时间在脑子里就会折腾一番，近期有一点小小突破，一直没有时间跟心情沉下来记录，到现在我仍然认为目前的CMDB的产品层的设计与实施层的建模思想都存在问题，可惜没有资源去验证自已的整个想法，我设计的模型如果有任何个人或公司在此之上做产品实现，我都是乐意的，甚至可以考虑提供免费的咨询支持，一个想法不断冲击你的大脑，你却无法看到它的实现与验证，这实在是一件让人沮丧的事情。
将这篇文章的标题写成CMDB模型设计仅仅是为了符合大家的认知与兴趣，我对CMDB这个狭义的名称越来越不感冒了，因为它与一个完整的ITSM系统有着某种二元对立之嫌，同时它又让大家忘记CMS是什么，所以接下来我讲的模型其实有两个层面，一个是基于CI级的模型，一个基于服务的模型，前者面对服务对象，后者面向服务本身，如果这两个模型是稳健的，它将一个ITSM的系统架构做了最底层的约束，或者说形成了这个ITSM系统的骨架或灵魂，基于这两个模型可以做许多延伸与分析，就我个人而言，我觉得它有一定的突破意义，对于外界或行业方面，只能在未来观察了。
与面向对象的思想一样，用类的方式来构建CI，一个类有三个方面的特性，它与[ /industry/1625.html]其它[/url]的类有什么样的关系，它有哪一些属性，它可以有哪一些动作，首先类、关系、属性、动作都需要结构化，且不能强制做分层数，即你不能要求CI分类全部要三层，你也不能要求关系只能做一层，这样等于形成四个树状的结构，以类为中心连接点，它可以与其它三个树形中的任何节点发生关系，拥有一个节点，则拥有其所有子节点，这会极大的灵活日后的维护，，下面分别讲解一下这几个纬度的意义：
1.分类：
即把IT架构中所有的元素进行分类别名。在这一个数据集中，只记录存着分类本身的树形结构，或者说是所有服务对象的分类结构，所以此处是不会出现虚拟CI的概念的，即类似组织、人员、地点、服务这类信息是不会成为某一种分类的，所以在这个模型之中，是建立IT架构本身的投影，尽可能真实的表达出真实架构的情况，在分类方面可以利用现有的资产清单，并做一次所有部门的服务对象调查，这样汇总后，做一次分析整理，做到完全穷尽，相互独立。理论上，如果两个分类它的关系、属性、动作全部一样，则不需要分成两个类，但在实施时我发现，不要吝啬分类的设计，许多人觉得属性一样时，就合并类，比如将[ /module/27646.html]刀片[/url]、PC服务器、小型机都置成一个类，叫服务器，这其实并不合适。
因为问题是出在了属性设计上，而不出在类上，你不能因为A病了，让B去吃药。类能在模型表达、动作、关系、统计分析上带无可比拟的方便性，它可以让你的一切都只需要基于类级做控制即可，如果只是在类上加一个属性叫“服务器类型”，这样的结果是你的系统功能变得非常复杂，你可能需要实现根据属性去过滤你的模型，需要考虑属性去计算业务影响，以及你的所有的报表统计。类的数据是整个CMDB的基础的基础，一定要严格做公司级的评审，当我们定清楚所有类的属性、关系、动作、生命周期时（注生命周期需要根据类去做不同的定义设计），事实上，我们就定义了变更的最小范围。为了让最终模型美观，可以根据类来设置不同的图例图片，来代表这个类，这样在模型时就可以显示依赖这个图片来表达显示。
2.关系：
在以前我一直希望抽象最精简的关系类型出来，慢慢的我感觉到这个路是不太可行的，可能有更简洁的方法去作业，我们在帮助一个客户实现CMDB时，我们可能根本不需要去提前帮客户抽象有哪几种关系类型，原因很简单，当我们定义出所有的类后，只要我们做一件事情，问问每一个类与其它所有的类会有怎样的关系，当我们把这个数据调查到之后，就会得到一个CMDB的蓝图，这个蓝图就是这个公司自已的CMDB模型，这样当在构建CI时，根本不需要用户再去决定填哪一种关系，因为关系是由类决定的，不是由CI决定的，当用户知道这个CI跟哪一个CI有关系时，模型层会自动添加上正确的关系类型，每个类跟哪一些类有怎样的关系，不能跟哪一些类有哪一些关系就在系统层做了控制。
也就是说用户永远无法构建出错误的模型，他只能构建出错误的数据，每一个关系的数据，最后在实体CI填充时，类似属性一样，可以填写一个值，这个值即是“关系说明”，我们以前在模型层只画一根线，表达两者有一种连接关系，这种表达有时是不够的，尤其在应用程序之间的关系上，比如你在模型上看两个应用程序有依赖关系，当你鼠标停留在此关系上时，系统会调用关系说明的值，显示出“A程序需要每隔1小时调取B程序的库存数据”。类与类之间的关系蓝图是比较花气力一件事，同时它又非常重要，同样需要公司级的严格评审，一旦通过后，CMDB的模型就稳固了。
关系的数据越细，日后的影响分析计算与模型表达就越精准，CMDB在实施时，以往存在的一个问题是，我们代替太多业务部门做太多的思考与决定了，当我们清楚每一个类时，每一个类与其它类有怎样的关系，其实业务部门最清楚，可以用一个很简单的调查表就实现盘点与收集，然后汇总评审，我发现这项工作太少人做了，其实只需要有几家公司认真去做一次，就完全可以总结出一个整个IT行业的关系蓝图，此时就可以做产品数据预制了。为了最终模型的美观，还可以定义不同的关系类型的线条粗细、颜色、箭头方向。
3.属性：
属性与以前的CMDB设计基本类似，不同之处在于，属性需要实现结构化，结构化的好处在于更加容易实现与类的关系建构，当一个类有一个属性子集（节点）时，自动拥有其下所有的属性，日后这个子集增加属性时，与它有关系的所有的类会自动增加此属性，同时更加容易让别人理解一个类的属性信息情况，单一的平面直列出数十个属性，会让人抓不住重点，以前如果要实现同性质的属性集中显示又需要进行界面定制开发，这成了一个两难的局面，一个简单些的逻辑是，将属性进行结构化，每一个节点形成一个单独的标签页，一个CI分类有几个节点就有几个标签页，同时每个标签页的属性显示可以做排序设定，这样可以达到既无须定制开发，又可以实现属性有效显示的效果。属性的填写方式需要进行控制，它如果是由用户选择，则需要定义它的数据源，比如地[ /dianxin]点信[/url]息，或者状态，如果是手工输入，则需要提供填写示例或说明的栏位，如果数值型，则需要考虑提供单位的选取等等。
4.动作：
一个类,或者说一个配置项，可能有怎样的维护或操作动作，这事实上属于服务标准化的过程，这也是目前整个IT服务行业最滞后的地方，每一名IT服务人员到底会做哪一些动作，每一种设备对应的维护动作有哪一些，最终每一种维护动作需要做多少次，需要多少时间成本，这对服务分析与服务管理是非常有意义的，它甚至可以解决能力成长与技能提升的问题，如果足够标准化，最后每一类设备的每一种动作形成一个手册，一个人是否能维护这一类设备，取决于他是否掌握这段上设备存在的所有动作，如果将一个设备的动作分解决了不同层次，那么一线与二线及三线的职能切分也就清楚了，因为大家的动作范围不一样，这又会带来派单处理的便利性，一个服务的内容有多少，事实上是由这个服务有多少个对象，这个对象有多少动作来决定的，这才是真正的服务目录。
全年下来时，整个IT组织知道了每一种动作的平均时长是多少，全年操作次数是多少，哪一些人做哪一些动作是最多的，可以想象这种层面的分析，完全可以让我们的管理水平与分析水平发生质的改变。如果日后人类的作业行为更加标准化，这个模型还可以发展，因为动作与关系与属性其实存在关联，理论层面则言，一个属性的改变或一个关系的改变，一定是由于某个动作所导致的，这又会直接引生成新的变更控制思想，更疯狂的是，任何对象的事件与变更是可预见的，如果抽象出来后，我们还会发现，某一种现象的事件或某一种类型的变更，它一定会由某一种动作来实现完成，此时自动判断用什么动作来处理事件或变更就成为了可能，但这一步，估计目前是做不到的，需要做全方面的提高后，才能可能成为现实。
在产品设计时，需要把基础数据维护与基础数据间的关系设置一分为二，以方便独立作业，所以这里应该会产生7个功能点，必须可能由最终用户来实现CMDB的基础数据维护与发展，需要依赖开发力量来增加类与属性或关系，这是一种僵化的系统设计。以上说的这些都还只是CMDB的基础数据，或者说是CI的基础数据，真正的CI此时还没有出现。
根据前面的模型，新创建一个CI时，首先要决定它是哪一个类，确定后，就自动继承这个类所有关系、属性、动作，需要提供一些比较方便的功能，比如一个CI构建时可以进行复制另一个CI的数据，如果日后技术上做一些发展，实现在图例操作，即直接在模型图上编辑关系与属性，这些都会带来一些不同的操作体验。当所有CI构建完成后，此时真正意义上的CMDB已经构建完成，此时的CMDB的数据完全是IT架构的数据，这些CI的关系组织在一起，会形成一张网，没有边缘也没有尽头，此时做影响分析，是基于IT层的，如果算法正确，我们会发现当CI发生故障时，它的故障路线是如何一步步发展的，但此时服务与IT仍然没有结合，也就无法进行服务影响分析，所此时是一个纯CMDB的CMDB，无法发挥真正的应用功能。必须结合下面的篇章。
对于一个服务而言，需要明确四个方面的问题，服务的对象是哪一些CI，服务的主体是哪一些单位或个人，服务的体制是哪一些单位与个人，服务的级别是哪一些要求。同样的这会形成一个四面魔方，每一个面都由一个树形结构所构成，由服务对象的任何一个节点和其它三个面做任意节点连接。
说明：
1.服务对象：
无论是业务服务还是IT服务，都是面向服务，我一直认为在IT服务或IT管理行业中说的业务服务是一种狭义的业务服务，业务服务与IT服务的区别不在于是不是面向服务，而在于IT服务将一切分成IT与非IT的，业务服务将一切分成业务与非业务的，由此带来范围与视角的绝大不同，要定义清楚什么是业务，每一个业务环节中哪一是业务的作业内容，哪一些是非作业需要服务的内容，将业务的重点放在核心上，剩余的外包一切，非业务的就是业务服务，业务服务可以包括物业服务、餐饮服务、IT服务等等，我相信业务服务不是IT行业可以玩得转的，而需要在目前的企业管理运营层面发生革命性的转折才有可能。
但对于模型层面而言，两者其实并无二致，无论是基于业务服务还是IT服务，上述的模型均可容纳，我认可服务可以分解的思路，一个服务可能由若干个子服务构成，但我不认同在CMDB模型层对CI进行层层分解的思路，在CMDB的世界里是没有聚合之物的，一切只是单一对象，如果把人比作CI，那么我认为家庭不应该是CI，你的CMDB模型里不能既有家庭又有个人，这样的关系构建逻辑就会有问题，当我们定义清楚每个人的关系时，每一个家庭的关系其实就自然出来了，在这里，我们可以把家庭理解成服务，把个人理解成CI，所以在模型设计时，服务的定义与一个服务有哪一些对象的定义，我是不会放到CMDB之中的，而是在ITSM系统之中，也就是虚拟CI解决方式。
不管我们是做网络维护、桌面维护、系统维护，还是物业服务，事实只有我们理清楚对象是什么，我们的服务的灰色地带才有可能清理清楚，当一个服务没有独立的对象支撑时，我认为定义它已经没有实质意义，就也就是为什么我一直反对将一个应用系统进行的拆分的原因，在实施CMDB时，许多人会把一个系统分解成若干个子功能或子服务，这除了结构好看些外，并没有会任何好处，反而有坏处，我们要深刻理解[ /industry/1593.html]软件[/url]即服务的意思，这里面的一个难题在于，我们还没有找到一个非常稳键的概念定义清楚，什么是一个系统。
在实际管理中，我们会把许多关系紧密的系统交给一个团队或一个人管理，然后习惯的叫它XXX系统，其余此时是因为我们在现实业务中没有定义清楚什么是一个系统，如果我认真审视，我们负责的所有系统清单，我们会发现，其实许多系统只是概念性的聚合之物，它属于某种业务领域或单元的概念，如果我们不定义清楚什么是一个系统，而用原有的概念去做CMDB的建模时，我们会发现就需要把一个所谓的系统拆成若干个子系统，从而引发建模思想与标准的问题。如果我们足够聪明，我认为我们是完全可以梳理出一个公司的所有业务及所有IT服务的关系图的，然后再定义每一个IT服务拥有哪一些对象（CI），此时业务世界与IT世界才真正的结合起来了，此时展现的模型已经超出了CMDB的世界，也就是说我们现在要达到的业务影响分析，是基于ITSM系统的，而不是仅仅基于CMDB的。
2.服务主体：
在做业务影响分析时，我们经常想知道到底会引影响哪一些人或部门，事实上服务主体的数据非常重要，我们需要把跟我们服务相关的所有公司的组织与人员数据全部置入ITSM系统之中，这就是我们的客户数据中心，当们把IT服务与服务主体建立关系时，会通过CI的故障计算出服务的故障，因此会计算出哪一些人员会受影响，需要注意的是，将IT服务与个人数据直接发生关系并不是一种好的方式，因为会带来维护的极大麻烦（新来一个人，离开一个人，你都需要手工维护更新），最好的方式是通过部门或岗位信息进行互联，这样只要维护组织数据的人员保障服务主体的正确就行了。
也许有人会问，一个系统的某一个报表模块只有A部门会用，如要系统功能不往下拆分，那怎么能实现当报表模块坏时，只有A部门会受影响的结果呢？，答案是，如果在IT架构中，没有任何一个元素来独立支撑报表模块，那么这种故障传导的结果是不会发生的，因为只要应用程序或数据实体发生问题，会直接导致所有用户受影响，这种问题也是一个在CMDB实施时常见到的倾向，一切似乎是围绕着业务影响分析的目的进行的，我的看法是，以目前的CMDB发展情况而言，是无法支撑一个精确的分析结果的，根本原因是一个CI的状态在分析时只有0与1的取舍，这在客观上就违背了现实世界的复杂性，用权重百分比之类的做法，也只是在一定程度上缓解这个问题，但因此引发的定义与判断的成本，甚至要远远超过丢掉它，来直接看现实世界的成本，这些做法仅仅是为了满足不掌握信息的管理者们，实在是无奈之举。
这好比大家都一直觉得在变更管理中，CMDB可以发挥很大的作用一样，事实上绝大多数变更是根本不需要利用CMDB影响分析的，因为这些提交与分析及实施变更的人是最了解情况的，所以出现的荒唐现象是，当一个变更是要个修改数据库中的一个客户数据时，根据现在的业务影响分析是整个公司的业务受到影响，因为整个公司业务中依赖此系统，此系统依赖数据，当领导们审批此变更时，发现这影响不对啊，于是大家细化模型，工程师们花更大的力气维护数据，但我们一直不敢做一个更简单决定，让那些不掌握信息的行政领导们不参与变更审批环节，把一个技术决策扭曲成一个行政决策，除了编制太多的材料以传递信息与知识外，还使得各种角色不能归位去承担应有的责任。 3.服务体制： 规划设计出每一个服务的作业体制，即服务经理、一二三线的支持人员，更庞大的服务需要更复杂的体制来应对，要清楚定义是由哪一些角色及人员来完成交付与支持服务，服务体制的数据取自行政组织的数据，行政组织多半以专业为划分，这样就形成服务与专业的两个层面，有的公司会更复杂，会有技能组类似的概念，不管组织数据如何复杂，都需要将这些人员映射到服务体制的某个角色之中，最后一个服务体制中的人员可能会包括多个不同公司的不同岗位的人员。在ITSM系统中，一个明确的服务体制会帮助我们控制权限（无论是工单还是CI）与派单，同时还会帮助我们了解在一个变更时，需要哪一些人员参与，从正常情况来看，一个变更单如果只涉及其服务内部的专属CI，则变更经理由相应的服务经理担任，如果变更涉及到的CI上支撑着多个服务时，此时需要进行联合审批，即通过变更关联CI的上层所有服务的服务体制来判别。
4.服务级别：
当我们定义一个服务时，需要定义出一个可量化的SLA，而且这种量化最好的可以基于ITSM系统的，这样当一个服务有事件产出时，会根据其SLA的数据进行提示告警，比如根据故障级别的不同定义出不同的解决时间要求，在任何事件发生时，需要进行CI定位，确定了CI后，就自动确定服务是哪一个或哪一些，有时一个CI上可能会有两种不同的SLA要求，因为其支撑着两种不同的服务，此时以最低的时间要求为准（这种情况也说明了SLA在设计时是不周全的）。
有了这几个模型时，当事件发生时，如果是一个用户报事件，我们就会知道与他相关的服务会有哪几个，如果是一件CI发生故障，我们同样也会知道是哪一个或哪几个服务，一旦这定位到CI，相应的人员与动作也会自动过滤出来，同样的SLA也就开始倒计时。在做业务影响分析时，由于CMDB中的CI关系是网状的，存在着一个无法截止的问题，所以任何试图做业务影响分析时，必须先确定分析的范围或发起点，在展现一个服务的内部结构时，可以通过确定一个服务的所有对象（CI），加上与这些对象存在关系的临近一层的CI，通过关系数据将它们的图例组合出来，这个视图应非常稳固，要找到一个模型排列的算法，比如首先判断有多少个CI（根据查询条件先计出需要输出的总数），将屏幕的面积切分为N份长宽相等的位格，图例占一位格，线条占一位格，需要找出CI数与位格数的函数关系（排列规则：哪种关系的哪种CI排在出发CI的上下左右，当CI数少时，模型较大，CI数多时，模型较小。
可定义衡定格位输出，将屏幕切分为宽多少，高多少的模型，或者提列手动拖拽调整保存视图的功能，这个视图要在ITSM系统中很方便调出，当事件发生时，用户可以直接在此视图上，标记其状态，这样图例就改变颜色，在事件处时结束时，再将此状态改为正常，这样我们在任何时刻查看一个完整的架构图时，在视觉上就知道整个架构中有哪一些的热点，也会知道哪一些服务在受影响。
这个全局视图的设计才是打动高层领导的关键，让他们随时监控掌握IT的现状与服务的现状，这个全局视图要可以过滤哪一些类显示或哪一类不显示，也可以设置在模型中显示的CI标识是哪一个属性（比如显示IP地址或型号），理论上我们应该可以找到一个算法，当第一个CI与第二个CI有关系，第二个CI与第三个CI有关系时，我们可以计算出第一个CI与第三个CI的关系，这样的话就可以解决一个困扰已久的问题，即模型的抽象问题，虽然将所有CI列在模型之上是真实的，但有的人只想看到主机这个层面的关系，有的人只想看到软件的关系，这样当他们在模型之中过滤不显示一些类的CI时，第一个CI与第三个CI就无法通过关系连接了，从而使整个模型断开，这其中的算法就好比人的人际关系一样，如果我的老婆是黄蓉，黄蓉的老爸是黄药师，这种条件下，黄药师跟我就是岳父与女婿的关系，如果黄药师再有儿子，我也有儿子，理论上他们两者间的关系也是可以计算知道的，如果这个定义的问题解决（我认为是完全现实的），通过一个真实描述IT架构的CMDB，可以生成各种不同的模型视图来满足不同人群的需要，不需要从影响分析的角度或其它的角度去构建CMDB，这样的局限性是先天存在的，从单一的视角出来做CMDB建模，就否定了其它一切的视角，因为事物需要通过多种视角才能表达清楚，这也就是我一直不厌其烦的说，只有真实是最合理及稳键，也是最有利于整体需求的原因。 | 
转播
分享
淘帖
()
