经过半年多的时间，终于把CMDB的设计工作结束了，时间虽然不长，但感觉象是很长一样，同时感觉到经过一次的思考过程，对于管理或事物有了一种新的视角，说不清是什么，只是更清晰了，好象有一点面对对象的概念一样，发现现在去破解一件任务或工作，更加容易了。
    俺是一个喜欢思考的人，对事物的看法比一般人要深入些，有些象越狱里那个MICHAEL SCOFIELD，那家伙看东西可以把内在的物理结构看清楚，俺没有那么高杆，只是情况有些类似，喜欢去思考事物的本质，俺也不认为我是一个智商过人的人，因为这在读书时已证明不是了，这种情形我不知道是后天训练的结果还是先天的性格等造成的，有时我感兴趣的东西跟别人不太一样，我喜欢坐在公交车里去思考那个该死的无人售票车的车票钱是如何交付的，怎样避免不被人贪污盗用？，那些态度恶劣的司机们每天象塞沙丁鱼罐头一样往车里装人，是一个怎样的绩效管理机制让他们如此？美国的登月工程与他们的第一个核子工程是如何实现管理的，数十万人要组织协同，各种物资的调配是怎样实现管理的，我会好奇这些东西，有时达到一种病态的地步。

   在我规划设计CMDB时，有各种人与资料告戒我，CMDB的设计要如何如何，难度是怎样怎样，今天回过头来看，真正理解CMDB并把握应用的人是极少的，包括那些顾问公司的顾问们，最终完成这份工作，外界的人与资料起到的作用很小，有时个人觉得国内可以独立完成这种设计结果的人不会超过50人（可能10个也不到），这可能让大家觉得狂妄了，但我个人真是如此认为的，但这份工作本身并没有结束，后续的应用才是关键，但我相信最终如果出面质量问题应该不会出在模型本身。下面是我将对一些我不太认同的观点进行说明一下，希望大家不象我一样在一开始又是被顾问恐吓，又是被网上的资料恐吓，搞得诚惶诚恐的，真正把脚站在你业务上，有一个清晰的头脑与思路，比什么都重要：

1、配置管理的颗粒度问题
   颗粒度过细的问题，我一直强调一个观点，全世界没有一个人可以给某个公司正确的配置管理的颗粒度的硬性指导原则，这不是一个硬性或可以测量的事物，但有一些基本的道理在内可以帮助我们思考，第一原则是颗粒度与我们运维能力成正比，当你可以去修复一台电脑的内存条或硬盘时，你的颗粒度就需要到达内存条这一颗粒度，如果没有这个运维能力，你只需要关注整机；第二个原则是当你需关注配件时，你的颗粒度最好能够覆盖到这一层级，因为在配置管理中，备用件的信息是起码需要关注的；第三个原则是你的管理需求决定你关注信息的多少（属性池）。而我正是根据这些原则引入模型来具体应用的（CI类有多少，CI属性有多少），讨论CI类有多少，这些一定要与具体负责运维服务作业的主管与工程师讨论交流确定，要防止有为了某种完美去追求极致的现象发生。对配置这项工作而言，需要有人能够超前思考，我们不能去确定一个CI分类与属性池，结果过不了一年就进行大的调整，因为CI分类与属性池局部的调整是可以的，但大范围改变，势必会引发混乱，比如打印机，现在大家为了贪图省力，只建了一个分类是打印机，那么我们几百个针式的、喷墨、激光的各式打印机都会被划入打印机这个分类中，但用了一段时间后，发现这样信息是不够或管理不方便，又想把打印机下面再建几个子类，把针式、喷墨、激光这几个建成子分类，这样意味着需对在CMDB中的已有几百台打印机进行重新维护分类。这还不是最麻烦的，如果日后的有一种既可以打印又可以传真的机器比较多时，而我们又没有提前设计好这个分类，到时如何划分呢，划分到打印机不合适，划分到传真机也不合适，甚至有可能对原有的分类造成冲击，这样原有的整个分类体系就可以需要调整，这才是最可怕的。所以在配置管理活动中，需要超前意识到管理需求与技术发展，这是一个智慧的事件，不能为了图一时之便去把难题都留给未来解决，一定需要预留空间发展，减少未来大的调整次数。关于配置管理颗粒度的最后一点意见是，一定要关注你的运维能力（变更控制能力）如果你没有办法能力对你置入CMDB的信息进行控制，必然会导致失败，建议的做法是，归划好CI分类，属性池可以逐步有战略的扩充，如果你的运维管理能力成熟度高，那OK，一步到位。

