CMDB:ITSM的必需―配置管理数据库构建过程拆解

在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中的CI信息覆盖了企业网络中的应用、操作系统、补丁、硬件设备、生命周期成本以及用户链接。针对目前大多数企业中IT配置数据以不同格式保存在桌面机、服务器、补丁包、操作系统和网络设备中的局面,CMDB把不同格式的数据统一采集到一个信息库中,打破了IT域之间的固有壁垒。
 

        伴随着ITIL版本的刷新,CMDB在整个ITIL框架中的作用也悄然发生着变化。有专家指出,ITIL v2奠定了CMDB在ITSM中的重要地位,而ITIL v3则进一步释放了CMDB的效能,将其与知识管理和报告展现紧密地联系在一起。


    模型设计:专注数据完整

有人将当下全球盛行的ITIL实践形容为一场“奥林匹克”盛会,一方面在“重在参与”精神的感召下,ITIL在企业用户中迅速普及;另一方面,“更高、更快、更强”的目标激发了参与者的潜能,用户和IT服务供应商开始追逐更有效率、更有效果的卓越IT运营能力。在这一轮激烈的竞技之中,CMDB被比喻为ITIL的“发动机”。

    而在许多基于ITIL的ITSM项目中,实践者虽深知CMDB的重要性,但在部署过程中却往往被其构建所涉及的庞大工作量所困扰,感觉困难重重,不得要领。同时,由于CMDB数据库工业标准尚处在讨论和修订阶段,并未形成通用标准,也让许多实践者感到无法从成熟规范中寻求支持。因此,有分析人士指出,IT管理者需要从CMDB概念的混乱中找到一条通向管理数据集成和最佳实践的路径。
     

      要实现CMDB的成功构建,CMDB的设计和运作是必须攻克的两大难点。如果设计不当或无法有效运作,将极大地制约ITSM系统的管理能力,让IT运营的效率和效果大打折扣。同时,也只有解决这两个问题,我们才能深入地探讨CMDB工具的选型,以及软件开发、数据挖掘和知识管理应用等更高层次的问题。

      在CMDB设计层面,对CMDB模型完整性的保证是设计过程中的重中之重。由于CMDB需要为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部门投入的管理成本。

      CI生命周期的确定主要包含对两个问题的确定:一是什么时候识别CI并记录到CMDB。在标准的配置管理流程中,CI全生命周期的理想状态应该覆盖从采购申请到报废退出的过程。但在实际实施时,流程执行主体的管理范围和职责将决定CI被识别的时间点;二是什么时候删除CI记录。这一时间点同样由流程执行主体的管理范围和职责所决定。例如,对于租赁的CI,IT部门并不关心它的报废过程,只关心其在生产环境中的运营状况,因此,CI被租赁公司更换,则该记录就有可能被标记为删除。而CI记录的删除并不是数据的真正删除,而是将其标记为删除,这样做的目的是为IT审计提供数据支持。

      第二步,定义配置项的属性。

      通常情况下,设计者需要遵循一个原则和一套结构。一个原则就是“精而不多”。如果我们将大量属性纳入CMDB,那么,无疑将加大信息维护的成本。反之,如果属性过少,CMDB对流程支持的有效性就降低了。所以,所谓“精而不多”就是找到适合自身需求的平衡点。ITIL专家指出,CI属性的定义要注重选择的属性是否具备“面向服务的特性”。例如,一台商用服务器可能会包含上百个属性,但实际上经过筛选,对企业有实际意义的往往是CPU个数、CPU主频、内存、硬盘、网卡等信息。

       一套结构指的是,我们通常可以把一个CI的属性分为五大来源。具体的划分方法如附表所示。

 

 

 

    第三步,构建CI之间的关系。
      
      CI关系的定义也是配置管理建设与IT资产管理建设的区别之一。一般可以采取两种方法进行CI关系的梳理工作,即“自上而下”和“自下而上”的方法。“自上而下”通常要求企业先明确对外提供的服务目录,然后基于服务目录按照“业务服务→IT服务→IT系统→IT组件”的顺序进行梳理;“自下而上”则是逆流而上,先从对内部IT组件关系的梳理开始,然后逐步将IT组件映射到IT服务。


    流程运作:确保数据正确

