在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更新之间的关系。
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信息总是准确的；配置审计员则主要负责通过审计操作确认配置数据。各个配置管理角色之间的关系.
部署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系统框架中处在相对独立的环境之中。因为频繁的变更操作将增加管理的难度，也更容易导致管理错误的发生。
