配置管理数据库

出自 MBA智库百科(https://wiki.mbalib.com/)

配置管理数据库(Configuration Management Database,CMDB)

　　配置管理数据库是指这样一种数据库，它包含一个组织的IT服务使用的信息系统的组件的所有相关信息以及这些组件之间的关系。配置管理数据库提供一种对数据的有组织的检查和从任何想要的角度研究数据的方法。

　　配置管理数据库的作用在于：用来收集所有与配置有关的信息；用来评价系统变更的效果；用来为配置管理过程提供管理信息。而根据配置管理数据库的不同应用，可以分为以下3种。

　　(1)开发库：它是指专门供给开发人员使用，里面存储的信息可能会作频繁的修改，而且对其控制也相当宽松。主要是为了更好地适应开发人员日常工作的需要。

　　(2)受控库：是指在生存期某一阶段工作结束后发布的阶段性产品，通常包括人工制品和机器可读信息{源代码、可执行文件等)。由于软件配置管理的关键也正是对受控库中的各个软件项进行管理，因此受控库也通常称之为软件配置管理库。

　　(3)产品库：是指开发的软件产品已经通过了系统测试后使用的配置管理数据库。它通常存放的是最终产品，等待交付用户或现场安装的产品。

　　1)确定配置管理的范围

　　建立配置管理数据库，首先要考虑的是IT基础架构中哪些信息需要纳入配置管理的控制、配置项的宽度和深度，以及配置项的生命周期。

　　配置管理流程作为IT服务的支持流程，IT服务本身也可以作为配置项记录在配置管理数据库中，配置管理数据库与组织IT服务管理水平密切相关。一方面组织的服务管理水平不断提高，需要配置管理数据库为之提供更详细、更准确的配置项信息，对配置管理数据库的管理要求也随之提高；另一方面，配置项的广度的扩大会造成IT成本的增加，深度的加深又会给IT管理带来一定的难度，因为组织海量级的配置项信息需要实时性和准确性才能对业务服务有所帮助，否则就很难体现出配置管理数据库的价值。所以组织应该从IT服务需求和配置管理数据库成本平衡角度出发，选择一个能够为业务提供所需基础信息又能将IT管理投资最小化的适合组织发展的配置管理范围。

　　配置项的生命周期应该从采购申请开始到报废销毁结束。所以组织需要确定一个配置项信息被记录到配置管理数据库和从配置管理数据库中被删除的时间点，为配置管理审计提供支持。

　　2)配置管理数据库基线

　　配置管理数据库的信息由配置信息基线和变更集组成，基线备份分为两种：

　　·基于数据库的定期备份

　　制定备份策略，备份代理定期或者适时连接备份服务器，将配置管理数据库备份到备份服务器上的备份库中。作为某个特定时刻配置管理数据库状态的快照，当配置信息遭到破坏或丢失时，配置管理数据库可以恢复到故障前最近的完整状态，提高系统资源的安全性和抗毁性，将灾难带来的损失降到最低。

　　·基于变更内容的备份

　　对配置项的修改来自于变更任务，在每次实际修改过程中，自动备份配置项的修改前内容，作为变更前版本，修改后内容作为配置项的当前值，保障配置项历史信息的回溯和查询。

　　3)确定配置项的颗粒度

　　配置管理数据库能否为业务服务提供良好的支持，很大程度上取决于配置项的详细程度，组织应该制定所有配置项分类的颗粒度范围，配置项颗粒度太粗会导致配置管理数据库无法为其他流程和业务服务提供支持，同时会影响到配置项之间的关联关系。举例来说，如果网络设备中以一个交换机为配置项，当交换机上的某一个端口发生故障时，无法立刻定位影响到哪套信息系统，只能说和这台交换机有关的业务可能都受到了影响，这就无法体现配置管理数据库的价值所在。但是配置项颗粒度如果太细，就会造成配置管理数据库管理人员的巨大压力，会大大增加IT运维成本。就刚才的例子来说，如果反之网络设备的配置项细化到每个交换机的端口都是一个配置项，那么当它发生故障时，的确能够很快根据配置管理数据库中的信息定位到受影响的业务系统，并且能够确定影响程度和范围，但是一个组织若有上百台甚至上千台的交换机，每天仅端口信息的修改就会给组织的人力、物力带来很大的压力。所以如何定义配置项的颗粒度对于配置管理数据库的使用和价值体现都起着决定性的作用。

　　4)确定配置项的属性内容

