《ITSM系统构建及ITIL实施笔记-配置管理篇.doc》由会员分享，可在线阅读，更多相关《ITSM系统构建及ITIL实施笔记-配置管理篇.doc（11页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、ITSM系统构建及ITIL实施笔记 之 配置管理篇这里就不对配置管理的一些根本知识做解释了，类似的文章挺多，这里直面配置管理深入一些的内容，我在这家公司工作了三年，很少象这样需要开动所有脑力去思考一件工作，配置是一个很重要的根底，同时也是让我消耗脑力最多的一块，所以先把它写下来。先介绍一下我们的业务情况，我们公司的运维工程较多，有网络、系统的、桌面的、软件的，而且这些工程用到的设备都存在共用的情况，比方一个段线路，会属于多个工程使用，一台客户的电脑，也可能装有多个管理软件，同时它又是属于桌面运维的，这些我们的IT组件一是数量多光是需要桌面运维的电脑台数在5000台以上，二是相互的关系复杂。我现
2、在所讲的，是经过很多思考与折腾后，所整理出来的，我对配置管理的出发点，是从软件实现方面考虑的，这可能与其它的公司有一些不一样，一开始，在思考整个配置的模型，也是CMDB的业务层面逻辑，很长一段时间，在CI的结构与关系方面，我一直无法理清楚，因为当CI的结构是怎样，关系是怎样不确定前，整个模型根本无从建立。最开始首先确定的是，我决定把CI的结构与关系别离，即结构是结构，关系是关系，两者不互为影响，作用也各自不同，这个想法应该是比拟大胆的，而且这是在我对ITIL不熟悉的情况做出的决定，如果这个做法错误，后续的很多工作都会受到影响。决定后，剩下来就是攻破结构与关系了。在那段时间的思考中，CI的结构是
3、首先想通的，可能是因为以前是做ERP实施的关系，也可能是因为客户是汽车制造商的关系，最终我发现将CI组装时，它的呈现很象ERP中的BOM结构，这是个父子结构，它可展开任意的节点，这种结构具有很大的扩展空间，也解决了配置管理颗粒度大小变化的问题，经过几天的思考后，我已非常确定这个思路可以解决我们的CI结构问题。剩下的关系是花的时间比拟久的，查了不少资料，我一直想确定到底CI之间有哪几种关系，这本身我一直觉得这个ITIL的推广组织本身需要制定或想通的，而不应该由我来思考，我也看了常态下象IBM他们的做法，但他们关系与结构是互为一体的，而且他们对关系的定义简单了些，所以最后没有采用。在思考CI的关系
4、时，我甚至上升到哲学的层面，去思考人与人之间的关系有哪一些，事物与事物之间的关系有哪一些，看是否能对得出CI之间的关系有一些启发作用，也在网上查了很多关于事物关系的说明，可惜没有找到有用的说明资料。最终找到一个解决方法，是一个周五下午快下班的时候，当时正在画一个示意图，想向领导表达，日后如果我们完成配置的结构与关系构建后，呈现给我们的是一个怎样的东西，当时只把CI抽象成几个集合，CI是用一个圆圈图示代替，在画了几个图示后，突然有一点灵光闪过，我发现当把几十万个CI用这样方式串联起来时，象一个个灯泡一样，有的亮有的不亮，通过关系将这数量庞大的灯泡连接起来时，这种情况好象电路图，每一个CI位于一个
5、复杂的线路中，形成我们公司自已的配置地图，而且这是一个三维的图形，多个工程形成一个面，每个工程的根据结构展开的所有CI形成一个面，而每个CI之间的关系又形成一个面，脑子里当时形成了这图象这个三维的图形后来尝试了好几次用VISIO或PPT画出来，一直没有成功，想到这一点当时很兴奋，终于看到了一道门。于在是周末休息时，去书店把数字电路的书找来看了一些篇章，最终确定引入门电路的概念来解决关系的问题。 上面介绍的是思考过程，在完成这个思考过程后，在工程启动会上，汇报了此设想，得到领导认可，同时为了验证可行性，我找了一个公司典型的工程做了一次试验，看一下这样的模型是否存在问题。这里要说明一下，我们把结构
6、与关系别离，一是考虑结构与关系是互不对等的，二是可以让其独立作用在不现的地方，这样别离之后，结构与关系本身更加严谨，我们将结构用于事件定位，关系用于故障推演，一个着眼于现在，一个着眼于未来。下面将展开细节说明一、 配置管理规划由于以前实施REMEDY时，我们积累了一定的经验与知识，也具备一些配置管理的概念，所以规划方面，相对单纯一些，我们以管理科为主导，各业务领域的主管为成员，目标是所有工程的CI项纳入管理，在此作业开展前，我制作了一个作业方案，主要分几个阶段。1) CI分类规划2) CI属性设计3) CI命名规划4) CI模版制作5) 配置数据收集细节的作业进程就不一一介绍了，在做这个方案与
7、真正执行时，发现一些很有意思的现象，也算是经验了，这些点我会在下面逐一介绍到，下面将我们的整体的配置模型做一个介绍，示意1说明：客户组织：指我们的客户的组织及用户信息运维组织：指我们内部的效劳机构及员工信息效劳目录：不作名词解释了运维对象：常态上说的配置管理，即CI的集合这四个纬度构成我们需要关注的所有配置信息，每一个纬度都是一个结构独立的树状目录，它可以多层级多节点的细分下去这一点非常重要，在CMDB中我只会放入运维对象的所有信息结构与关系，而运维对象与其它三个面的关系，也是会存放在CMDB中的，当客户组织、效劳目录、运维组织都与运维对象发生关联时，这时，运维组织与客户组织一个效劳人员效劳的
8、客户是哪一些，或一个客户对应的效劳人员是谁，客户组织与效劳目录一个客户享用哪一些效劳，或一个效劳哪一些客户，运维组织与效劳目录一个效劳人员可以提供哪一些效劳，某个效劳哪一些效劳人员可以提供，这些都可以通过虚拟连接起来，这种模型的建立，会带来日后无比便利的统计分析与查询汇总，同时也会解决我们现在许多管理上的症结。为了后续交流的方便，我还需要对工程这个名词做一个定义，我是把它当成一个CI的集合，它是运维对象的一个节点，你也可以理解一个工程就是一个CI，这个CI是一个虚拟CI，它可以展开许多子节点，每一个节点都是CI，工程由于是我们公司很重要的一个“单位，它与结算、人员、组织、效劳目录这些都会存在关
9、联，所以后续会经常提到它。整体模型上面介绍的都是规划阶段的事情，这时具体的配置工作还没有真正展开，上面的整体模型相当于战略，也是一个重要的基石，它决定了后续许多的事物构造，比方后续要介绍的内容，同时这种模型如此规划时，它如何在其它的流程中作用比方事件管理、变更等中发挥作用，也是做了考虑的。说到这个就有一个建议了：在构建ITSM系统时，我的建议是首先从配置管理开始，而不是通常人们建议的从事件管理开始，配置管理决定地你们的运维管理的精细度与作业方向，它如何规划设计，会直接影响流程，你的绝大多数的数据质量也是由配置管理所决定的，在这个基石没有想清楚与确定前，展开事件及其它流程，最后整个作业可能是松散
10、的，甚至可能是错误的，你的配置管理越精细，它对你的事件流程及变更流程，都是会产生影响的，配置管理颗粒度越细，它对我们的效劳人员的作业行为要求就越高，引发的变更控制措施也就越多。在我的想象中，配置管理是一个效劳平台的最底层建筑，它也是一个约束整个效劳机制的重要所在。所以在工程的最初期，我一直是想先开发CMDB的，先把CDMB搞出来，然后灌数据，直接维护，不用事件管理，也不要变更管理，而是光光的CMDB，到时我想看看所有的CI信息进去后，整个运维地图是如何的，故障的推演是否能实现，如果这些都是稳固的，再在这个根底上构建其它的应用模块。CMDB先开发出来还有一个好处，解决了配置数据收集维护问题，我们
11、的配置数据届时会非常庞大，如果先收集，那在系统还未上线前，只能用电子表格维护，考虑到关系、结构的复杂，这根本上是不现实，每天有事件发生，无法做到同步的更新，不先收集，要等到系统上线的准确时间点，完成数据收集，这个难度又太大。做过ERP的朋友，应该知道在系统上线时，仓库盘点数据导入的难度，只要业务不停，数据总是一个动态的，而我们的配置数据远比这种数据复杂，有了CMDB后，我们有足够的时间去收集试验，同时还可以同步更新。二、 配置模型设计1) CI结构在CI的结构定义中，我们的思路中，有两个关键词，“树状目录和“父子节点及“虚拟CI，根本的理念中，根据BOM的原理去构建我们的配置结构，最终形成的，
12、整个公司的所有CI最终会挂在一个目录之下，象一棵枝叶茂密的大树，一个工程相当于一根树枝，一个CI相当于树枝上面的一片树叶，树干是父，树枝是子，树枝是父，树叶是子，父与子是一个相对的概念，用一个实例来说明，比方我们一个桌面工程，有2000多台电脑维护，每个电脑由显示屏、主机、电源之类的组成，这个工程就是父节点，每一个台电脑就是子节点，但当颗粒度到更细时，一个电脑由显示屏及主机组成，这时，相对于显示屏、主机而言，电脑是父节点，而主机是子节点了，如果颗粒度再精细时，把硬盘、内存、主板、CPU作为CI管理时，此时主机又是父节点了。这里还有一个现实问题，一个桌面工程，它的子节点就是2000多台电脑，这样
13、的目录，可能会太长了，不利于管理，这时为了统计或管理的方便，我们可以构建几个虚拟CI，比方按厂区，如果这2000多个台电脑是分布在十几个厂区内的，我们可以将这十几个厂区，也做为节点管理，这时，桌面工程下面的子节点就只有十几个了厂区，每一个子节点下面的节点只有100多台电脑了，这样更富于结构，也便于查询定位，这是虚拟CI的概念，它是由于管理的需要产生的，这里面要尤其注意一个问题，当厂区已经作为属性管理时，是不能再为之构建虚拟节点的，因为你的一切管理需求已经在属性中考虑了，所以结构的设计是一个智慧的事情，你要考虑到分类、属性设计的空间问题，不然到时有许多要素重叠，这样一是不效率，二是可能导致数据冲
14、突。对于偏硬件的工程而言，它的CI结构规划是相对简单的，真正复杂的是软件类的工程，比方象我们的DMS经销商管理系统类工程，它是汽车制造商为了管理它的分销商而产生的，一般大型的汽车制造商的分销商4S店有200-400家左右，甚至更多。每一家分销商的店内都有一台效劳器，安装有DMS的效劳端，店内还有许多电脑安装有客户端，而汽车制造商本身也有效劳器，它与每一家分销商的效劳器对话，交流数据。这种工程涉及网络，数据接口，几百个的数据库，众多的效劳器与工作站，这时的配置规划就有一定难度了，但根本上我还是发现存在一定的规律，在工程下面的一级节点中，按应用效劳器、数据库效劳器、接口效劳器、程序、接口程序、数据
15、库、专用设备、相关组件、相关网络等这样的思种去规划，再逐个细化，就可以理清整个工程的CI结构，这里需要注意的事情是共用CI的问题，当一个CI的运维权在某个工程时，这个CI的所有内部信息，别的工程只能调用，不能对其进行解释，比方上面说的DMS工程中会用到相关网络A网路，A网络内部的所有结构与关系信息，都是由网络领域的团队进行规划设计的，DMS工程只能调用A网络本身这一个组件，这一个理念会非常重要，因为当工程众多，组件复杂庞大时，整个公司级的配置结构是难以合作同时构建的，这时需要制定相应的游戏规划，教每个团队按规那么去绘制自已的整个树枝，最后会自动组装成一个参天大树，把最专业的事情交给最专业的人，
16、用一种比拟简单的逻辑，最后形成一个复杂的东西，象计算机的二进制是如此，象我们的整体模型也是如此，每一个纬度只需要与一个续度建立关系，最后所有纬度会相互关联。这种最简单的逻辑构成的好处在于相互独立，分拆容易，同时容错性强，构建容易。下列图是一个工程的CI结构示意，可以看到都是一个树状的结构，希望可以让大家更加形象的了解结构：2) CI关系如果建立公司的所有运维对象地图，会发现某种意义上，配置项之间的关系类似电路图，因而引入数字电路的根本逻辑概念，从应用的视角构建新型的组件之间的关系，将组件的结构与关系独立出来，分而治之。在逻辑电路的根本逻辑的类型如下：u 与门当一个事件由两个以上的条件决定时，只
17、有全部条件为真时，条件才能成立现实中，如果一道门有两把锁，只有这两把锁全部翻开时，门才能翻开，这就是一种与的关系。u 或门当一个事件由两个以上的条件决定时，只要任一条件为真时，条件就能成立或的关系，在IT环境中就很多了，比方将一台编号为A001的电脑这个CI，与其子节点的，CPU、内存、硬盘、操作系统等就是一个或的关系，即只有CPU、内存、硬盘、操作系统这其中任何一个CI出现问题，都会导致A001这个CI出现问题。u 非门当一个事件的条件为假时，对象才为真非的关系，我们暂时不考虑加以引用，本来的是考虑利用此非的关系将CI的备件等进行关系构建备用设备，或维修备件，但想到一些现实问题，备件用其它的
18、方式进行管理，不直接引用关系，以免过于复杂。这里面还需要说明几个比拟重要的概念：关系的视角：我们构建CI的关系，是从被影响的角度出发的，这一点非常重要，因为事实上中关系总是双向的，一号CI会影响别的CI，别的CI也会影响一号CI，这时如果双向构建很可能会导致重复构建或错误构建，由于我们的关系只需要用来分析当故障出现时会导致的结果，所以我们只用单流向的关系，即可满足需求这个道理类似以面介绍的，用简单的逻辑组装成一个复杂的事物，因为当所有CI从被影响的角度出来后，网状关系即已形成。这一点需要很好思考一下，不然理解会出问题。下列图是一个应用方面的示意，我的想法利用关系，届时可以图形化推演故障路线，这
19、样可以直观的采用紧急预案切断故障路线红色为故障组件。关系构建原那么：在逻辑上，可参一个CI会直接与间接与所有CI有关系影响，但很显然，我们无法将一个CI直接与其它所有CI去构建关系，那需要找到一个机制去解决这个问题，说到这儿要说一下我的爱好，我一直喜欢看DISCOVERY的节目，大家在看到一些自然记录片时，会看到一大群鸟或蝗虫在天空飞行时，是聚集在一起的，象一团乌云一般，再或者我们在看海底时，那些鱼群在水中游动时，总是保持一个集合，不管它们往哪个方向游动，总是非常有效的保持一个群的形态，这些东西看起来很有美感，并感到有些不可思议，其实在这个下面，只是一个简单的原那么，当鱼群游动时，每一条鱼只需
20、要与邻近的鱼保持适当的距离，这样最终就会群。我把这个叫鱼群原那么，在CI的关系构建时，我当时也碰到如何去有效构建关系的问题，最近我发现利用这个原理，可以解决，即一个CI只与结构相邻或直接影响的CI构建关系，这样构建关系就会简单很多，当每一个CI用这样的机制去构建完成后，也会形成一个庞大的群，会把所有的CI有机制的串联在一起。在用与、或的关系构建关系，我发现一个原理，如果IT环境的与关系越多这个IT环境是会相对稳定的，不易被故障将环境瓦解，同时故障的影响度也会较低，因为一个点发生故障，不会马上导致业务应用出现问题。或的关系越多，运维将变成更为吃力，因为每一点的影响都会导致后果发生。这也某程度上指
21、导了我们日后的方案设计与运维管理。是不是我们现在的这种关系构建是完美无缺的？它到底存在什么问题，有什么局限性，这一点真正深入思考的人，应该会发现关键所在的，在我所设想的整个配置模型中，有两个比拟大的局限，我不打算单独一个人去挑战这两个最难的命题，因为我很清楚对于当前的业务而言，这个模型可以满足他们很多年，我再深入去挖掘，对于业务需要而言，过于超前了，同时我个人不太希望在这个方面走得太过深入，也因为志不在此，如果真正投入精力去研究，我觉得是有可能找到一个终极模型的，因为我道方向在哪儿，局限何在。想到这些我就对现在的这些理论传播者或那些参谋公司有意见，这些东西是不应该由我们这样的公司，或者我这样的
22、人去研究的。就象我写的这些文字，我相信那些ITIL的制定者、传播者是没有告诉过我们的，我在工程初期在在百度与GOOGLE上流浪N久，就是想找到我现在写的这些文字，但一无所获，有的只是那些大而空的理论，听起很有道理，但是你根本无法将它与现实业务去结合起来思考。不扯了，继续往下！3) CI分类 本来按正常的逻辑，CI分类应该放在第一位去思的，而不是先去说结构谈关系，这样做一是因为我们确实是先把结构与关系理清后，才去做CI分类的，二是觉得在结构关系没有做一交待前，可能先谈后面的东西，会不利于了解，这也是因为社会上没有把CI的结构与关系跟我们做一些标准或定义，才造成的，正常来说，我们真正开始做具体的配
23、置工作时，CI分类应该是第一步，这个过程会非常重要，在没有真正开始做前，我还没有意识到它的影响会这么大。再说明一下工程的情况，配置的结构、配置的关系，根本上我一个人去完成思考的，没有动用到公司的管理资源，当这些定下来后，开始做CI分类时，这就需要走出办公室，调动管理资源了，因为这不是一个人思考就可以决定的，这一点很重要，日后各位从事这样的活动时，也需要把管理资源拉上，能抓到多少资源就要去抓，这是一个很好的洗脑的过程也是一个很好的互动过程，让具体的业务领域及高层管理者开始真正参与进来。 记住一句话：CI的一级分类决定了配置管理的范围，CI的最底层分类决定了配置管理的颗粒度。这句话是后面真正领悟总
24、结出来，一开始也没有意识。CI分类我们的做法是这样的，我们先找一些对业务领域比拟熟的专家或管理者，首先谈CI的一级分类，我们谈着谈着，发现谈不下去了，因为没有具体的数据支持，我们根本无法确定一级分类，于是我们转变策略，先发模版，让公司的各个业务领域把自已所有的运维对象全部罗列出来，最终收集上来是五花八门的清单，这就是我们最初的数据，然后我们再组织人员讨论。现在的体会是，分类真的是一门艺术，更是需要智慧的。这里面要说一下我们有两个优势，一是我们是从系统实现的角度才开始这项工作的，所以我脑子里事实是有一个预期的，虽然我不知道具体分一类有一些什么东西，但我很清楚分类对不对，能否有效，有没有扩展性。二
25、个是我们以前实施过REMEDY，业务领域的人员具备一定的分类根底。 经过讨论后，我们把一级分类确定下来了，这里又得废话几句，我一直也不觉得这个工作是我们需要花如此的气力做的，我们也与参谋公司交流过，他们根本上没有给出任何有用的建议，IT的设备或环境，全世界也就那么一回事，我一直奇怪居然没有一个关于分类标准或建议，网上也是查不到相关的有用信息。最终我们把一级二级的分类，大家分工确定下来了，然后再发布给各个业务领域评审，是否有遗漏的，分类是配置的最根底一项工作，如果分类不当，带来的后果很严重，你的统计分类，你后续的属性设计都会受到影响，而且日后你想对某一个类做调整时，这是一个非常复杂的工程。CI的
26、分类我们最终的结果是，将CI分类，分为三层，一层分类为六个：环境、计算机及外设、软件、通讯、网络、文档代码。最低层的分类为190个，现在让我来说一下我们的分类原那么，好象我很难总结得出来，这是一个倒推的结果，我们的分类也不是完美的，因为有许多IT设备你很难去定义它属于哪一个类，比方我们有两个二级分类一是计算机配件，一是存储设备。一个硬盘，你说它属于哪一类呢，好象两者都可以放进去，又好象二级分类不对，但是我们有着大量的鼠标、键盘、光驱、内存条、显卡、网卡这些配件存在，所以必须有一个计算机配件的分类，另一方面我们在磁带设备、磁盘阵列、带库、光存储设备，这些又必须建一个专门的存储设备的分类出来，这样
27、的情况还好好多，我相信随着IT技术的开展，原有的分类还必须打破，因为技术与产品的换代，使许多分类的界限完全打破了，所以在分类时还需要一定程度上考虑未来技术开展，有一些IT设备现在虽然数量不大，种类不多，但现在有明显的趋势看出未来一定会独立开展成一种专门领域的话，那就有必要先把分类建好，一个目的，最大可能的减少日后对分类的调整。另外还有一点需要说明的是，CI的结构与分类，很多时候是会让人混淆的，比方在我们最底层的分类中，硬盘、内存条、CPU与计算机是并列，当时有人认为硬盘、内存条、CPU等是应该在计算机类下面的子类中的，这种意识是好多人都会存在的，包括当时我们的领导也是觉得这样的分类好象不对，也
28、认为应该如此。但事实上这样是不对，他们都把CI的分类与CI的结构混淆了，而且忽略了分类的根本意义，硬盘、内存等都是计算机的组成部份，这是一个结构信息，我们分类是为了把所有CI种类做一个分类，然后在构建CI结构时，再把每一个种类进行组装，分类不需要考虑任何的结构信息，再说分类的作用，分类更多是为了日后的统计，如果把计算机作为一大类，把硬盘、内存等作为子类，这样统计出来的数据全部是错误的，因为这样分类的话，程序会把每一个硬盘、内存条都作为一台计算机统计出来，统计一个父分类时，一定会把其所有的子分类全部计入。所以有时我们从程序实现的角度来考虑问题，也带给我们一些便利。最终我们的做法是，建了两个大类，
29、一个是计算机整机，一个是计算机配件，把硬盘、内存、CPU这些东西统统丢在计算机配件中。本段开头的第一句话是：CI分类的第一层分类决定了配置管理范围，最底层分类决定了配置管理的颗粒度，我们的一层分类是：环境、计算机及外设、软件、通讯、网络、文档代码，这是我们的配置管理范围，告诉我们这些东西是我们统统要管理的，最底层分类，比方计算机及外设这个一层分类中，分了计算机整机与计算机配件，而计算机配件这一个分类下面，又分为鼠标、键盘、光驱、内存条、硬盘、CPU、显卡、网卡、电池、电源等，这个最底层分类告诉我们，我们日后关于计算机及外设这个配置管理范围下面的颗粒度要到达CPU级的，事实上CI分类的过程就是你
30、配置规划的过程，它是你整个运维目标及能力的提现，它决定了你日后约大多数的效劳活动。关于分类有一点说明：如果你的仓库中存在某一款配件的话，即便你的配置管理颗粒度不想到达一个级别，你也最好需要为此构建分类，同时这一类的配件，你需要日后构建为CI进行管理。比方，如果你是做桌面运维的，你的配件仓库中存在硬盘的备件，那么你就需要建一个分类出来，同时你在构建CMDB时，每一个硬盘你最好作为CI管理，不然这会造成许多问题。这也算是分类的一个原那么吧，任何你需要加以关注的设备或配件，都必须可以被分配到你CI分类的某个最底层分类中。 最后一点需要说明的是，分类与属性的平衡，分类时要注意，如果有一些信息是可以利用
31、属性控制的，可以适当减少分类，比方鼠标，有光电的，也有普通滑轮的，这是两个不同种类的东西，但是我们没有必要为此建两个分类，我们只需建一个分类，就是鼠标，同时多为这一个CI分类多设计一个属性，叫鼠标类型，这样通过属性就可控制了，同时后续的统计分统也可以满足了，这里没有一个很硬性的标准，比方计算机，有大型机，有小型机，有普通的工作站或效劳器，为什么计算机就需要做多个CI分类，而鼠标就不用分类，用属性控制呢？，这是由属性的异同决定的，如果同样一个范围的IT组件，它们的属性是很接近或相同，我们就是没有必要建多个分类；如果它们的属性差异很大，这时就需要多建分类了，这是为了管理的便利。所以我一直说分类是一
32、个智慧的事情，就象配置管理的颗粒度一样，这需要去各方面平衡把握的。CI分类就说这些了，真正在做分类时，相信大家就有体会了，这些也不是抄书或谁教的，都具备的作业过程中个人的一些经验与智慧。战斗英雄4) CI属性设计当所有CI的分类确定后，下一步的工作就是需要设计属性了。说到这个可能还是得做一些知识或概念说明，因为这方面的资料并不多。在编程中有一个概念叫面向对象，我们在配置规划或构建CMDB时，跟这个道理有一些类似。说简单些，我跟刘德华，我们是否不同，取决于我们各自的属性，属性可能理解为对我们的信息的进一步补充，对我如果我们需要的信息不多，可能我们的属性只是：身高、性别、体重、面容等等，这时刘德华
33、没有我伟岸，我也没有他帅，所以我们就可以区分出来了，我是我，他是他，这是我们的属性不同，但是这里需要注意，这里我和刘德华是不同的对象，但是我们属于同一个分类都是人、我们属性范围是一样的，只是属性值不一样身高不一样，长得不一样，我们的想法是根据分类设计不同的属性，两个不同的分类，是因为属性范围不一样，人的属性有身高、性别、体重、面容等，计算机的属性有制造商、品牌、生产日期等，这时人与计算机的属性范围是不一样的，所以是不同的分类，所以我们前面说了CI分类，那一个CI分类跟另一个CI分类有什么不一样，这是由各自的属性决定的。这是第一个概念。第二个概念是父子继承的概念，即子类会继承父类的属性，父类有什
34、么属性，它的子类就一定会有，如果我们的CI分类有三层，那么第三层的分类，会继承其第二层，以及第一级的属性，比方计算机整机这一个分类，下面分有大型计算机、中型计算机、小型计算机、工作站等这几个子类，如果计算机整机这一个分类有属性：制造商、型号、购置日期等这几个属性，那么大型计算机、中型计算机、小型计算机、工作站这几个分类都会有制造商、型号、购置日期这三个属性。这是继承的概念。CI属性设计，我们的工作是这样展开的，我们把所有CI分类清单确定后，确定分工，哪一些人对哪一些IT设备是最专业的，就由他们来设计属性，这个工作是比拟复杂的，因为最后需要做大量的整理工作，因为事实上许多分类的的大部份属性是相同
35、的，我们需要把属性整理好，做到不重复，比方计算机有属性叫型号，空调有属性叫机型，这时事实是同样的属性，我们需要把它统一起来，我们发放的是最底层的190个分类，这样每一个分类由不同的设计属性出来后，我们再统一命名，然后将属性上浮，因为许多属性可以提升为二层分类属性，甚至提升为一层分类属性，甚至是公用属性，这个工作需要比拟好的大脑才行。CI属性总的来说，分为公用属性、一层分类属性、二层分类属性、三层分类属性，还可以设私有属性。所有属性最终形成一个“属性池供每一个分类去取用。然后当我们真正需要建立一个CI项时，首先要确定这个CI属于哪一个分类，如果它属于计算机硬盘，那么它会自动拥有公用属性、计算机及
36、外设属性一级分类属性计算机配件二级分类属性硬盘属性三级分类属性，我们需要做的是填上每个属性的属性值，这样一个CI就完成建立了。另外有一点需要说明的是，属性的设计也是一个智慧的事情，取舍会非常重要，我们是先穷尽收集，保证每一个CI类需要关注的信息都收集上来，然后再做挑选，因为有许多信息是没有价值的，或者本身的信息是难以取得的，象一些高度动态变化的信息，是不宜取用属性时行管理的，比方CPU的使用率，除非你有底层的监控软件可以自动通过数据接口读取到系统中，否那么这个信息是无法维护的，所以就不用为CPU这个一个分类，建一个占用率的属性。要考虑到日后的效劳本钱，量力而为，如果构建得信息无法进行维护，一是
37、影响CMDB的数据精确度，二是带来效劳本钱增加过大，一旦设计了这个属性，那么日后这一类CI的这个属性发生变化时，需要进行监控与管理，这个本钱是相当可观的。三、 配置管理的后续工作当完成上述的配置规划动作后，需要做二件事件，一是CMDB的构建，二是数据收集模版的设计。我一直的看法是，当IT效劳到达一定的规模后，尤其是当IT组件庞大时，在没有系统实现或支撑的情况下，做深入IT效劳管理是空谈的，暂不说事件、变更等流程，光是配置管理，没有系统的支撑，是根本无从保证质量的，这里我觉得有一个规律，做管理咨询的公司往往是自身公司的管理最需要被咨询的，做软件的公司内部往往也是最需要信息化的，做IT效劳管理的，
38、可能也是最需要接受IT效劳管理的，我们在提供IT效劳的同时，我们自身的IT应用其实做得远远不够。 我们的系统现在还没有出来，关于配置管理的工作事实上才刚起步，慢慢的再跟各位交流，光是写配置管理，我其实还是收着手在写，但也写了10000多字了，如果加上以后的实施，整个笔记，我疑心是一个长篇大论了，如果再把效劳支持的每一个流程都这样写，加上工程的后续实施应用，那是巨作了，所以还好是拆了，不然不知写到几时才能出来。关于我们自已的配置管理的思路以及我们的配置模型，我也费了不少口舌了，也不知大家有没有收获，或者真正看懂没有，有一些东西没有方法一次性写完写好，先不用用文字表达，光是这个配置模型，我在公司给
39、领导同事们讲了无数次，讲得到后面都烦了，但还是很多人没有真正体会理解，所以写这些有时也挺担忧看的人能否真正看进去了，我不愿意写一个完整的，主要也是没有动力，加上写出来也不知给谁看，你说写成一本书，那得花多少时间精力，又不能出版。所以现在拆分着写，先写这一篇配置管理试试水，大家可以多提意见，我在做这个时也是诚惶诚恐的心态，当时真是苦于没人交流。每每辛苦写出来的东西没有什么人看或支持，也是一件挺打击人的事情，一些泛泛而谈的资料N多的人下载，真正的总结出来的经验之物，反而没有什么人愿意看。反正一句话，各位的支持是唯一动力。关于我文中提到的我们配置模型的局限问题以后的模型扩展问题，我本来打算在文章最后写出来的，想想还是算了，留给各位思考发表意见吧，文章没有经过什么润色，行文不通之处，还望见谅！ 破子 2007年7月3日星期二