学习资料： ITIL培训基地专家讲堂直播 300期视频回放

把结构与关系分离，一是考虑结构与关系是互不对等的，二是可以让其独立作用在不现的地方，这样分离之后，结构与关系本身更加严谨，将结构用于事件定位，关系用于故障推演，一个着眼于现在，一个着眼于未来。

我在这家公司工作了三年，很少象这样需要开动所有脑力去思考一件工作，配置是一个很重要的基础，同时也是让我耗费脑力最多的一块，所以先把它写下来。

先介绍一下我们的业务情况，我们公司的运维项目较多，有网络、系统的、桌面的、软件的，而且这些项目用到的设备都存在共用的情况，比如一个段线路，会属于多个项目使用，一台客户的电脑，也可能装有多个管理软件，同时它又是属于桌面运维的，这些我们的IT组件一是数量多（光是需要桌面运维的电脑台数在5000台以上），二是相互的关系复杂。

我现在所讲的，是经过很多思考与折腾后，所整理出来的，我对配置管理的出发点，是从软件实现方面考虑的，这可能与其它的公司有一些不一样，一开始，在思考整个配置的模型，也是CMDB的业务层面逻辑，很长一段时间，在CI的结构与关系方面，我一直无法理清楚，因为当 CI的结构是怎样，关系是怎样不确定前，整个模型根本无从建立。最开始首先确定的是，我决定把CI的结构与关系分离，即结构是结构，关系是关系，两者不互为影响，作用也各自不同，这个想法应该是比较大胆的，而且这是在我对ITIL不熟悉的情况做出的决定，如果这个做法错误，后续的很多工作都会受到影响。

决定后，剩下来就是攻破结构与关系了。在那段时间的思考中，CI的结构是首先想通的，可能是因为以前是做ERP实施的关系，也可能是因为客户是汽车制造商的关系，最终我发现将CI组装时，它的呈现很象ERP中的BOM结构，这是个父子结构，它可展开任意的节点，这种结构具有很大的扩展空间，也解决了配置管理颗粒度大小变化的问题，经过几天的思考后，我已非常确定这个思路可以解决我们的CI结构问题。

剩下的关系是花的时间比较久的，查了不少资料，我一直想确定到底CI之间有哪几种关系，这本身我一直觉得这个ITIL的推广组织本身需要制定或想通的，而不应该由我来思考，我也看了常态下象IBM他们的做法，但他们关系与结构是互为一体的，而且他们对关系的定义简单了些，所以最后没有采用。在思考CI的关系时，我甚至上升到哲学的层面，去思考人与人之间的关系有哪一些，事物与事物之间的关系有哪一些，看是否能对得出CI之间的关系有一些启发作用，也在网上查了很多关于事物关系的说明，可惜没有找到有用的说明资料。

最终找到一个解决方法，是一个周五下午快下班的时候，当时正在画一个示意图，想向领导表达，日后如果我们完成配置的结构与关系构建后，呈现给我们的是一个怎样的东西，当时只把CI抽象成几个集合，CI是用一个圆圈图示代替，在画了几个图示后，突然有一点灵光闪过，我发现当把几十万个CI用这样方式串联起来时，象一个个灯泡一样，有的亮有的不亮，通过关系将这数量庞大的灯泡连接起来时，这种情况好象电路图，每一个CI 位于一个复杂的线路中，形成我们公司自已的配置地图，而且这是一个三维的图形，多个项目形成一个面，每个项目的根据结构展开的所有CI形成一个面，而每个 CI之间的关系又形成一个面，脑子里当时形成了这图象（这个三维的图形后来尝试了好几次用VISIO或PPT画出来，一直没有成功），想到这一点当时很兴奋，终于看到了一道门。于在是周末休息时，去书店把数字电路的书找来看了一些篇章，最终确定引入门电路的概念来解决关系的问题。

上面介绍的是思考过程，在完成这个思考过程后，在项目启动会上，汇报了此构想，得到领导认可，同时为了验证可行性，我找了一个公司典型的项目做了一次试验，看一下这样的模型是否存在问题。这里要说明一下，我们把结构与关系分离，一是考虑结构与关系是互不对等的，二是可以让其独立作用在不现的地方，这样分离之后，结构与关系本身更加严谨，我们将结构用于事件定位，关系用于故障推演，一个着眼于现在，一个着眼于未来。下面将展开细节说明