上线后的CMDB要做到所记录信息与生产环境的数据保持一致,这就需要建立一套良好的配置管理运作机制。这套机制包含了制定配置管理策略、确定变更/发布与配置之间的流程关系、制定CMDB审计流程,以及配置管理的角色安排等工作。

    配置管理政策的制定

    该政策是企业配置管理的行动指南和共同纲领。它能够帮助企业统一认识,减少不必要的沟通成本,实现流程的高效执行。配置管理政策主要包含宏观政策和运营政策。其中,宏观政策涉及企业或IT部门层面指导性、方向性的政策。

     运营政策主要涉及到流程目标、人员、输入、输出、活动以及KPI(关键绩效指标)等要素,以及流程之间相互协调、信息交互方面的指导原则,其目标是使流程能够在政策的指引下稳健、有效地执行。一般而言,包括CI的命名规范政策、CMDB数据保留政策,以及数据备份和恢复政策等。

     确定流程间的接口关系

     要实现CMDB的有效运作,成熟的变更/发布管理流程必不可少。其原因是,这一流程掌握着CMDB中数据变更的通行证。变更/发布管理流程与CMDB更新之间的关系如图1所示。

 

 

 

 


    在图1中,CMDB数据的任何变更都应该对应已批准的变更请求单。同时,由变更管理流程将变更信息递送给负责配置管理的相关人员进行CMDB数据的更新。其中,CMDB数据的更新主要包括以下三种情况:
       一是CMDB数据结构的变更。通常发生在因管理需要而重构CMDB模型的情况下。例如新增需进行变更控制而未识别的CI,因服务调整而重新梳理CI间的关系等;二是新增或删除CI。即指对已有CI的操作。例如更换或报废设备,新采购标准的配置等;三是修改CI的属性。此类变更是针对某CI具体属性的操作。例如增加了某服务器CI的硬盘容量,就需要对其相应属性进行调整。

        需要注意的是,CI属性的变更通常会关联到其他CI属性的调整。例如,硬盘CI信息变更时,管理员还需要调整服务器CI的属性,这无疑会增加数据维护的成本。针对这一问题,建议企业在确定CI属性数据时,尽可能地从其他可靠数据源中获取。例如,可以将服务器需要的硬盘容量属性数据通过数据继承关系,从硬盘CI本身的属性中获取。

        CMDB审计流程的制定

        在确保CMDB变更准确性的前提之下,变更管理流程的构建需要经历一个持续改进的过程。用户往往会遇到CMDB数据仍与实际环境不符的问题,这就需要通过审计流程来进行检查、分析和修订。

        制定CMDB审计过程中需要注意的是,首次审计一般发生在CMDB初始化准备上线之前,此后CMDB的全面审计应该定期展开,企业应根据需要设置周期,一般一年至少展开一次。另外,CMDB还需要进行一些专项审计,从而小范围、细致地核查某类CI或某项关键服务所涉及的CI“账实相符”的状况。当CMDB审计发现数据不符时应尽快查明原因,并通过变更工单提请变更,最终修改CMDB数据。CMDB审计流程应该独立展开,审计员应由监管单位或部分的相关人员担任。

         配置管理的角色安排

        配置管理活动所涉及的角色主要分为四类,他们各司其职,协同完成CMDB的运作任务。其中,配置流程负责人需要对整个流程执行的结果负责,并拥有一定的流程管理权力;配置经理主要担当流程开发和管理的角色,重点确保配置信息的准确性和可用性;配置管理员负责维护配置数据,保证提供给IT部门的CMDB信息总是准确的;配置审计员则主要负责通过审计操作确认配置数据。各个配置管理角色之间的关系如图2所示。

 

 

 

    部署CMDB:丰俭由人

