CMDB最后的吹牛.docVIP

CMDB最后的吹牛 经过半年多的时间，终于把CMDB的设计工作结束了，时间虽然不长，但感觉象是很长一样，同时感觉到经过一次的思考过程，对于管理或事物有了一种新的视角，说不清是什么，只是更清晰了，好象有一点面对对象的概念一样，发现现在去破解一件任务或工作，更加容易了。? ? 俺是一个喜欢思考的人，对事物的看法比一般人要深入些，有些象越狱里那个MICHAEL SCOFIELD，那家伙看东西可以把内在的物理结构看清楚，俺没有那么高杆，只是情况有些类似，喜欢去思考事物的本质，俺也不认为我是一个智商过人的人，因为这在读书时已证明不是了，这种情形我不知道是后天训练的结果还是先天的性格等造成的，有时我感兴趣的东西跟别人不太一样，我喜欢坐在公交车里去思考那个该死的无人售票车的车票钱是如何交付的，怎样避免不被人贪污盗用？，那些态度恶劣的司机们每天象塞沙丁鱼罐头一样往车里装人，是一个怎样的绩效管理机制让他们如此？美国的登月工程与他们的第一个核子工程是如何实现管理的，数十万人要组织协同，各种物资的调配是怎样实现管理的，我会好奇这些东西，有时达到一种病态的地步。? ?在我规划设计CMDB时，有各种人与资料告戒我，CMDB的设计要如何如何，难度是怎样怎样，今天回过头来看，真正理解CMDB并把握应用的人是极少的，包括那些顾问公司的顾问们，最终完成这份工作，外界的人与资料起到的作用很小，有时个人觉得国内可以独立完成这种设计结果的人不会超过50人（可能10个也不到），这可能让大家觉得狂妄了，但我个人真是如此认为的，但这份工作本身并没有结束，后续的应用才是关键，但我相信最终如果出面质量问题应该不会出在模型本身。下面是我将对一些我不太认同的观点进行说明一下，希望大家不象我一样在一开始又是被顾问恐吓，又是被网上的资料恐吓，搞得诚惶诚恐的，真正把脚站在你业务上，有一个清晰的头脑与思路，比什么都重要：1、配置管理的颗粒度问题? ?颗粒度过细的问题，我一直强调一个观点，全世界没有一个人可以给某个公司正确的配置管理的颗粒度的硬性指导原则，这不是一个硬性或可以测量的事物，但有一些基本的道理在内可以帮助我们思考，第一原则是颗粒度与我们运维能力成正比，当你可以去修复一台电脑的内存条或硬盘时，你的颗粒度就需要到达内存条这一颗粒度，如果没有这个运维能力，你只需要关注整机；第二个原则是当你需关注配件时，你的颗粒度最好能够覆盖到这一层级，因为在配置管理中，备用件的信息是起码需要关注的；第三个原则是你的管理需求决定你关注信息的多少（属性池）。而我正是根据这些原则引入模型来具体应用的（CI类有多少，CI属性有多少），讨论CI类有多少，这些一定要与具体负责运维服务作业的主管与工程师讨论交流确定，要防止有为了某种完美去追求极致的现象发生。对配置这项工作而言，需要有人能够超前思考，我们不能去确定一个CI分类与属性池，结果过不了一年就进行大的调整，因为CI分类与属性池局部的调整是可以的，但大范围改变，势必会引发混乱，比如打印机，现在大家为了贪图省力，只建了一个分类是打印机，那么我们几百个针式的、喷墨、激光的各式打印机都会被划入打印机这个分类中，但用了一段时间后，发现这样信息是不够或管理不方便，又想把打印机下面再建几个子类，把针式、喷墨、激光这几个建成子分类，这样意味着需对在CMDB中的已有几百台打印机进行重新维护分类。这还不是最麻烦的，如果日后的有一种既可以打印又可以传真的机器比较多时，而我们又没有提前设计好这个分类，到时如何划分呢，划分到打印机不合适，划分到传真机也不合适，甚至有可能对原有的分类造成冲击，这样原有的整个分类体系就可以需要调整，这才是最可怕的。所以在配置管理活动中，需要超前意识到管理需求与技术发展，这是一个智慧的事件，不能为了图一时之便去把难题都留给未来解决，一定需要预留空间发展，减少未来大的调整次数。关于配置管理颗粒度的最后一点意见是，一定要关注你的运维能力（变更控制能力）如果你没有办法能力对你置入CMDB的信息进行控制，必然会导致失败，建议的做法是，归划好CI分类，属性池可以逐步有战略的扩充，如果你的运维管理能力成熟度高，那OK，一步到位。2、CMDB的维护成本问题? ?CMDB日后的维护成本也是大家比较关心的一个问题，事实上CMDB的维护成本与颗粒度是与正比的，因为信息越大，维护成本就可能越大，这里面我要说明三个观点：一顾问公司与我们的目标并不是时刻一致的，他们的意见有时我们需要过滤。二是维护成本与服务活动是相关的，当我们的服务活动真的造成配置信息改变，是必须记录的，这个成本是必须付出的。第三是维护成本真正分析后，我们会发现它是一个弱成本。具体说明如下：? ???我们对日后维护成本的担心，更多来自顾问们的建议，对于成本问题，我在半年前构建我们公司模型时就考