一、配置管理规划

由于以前实施REMEDY时，我们积累了一定的经验与知识，也具备一些配置管理的概念，所以规划方面，相对单纯一些，我们以管理科为主导，各业务领域的主管为成员，目标是所有项目的CI项纳入管理，在此作业开展前，我制作了一个作业计划，主要分几个阶段。

1)CI分类规划

2)CI属性设计

3)CI命名规划

4)CI模版制作

5)配置数据收集

细节的作业进程就不一一介绍了，在做这个计划与真正执行时，发现一些很有意思的现象，也算是经验了，这些点我会在下面逐一介绍到，下面将我们的整体的配置模型做一个介绍，

示意1

说明：

客户组织：指我们的客户的组织及用户信息

运维组织：指我们内部的服务机构及员工信息

服务目录：不作名词解释了

运维对象：常态上说的配置管理，即CI的集合

这四个纬度构成我们需要关注的所有配置信息，每一个纬度都是一个结构独立的树状目录，它可以多层级多节点的细分下去（这一点非常重要），在CMDB中我只会放入运维对象的所有信息（结构与关系），而运维对象与其它三个面的关系，也是会存放在CMDB中的，当客户组织、服务目录、运维组织都与运维对象发生关联时，这时，运维组织与客户组织（一个服务人员服务的客户是哪一些，或一个客户对应的服务人员是谁），客户组织与服务目录（一个客户享用哪一些服务，或一个服务哪一些客户），运维组织与服务目录（一个服务人员可以提供哪一些服务，某个服务哪一些服务人员可以提供），这些都可以通过虚拟连接起来，这种模型的建立，会带来日后无比便利的统计分析与查询汇总，同时也会解决我们现在许多管理上的症结。

为了后续交流的方便，我还需要对项目这个名词做一个定义，我是把它当成一个CI的集合，它是运维对象的一个节点，你也可以理解一个项目就是一个CI，这个CI是一个虚拟CI，它可以展开许多子节点，每一个节点都是CI，项目由于是我们公司很重要的一个“单位”，它与结算、人员、组织、服务目录这些都会存在关联，所以后续会经常提到它。

整体模型

上面介绍的都是规划阶段的事情，这时具体的配置工作还没有真正展开，上面的整体模型相当于战略，也是一个重要的基石，它决定了后续许多的事物构造，比如后续要介绍的内容，同时这种模型如此规划时，它如何在其它的流程中作用（比如事件管理、变更等）中发挥作用，也是做了考虑的。说到这个就有一个建议了：

在构建ITSM系统时，我的建议是首先从配置管理开始，而不是通常人们建议的从事件管理开始，配置管理决定地你们的运维管理的精细度与作业方向，它如何规划设计，会直接影响流程，你的绝大多数的数据质量也是由配置管理所决定的，在这个基石没有想清楚与确定前，展开事件及其它流程，最后整个作业可能是松散的，甚至可能是错误的，你的配置管理越精细，它对你的事件流程及变更流程，都是会产生影响的，配置管理颗粒度越细，它对我们的服务人员的作业行为要求就越高，引发的变更控制措施也就越多。在我的想象中，配置管理是一个服务平台的最底层建筑，它也是一个约束整个服务机制的重要所在。所以在项目的最初期，我一直是想先开发CMDB的，先把CDMB搞出来，然后灌数据，直接维护，不用事件管理，也不要变更管理，而是光光的 CMDB，到时我想看看所有的CI信息进去后，整个运维地图是如何的，故障的推演是否能实现，如果这些都是稳固的，再在这个基础上构建其它的应用模块。

CMDB先开发出来还有一个好处，解决了配置数据收集维护问题，我们的配置数据届时会非常庞大，如果先收集，那在系统还未上线前，只能用电子表格维护，考虑到关系、结构的复杂，这基本上是不现实，每天有事件发生，无法做到同步的更新，不先收集，要等到系统上线的准确时间点，完成数据收集，这个难度又太大。（做过ERP的朋友，应该知道在系统上线时，仓库盘点数据导入的难度，只要业务不停，数据总是一个动态的，而我们的配置数据远比这种数据复杂），有了CMDB后，我们有足够的时间去收集试验，同时还可以同步更新。