CMDB构建的重点在于对数据变更的把握,管理者需要用最合理的资源保证CMDB信息的“新鲜度”。这无疑是一项艰苦的任务,好在一些先行者积累了宝贵经验供后来者分享。同时,CMDB已经在金融、电信、政府、教育等行业拥有了一定的部署规模,这些案例将在同行业的CMDB构建过程中发挥示范效应。
     

        中国工商银行在ITSM领域的实践一直处于行业领先地位,并且项目执行到位。在CMDB构建的问题上,工商银行并没有购买CMDB商业软件,而是采取了自建的方法。在解释选择自建策略的原因时,工商银行信息科技部的技术负责人表示,市场上商业化CMDB工具还不够成熟。

        目前,大部分的CMDB软件可以自动发现基于服务器的软件应用,并构建映射关系图,但是对于一些主机应用或企业自行开发的应用却检测不到。对于应用种类繁多,同时存在大量自有和遗留应用的金融企业,商业CMDB工具对整个IT环境的覆盖能力有限。

    自建CMDB虽然需要企业投入更多的资金,但CMDB的独立性和实时性却能够在企业内部得到有效保障。目前,工商银行总行的资源管理库已经运行多年,实现了CMDB与帮助台、相关管理工具的有机结合,管理范围覆盖全行各分支机构,功能囊括主要的配置管理操作。而在电信行业,也有很多用户倾向于自建方式,主要也是考虑到商业CMDB软件对生产系统中管理对象的发现和管理能力欠缺的问题。

        无论是购买商业产品还是自行构建,CMDB的建设似乎都意味着企业需要投入巨资才能完成。这实际上是对CMDB的一种误解。作为ITSM实践的起点,同时也是ITIL的基础部件,CMDB的构建还有很多省钱的途径。

        美国杨百翰大学基于MySQL开源数据库构建校园CMDB是一个经典案例。新数据中心的落成和学校与上级机构的合并驱动了杨百翰大学踏上ITIL实践之路,并着手进行IT资产配置数据的集成与分享。但是CMDB项目并没有足够的资金支持,因此,他们着眼于开源软件。通过MySQL和廉价的学生劳动力,杨百翰大学构建了具备常规配置管理特性的CMDB。在CMDB构建的过程中,杨百翰大学对CI的类和子类进行了仔细的筛选,有效规避了CI颗粒度过细而容易导致的部署成本上升和构建难度加大等问题。而在未来,他们计划将这一系统升级到甲骨文数据库平台。


    联邦性:CMDB成熟的印记

Gartner2006年发布的CMDB研究报告指出,并不是所有的配置数据库都是CMDB,它必须具备联邦性、协调性、同步性、映射和可视化四大特性。这份报告给出了CMDB成熟度评估的具体依据。目前,很多软件厂商都宣称向用户提供CMDB工具,在其ITSM解决方案中也会包含CMDB组件。但如果站在专业ITSM实施的角度,它们中的一些更像是帮助台资产库尚未蜕变完全的产物。我们看到,很多所谓的CMDB得不到完整变更流程的支撑,数据的实时性无法保证;而一些产品介于IT资产库和配置数据库的中间,模型设计和配置策略不符合ITIL流程规范。联邦性、协调性、同步性、映射和可视化是区分不成熟和成熟CMDB的刚性标准。而现在,CMDB市场的发展仍然处在向这一标准逐渐靠近的过程之中。

        联邦性是软件供应商难于攻克的部分,同时也是近期技术进展最大的CMDB特性。从2006年开始,许多厂商将CMDB的联邦能力作为产品研发的重点,并相继推出了具有联邦特性的CMDB产品。这些产品包括IBM的CCMDB(变更和配置管理数据库)、Managed Objects的CMDB 360°,以及HP、BMC、CA、Symantec等公司的类似产品。
    

        联邦式CMDB符合技术和应用的发展方向,这一点已经能够通过现阶段的客户实践加以验证。在高度异构化的IT环境中,企业将所有IT资产的配置信息保存在一个通用数据库的想法并不现实。如果能够将多个数据库连接在一起,通过一个逻辑配置数据库构筑一个联邦式的CMDB,对于企业而言是一种切实可行的方案。这样一来,客户不必把所有配置数据都存储在一个大数据库中。联邦式CMDB通过记录不同数据库中配置信息的关联关系,在接到客户的访问请求时,可以快速追溯配置数据的保存位置。以前,很多厂商把CMDB的开发局限在自己的专有架构中,这种传统的技术方式限制了CMDB对多数据源配置信息的发现与集成能力。同时,不合理的数据复制方式还会造成集成后CI的高度冗余。联邦式CMDB通过逻辑上对配置数据的灵活调用和统一管理,弥补了传统CMDB的缺憾。


    推进方式:由点及面

