×

扫描二维码登录本站

QQ登录

只需一步,快速开始

标签: 暂无标签

学习资料: ITIL培训基地专家讲堂直播 300期视频回放





引言
  面对越来越丰富的IT资源,越来越复杂的IT环境,无论企业还是政府用ITIL作为实施ITSM一个包含IT基础设施和的IT部门都开始广泛采的依据。根据ITIL,构建IT服务逻辑模型的CMDB是进行有效的IT服务管理的基础。虽然ITIL已经有许多应用案例,但由于ITIL中没有对CMDB的内容做出规范性定义,所以这些应用对CMDB应涵盖的内容并没有达成共识。随着ITIL的推广,为CMDB定义1个通用模型已成为ITSM领域的共同需求。


  现在已有的其他领域的管理模型,如CIM和SID等,对于CMDB的建模都有一定参考价值。但是每个模型的出发点不同,关注的角度也不同。CIM只关注于IT基础设施的建模,忽略了ITSM所关注的IT服务和ITSM流程的一些特性。并且CIM偏重于对底层资源的细节建模,而有些细节已经超出了ITSM的范围。相比之下,SID提出的分域建模思想更关注从高层对管理对象建模。SID所分域内实体紧密关联,域间实体关联相对松散,做到了高内聚、低耦合,从而可以对完整的业务问题进行有效的分割。可以说,SID模型可以提供共享信息和数据的层次化、非重叠视图。但是,SID是对电信运营管理中的信息进行建模,其中不仅包含配置信息还有许多性能、使用、故障和测试的信息,这与CMDB所关注的信息的种类和资源的类别都有一些出入,并且它也没能满足ITIL中CMDB应与管理流程紧密结合的需求。通过对以上2个模型的分析,本文提出一种适用于CMDB的建模方法,并利用此方法建立了CMDB信息模型。该模型吸收了上述2个模型的优点,涵盖多个域,兼顾IT基础设施、IT服务、客户和ITSM流程特性等内容。

