支持楼主继续，这种实战的内容太好了

开始接触CI的时候，我的想法和破子一致，觉得CI的结构很象BOM。但是我没在企业做过，对BOM的认识比较粗浅。这里看了的确是有了更清晰的认识。

通读完此篇文章，最大的感受就是：对于配置管理，我们有了一个明确的、可以具体指导的思路。我们的业务没有这么复杂，也不可能考虑设计开发一套ITSM软件。但是对于CI，对于CMDB，我们即使没有使用什么IT服务管理工具来实现，但这些CI分类、结构及其之间的关系依然是我们要考虑的。

让我们再来回味其中的经典思想吧：
1、一个CI只与结构相邻或直接影响的CI构建关系。
2、CI的一级分类决定了配置管理的范围，CI的最底层分类决定了配置管理的颗粒度
3、在分类时还需要一定程度上考虑未来技术发展，有一些IT设备现在虽然数量不大，种类不多，但现在有明显的趋势看出未来一定会独立发展成一种专门领域的话，那就有必要先把分类建好，一个目的，最大可能的减少日后对分类的调整。
4、分类是为了把所有CI种类做一个分类，然后在构建CI结构时，再把每一个种类进行组装，分类不需要考虑任何的结构信息
5、CI属性总的来说，分为公用属性、一层分类属性、二层分类属性、三层分类属性，还可以设私有属性。
6、当IT服务到达一定的规模后，尤其是当IT组件庞大时，在没有系统实现或支撑的情况下，做深入IT服务管理是空谈的
7、信息是无法维护的，所以就不用为CPU这个一个分类，建一个占用率的属性。要考虑到日后的服务成本，量力而为
8、分类与属性的平衡，分类时要注意，如果有一些信息是可以利用属性控制的，可以适当减少分类
9、属性的设计也是一个智慧的事情，取舍会非常重要，我们是先穷尽收集，保证每一个CI类需要关注的信息都收集上来，然后再做挑选，因为有许多信息是没有价值的，或者本身的信息是难以取得的，象一些高度动态变化的信息，是不宜取用属性进行管理

破子，我今天又想了下，虽然说CI结构和CI分类没有关系，可是CI结构有分类，CI分类，这两个在正式实施CMDB的时候是如何建立的？如何在CMDB中同时实施CI结构和CI关系，以及CI分类？

颗粒度讲下

yujunhappy,一看你的问题，就是没有好好把文章看懂，罚你重看十遍！
CI的结构与分类是没有直接关系的，比如我们身体的组成部份，有手、有脚、有头，有躯干，手、脚、头这些都是一个类，我们世界上的每个人都是不同类的这些东西组装起来的（这个比喻可能比较烂？），结构描述的是一个CI的内部结构的详细信息，一台电脑，它是由显示器、机箱、电源、CPU、内存、主板、硬盘等等组成，这是结构告诉我们的，但是CPU、内存、主板等这些东西都是一个种类的，这就是CI分类，每个CI类都会有自已的属性的，在CMDB中当在建一个CI时，如果定义这个CI是一个“内存”类，那么这个CI就会继续内存类的所有属性集。
再看看文章吧，然后再交流
、

那破子，我这么理解你看对不对。就拿一个学生管理系统来说吧，各个目录比如哪个年级哪个班就相当于CI结构，而具体到最后要填充学生的具体信息比如姓名、性别、年龄、户口等，就是CI分类了，而每一个具体信息就叫做CI的属性，

破子，我今天又整理了一遍，我推翻上面的说法。

6楼的兄弟，你的理解也有一些问题，我再说明一下吧
人分为男人、女人，这是一种分类，男人是一个类，女人是一个类，这是一种分类方式，但我还可以这样分，人分为学生、工人、其它这三类（其实分得不够好），学生就是一个类了，工人也是一个类的，这时学生有学生自已的属性：姓名、性别、学号、学籍、所在学校、所在学科等，工人也工人的属性：姓名、性别、工号、社会保险、身份证号、婚否等等，学生与工人是两个不同的类，属性也有所不同，但也有一些属性是相同的，比如姓名、性别；其实还可以继续细分，把学生按小学、中学、大学分，把工人按行业分，然后再根据每一个类设计属性。
这样类与属性的关系明白了没？其上面还有没有介绍完，按类设计出属性后，后面还有工作要做的，这是后话了
我是破子

我刚吃过饭，再说两句，是不是我表达能力太差了，我的整个配置的想法，跟公司的领导与同事也是讲了好多次，讲得我都烦了，结果他们也是有一些似是而非的，我现在把这些写下来了，各位看起来，还是不太明白一样。
不过谢谢你们有真正看我写的东西，我还是很开心的。你们要把我的两篇文章结合起来看，不要只是看配置管理2，还有一篇配置管理1
有问题继续交流，我一直回复到你们满意为止，好不好？

当完成上述的配置规划动作后，需要做二件事件，一是CMDB的构建，二是数据收集模版的设计。 这个破子也大概的讲讲哈。

