注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

秋风扫落叶

 
 
 

日志

 
 
 
 

[推荐]ITIL实施记实之配置管理经验谈 (入选推荐日志,加10币)  

2013-02-22 07:45:04|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

[推荐]ITIL实施记实之配置管理经验谈 (入选推荐日志,加10币)

我在这家公司工作了三年,很少象这样需要开动所有脑力去思考一件工作,配置是一个很重要的基础,同时也是让我耗费脑力最多的一块,所以先把它写下来。
  先介绍一下我们的业务情况,我们公司的运维项目较多,有网络、系统的、桌面的、软件的,而且这些项目用到的设备都存在共用的情况,比如一个段线路,会属于多个项目使用,一台客户的电脑,也可能装有多个管理软件,同时它又是属于桌面运维的,这些我们的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后,我们有足够的时间去收集试验,同时还可以同步更新。
  二、配置模型设计
  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网络本身这一个组件,这一个理念会非常重要,因为当项目众多,组件复杂庞大时,整个公司级的配置结构是难以合作同时构建的,这时需要制定相应的游戏规划,教每个团队按规则去绘制自已的整个树枝,最后会自动组装成一个参天大树,把最专业的事情交给最专业的人,用一种比较简单的逻辑,最后形成一个复杂的东西,象计算机的二进制是如此,象我们的整体模型也是如此,每一个纬度只需要与一个续度建立关系,最后所有纬度会相互关联。这种最简单的逻辑构成的好处在于相互独立,分拆容易,同时容错性强,构建容易。
  可以看到都是一个树状的结构,希望可以让大家更加形象的了解结构:(略)
  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应用其实做得远远不够。

 

本文转自网络,作者不详,出处不详

  评论这张
 
阅读(129)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017