1 CMDB模型需求
根据ITIL,CMDB是用来存储配置项属性和配置项间重要关系的数据库。这里的配置项是指为交付IT服务而管理的任何组件,典型的配置项包括IT服务、硬件、软件、建筑物、人员和文档(如流程文档和SLA。根据已有的研究成果得出CMDB信息模型应该满足6种需求。


1.1模型应具有适应性
所有的ITSM流程都要受可持续改进生命周期的控制,配置管理流程也不例外。因此,CMDB必须具有适应需求变更的能力,特别是配置项范围,种类和信息颗粒度的改变,CMDB的信息模型也需要具有动态的适应力。


1.2模型应为ITSM流程提供必要的信息
根据ITIL,CMDB的信息模型应该可以满足ITSM流程中的所有信息需求。因此信息模型应该包含所有相关实体的模型(如RFC等)。


1.3模型应包含ITSM流程记录
对于每个ITSM流程,ITIL不仅规定了哪些信息应该保存在CMDB中,同时也规定每个流程需要创建一些流程记录(如事故记录)。这些流程记录间的关系(如事故记录和问题记录闻的关系),流程记录和基础设施之间的关系都需要记录在CMDB中,同样也需要作为信息模型的一部分。


1.4可展现配置项类间复杂关系的综合视图
配置项类间关系是CMDB中1个相当重要的概念,例如它可以支持性能影响的分析。因此,CMDB信息模型中应该包含常见配置项类种类问的基本关系,并且应该支持对配置项类间多重关系建模。


1.5可跟踪配置项类生命周期状态
根据ITSM,应该对每个配置项类的生命周期状态进行跟踪和记录,这点也应该在CMDB信息模型中得到体现。同样,CMDB中也应该保存所有生命周期阶段的附属信息,这些信息可以通过配置项类的属性、配置项类间关系、配置项类与其他数据记录(如采集数据、测试记录)间关系得以保存。


1.6模型应预定义基本配置项类
预定义一些可以扩展的配置项类可显著缩短CMDB的实现时间,这些配置项类可以直接应用于数据模型。


2 建模方法
CMDB建模方法采用自顶向下的建模思路、面向对象的建模方法、使用统一建模语言(UML,unifled modeling language)进行模型描述。同时继续沿用SID方法中分域的建模思想,在模型中引入域和类的定义。但是ITIL和eTOM(增强的电信运营图)在结构上相差甚远,所以不适合将SID的域、类的内容全部包含在CMDB模型中。下面从模型组织和模型描述2个方面对信息模型的建立过程进行描述。


2.1模型组织
模型组织是按照面向对象思想,对模型中元素间包含、继承关系的组织。在对CMDB的建模过程中引入了域的概念,对配置项类进行划分。域是特定管理范围内的一组功能相似的配置项类组成的类集合。对于包含众多配置项类的域,在域内又可按类别将关系相对紧密的配置项类继续划分到不同的配置项组中。对配置项组的划分是关系到整个模型是否具备通用性、完备性和可扩展性的重要环节。


包含于配置项域和配置项组中的配置项类是根据面向对象思想,由现实世界中的配置项抽象而来。对配置项的抽象应遵循从一般到具体的原则。先抽象通用的一级配置项类,然后抽象二级或**配置项类。为确保模型的完整性和一致性,一级配置项类就是根配置项类。所有二级和**配置项类都具有根配置项类的全部属性。根配置项类并没有实际的含义,仅作为所有类的**父类,从而将所有配置项类统一在1棵继承树中。


配置项类之间的关系是CMDB的核心,它是进行故障诊断、告警关联、性能分析等问题的关键,也是配置管理与IT资产管理的区别之一。对配置项类关系的分析主要有2种方法:自顶向下和自底向上。自顶向下的方法是指企业按照业务服务-IT服务-IT系统-IT组件的顺序进行梳理配置项类之间的关系;自底向上方法是自顶向下的逆向过程,企业先对内部IT组件关系进行梳理,然后逐步将IT组件映射到IT服务。


在CMDB建模的过程中,除了构建配置项类之间的关系外,还需要为每个配置项类定义属性。通常要选取那些可以表述配置项特征的配置信息作为配置项类的属性,而不是那蝗随时变化的性能信息。配置项类属性还要满足IT资产管理和IT服务财务管理的需要,包括厂商、购买日期、成本等信息。同时根据CMDB模型需求,配置项类的生命周期状态也应通过配置项类属性得到记录。


2.2模型描述
模型的描述是为模型中元素定义统一的描述模板。为使信息模型具有较强的通用性和可移植性,采用语义透明的模型描绘语言,便于模型的适配,有助予实现管理的自动化。本文提出的CMDB模型采用文本结合表格的形式对配置项类进行描述。其中文本用于描述配置项名称及其所属配置项域或配置项组;表格用于描述配置项属性,包括属性英文名称和中文名称、属性类型(如字符串型、整型、布尔型、实型、日期型、枚举型等)、属性说明、是否强制(如强制、条件可选、可选)等。同时采用UML图对配置项类间关系进行描述。例如,使用继承图描述配置项类之问的继承关系,使用关联关系图描述配置项类之间的使用、连接、依赖、安装等关系。根据以上对整个建模方法的介绍,本文描述的CMDB信息模型结构如图1所示。


  图1 CMDB信息模型描述结构  


3 CMDB信息模型
下面通过列举信息模型中包含的配置项域、配置项组、配置项类及其关系,对CMDB信息模型进行详细阐述。
参照SID中域的划分,按照管理需求以及高内聚、低耦合的原则,将CMDB信息模型划分为客户域、服务域、资源域、供应商/合作伙伴域以及公共域。域的划分如图2所示。其中客户域包含IT服务的各类客户的信息。服务域涵盖各类服务信息。资源域涵盖IT服务提供和管理过程中涉及的各类资源,范围包括IT基础设施、IT应用系统等。ITSM流程需要的信息多来自服务域和资源域。供应商/合作伙伴域包含IT服务相关的各类供应商和合作伙伴的信息。公共域涵盖支持上述多个域的实体信息,如根配置项、人员、文档和服务管理记录(如事故记录、问题记录)等。



图2 配置项类分域示意图  


在每个域内可将关联紧密的配置项类继续划分为配置项组。在上述定义的5个域中,资源域的涵盖面最广,其中包括支撑服务的各种软件和硬件资源,如网络、主机、存储备份、网络安全、终端、机房、操作系统、数据库、中间件、逻辑实体和应用系统等配置项组。公共域中包含文档组和服务管理记录组。而有些配置项域下直接包含配置项类。如服务域中直接包含服务包、服务项和服务等级协议等配置项类,客户域中直接包含客户配置项类,供应商/合作伙伴域中直接包含供应商,合作伙伴配置项类。

每个配置项组中可以继续包含配置项组或者直接包含配置项,如服务管理记录配置项组中包含事故记录、问题记录、变更记录和发布记录等。每个域或组下的配置项类之间又有着继承关系和关联关系。


3.1继承关系
根据建模方法的介绍可知,根配置项类、二级配置项类和**配置项类之间有着继承关系。图3所示为配置项类之间的继承关系,列举了CMDB信息模型中包含的二级配置项类目录、配置项域以及配置项组与配置项类之问的包含关系。



图3配置项类继承关系图  


3.2 关联关系
为满足CMDB模型展现配置项类间关系综合视图的需求,模型还通过UML图对配置项类间复杂的关联关系进行了描述。关联关系表示配置项之间互相依存或者互相影响的关系,如网络设备与主机之间的连接关系。配置项类间的关联关系如图4所示。


4 应用与验证
本文提出的CMDB信息模型在某电信运营商的IT服务管理中得到应用。下面以某运营商的计费服务为例,用本文定义的信息模型自顶向下对计费服务和IT基础设施关系进行描述。


  图4配置项类关联关系图  



与计费服务直接相关的配置项实例包括作为客户的业务部门和作为供应商的运维部门以及由他们签订的计费服务合同。同时与计费服务相关联的服务等级协议对该服务的开始时间、进度计划和服务水平等作出规定。计费服务的实现需要计费系统对其进行支撑。而计费系统的实现又依赖于各种IT基础设施,其中包括服务器、防火墙和路由器等硬件设备,也包括操作系统、数据库和中间件等软件。同时计费系统也与系统日志、使用手册等文档相关联。而计费服务、计费系统和基础设施配置项都可能与事故记录等ITSM流程管理记录有关。各配置项实例的生命周期状态都在其属性中得到记录。以上关于计费服务实例的UML图如图5所示。

实验证明,上述模型可以全面涵盖从客户到供应商,从系统到组件等计费服务所涉及的配置项域。并且可以自顶向下地将计费服务与基础设施组件间的关系梳理清晰,能为ITSM流程提供所需的各种重要信息,有力地支撑了配置管理功能。


(b)与计费服务相关的资源域和流程管理记录等UML图



图5 计费服务相关UML图  



5 结束语
由于当前的研究成果偏重于对CMDB进行需求分析,本文提出的基于分域思想的CMDB信息模型相对于已有的成果又迈进了一步。模型中对基本的配置项类和配置项类间关系做了详细描述,其中对常用基础设施和商务实体的定义借鉴了CIM和SID中已有的信息模型。同时又添加了IT服务、IT流程管理记录等ITSM所特有的信息项,并通过应用证明该模型可有效指导建立CMDB。但模型中对服务域的定义还略显单薄。考虑到IT服务是整个ITSM的核心概念,下一步可进一步地丰富服务域包含的配置项类,深度挖掘服务域与资源域间关系。


本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x




上一篇:这些ITIL“死而复生”
下一篇:IT运维如何实现“向管理要效益”
忘我之境

写了 302 篇文章,拥有财富 1631,被 3 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies
boy
boy 发表于 2011-7-14 16:32:00

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
恋恋1983 发表于 2014-4-10 10:29:42
我也是坐沙发的
漂零 发表于 2014-4-10 11:38:48
这么强,支持楼主,佩服
返回顶部