回复 achotsao 的帖子

二、配置模型设计

1)CI结构

在CI的结构定义中，我们的思路中，有两个关键词，“树状目录”和“父子节点”及“虚拟CI”，基本的理念中，根据BOM的原理去构建我们的配置结构，最终形成的，整个公司的所有CI最终会挂在一个目录之下，象一棵枝叶茂密的大树，一个项目相当于一根树枝，一个CI 相当于树枝上面的一片树叶，树干是父，树枝是子，树枝是父，树叶是子，父与子是一个相对的概念，用一个实例来说明，比如我们一个桌面项目，有2000多台电脑维护，每个电脑由显示屏、主机、电源之类的组成，这个项目就是父节点，每一个台电脑就是子节点，但当颗粒度到更细时，一个电脑由显示屏及主机组成，这时，相对于显示屏、主机而言，电脑是父节点，而主机是子节点了，如果颗粒度再精细时，把硬盘、内存、主板、CPU作为CI管理时，此时主机又是父节点了。

这里还有一个现实问题，一个桌面项目，它的子节点就是2000多台电脑，这样的目录，可能会太长了，不利于管理，这时为了统计或管理的方便，我们可以构建几个虚拟CI，比如按厂区，如果这2000多个台电脑是分布在十几个厂区内的，我们可以将这十几个厂区，也做为节点管理，这时，桌面项目下面的子节点就只有十几个了（厂区），每一个子节点下面的节点只有100多台电脑了，这样更富于结构，也便于查询定位，这是虚拟 CI的概念，它是由于管理的需要产生的，这里面要尤其注意一个问题，当厂区已经作为属性管理时，是不能再为之构建虚拟节点的，因为你的一切管理需求已经在属性中考虑了，所以结构的设计是一个智慧的事情，你要考虑到分类、属性设计的空间问题，不然到时有许多要素重叠，这样一是不效率，二是可能导致数据冲突。

对于偏硬件的项目而言，它的CI结构规划是相对简单的，真正复杂的是软件类的项目，比如象我们的DMS（经销商管理系统）类项目，它是汽车制造商为了管理它的分销商而产生的，一般大型的汽车制造商的分销商（4S店）有200-400家左右，甚至更多。每一家分销商的店内都有一台服务器，安装有DMS的服务端，店内还有许多电脑安装有客户端，而汽车制造商本身也有服务器，它与每一家分销商的服务器对话，交流数据。

这种项目涉及网络，数据接口，几百个的数据库，众多的服务器与工作站，这时的配置规划就有一定难度了，但基本上我还是发现存在一定的规律，在项目下面的一级节点中，按应用服务器、数据库服务器、接口服务器、程序、接口程序、数据库、专用设备、相关组件、相关网络等这样的思种去规划，再逐个细化，就可以理清整个项目的CI结构，这里需要注意的事情是共用 CI的问题，当一个CI的运维权在某个项目时，这个CI的所有内部信息，别的项目只能调用，不能对其进行解释，比如上面说的DMS项目中会用到相关网络（A网路），A网络内部的所有结构与关系信息，都是由网络领域的团队进行规划设计的，DMS项目只能调用A网络本身这一个组件，这一个理念会非常重要，因为当项目众多，组件复杂庞大时，整个公司级的配置结构是难以合作同时构建的，这时需要制定相应的游戏规划，教每个团队按规则去绘制自已的整个树枝，最后会自动组装成一个参天大树，把最专业的事情交给最专业的人，用一种比较简单的逻辑，最后形成一个复杂的东西，象计算机的二进制是如此，象我们的整体模型也是如此，每一个纬度只需要与一个续度建立关系，最后所有纬度会相互关联。这种最简单的逻辑构成的好处在于相互独立，分拆容易，同时容错性强，构建容易。

下图是一个项目的CI结构示意，可以看到都是一个树状的结构，希望可以让大家更加形象的了解结构：(略)


2) CI关系

如果建立我们公司的所有运维对象地图，会发现某种意义上，配置项之间的关系类似电路图，因而引入数字电路的基本逻辑概念，从应用的视角构建新型的组件之间的关系，将组件的结构与关系独立出来，分而治之。在逻辑电路的基本逻辑的类型如下：