　　一个配置项的属性内容决定了它能为其他流程服务提供的具体信息，但是一个配置项的属性可能有成百上千个，选择找到适合配置项自身需求的属性、最有用的信息，就能够大大降低维护信息的成本。一个配置项属性的定义要具备面向服务的特性。例如一台服务器有很多属性，但是可能对于某个组织来说，只有IP地址、内存、CPU等信息是有实际意义的。

　　5)建立配置项之间的关联关系

　　配置项的关联关系对于处理事件、问题，确定变更的影响范围和程度以及对服务可用性的预测起着很大的帮助作用。配置项之间的关联关系可以分为四种，属于、包含、对应和连接。组织可以采用两种方式对配置项关联关系进行整理，第一种方式是自上而下的方式，即按照“业务服务→IT服务→IT系统→IT组件”的模型定义配置项关联关系，这种模式的优点在于以业务为主线能够快速建立起所需要的配置项关联关系模型，但是很难建立完整的配置管理数据库。另一种方式是自下而上的模式，即先建立组织内部的所有配置项和配置项关系，然后逐步映射到相应的业务服务。这种模式的优点在于能够建立全面的配置管理数据库，为配置管理日后发展打下扎实的基础，但是建立周期较长，企业会在配置项的建立上花很多的时间。

　　6)配置项状态

　　配置项的状态共分为以下四种。

　　·新申请状态：当对于新增配置项的变更请求还未经过评估和批准，需要在配置管理数据库中记录该新增配置项时，其状态为“新申请”。

　　·准备状态：新增配置项的变更请求已经经过评估和批准，但是配置项还未投入正常使用，其状态为“准备”。

　　·运行状态：配置项在正常使用，其状态可置为“运行”。

　　·报废：当配置项已经被撤销，不会再使用时，将状态置为“报废”。

　　7)配置项的命名规范

　　每个配置项都应该有唯一的配置项编号，建议组织在制定配置项命名规范时，能够充分考虑编号的可扩展性和易记性，同时从编号中能够反映一部分的配置项信息和关联关系信息，为配置项管理员提供帮助。

　　8)配置项和流程的关联

　　变更、事件、问题管理流程都会牵涉到配置项的更新，同时配置项信息也为IT服务管理流程提供帮助，这就需要配置项能够和这些流程紧密结合。

　　一个高效、好用的配置管理数据库(Configuration Management Database，CMDB)需满足以下6条重要标准，即联合、灵活的信息模型定义、标准合规、支持内置策略、自动发现和严格的访问控制。

　　车辆制造商、大型零售商、银行这些全然不同的企业之间有什么共同之处？答案就是它们都需要IT，或者更准确地说，它们都要遵循IT基础架构库(ITIL)服务管理的最佳实践，采用自动化IT管理解决方案以实现重要的业务目标，包括减少服务中断、降低成本、提高IT效率、促进法规遵从等。

　　实施ITIL最佳实践的核心就是配置管理数据库(CMDB)。CMDB将IT基础架构的所有组件储存为配置项，它不仅能维护每个配置项的详细数据，而且能维护各配置项之间的关系数据。同时，CMDB还能维护各配置项中包括其事件和变更历史在内的管理数据。通过将这些数据整合到中央存储库，CMDB可为企业了解和管理数据类型之间的因果关系提供保障。更为关键的是，CMDB可实现IT服务支持、IT运维及IT资产管理内部及三者之间的流程整合与自动化，为业务服务管理(BSM)这全面、统一的IT运行平台奠定坚实基础。

　　业内普遍认为，一个精心架构的CMDB能为IT部门奠定坚实的基础，提高服务基础架构的透明度、可靠性以及可控性，并能自动化服务的配置管理，同时确保IT运维持续遵从企业政策、政府法规、行业标准和最佳实践。当然，为实现这种高水平的集成度和自动化，CMDB需满足以下六条重要标准，即联合、灵活的信息模型定义、标准合规、支持内置策略、自动发现和严格的访问控制。

　　联合

　　CMDB提供IT环境的单一、准确的信息源，因此，可以将它看做是一个记录IT基础架构数据的中央存储库。但是，将所有基础架构信息存放在一个数据库中很难实现，因为基础架构的类型、各类元素类型及管理数据的类型种类繁多，且各数据类型中也存在着不同的粒度水平。比较可行的方法是将各个CMDB和其他的数据存储统一到ITIL所定义的配置管理系统(CMS)中。这样，根据IT基础架构和运维管理的不同功能所创建的各个CMDB数据集将共同形成一个整体的企业CMDB。