CMDB的实施自然是“条条大路通罗马”,但在现阶段,从小处入手精心设计,逐步扩大CMDB的覆盖范围还是技术专家和企业客户所青睐的项目推进方式。

        传统的CMDB构建方法是自下而上地推进,也就是先做一个大的配置数据库,再逐步精炼CI。但这种方式的缺点是投入巨大且浪费时间,很多企业耗时数年才能完成CMDB的部署;已经拥有简单配置数据库的用户往往会选择自中而上的推进方式,以现有数据库为基础,添加必要的CI和CI之间的关系后,用户可以用比较短的时间就组建一个功能相对丰富的CMDB。

    而对于占据大多数的白手起家的用户而言,“自上而下,渐进式扩充”是一种可行性更高的方法。专家建议,用户可以先从订单系统、邮件系统这样的垂直应用开始,尝试在单一环境中发现、收集、追踪和管理配置信息的技巧,逐渐积累配置管理经验。在构建了相对成熟的配置管理流程后再构建更大范围的CMDB。

        一些用户还会先期规划一个小型的试验项目,它会包含CMDB所必须的审计、控制、自动化等环节。启动这种试验项目可以帮助企业收获一些关键的CMDB部署体验。例如,对IT资产配置的描述方法,如何通过准确的配置信息来支持IT服务管理,事件、故障、变更和发布管理流程的串联和磨合,以及如果更高效地对配置记录做出变更。

        而有专家建议,在启动这样的试验时,最好选择一个能够得到广泛支持的IT服务,而不是对业务营收至关重要的IT服务。同时,这样的服务不应该需要进行频繁地更新,并且在IT系统框架中处在相对独立的环境之中。因为频繁的变更操作将增加管理的难度,也更容易导致管理错误的发生。   
 

本文出自 www.sinoserviceone.com 转载等请务必保留此出处

【CNW.com.cn 专稿】在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中的CI信息覆盖了企业网络中的应用、操作系统、补丁、硬件设备、生命周期成本以及用户链接。针对目前大多数企业中IT配置数据以不同格式保存在桌面机、服务器、补丁包、操作系统和网络设备中的局面,CMDB把不同格式的数据统一采集到一个信息库中,打破了IT域之间的固有壁垒。
  

        伴随着ITIL版本的刷新,CMDB在整个ITIL框架中的作用也悄然发生着变化。有专家指出,ITIL v2奠定了CMDB在ITSM中的重要地位,而ITIL v3则进一步释放了CMDB的效能,将其与知识管理和报告展现紧密地联系在一起。

    模型设计:专注数据完整

有人将当下全球盛行的ITIL实践形容为一场“奥林匹克”盛会,一方面在“重在参与”精神的感召下,ITIL在企业用户中迅速普及;另一方面,“更高、更快、更强”的目标激发了参与者的潜能,用户和IT服务供应商开始追逐更有效率、更有效果的卓越IT运营能力。在这一轮激烈的竞技之中,CMDB被比喻为ITIL的“发动机”。

    而在许多基于ITIL的ITSM项目中,实践者虽深知CMDB的重要性,但在部署过程中却往往被其构建所涉及的庞大工作量所困扰,感觉困难重重,不得要领。同时,由于CMDB数据库工业标准尚处在讨论和修订阶段,并未形成通用标准,也让许多实践者感到无法从成熟规范中寻求支持。因此,有分析人士指出,IT管理者需要从CMDB概念的混乱中找到一条通向管理数据集成和最佳实践的路径。
      

      要实现CMDB的成功构建,CMDB的设计和运作是必须攻克的两大难点。如果设计不当或无法有效运作,将极大地制约ITSM系统的管理能力,让IT运营的效率和效果大打折扣。同时,也只有解决这两个问题,我们才能深入地探讨CMDB工具的选型,以及软件开发、数据挖掘和知识管理应用等更高层次的问题。

      在CMDB设计层面,对CMDB模型完整性的保证是设计过程中的重中之重。由于CMDB需要为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部门投入的管理成本。

      CI生命周期的确定主要包含对两个问题的确定:一是什么时候识别CI并记录到CMDB。在标准的配置管理流程中,CI全生命周期的理想状态应该覆盖从采购申请到报废退出的过程。但在实际实施时,流程执行主体的管理范围和职责将决定CI被识别的时间点;二是什么时候删除CI记录。这一时间点同样由流程执行主体的管理范围和职责所决定。例如,对于租赁的CI,IT部门并不关心它的报废过程,只关心其在生产环境中的运营状况,因此,CI被租赁公司更换,则该记录就有可能被标记为删除。而CI记录的删除并不是数据的真正删除,而是将其标记为删除,这样做的目的是为IT审计提供数据支持。

      第二步,定义配置项的属性。

      通常情况下,设计者需要遵循一个原则和一套结构。一个原则就是“精而不多”。如果我们将大量属性纳入CMDB,那么,无疑将加大信息维护的成本。反之,如果属性过少,CMDB对流程支持的有效性就降低了。所以,所谓“精而不多”就是找到适合自身需求的平衡点。ITIL专家指出,CI属性的定义要注重选择的属性是否具备“面向服务的特性”。例如,一台商用服务器可能会包含上百个属性,但实际上经过筛选,对企业有实际意义的往往是CPU个数、CPU主频、内存、硬盘、网卡等信息。

       一套结构指的是,我们通常可以把一个CI的属性分为五大来源。具体的划分方法如附表所示。


 


    第三步,构建CI之间的关系。
      
      CI关系的定义也是配置管理建设与IT资产管理建设的区别之一。一般可以采取两种方法进行CI关系的梳理工作,即“自上而下”和“自下而上”的方法。“自上而下”通常要求企业先明确对外提供的服务目录,然后基于服务目录按照“业务服务→IT服务→IT系统→IT组件”的顺序进行梳理;“自下而上”则是逆流而上,先从对内部IT组件关系的梳理开始,然后逐步将IT组件映射到IT服务。

    流程运作:确保数据正确