与门（当一个事件由两个以上的条件决定时，只有全部条件为真时，条件才能成立）

现实中，如果一道门有两把锁，只有这两把锁全部打开时，门才能打开，这就是一种与的关系。

或门（当一个事件由两个以上的条件决定时，只要任一条件为真时，条件就能成立）

或的关系，在IT环境中就很多了，比如将一台编号为A001的电脑这个CI，与其子节点的，CPU、内存、硬盘、操作系统等就是一个或的关系，即只有CPU、内存、硬盘、操作系统这其中任何一个CI出现问题，都会导致A001这个CI出现问题。

非门（当一个事件的条件为假时，对象才为真）

非的关系，我们暂时不考虑加以引用，本来的是考虑利用此非的关系将CI的备件等进行关系构建（备用设备，或维修备件），但想到一些现实问题，备件用其它的方式进行管理，不直接引用关系，以免过于复杂。

这里面还需要说明几个比较重要的概念：

关系的视角：

我们构建CI的关系，是从被影响的角度出发的，这一点非常重要，因为事实上中关系总是双向的，一号CI会影响别的 CI，别的CI也会影响一号CI，这时如果双向构建很可能会导致重复构建或错误构建，由于我们的关系只需要用来分析当故障出现时会导致的结果，所以我们只用单流向的关系，即可满足需求（这个道理类似以面介绍的，用简单的逻辑组装成一个复杂的事物），因为当所有CI从被影响的角度出来后，网状关系即已形成。这一点需要很好思考一下，不然理解会出问题。下图是一个应用方面的示意，我的想法利用关系，届时可以图形化推演故障路线，这样可以直观的采用紧急预案切断故障路线（红色为故障组件）。


关系构建原则：

在逻辑上，可参一个CI会直接与间接与所有CI有关系影响，但很显然，我们无法将一个CI直接与其它所有CI去构建关系，那需要找到一个机制去解决这个问题，说到这儿要说一下我的爱好，我一直喜欢看DISCOVERY的节目，大家在看到一些自然记录片时，会看到一大群鸟或蝗虫在天空飞行时，是聚集在一起的，象一团乌云一般，再或者我们在看海底时，那些鱼群在水中游动时，总是保持一个集合，不管它们往哪个方向游动，总是非常有效的保持一个群的形态，这些东西看起来很有美感，并感到有些不可思议，其实在这个下面，只是一个简单的原则，当鱼群游动时，每一条鱼只需要与邻近的鱼保持适当的距离，这样最终就会群。我把这个叫鱼群原则，在CI的关系构建时，我当时也碰到如何去有效构建关系的问题，最近我发现利用这个原理，可以解决，即一个CI只与结构相邻或直接影响的CI构建关系，这样构建关系就会简单很多，当每一个CI用这样的机制去构建完成后，也会形成一个庞大的群，会把所有的CI有机制的串联在一起。

在用与、或的关系构建关系，我发现一个原理，如果IT环境的与关系越多这个IT环境是会相对稳定的，不易被故障将环境瓦解，同时故障的影响度也会较低，因为一个点发生故障，不会马上导致业务应用出现问题。或的关系越多，运维将变成更为吃力，因为每一点的影响都会导致后果发生。这也某程度上指导了我们日后的方案设计与运维管理。

是不是我们现在的这种关系构建是完美无缺的？它到底存在什么问题，有什么局限性，这一点真正深入思考的人，应该会发现关键所在的，在我所构想的整个配置模型中，有两个比较大的局限，我不打算独自一个人去挑战这两个最难的命题，因为我很清楚对于当前的业务而言，这个模型可以满足他们很多年，我再深入去挖掘，对于业务需要而言，过于超前了，同时我个人不太希望在这个方面走得太过深入，也因为志不在此，如果真正投入精力去研究，我觉得是有可能找到一个终极模型的，因为我已知道方向在哪儿，局限何在。想到这些我就对现在的这些理论传播者或那些顾问公司有意见，这些东西是不应该由我们这样的公司，或者我这样的人去研究的。就象我写的这些文字，我相信那些ITIL的制定者、传播者是没有告诉过我们的，我在项目初期在在百度与 GOOGLE上流浪N久，就是想找到我现在写的这些文字，但一无所获，有的只是那些大而空的理论，听起很有道理，但是你根本无法将它与现实业务去结合起来思考。不扯了，继续往下！