破子，我想了一下，大家之所以把结构和分类混淆，我觉得是因为你一直强调的是CI结构和CI分类不是一个层面，没有直接关系。可是CI的结构是由各个CI组成的，CI分类也是由CI项组成的，都是和CI相关，所以这个时候就很容易让人产生迷惑。
我再说下我今天看完后的理解。就像人的骨架一样，有两条腿，两个胳膊，这4个就是骨架结构的一部分，然后两条腿就属于CI分类中的腿骨这一类。不知道我这么说对不对。

yujunhappy，你精神可嘉
我说后面的事情是，类的属性收集上来后，还要做属性分析动作，决定哪一些是公用属性，哪一些是一类属性、二类属性，还有做命名规范之类的事情，这样才把属性池确定下来，再制作模版，再去搞CMDB建设
CI、CI属性、CI分类、CI结构、CI关系，这几个不同的对象要区别清楚，CI结构与CI分类的确是不同层面的东西。就好象说一个公司的组织架构和男人、女人，你说这两个东西是有关系的吗？这是两个不同层面的东西，你一定说他们有关系也是可以的，因为组织架构中会包括人员，人员又分男与女。但在我们说的CMDB的逻辑上最好还是区别开，不然会很麻烦的。
看你说的骨架、腿、胳膊又是腿骨的，看得我心惊肉跳的，太汉尼拔了吧。。。怕怕。。。。你再继续下去，担心过一阵子内脏都会出来。。哈哈。。。

你好：
我的CMDB中有两个CI，主干交换机（CI-01）和边缘交换机（CI-11）,物理环境中两台交换机通过一根网线相连。
请问：
1）这两各CI关系如何？
2）这两个CI的影响或方向？

我不太懂网络方面的知识，但可以谈谈老兄说的问题
主干交换机与边缘交换机在配置结构上相连的，但在这两个CI并非一定要有关系，因为主干交换机的损坏并不一定会导导致边缘交换机损坏，交换机的损坏会影响某段网络（另一个CI），而不是影响平级的CI，所以就我的理解，你提到的这两个CI只在结构中构建，关系不需要构建。
老兄可能发现了一个问题，即在我构想中的配型，在关系的推演中，其实不是完美的，只是一个抽象的表达，把关系的影响定位在CI这个级别，并不是最终的解决方案，但就一般企业，包括我们公司而言，根本没有必要也没有办法承受我认为的终极的模型。事实，到今天，我的配置模型以及CMDB的设计中，已经跟文中提到的有一些不一样了。

不错，很实用！

破子，你好！
一直在关注你的文章；你的想法让我受益匪浅，在此表示深深的谢意！
你用“关系”的概念来破解评估“影响”的方法很值得借鉴。但是从现在的“关系”思想中，我觉得还可以更加完善一些，与你一起探讨一下吧。先说2个不成熟的想法吧，一是没有解决CI-业务-用户之间的关系。既然谈到影响，首先应明确主体即影响的是“人”（相关方），如果不影响到人，那么这个影响是无所谓的，因此，我觉得CI关系的推理逻辑应是CI-业务（应用系统）-人；所以，在CI模型中，我建议增加“业务系统”元素，但与其他元素什么关系、什么逻辑我也没考虑清楚。第二个问题，其实也是一个建议，用“系统”的概念来考虑ＣＩ关系和架构。系统这个词是我在深究“Category”和“Class”的区别时、也是ITIL中提高的System概念学习到的。能否用现有的ＣＩ关系解释、呈现系统或子系统的轮廓或形象？我也在思考中......
　　因急于与你探讨以上所述考虑的还不成熟，请指正！另外，能否让我们欣赏一下你的“终极模型”呢？）：

楼上的兄弟你好，可以一起交流一下：
1、关于你说的人的概念，其实是纳入我的模型中考虑了的，等说，我的一个设备或系统坏了，会影响哪一些人（用户）是可以计算得出来的。这个在难度倒并不大。
2、你说的业务系统，我没有完全理解，如果你说的是一个应用系统，其实就是我模型中的一个CI，这个模型中也有解释了，我就是再多介绍，如果你说的业务系统是指“服务”，这个问题我去年时也思考过，但想了很多，决定不纳入模型中，原因是：一对于服务的定义是非常困难与穷尽独立的，比如一个应用系统，它的每一个功能点就是一种服务的体现，但并不等同于服务，同时服务与服务之间也是有逻辑关系的，从逻辑而言，你的每一个CI都会与一个服务关系到，另外我们作为IT服务商，着眼的第一点是把我们的基础架构管理好，我们把每一个设备与系统维护好，更快的响应，只要我们的这些东西是好的，对客户的服务也会是好的。同时将服务做为一极纳入模型，这太过复杂了，就我们公司而言，应用起来不太现实。所以当时在模型思考时，我只把我们的服务目录纳入模型之中（注服务目录并不等同于服务）
3、严格意义来说，根据我的模型完成可以图形化整个基础系统，甚至可以把网络拓补图自动画出来，甚至可以组装出一个机房的图象。当然这些是需要一定的软件实现能力的。
4、关于我上面说的2、3两点，美国的MO美奥公司已经实现了，前段时间他们公司过来跟我们交流，他们讲的是BSM（业务服务管理），他们就把你的服务纳入其中了，而且他们的界面表现力很强，整个基出设施可以象GOOGLE地图一些翻转查看，我个人感觉，他们的想法跟我的差不多，唯一就是把服务作为一极做进来了，但是他们也只是定义了关键服务（我个人认为，在实际应用时局限很大的，而且非常困难）
5、我说的终极模型，最高就是突破上面的说“服务”，最底层就是突破“属性”，整个完整的体系，现在还是没有有效建立起来的，只是知道方向何在，主要也是没有需求，公司没有这种需求，光现在的模型5年内公司可以应用好已算不错了。
6、我的博客与资料都有时效性的，前面的文章与资料，只代表我以前的思考，事实现在，配置模型我做了一些调整了，我也不回头去更改以前写的文章，因为我写这些最重要的目的一是交流二是记录我一生的思考。