上线后的CMDB要做到所记录信息与生产环境的数据保持一致,这就需要建立一套良好的配置管理运作机制。这套机制包含了制定配置管理策略、确定变更/发布与配置之间的流程关系、制定CMDB审计流程,以及配置管理的角色安排等工作。

    配置管理政策的制定

    该政策是企业配置管理的行动指南和共同纲领。它能够帮助企业统一认识,减少不必要的沟通成本,实现流程的高效执行。配置管理政策主要包含宏观政策和运营政策。其中,宏观政策涉及企业或IT部门层面指导性、方向性的政策。

     运营政策主要涉及到流程目标、人员、输入、输出、活动以及KPI(关键绩效指标)等要素,以及流程之间相互协调、信息交互方面的指导原则,其目标是使流程能够在政策的指引下稳健、有效地执行。一般而言,包括CI的命名规范政策、CMDB数据保留政策,以及数据备份和恢复政策等。

     确定流程间的接口关系

     要实现CMDB的有效运作,成熟的变更/发布管理流程必不可少。其原因是,这一流程掌握着CMDB中数据变更的通行证。变更/发布管理流程与CMDB更新之间的关系如图1所示。





    在图1中,CMDB数据的任何变更都应该对应已批准的变更请求单。同时,由变更管理流程将变更信息递送给负责配置管理的相关人员进行CMDB数据的更新。其中,CMDB数据的更新主要包括以下三种情况:
       一是CMDB数据结构的变更。通常发生在因管理需要而重构CMDB模型的情况下。例如新增需进行变更控制而未识别的CI,因服务调整而重新梳理CI间的关系等;二是新增或删除CI。即指对已有CI的操作。例如更换或报废设备,新采购标准的配置等;三是修改CI的属性。此类变更是针对某CI具体属性的操作。例如增加了某服务器CI的硬盘容量,就需要对其相应属性进行调整。

        需要注意的是,CI属性的变更通常会关联到其他CI属性的调整。例如,硬盘CI信息变更时,管理员还需要调整服务器CI的属性,这无疑会增加数据维护的成本。针对这一问题,建议企业在确定CI属性数据时,尽可能地从其他可靠数据源中获取。例如,可以将服务器需要的硬盘容量属性数据通过数据继承关系,从硬盘CI本身的属性中获取。

        CMDB审计流程的制定

        在确保CMDB变更准确性的前提之下,变更管理流程的构建需要经历一个持续改进的过程。用户往往会遇到CMDB数据仍与实际环境不符的问题,这就需要通过审计流程来进行检查、分析和修订。

        制定CMDB审计过程中需要注意的是,首次审计一般发生在CMDB初始化准备上线之前,此后CMDB的全面审计应该定期展开,企业应根据需要设置周期,一般一年至少展开一次。另外,CMDB还需要进行一些专项审计,从而小范围、细致地核查某类CI或某项关键服务所涉及的CI“账实相符”的状况。当CMDB审计发现数据不符时应尽快查明原因,并通过变更工单提请变更,最终修改CMDB数据。CMDB审计流程应该独立展开,审计员应由监管单位或部分的相关人员担任。

         配置管理的角色安排

        配置管理活动所涉及的角色主要分为四类,他们各司其职,协同完成CMDB的运作任务。其中,配置流程负责人需要对整个流程执行的结果负责,并拥有一定的流程管理权力;配置经理主要担当流程开发和管理的角色,重点确保配置信息的准确性和可用性;配置管理员负责维护配置数据,保证提供给IT部门的CMDB信息总是准确的;配置审计员则主要负责通过审计操作确认配置数据。各个配置管理角色之间的关系如图2所示。


 


    部署CMDB:丰俭由人