3) CI分类

本来按正常的逻辑，CI分类应该放在第一位去思的，而不是先去说结构谈关系，这样做一是因为我们的确是先把结构与关系理清后，才去做CI分类的，二是觉得在结构关系没有做一交待前，可能先谈后面的东西，会不利于了解，这也是因为社会上没有把CI的结构与关系跟我们做一些规范或定义，才造成的，正常来说，我们真正开始做具体的配置工作时，CI分类应该是第一步，这个过程会非常重要，在没有真正开始做前，我还没有意识到它的影响会这么大。

再说明一下项目的情况，配置的结构、配置的关系，基本上我一个人去完成思考的，没有动用到公司的管理资源，当这些定下来后，开始做CI分类时，这就需要走出办公室，调动管理资源了，因为这不是一个人思考就可以决定的，这一点很重要，日后各位从事这样的活动时，也需要把管理资源拉上，能抓到多少资源就要去抓，这是一个很好的洗脑的过程也是一个很好的互动过程，让具体的业务领域及高层管理者开始真正参与进来。

记住一句话：CI的一级分类决定了配置管理的范围，CI的最底层分类决定了配置管理的颗粒度。这句话是后面真正领悟总结出来，一开始也没有意识。CI分类我们的做法是这样的，我们先找一些对业务领域比较熟的专家或管理者，首先谈CI的一级分类，我们谈着谈着，发现谈不下去了，因为没有具体的数据支持，我们根本无法确定一级分类，于是我们转变策略，先发模版，让公司的各个业务领域把自已所有的运维对象全部罗列出来，最终收集上来是五花八门的清单，这就是我们最初的数据，然后我们再组织人员讨论。现在的体会是，分类真的是一门艺术，更是需要智慧的。这里面要说一下我们有两个优势，一是我们是从系统实现的角度才开始这项工作的，所以我脑子里事实是有一个预期的，虽然我不知道具体分一类有一些什么东西，但我很清楚分类对不对，能否有效，有没有扩展性。二个是我们以前实施过REMEDY，业务领域的人员具备一定的分类基础。

经过讨论后，我们把一级分类确定下来了，这里又得废话几句，我一直也不觉得这个工作是我们需要花如此的气力做的，我们也与顾问公司交流过，他们基本上没有给出任何有用的建议，IT的设备或环境，全世界也就那么一回事，我一直奇怪居然没有一个关于分类规范或建议，网上也是查不到相关的有用信息。最终我们把一级二级的分类，大家分工确定下来了，然后再发布给各个业务领域评审，是否有遗漏的，分类是配置的最基础一项工作，如果分类不当，带来的后果很严重，你的统计分类，你后续的属性设计都会受到影响，而且日后你想对某一个类做调整时，这是一个非常复杂的工程。

CI的分类我们最终的结果是，将CI分类，分为三层，一层分类为六个：环境、计算机及外设、软件、通讯、网络、文档代码。最低层的分类为190个，现在让我来说一下我们的分类原则，好象我很难总结得出来，这是一个倒推的结果，我们的分类也不是完美的，因为有许多IT 设备你很难去定义它属于哪一个类，比如我们有两个二级分类一是计算机配件，一是存储设备。一个硬盘，你说它属于哪一类呢，好象两者都可以放进去，又好象二级分类不对，但是我们有着大量的鼠标、键盘、光驱、内存条、显卡、网卡这些配件存在，所以必须有一个计算机配件的分类，另一方面我们在磁带设备、磁盘阵列、带库、光存储设备，这些又必须建一个专门的存储设备的分类出来，这样的情况还好好多，我相信随着IT技术的发展，原有的分类还必须打破，因为技术与产品的换代，使许多分类的界限完全打破了，所以在分类时还需要一定程度上考虑未来技术发展，有一些IT设备现在虽然数量不大，种类不多，但现在有明显的趋势看出未来一定会独立发展成一种专门领域的话，那就有必要先把分类建好，一个目的，最大可能的减少日后对分类的调整。