2、CMDB的维护成本问题
   CMDB日后的维护成本也是大家比较关心的一个问题，事实上CMDB的维护成本与颗粒度是与正比的，因为信息越大，维护成本就可能越大，这里面我要说明三个观点：一顾问公司与我们的目标并不是时刻一致的，他们的意见有时我们需要过滤。二是维护成本与服务活动是相关的，当我们的服务活动真的造成配置信息改变，是必须记录的，这个成本是必须付出的。第三是维护成本真正分析后，我们会发现它是一个弱成本。具体说明如下：
     我们对日后维护成本的担心，更多来自顾问们的建议，对于成本问题，我在半年前构建我们公司模型时就考虑过，要构建配置模型时，如何应用，如何维护，如果调用，甚至在事件、问题、变更中哪几个界面会有接口调用，我都考虑好了。我们公司也是一个项目型的公司，出于成本考虑，当合同金额确定时，我们会希望客户在最短的时间完成项目交付，同样的道理，顾问也会一样考虑，顾问们第一考虑是认证的问题，你的配置做得粗放，不会影响认证，但你做得越细，对顾问公司而言，没有收益，只会增加相应的作业成本，因为你会把项目周期拉长，也会产生一定项目风险，是不是把CMDB做实，这不是顾问公司关心的，这一点会非常重要，对顾问公司的建议，首先要考虑他们利益立场，然后再理性的客观分析，我从来不迷信所谓的专业权威，这只会导致盲从。

    在运维服务作业中，真正的成本取于我们的运维活动，你的运维活动越多，你的成本就会越大，而你每一个运维活动如果产生或改变了信息，从管理角度而言，就必须记录的，当我们把客户的5000台电脑的配置记录在CMDB时，当一个工程师把一台电脑的硬盘更换了或者操作系统升级了，我们不应该做相应的记录与控制吗？这里面真正的成本是工程师在更换硬盘与操作系统升级的时间，而不是在CMDB中做信息维护的时间（这是大家一直混淆这两个概念，真正的运维成本与CMDB的维护成本是两回事，CMDB不管是不是需要维护，我们的运维成本还是摆在哪儿的，因为那个硬盘你还是得去更换，操作系统你还是得去升级），这种信息的管理是最起码而必须的，我们不可能说客户把5000台机器交给我们，而最后我们这5000台机器的起码配置信息都不知道，这里不谈什么我们的服务产品化，而是一个最基本的管理规范问题，这种因管理规范而产生的成本，作为服务商必须自我消化，如果连这种信息成本都无法承担，只能说明两种情况：要么，我们的运维业务根本没有市场竞争力，要么客户服务支付价格过低，不值得签订下一次运维合同。就我对当前的运维业务的了解，一般是完全有空间去规范这种基础管理的。

   最后具体来谈谈CMDB的维护成本，CMDB维护成本取决于两点，一是我们的配置管理颗粒度，二是作业过程中对配置信息产生变更的次数。首先说我们的配置管理颗粒度，配置信息的多少与CMDB维护成本是有关系的，但不一定是成正比的，因为有许多我们关心的信息事实是不会发生改变的，所以不会产生维护成本，比如一台服务器，它的制造商、技术参数、生产日期、停用日期、存放在点等等，这些信息是我们关心的，但是基本不可能发生变化，所以这种信息不会带来日后的维护成本。第二点关于作业过程中对配置信息产生变更的次数，这才是真正对我们CMDB维护成本起到决定性因素的地方，因为你的配置信息每发生一次更改，就得做一次维护控制，但现实中，我们的配置信息真正多是桌面类的项目上，发生变更最多也是桌面项目上，在应用软件项目中，除了软件版本会偶尔发生变化外，其余的配置信息是很少变动的。而系统类项目的配置信息更是改变更少，因为服务器的配置信息很少在他们作业过程中发生变更。而网络领域发生配置信息变化的情况也是相对很少的，如果多是一定出了问题，因为这种最基础的设施是不可能经常做调整改动的。如果大家真正把自已的CI分类与属性池真正分析一次，然后分析一下各个业务领域的作业特性的话，我相信大家会得出和我一样的结论，真正日后频繁做CMDB维护动作的只有桌面类的项目，在上一段落我已说明了做这个维护CMDB动作的必须性（因为你的确把人家的硬盘更换了，把操作系统升级了），现在再具体说成本，在系统设计时，我一直站在一线工程师的角度考虑，怎么操作便利，怎么才能把大家的时间资源从系统维护中释放出来，而投入到真正的生产过程中。真正在CMDB中把一硬盘的信息完成更新，需要多久时间呢？我的估计最多是一分钟，这里大家就会发现CMDB维护的时间是零散的分在各个业务活动中的，我无法相信工程师做了一分钟的工作就会引发成本变化或生产就会受到影响了。就算一名工程师一天可以修十台机器，一天需要花15分钟来做CMDB的维护，就对我们的运维成本产生影响了吗？我们的运维成本是取决于我们的人员工资，我们会因为CMDB上线就为桌面多招一名工程师吗？不可能，我们会因为CMDB上线后，而让人员加班吗或者因此发放加班费吗？不会。所以不会带来成本的上升。另一方面我们的工程师真的忙到一天连十几钟的软件填写时间都没有吗？就我看到的业务情况，运维人员一般还不至于忙到这个地步。所以对成本上升一事，不深入到业务细节是无法正确得出结论的，CMDB的维护对公司的整个运维成本不会产生直接影响的，当网上与所谓的ITIL专家们叫着在实施CMDB实施时，要注意日后的维护成本一事，我认为这更多是一个业务问题，也是一个能力问题，当你真正把握事物的本质时，真正洞悉业务后，这其实是一个伪问题了