　　统一多个数据存储需要采用一种联合的方法，并且在创建企业CMDB架构时就需设计考虑到这种联合方法，而不能事后补入。建立在联合架构中的CMDB能接入广泛的信息，而无需将所有数据移动或复制到CMDB中。为确保该方法有效实行，整体企业CMDB中的各个数据存储必须清晰地隶属于不同的功能领域，且满足数据交换、数据核实和数据访问三方面要求。

　　比如，在一家大型服装零售店里， CMDB存储了IT环境的基本信息，并为其他关键、详细的数据存储提供索引。配置项关系和管理信息使工作人员能够将资产与事件和问题相关联，理清事件之间的相互关联信息，从而能从根源上分析事件和问题产生的原因。通过联合方法，CMDB向工作人员提供所需信息，让他们更有效地管理资产生命周期。这将有助于确保企业不会浪费资金，继续支持维护历史遗留系统。

　　采用联合方法的一项关键要求是具备强大的数据整合能力，以确保多源数据的准确性和一致性。数据整合不仅能消除重复数据，使各部分有且仅有一个配置项，还能确保多源数据连接到正确的配置项。

　　灵活的信息模型定义

　　CMDB信息模型有两种不同的方式。一种是自上而下，即先有一个宏观的企业视图，然后在CMDB中为该视图部署一个元数据模型，然后确保所有管理应用程序符合元数据模型。另一种方式是自下而上，即把低层的数据集进行标准化，依此开发元数据模型。

　　大多数IT机构会选择自下而上的方式。因为采用这种方式，现有的管理数据集能轻松地并入元数据模型中，减少部署工作，加快产生价值。由此产生的元数据模型与具体的管理功能和应用无关，因而比实际的低层次数据集更易操控，而那些低层次数据集则受制于具体应用所引发的具体管理功能。自下而上方式的另一项优点在于它更易被接受，因为与自上而下的方法不同，它无需破坏企业的组织架构和文化。精心架构的CMDB可同时支持这两种方式，满足IT要求并提供部署CMDB所需的IT灵活性。

　　标准合规

　　联合架构包含多个CMDB，也就意味着出现多个数据集，因此必须实现各个CMDB之间及数据集之间的互操作性。这就需要标准化的数据交换机制，以确保数据准确，保护数据安全，实现有控制的访问。所以，CMDB架构需在网络服务方面支持如XML和SOA等开放标准。通过标准支持，可实现不同数据存储之间的相互操作，同时确保数据不违反IT部门为其企业CMDB开发的元数据定义的整体性。

　　支持内置策略

　　精心架构的CMDB可以涵盖策略、记录服务及服务相关辅助组件的创建、更新、实施、持续合规追踪等环节中用到的标准。这些服务可以是应用、中间件、系统可用性、数据库、网络设备和操作系统等。服务相关辅助组件可以是网络服务器、数据库服务器、应用服务器、网络设备、客户机等。标准中必须包括数据集的详细信息，如配置、安装、性能和运行时间。策略可能是动态的，并且可能因时间、用户数和服务水平协议(SLA)等因素而变动。

　　精心架构的CMDB还可包括流程模型。由于IT环境通常随时间变化而发生变更，因此这些流程模型必须也是动态的，以自动适应这些变更。

　　由于能够包含策略和流程模型，CMDB在基于策略的流程自动化中发挥着十分重要的作用。这种自动化能大幅加快流程执行，同时执行最佳实践流程应用。例如，一家专注于卡式支付交易服务、电子支付系统和国际金融信息的基础架构服务供应商应用了CMDB之后表示，CMDB可以帮助IT部门在极短时间内高质量高水平地执行所有发布、变更和SLA管理等主动的、前瞻性的流程。

　　自动发现

　　CMDB需自动发现IT基础架构中的所有资产及其详细信息、各项资产之间的物理和逻辑关系，以及资产与其支持的服务之间的关系。联合方法可以支持自动发现，因为该方法能获得基础架构中任何一项组件的详细信息。

　　已经有一些领先的企业选择了自动化工具来发现IT环境中的配置项并将其反馈到CMDB，这些工具还能捕捉组件之间的逻辑依赖关系，并识别哪些IT组件包含企业应用。

　　传统上，IT利用自动发现功能快速传播库存信息。最新一代的自动发现方案还可定期扫描IT环境，提供特定组件在不同时间点的实时配置信息。对于任何针对组件及其支持的服务所进行的分析而言，实时发现加之按时间顺序产生的一系列实时信息，将有着十分重要的意义。

　　严格的访问控制