另外还有一点需要说明的是，CI的结构与分类，很多时候是会让人混淆的，比如在我们最底层的分类中，硬盘、内存条、CPU与计算机是并列，当时有人认为硬盘、内存条、CPU等是应该在计算机类下面的子类中的，这种意识是好多人都会存在的，包括当时我们的领导也是觉得这样的分类好象不对，也认为应该如此。但事实上这样是不对，他们都把CI的分类与CI的结构混淆了，而且忽略了分类的根本意义，硬盘、内存等都是计算机的组成部份，这是一个结构信息，我们分类是为了把所有CI种类做一个分类，然后在构建CI结构时，再把每一个种类进行组装，分类不需要考虑任何的结构信息，再说分类的作用，分类更多是为了日后的统计，如果把计算机作为一大类，把硬盘、内存等作为子类，这样统计出来的数据全部是错误的，因为这样分类的话，程序会把每一个硬盘、内存条都作为一台计算机统计出来，统计一个父分类时，一定会把其所有的子分类全部计入。所以有时我们从程序实现的角度来考虑问题，也带给我们一些便利。最终我们的做法是，建了两个大类，一个是计算机整机，一个是计算机配件，把硬盘、内存、CPU这些东西统统丢在计算机配件中。

本段开头的第一句话是：CI分类的第一层分类决定了配置管理范围，最底层分类决定了配置管理的颗粒度，我们的一层分类是：环境、计算机及外设、软件、通讯、网络、文档代码，这是我们的配置管理范围，告诉我们这些东西是我们统统要管理的，最底层分类，比如计算机及外设这个一层分类中，分了计算机整机与计算机配件，而计算机配件这一个分类下面，又分为鼠标、键盘、光驱、内存条、硬盘、CPU、显卡、网卡、电池、电源等，这个最底层分类告诉我们，我们日后关于计算机及外设这个配置管理范围下面的颗粒度要达到CPU级的，事实上CI分类的过程就是你配置规划的过程，它是你整个运维目标及能力的提现，它决定了你日后约大多数的服务活动。

关于分类有一点说明：如果你的仓库中存在某一款配件的话，即便你的配置管理颗粒度不想达到一个级别，你也最好需要为此构建分类，同时这一类的配件，你需要日后构建为CI进行管理。比如，如果你是做桌面运维的，你的配件仓库中存在硬盘的备件，那么你就需要建一个分类出来，同时你在构建CMDB时，每一个硬盘你最好作为CI管理，不然这会造成许多问题。这也算是分类的一个原则吧，任何你需要加以关注的设备或配件，都必须可以被分配到你CI分类的某个最底层分类中。
最后一点需要说明的是，分类与属性的平衡，分类时要注意，如果有一些信息是可以利用属性控制的，可以适当减少分类，比如鼠标，有光电的，也有普通滑轮的，这是两个不同种类的东西，但是我们没有必要为此建两个分类，我们只需建一个分类，就是鼠标，同时多为这一个CI 分类多设计一个属性，叫鼠标类型，这样通过属性就可控制了，同时后续的统计分统也可以满足了，这里没有一个很硬性的标准，比如计算机，有大型机，有小型机，有普通的工作站或服务器，为什么计算机就需要做多个CI分类，而鼠标就不用分类，用属性控制呢？，这是由属性的异同决定的，如果同样一个范围的IT组件，它们的属性是很接近或相同，我们就是没有必要建多个分类；如果它们的属性差别很大，这时就需要多建分类了，这是为了管理的便利。所以我一直说分类是一个智慧的事情，就象配置管理的颗粒度一样，这需要去各方面平衡把握的。CI分类就说这些了，真正在做分类时，相信大家就有体会了，这些也不是抄书或谁教的，都具备的作业过程中个人的一些经验与智慧。


4)CI属性设计

当所有CI的分类确定后，下一步的工作就是需要设计属性了。说到这个可能还是得做一些知识或概念说明，因为这方面的资料并不多。

