这几年以来，CMDB 的模型每隔段时间在脑子里就会折腾一番，近期有一点小小突破，一直没有时间跟心情沉下来记录，到现在我仍然认为目前的CMDB 的产品层的设计与实施层的建模思想都存在问题，可惜没有资源去验证自已的整个想法，我设计的模型如果有任何个人或公司在此之上做产品实现，我都是乐意的，甚至可以考虑提供免费的咨询支持，一个想法不断冲击你的大脑，你却无法看到它的实现与验证，这实在是一件让人沮丧的事情。 将这篇文章的标题写成 CMDB 模型设计仅仅是为了符合大家的认知与兴趣，我对 CMDB 这个狭义的名称越来越不感冒了，因为它与一个完整的ITSM 系统有着某种二元对立之嫌，同时它又让大家忘记CMS 是什么，所以接下来我讲的模型其实有两个层面，一个是基于 CI 级的模型，一个基于服务的模型，前者面对服务对象，后者面向服务本身，如果这两个模型是稳健的，它将一个ITSM 的系统架构做了最底层的约束，或者说形成了这个ITSM 系统的骨架或灵魂，基于这两个模型可以做许多延伸与分析，就我个人而言，我觉得它有一定的突破意义，对于外界或行业方面，只能在未来观察了。 首先要介绍的CI 本身的构建模型，见下图 与面向对象的思想一样，用类的方式来构建CI，一个类有三个方面的特性，它与其它的类有什么样的关系，它有哪一些属性，它可以有哪一些动作，首先类、关系、属性、动作都需要结构化，且不能强制做分层数，即你不能要求 CI分类全部要三层，你也不能要求关系只能做一层，这样等于形成四个树状的结构，以类为中心连接点，它可以与其它三个树形中的任何节点发生关系，拥有一个节点，则拥有其所有子节点，这会极大的灵活日后的维护，，下面分别讲解一下这几个纬度的意义： 1. 分类： 即把IT 架构中所有的元素进行分类别名。在这一个数据集中，只记录存着分类本身的树形结构，或者说是所有服务对象的分类结构，所以此处是不会出现虚拟CI 的概念的，即类似组织、人员、地点、服务这类信息是不会成为某一种分类的，所以在这个模型之中，是建立 IT 架构本身的投影，尽可能真实的表达出真实架构的情况，在分类方面可以利用现有的资产清单，并做一次所有部门的服务对象调查，这样汇总后，做一次分析整理，做到完全穷尽，相互独立。理论上，如果两个分类它的关系、属性、动作全部一样，则不需要分成两个类，但在实施时我发现，不要吝啬分类的设计，许多人觉得属性一样时，就合并类，比如将刀片、PC 服务器、小型机都...