3、 CMDB的构建原则
    什么自上而下，什么自下而上，这些大家应该听说过，老实说我认为这不叫什么原则，同时这种所谓的原则连顾问公司也没有几个人可以真正说清楚，更没有真正应用实践过，我的建议是，大家老实老实把自已的CI分类搞清楚再说，搞清楚了分类，再去谈属性，最后想好CI如何组装在一起，方便调用，CMDB不是孤立存在的，一定要想好各个其它流程的调用与关联问题，没有想好前，就不要动手设计数据库。

    关于配置管理与CMDB我写得太多了些，就差不多到这儿了，短时间内不打算再针对这一块写什么东西了，我们搞ISO20000的体系的认证，每个流程有安排流程经理负责，CMDB写这么多，主要是我除了负责整个体系的推行又专门负责了配置管理这个流程，后续我有时间写写ISO20000体系方面的，那才是我花时间最多的地方，时间够的话，最好是能每一个流程都写一篇，但怀疑可能性不大，因为太耗时间了，最近也忙得有些受不了了。CMDB就吹牛到这儿吧，大家对付着看看了。。。

LZ逃狱成功

深刻啊！

呵呵，挺好的，实践出真知。。。

QUOTE:

---

最初由 破子 发布
......日后的维护成本一事，我认为这更多是一个业务问题，也是一个能力问题，当你真正把握事物的本质时，真正洞悉业务后，这其实是一个伪问题了......

---

维护成本不只是工程师修改配置信息耗费时间的问题，我认为维护成本真正的问题在于：
1、如何如果让工程师有内在的动力去及时更新CMDB。
2、我们还需即确定在什么时机、由什么人员去完成配置信息更新。
3、最后，我们需通过某种方式确保配置信息被更新正确，如技术方面的数据自动发现或监控，管理方面的审计。

听君一席话，深有同感；

我们也面临了同样的问题，业务逻辑这一块，相信每个公司，每套系统都不尽相同，需要大家在实践中不断摸索，思考，设计，优化。

我现在比较关心的是比较低级的问题，数据库怎么设计比较好
现在主要考虑一下问题，
1.不同类型的CI都事先设计好数据表？
2.如何适应灵活的CI变化，包括两个层次，Item层的和属性层的？
3.CMDB一般有自动发现功能，也有可能是变更引起信息多个版本不一致；这时需要融合技术实现信息更新；数据库采用什么方式支持这种更新呢？

希望大家针对CMDB数据库设计的问题，帮忙献计献策；特别是过来人。

现在很多大的企业和政府部门都在上服务流程，这肯定要涉及到CMDB，有的企业实际上已经有这方面的资料，所以在实施在做的事情就是将现有CMDB和流程的集成，这个过程需要判断的事情比较多，比如原有CI设计是否适应现有流程的需要，如果不适应，那么可能需要重新设计CI。如果企业没有这方面的东西，重新在建，反而操作的难度要小些，但实际做的事情也绝不会少。CMDB是这两年才刚开始的一个东西，可能楼主是甲方的原因，接触面比较小，实际上在IT服务管理的专业公司里，有不少这方面的专家，都是有丰富项目经验的实施顾问。我需要强调的是，IT服务管理的实施有一些基本原则，但每一个项目都是不同的情况，所以在很多情况下，都是需要在实践中修订认识。

QUOTE:

---

原帖由 fbm006@tom.com 于 2007-10-1 22:28 发表


维护成本不只是工程师修改配置信息耗费时间的问题，我认为维护成本真正的问题在于：
1、如何如果让工程师有内在的动力去及时更新CMDB。
2、我们还需即确定在什么时机、由什么人员去完成配置信息更新。
3 ...

---

1、第一个问题比较现实，很多工程师觉得干了活就好了，为啥还得维护CMDB，对公司来说是很有用的，变化后的配置一下就能查到不至于出错，个人的动力呢？可能除了多引导，还得加强相关的监督，有了更新就必须得维护相关CMDB；
2、第二个问题应该有相关的流程来处理，既然要上服务管理，不能说安装一套软件就好了，什么人该干什么事，何时干都应该有了安排，不然这个项目就不能算完成。

学习了。楼主厉害。

其实还应该关注ci的同步和ci之间的关系，

楼主仅仅介绍了ci的分类和ci的属性，感觉还有点欠缺。



[ 本帖最后由 vecentli 于 2008-2-20 16:56 编辑 ]