2007-12-29 15:41
在IT管理向ITSM(IT服务管理)体系演进的征途中,CMDB(配置管理数据库)从传统的电子报表中走来,蜕变为基于ITIL最佳实践的IT服务管理核心。对于所有的ITSM体系的建设者而言,CMDB都是一部庞大机器上必须精心打磨与调试的一个关键部件。
“水域,这是俄罗斯的必需!”彼得大帝的慨叹表达了一个民族对海洋的渴望。而在获得了出海口之后,封闭的俄罗斯终于打开了通往文明欧洲的窗口,走上富强之路。CMDB之于ITSM,或许远不如十六世纪海洋对于俄罗斯如此那般的迫切。但是在今天的IT管理领域,CMDB在完整ITSM系统中的核心地位绝对无可替代。今天,CMDB不仅是管理软件厂商和ITIL倡导者常挂嘴边的时髦词汇,也早已成为企业用户在IT管理项目推进中关注的焦点。
“通过更先进的资产管理和自动化流程,帮助用户建立跨系统的数据管理关联,从而最终推动跨功能的流程整合”是CMDB对用户的最新承诺。而在阐述CMDB现阶段的定义之前,必须说明的是,CMDB并不是IT管理领域的新生事物或名词。从诞生至今,CMDB经历了三次脱胎换骨的技术蜕变。实际上,早期的许多管理软件中都包含了现代CMDB的雏形,它们以电子报表的形式出现,简单记录IT资产信息;后来,CMDB演变为依附于帮助台的资产库,与帮助台捆绑并向用户销售;如今,CMDB摆脱了管理软件附属品的角色,成为独立的系统管理模块,是企业级集中式的配置数据库。
英国商务部出版的《ITIL服务支持》一书这样定义CMDB:“它是一种包含每一个配置项(Configuration Item,CI)全部关联细节以及配置项之间重要关联细节的数据库”。可以说,是ITIL最佳实践孕育了现代CMDB,目前CMDB中配置项信息覆盖了企业网络中的应用、操作系统、补丁、硬件设备、生命周期成本以及用户链接。针对目前大多数企业中IT配置数据以不同格式保存在桌面机、服务器、补丁包、操作系统和网络设备中的局面,CMDB把不同格式的数据统一采集到一个信息库中,打破了IT域之间的固有壁垒,有效管理IT资产。同时,通过对配置项信息的分析,快速定位系统故障来源。
而伴随着ITIL版本的刷新,CMDB在整个ITIL框架中的作用也悄然发生着变化。有专家指出,ITIL v2奠定了CMDB在ITSM中的重要地位,而ITIL v3则进一步释放了CMDB的效能,将其与知识管理和报告展现紧密地联系在一起。
模型设计:专注数据完整
有人将当下全球盛行的ITIL实践形容为一场“奥林匹克”盛会,一方面在“重在参与”精神的感召下,ITIL在企业用户中迅速普及;另一方面,“更高、更快、更强”的目标激发了参与者的潜能,用户和IT服务供应商开始追逐更有效率、更有效果的卓越IT运营能力。在这一轮激烈的竞技之中,CMDB因其对企业ITIL实施效果的决定性作用,被比喻为ITIL的“发动机”。
而在许多基于ITIL的ITSM项目中,实践者虽深知CMDB对于企业IT服务管理能力的重要性,但在部署过程中却往往被CMDB构建所涉及的庞大工作量所困扰,感觉困难重重,不得要领。同时,由于CMDB数据库工业标准尚处在讨论和修订阶段,并未形成通用标准,也让许多实践者感到无法从成熟规范中寻求支持。因此,有分析人士指出,IT管理者需要从CMDB概念的混乱中找到一条通向管理数据集成和最佳实践的路径。
要实现CMDB的成功构建,CMDB的设计和运作是必须攻克的两大难点。如果设计不当或无法有效运作,将极大地制约ITSM系统的管理能力,让IT运营的效率和效果大打折扣。同时,也只有实现了合理的模型设计和配置管理流程的有效运作,我们才能深入地探讨CMDB工具的选型,以及软件开发、数据挖掘和知识管理应用等更高层次的话题。在CMDB设计层面,对CMDB模型完整性的保证是设计过程的重中之重。
由于CMDB是ITIL流程支持的核心,它需要为ITIL其他流程提供IT服务及基础架构层面的配置信息,所以只有CMDB记录的数据完整,才能准确地反映IT服务的真实状态。而所谓CMDB的完整,包含了配置管理范围的识别、CI属性的选取和CI关系的构建。
第一步,确定配置管理的范围。这主要涉及CI的宽度和深度,以及CI的生命周期。需要说明的是,ITIL规范认为,CI的生命周期是从CI的接收到最终报废退出的全过程,但在具体实施过程中,由于流程管理主体的差异化,不同项目对CI生命周期的划分和定义会有所不同。
在确定CI的宽度和深度时,设计者应当从企业IT服务的需求、企业IT服务管理水平和CMDB运营管理成本三个方面进行合理规划。具体来说,CMDB构建应该主要从IT服务角度考虑,IT服务本身也可以作为CI记录到CMDB中,同时IT服务涉及的IT基础架构及其相关的重要信息都应记录到CMDB中;必须认识到CMDB与企业IT服务管理水平之间紧密的联动。企业IT服务管理水平越高,其对CMDB的依赖程度也随之上升,对CMDB数据的准确性和完整性也越高。同时,企业变更管理的成熟度,包括变更管理范围和流程执行力度也将在很大程度上影响CMDB数据的准确性和完整性;成本方面,CI的颗粒度决定CMDB中信息的详细程度,而这些信息的有效维护取决于IT部门投入的管理成本。如果无法投入相应资源进行CMDB的维护,其数据准确性便无法保证,也无法发挥其应有价值。
CI生命周期的确定主要包含对两个问题的确定。一是什么时候识别CI并记录到CMDB。在标准的配置管理流程中,CI全生命周期的理想状态应该覆盖从采购申请到报废退出的过程。但在实际实施时,流程执行主体的管理范围和职责将决定CI被识别的时间点;二是什么时候删除CI记录。这一时间点同样由流程执行主体的管理范围和职责所决定。例如,对于租赁的CI,IT部门并不关心它的报废过程,只关心其在生产环境中的运营状况,因此CI被租赁公司更换,则该记录就有可能被标记为删除。而CI记录的删除并不是数据的真正删除,而是将其标记为删除,这样做的目的是为IT审计提供数据支持。
第二步,定义配置项的属性。对于同一类型CI属性的定义,不同企业的定义方法可能截然不同。通常情况下,设计者需要遵循一个原则和一套结构。一个原则就是“精而不多”。如果我们将大量属性纳入CMDB,那么无疑将加大信息维护的成本。反之,如果属性过少,CMDB对流程支持的有效性就降低了。所以,所谓“精而不多”就是找到适合自身需求的平衡点。ITIL专家指出,CI属性的定义要注重选择的属性是否具备“面向服务的特性”。例如,一台商用服务器可能会包含上百个属性,但实际上经过筛选,对企业有实际意义往往是CPU个数、CPU主频、内存、硬盘、网卡等信息。
一套结构指的是,我们通常可以把一个CI的属性分为五大来源。
第三步,构建CI之间的关系。CI关系的定义也是配置管理建设与IT资产管理建设的区别之一。一般可以采取两种方法进行CI关系的梳理工作,即“自上而下”和“自下而上”的方法。“自上而下”通常要求企业先明确对外提供的服务目录,然后基于服务目录按照“业务服务→IT服务→IT系统→IT组件”的顺序进行梳理;“自下而上”则是逆流而上,先从对内部IT组件关系的梳理开始,然后逐步将IT组件映射到IT服务。
流程运作:确保数据正确
上线后的CMDB需要向ITSM系统提供准确的配置管理数据,尤其是要做到所记录信息与生产环境的数据保持一致,这就需要建立一套良好的配置管理运作机制。这套机制包含了制定配置管理策略、确定变更/发布与配置之间的流程关系、制定CMDB审计流程,以及配置管理的角色安排等工作。
1.配置管理政策的制定 该政策是企业配置管理的行动指南和共同纲领。它能够帮助企业统一认识,减少不必要的沟通成本,实现流程的高效执行。配置管理政策主要包含宏观政策和运营政策。其中,宏观政策涉及企业或IT部门层面指导性、方向性的政策,目标是在企业内部形成统一认识。例如,IT部门应该使用统一的配置管理流程,并且使用标准的文档记录和汇报机制。
运营政策主要涉及到流程目标、人员、输入、输出、活动以及KPI(关键绩效指标)等要素,以及流程之间相互协调、信息交互方面的指导原则,其目标是使流程能够在政策的指引下稳健、有效地执行。一般而言,包括CI的命名规范政策、CMDB数据保留政策,以及数据备份和恢复政策等。
2.确定流程间的接口关系 要实现CMDB的有效运作,成熟的变更/发布管理流程必不可少。其原因是,这一流程掌握着CMDB中数据变更的通行证。
CMDB数据的任何变更都应该对应已批准的变更请求单。同时,由变更管理流程将变更信息提供给负责配置管理的相关人员进行CMDB数据的更新。其中,CMDB数据的更新主要包括以下三种情况。
一是CMDB数据结构的变更。通常发生在因管理需要而重构CMDB模型的情况下,例如新增需进行变更控制而未识别的CI,因服务调整而重新梳理CI间的关系等;二是新增或删除CI。即指对已有CI的操作,例如更换或报废设备,新采购标准的配置等。从方便管理的角度出发,IT服务供应商往往会制定标准配置清单,用户应根据实际关系需求,确定配置清单颗粒细节的符合度;三是,修改CI的属性。此类变更是针对某CI具体属性的操作,例如增加了某服务器CI的硬盘容量,就需要对其相应属性进行调整。需要注意的是,CI属性的变更通常会关联到其他CI属性的调整。例如,硬盘CI信息变更时,管理员还需要调整服务器CI的属性,将无疑会增加数据维护的成本。针对这一问题,建议企业在确定CI属性数据时,尽可能地从其他可靠数据源中获取。例如,可以将服务器需要的硬盘容量属性数据通过数据继承关系,从硬盘CI本身的属性中获取。
3.CMDB审计流程的制定 在确保CMDB变更准确性的前提下,变更管理流程的构建需要经历一个持续改进的过程。用户往往会遇到CMDB数据仍与实际环境不符的问题,这就需要通过审计流程来进行检查、分析和修订。
来源:网界网