CI 信息的录入、更新、同步问题如何解决？

CI 信息的录入、更新、同步问题如何解决？
同问，如何保证数据？你们的维护流程建设怎么做的？

CI的信息的录入与更新，的确存在一个同步问题，我们是这样做的，CI锁定：当一个CI发起变更时，此时把这个CI锁定，只有当变更终结才将这个CI解锁，这样可以保持一个单线程对CI进行维护，以免引发多处维护导致的错误。
CI的数据正确，我是这样考虑的：对于一个ITSM系统而言，更重要的是保证生产环境中的配置正确（而不是CMDB的正确），CMDB的正确固然重要，所以在变更中进行控制，事实上我们把CMDB的维护授权给了很多人员，为什么这样做呢。我是这样认为的，当一个运维人员可以对生产环境的这台设备做调整与维护时，他是应该具备有维护这台设备的配置数据的权限的（当然这也是受现实条件的限制，你让别人改，一是效率问题，二是数据更新问题，三是同样起不到控制的作用），我们在配置模型中哪一些人可以维护哪一些设备其实是可以定义的，最后每个阶段再做配置数据的审计，总体来说就是这样吧。
以上可能讲得不够细，楼上的兄弟再看看。。。

从来没有看到过经过这样细致思考的关于CMDB的文章，很有收获。不过既然破子已经能够看到自身配置模型的局限及以后的模型扩展问题，还特别特别期盼着破子能跟大家分享你的先知！

在这里请教破子一个细节问题：
CMDB一个非常重要的作用是通过CI之间的关系来发现故障或者变更影响，正如图中所示发现元凶组件的例子。但是我一直感到比较困惑，CI之间与或的关系是根据什么来确定的？硬盘、网卡、程序、IP地址，一个主机之中个别程序模块的问题可能只导致局部的问题，不会影响到其它的组件，而一些构成的硬件问题却是致命的，到底参照什么标准来设置组件之间的关系呢？望指教，谢谢！

楼上的二位：
1、关于配置模型的局限以及扩展的问题，由于不是十分成熟，所以暂时不想整篇的进行介绍，原因是一来近来一直忙着杂务，无法抬头静下心来思考，二是即便是我规划出来了，以我们公司的技术能力与应用空间都不是特别现实，所以没有太多冲动去折腾了。我个人觉得象MO与EMC这类的公司才可能需要这种级别的模型的。
2、在当时的规划中，与或的关系确定完是需要凭借你的知识，如果A-CI一旦出现问题，B-CI就会出现问题，即B与A与或的关系，如果只有当C-CI、D-CI同时出现问题时，A-CI才会出现问题，则表示A跟C、D是与的关系。如果你认真的思考，其实你会发现与、或的关系是一种伪关系。所以在CMDB开发时，我把这两种关系类型去掉了，换成了“构成、连接、需要”。你的这个问题其实接近问题的核心了，这也是我说CMDB模型的局限，以当前的模型，是很难接近模拟现实的物理世界的。

谢谢破子的及时回答，而我抱歉，出差才回来。如果实际构建中换成成了“构成、连接、需要”，你在树级显示时是参照什么关系呢，是否以构成关系显示，而查看影响时参照连接和需要关系。另外，这种关系建立起来，要去有效、省力维护这种关系的关键是什么？相关的软件最好应具备什么功能？谢谢啦！

树级显示时还是以构成为根进行展开的，按树展开时，只是每一个节点（CI）的连接、需要关系也会展示出来。
我觉得关键在于两点，一是你的设计要合理，二是这种维护要下沉到工程师的手中。
软件的功能我觉得常态下的CMDB的功能都会有的，只是关系的推演可能会特殊一些。

感谢回答！

最近单位总部利用CA unicenter实现了事件管理、变更管理、问题管理,但没有实现配置管理。
根据ITIL的要求,其实变更管理是需要配置管理做基础的,因此本人希望能在CMDB和CFCA做一些尝试,翻阅和搜索许多ITIL资料,感触和您一样,多是些概念和条筐,直到今天拜读到您的文章。
由于经费原因，可能无法购置相应流程工具实现，请问您单位是自行开发的，还是利用了BMC的工具，谢谢！！！---老江汽

另外，在以后的开发设计过程中，还希望得到您更多的指导，！！！---老江汽

我们是自已开发的，以后可以交流交流

谢谢破子