CMDB构建的重点在于对数据变更的把握,管理者需要用最合理的资源保证CMDB信息的“新鲜度”。这无疑是一项艰苦的任务,好在一些先行者积累了宝贵经验供后来者分享。同时,CMDB已经在金融、电信、政府、教育等行业拥有了一定的部署规模,这些案例将在同行业的CMDB构建过程中发挥示范效应。
      

        中国工商银行在ITSM领域的实践一直处于行业领先地位,并且项目执行到位。在CMDB构建的问题上,工商银行并没有购买CMDB商业软件,而是采取了自建的方法。在解释选择自建策略的原因时,工商银行信息科技部的技术负责人表示,市场上商业化CMDB工具还不够成熟。

        目前,大部分的CMDB软件可以自动发现基于服务器的软件应用,并构建映射关系图,但是对于一些主机应用或企业自行开发的应用却检测不到。对于应用种类繁多,同时存在大量自有和遗留应用的金融企业,商业CMDB工具对整个IT环境的覆盖能力有限。

    自建CMDB虽然需要企业投入更多的资金,但CMDB的独立性和实时性却能够在企业内部得到有效保障。目前,工商银行总行的资源管理库已经运行多年,实现了CMDB与帮助台、相关管理工具的有机结合,管理范围覆盖全行各分支机构,功能囊括主要的配置管理操作。而在电信行业,也有很多用户倾向于自建方式,主要也是考虑到商业CMDB软件对生产系统中管理对象的发现和管理能力欠缺的问题。

        无论是购买商业产品还是自行构建,CMDB的建设似乎都意味着企业需要投入巨资才能完成。这实际上是对CMDB的一种误解。作为ITSM实践的起点,同时也是ITIL的基础部件,CMDB的构建还有很多省钱的途径。

        美国杨百翰大学基于MySQL开源数据库构建校园CMDB是一个经典案例。新数据中心的落成和学校与上级机构的合并驱动了杨百翰大学踏上ITIL实践之路,并着手进行IT资产配置数据的集成与分享。但是CMDB项目并没有足够的资金支持,因此,他们着眼于开源软件。通过MySQL和廉价的学生劳动力,杨百翰大学构建了具备常规配置管理特性的CMDB。在CMDB构建的过程中,杨百翰大学对CI的类和子类进行了仔细的筛选,有效规避了CI颗粒度过细而容易导致的部署成本上升和构建难度加大等问题。而在未来,他们计划将这一系统升级到甲骨文数据库平台。

    联邦性:CMDB成熟的印记

Gartner2006年发布的CMDB研究报告指出,并不是所有的配置数据库都是CMDB,它必须具备联邦性、协调性、同步性、映射和可视化四大特性。这份报告给出了CMDB成熟度评估的具体依据。目前,很多软件厂商都宣称向用户提供CMDB工具,在其ITSM解决方案中也会包含CMDB组件。但如果站在专业ITSM实施的角度,它们中的一些更像是帮助台资产库尚未蜕变完全的产物。我们看到,很多所谓的CMDB得不到完整变更流程的支撑,数据的实时性无法保证;而一些产品介于IT资产库和配置数据库的中间,模型设计和配置策略不符合ITIL流程规范。联邦性、协调性、同步性、映射和可视化是区分不成熟和成熟CMDB的刚性标准。而现在,CMDB市场的发展仍然处在向这一标准逐渐靠近的过程之中。

        联邦性是软件供应商难于攻克的部分,同时也是近期技术进展最大的CMDB特性。从2006年开始,许多厂商将CMDB的联邦能力作为产品研发的重点,并相继推出了具有联邦特性的CMDB产品。这些产品包括IBM的CCMDB(变更和配置管理数据库)、Managed Objects的CMDB 360°,以及HP、BMC、CA、Symantec等公司的类似产品。
     

        联邦式CMDB符合技术和应用的发展方向,这一点已经能够通过现阶段的客户实践加以验证。在高度异构化的IT环境中,企业将所有IT资产的配置信息保存在一个通用数据库的想法并不现实。如果能够将多个数据库连接在一起,通过一个逻辑配置数据库构筑一个联邦式的CMDB,对于企业而言是一种切实可行的方案。这样一来,客户不必把所有配置数据都存储在一个大数据库中。联邦式CMDB通过记录不同数据库中配置信息的关联关系,在接到客户的访问请求时,可以快速追溯配置数据的保存位置。以前,很多厂商把CMDB的开发局限在自己的专有架构中,这种传统的技术方式限制了CMDB对多数据源配置信息的发现与集成能力。同时,不合理的数据复制方式还会造成集成后CI的高度冗余。联邦式CMDB通过逻辑上对配置数据的灵活调用和统一管理,弥补了传统CMDB的缺憾。

    推进方式:由点及面