　　在IT领域，未经授权或未预料到的访问和变更会导致服务中断或宕机。因此，安全和访问控制在CMDB设计和部署中发挥着必不可少的作用。访问政策可用于用户和工作群创建资料介绍和访问控制。

　　CMDB必须符合安全标准，以防止对数据集执行任何未经授权的变更。这些标准可以通过目录进行归档，以确定各个数据集的各自授权访问人员，以及访问人员的数据集操作权限。CMDB具有这种内置的、基于角色的访问控制之后，就可以通过目录访问权限来实现用户身份验证。

　　为了确保CMDB项目实施的成功，防止不必要的项目拖延，企业在实施配置管理数据库（CMDB）时应该有一些预防措施，本文提出了6个方面的缺陷，企业在实施CMDB时应该极力避免。

　　缺陷1:不能识别CMDB的目标和收益

　　CMDB管理着企业环境内的众多配置项及其关系，这些配置项可以是服务、软件、硬件、系统、操作系统、应用程序、数据库、流程文档、安全文档、网络组件等。

　　在不同的企业之内，这些特定的配置项的重要性是不同的。CMDB不能也不应该管理企业内的每个资产、文档或流程。每一个企业都不应该对自己的配置项的特定目标和利益视而不见。

　　如果知道CMDB如何应用，比如理解变更的影响，就可以基于CMDB购买和实施的成本，对项目的目标进行成本－利益分析和衡量。清楚地定义短期目标和长期规划，对于CMDB项目的初期开展很关键。如果不能合理地定义目标和量化投入产出比（ROI），你的方案就很难得到管理层的同意。

　　缺陷2:让CMDB成为一个元数据的倾销库

　　为了获得最大的业务价值，要认识到CMDB中什么可以管理与什么应该管理两者之间的区别。一些企业在发起实施CMDB时，有时候会不加区别地将所有来自配置项（CI）仓库的数据全部输入到CMDB，而未能进行充分地关系文档化或者是对配置项的变化进行管理。

　　CMDB应该只包含那些计划将要积极去管理的配置项。如果将所有的数据都倒入CMDB之中，没有一个规划，企业就会身处一个难以管理且价值不大的知识库之中。

　　缺陷3:忽视变更管理的需要

　　如果没有一个有效的变更管理流程，CMDB将很快就会与现实不同步。因此，CMDB和配置管理流程必须与变更管理流程紧密结合在一起。只有经过认可的变更可以进入CMDB，只有作为变更请求（RFC）的一部分的配置项才能进行更新。如果不能满足这些要求，CMDB的实施将会陷入一个向下的螺旋，直至失败。

　　缺陷4:不能获得利益相关者的支持

　　CMDB实施在企业之内会有很多接触点。与配置项相关财务、能力和可用性等属性都要求从分离的不同部门输入，如果关键的利益相关者从一开始就没参与，如果他们不能得到CMDB能为组织交付的真正价值，那么要让他们支持一个包含所有必要的属性和关系的CMDB的建设会很困难。

　　因此，在CMDB项目的开始，就要努力获得关键的利益相关者的支持。要向他们表明，CMDB将会使得他们持续不断地改善相关指标和关键绩效指标（KPI），这样你就能得到所有相关方面的支持。

　　缺陷 5: 难以更广泛地实施

　　在项目开始之初就能对其进行有效的引导和控制，比如说一个被清楚定义的业务服务的实施，这对于项目的成功是关键的。首先要确定支持业务服务的配置项，如应用服务器、网络服务器、路由器、数据库和数据库服务器等，然后就要确定在这些配置项之间存着什么类型的关系，比如说是“依托运行”、“主机”、“连接”、“管理者”等。这些关系有助于理解和降低与组成服务的配置项的变更相关的风险

　　一旦CMDB按照这样的做法初步成功实施，企业就可以考虑扩展项目的范围，以一种有效且高效率的方式来管理更多的配置项。这种渐进的方法可以让企业迅速地实现价值，同时还会获得进行更广泛实施所需要的经验。

　　缺陷6：在流程和培训的投入上吝惜

　　CMDB的成败取决于使用和维护它的人，如果这个人没有经过合理使用和维护流程的培训，那么，CMDB将会是低效的，其中的内容很快就会变得过时和不准确。正确的培训也有助于确保一个成功的实施，以及一次值得付出的投资。

　　能够避免以上六个方面错误的企业将会安全地完成CMDB的实施，并提高成功的可能性。这意味着他们能以更低的成本为业务提供所需要的服务，同时还能确保这些服务在一个符合要求的绩效水平上运行。