在编程中有一个概念叫面向对象，我们在配置规划或构建CMDB时，跟这个道理有一些类似。说简单些，我跟刘德华，我们是否不同，取决于我们各自的属性，属性可能理解为对我们的信息的进一步补充，对我如果我们需要的信息不多，可能我们的属性只是：身高、性别、体重、面容等等，这时刘德华没有我伟岸，我也没有他帅，所以我们就可以区分出来了，我是我，他是他，这是我们的属性不同，但是这里需要注意，这里我和刘德华是不同的对象，但是我们属于同一个分类（都是人）、我们属性范围是一样的，只是属性值不一样（身高不一样，长得不一样），我们的想法是根据分类设计不同的属性，两个不同的分类，是因为属性范围不一样，人的属性有身高、性别、体重、面容等，计算机的属性有制造商、品牌、生产日期等，这时人与计算机的属性范围是不一样的，所以是不同的分类，所以我们前面说了CI分类，那一个CI分类跟另一个CI分类有什么不一样，这是由各自的属性决定的。这是第一个概念。

第二个概念是父子继承的概念，即子类会继承父类的属性，父类有什么属性，它的子类就一定会有，如果我们的CI分类有三层，那么第三层的分类，会继承其第二层，以及第一级的属性，比如计算机整机这一个分类，下面分有大型计算机、中型计算机、小型计算机、工作站等这几个子类，如果计算机整机这一个分类有属性：制造商、型号、购买日期等这几个属性，那么大型计算机、中型计算机、小型计算机、工作站这几个分类都会有制造商、型号、购买日期这三个属性。这是继承的概念。

CI属性设计，我们的工作是这样展开的，我们把所有CI分类清单确定后，确定分工，哪一些人对哪一些IT设备是最专业的，就由他们来设计属性，这个工作是比较复杂的，因为最后需要做大量的整理工作，因为事实上许多分类的的大部份属性是相同的，我们需要把属性整理好，做到不重复，比如计算机有属性叫型号，空调有属性叫机型，这时事实是同样的属性，我们需要把它统一起来，我们发放的是最底层的190个分类，这样每一个分类由不同的设计属性出来后，我们再统一命名，然后将属性上浮，因为许多属性可以提升为二层分类属性，甚至提升为一层分类属性，甚至是公用属性，这个工作需要比较好的大脑才行。

CI属性总的来说，分为公用属性、一层分类属性、二层分类属性、三层分类属性，还可以设私有属性。所有属性最终形成一个“属性池”供每一个分类去取用。然后当我们真正需要建立一个CI项时，首先要确定这个CI属于哪一个分类，如果它属于计算机硬盘，那么它会自动拥有公用属性、计算机及外设属性（一级分类属性）计算机配件（二级分类属性）硬盘属性（三级分类属性），我们需要做的是填上每个属性的属性值，这样一个CI就完成建立了。

另外有一点需要说明的是，属性的设计也是一个智慧的事情，取舍会非常重要，我们是先穷尽收集，保证每一个CI类需要关注的信息都收集上来，然后再做挑选，因为有许多信息是没有价值的，或者本身的信息是难以取得的，象一些高度动态变化的信息，是不宜取用属性时行管理的，比如CPU的使用率，除非你有底层的监控软件可以自动通过数据接口读取到系统中，否则这个信息是无法维护的，所以就不用为CPU这个一个分类，建一个占用率的属性。要考虑到日后的服务成本，量力而为，如果构建得信息无法进行维护，一是影响CMDB的数据精确度，二是带来服务成本增加过大，一旦设计了这个属性，那么日后这一类CI的这个属性发生变化时，需要进行监控与管理，这个成本是相当可观的。

三、配置管理的后续工作

当完成上述的配置规划动作后，需要做二件事件，一是CMDB的构建，二是数据收集模版的设计。我一直的看法是，当 IT服务到达一定的规模后，尤其是当IT组件庞大时，在没有系统实现或支撑的情况下，做深入IT服务管理是空谈的，暂不说事件、变更等流程，光是配置管理，没有系统的支撑，是根本无从保证质量的，这里我觉得有一个规律，做管理咨询的公司往往是自身公司的管理最需要被咨询的，做软件的公司内部往往也是最需要信息化的，做IT服务管理的，可能也是最需要接受IT服务管理的，我们在提供IT服务的同时，我们自身的IT应用其实做得远远不够。（编辑：建丁）

不错，支持一下。