CMDB的实施自然是“条条大路通罗马”,但在现阶段,从小处入手精心设计,逐步扩大CMDB的覆盖范围还是技术专家和企业客户所青睐的项目推进方式。

        传统的CMDB构建方法是自下而上地推进,也就是先做一个大的配置数据库,再逐步精炼CI。但这种方式的缺点是投入巨大且浪费时间,很多企业耗时数年才能完成CMDB的部署;已经拥有简单配置数据库的用户往往会选择自中而上的推进方式,以现有数据库为基础,添加必要的CI和CI之间的关系后,用户可以用比较短的时间就组建一个功能相对丰富的CMDB。

    而对于占据大多数的白手起家的用户而言,“自上而下,渐进式扩充”是一种可行性更高的方法。专家建议,用户可以先从订单系统、邮件系统这样的垂直应用开始,尝试在单一环境中发现、收集、追踪和管理配置信息的技巧,逐渐积累配置管理经验。在构建了相对成熟的配置管理流程后再构建更大范围的CMDB。

        一些用户还会先期规划一个小型的试验项目,它会包含CMDB所必须的审计、控制、自动化等环节。启动这种试验项目可以帮助企业收获一些关键的CMDB部署体验。例如,对IT资产配置的描述方法,如何通过准确的配置信息来支持IT服务管理,事件、故障、变更和发布管理流程的串联和磨合,以及如果更高效地对配置记录做出变更。

        而有专家建议,在启动这样的试验时,最好选择一个能够得到广泛支持的IT服务,而不是对业务营收至关重要的IT服务。同时,这样的服务不应该需要进行频繁地更新,并且在IT系统框架中处在相对独立的环境之中。因为频繁的变更操作将增加管理的难度,也更容易导致管理错误的发生。

(本文作者之一陈宏峰先生为翰纬IT管理研究咨询中心研发总监)

    编看编想

CMDB普及期待标准支持

      CMDB在ITSM领域的重要性毋庸置疑,但是用户在相关产品选型上的困惑短期内仍然难以消除。长期以来,不同品牌CMDB之间的互操作能力一直无法让用户满意,这也是一部分用户不惜巨资自建CMDB的关键原因。由于CMDB本身的演进过程就非常漫长,并且在相当长的时间内是通过与帮助台捆绑的方式进入企业的IT环境的,那么,配置数据库的重叠在信息化起步早的企业中便成了非常普遍的现象。如何将分散在不同应用中的配置信息收集起来,并进行有效集成,目前的商业CMDB工具并不能提供成熟的解决方案。而这一问题的解决,有赖于CMDB标准化进程的快速推进。

      目前这一领域的软件公司已经意识到,标准是激发CMDB市场潜力的催化剂。2006年4月,一个旨在建立配置数据共享通用规范的协作性组织CMDB联盟工作组(CMDBf)成立,成员包括IBM、BMC、CA、HP、微软等。今年2月,该组织推出了一份阐述配置信息共享机制的白皮书,8月,该组织发布了公共过渡性草案0.95版本,定义了联邦式CMDB与其他管理数据库数据共享的形式。虽然CMDB规范框架初现,但与用户的部署需求及项目实施的步伐相比,其进展仍显滞后。这样的规范缺失虽不致于让用户的实践陷于无序,但这种状态的持续将制约CMDB的普及。因此,无论是出于市场拓展的需要,还是向用户提供规范化的部署指导,开放和遵循统一标准都应该是CMDB软件供应商的共同选择。


 
本文出自 www.sinoserviceone.com

你可能感兴趣的:(职场,休闲,ITIL,CMDB,ITSM)