OneCMDB中文

去年做的省公司IT服务流程中设计了了一个“不可用CI”报告的功能，同时配置管理流程里面针对配置变更有“配置变更申请”功能，同事对这两个功能不能理解。因为在实际开发过程中，开发人员将“不可用CI”报告的功能最后操作定义成了直接更新CMDB，不需要走流程，而将“配置变更申请”功能需要走“CMDB控制和维护”流程。同事的疑问不可用CI是否会破坏流程性及用户误操作。我的意见是这两个功能都不可缺失。

配置管理员是配置管理流程中主要工作承担者，其职责为：通过手工或自动化操作增加及更改配置项，保证所负责的关键CI的关键属性、关键CI间的关键关系完整、准确。实际工作中由各专业技术人员分别担任配置管理员，维护各自所管的设备或应用。配置管理员可以按照基础架构的分类划分，也可以按照所属业务的类别进行划分。也就是说实际过程中配置管理员数量会是1+个。

配置管理和其他流程关联原则

• 配置管理和变更管理的关联
  • 变更主管在变更计划阶段必须制定配置项更新计划，对计划修改的配置项进行说明
  • 变更实施完后，由变更主管汇总相应的配置项修改的情况，并通知相应的配置管理员，配置管理员接收到配置项修改请求后，与CI实体进行核对，核对无误后方可修改CI属性以及关系
  • 对于风险等级为高和重大的变更，CAB中应该包括配置经理，以确保对CMDB的适当控制
  • CI应与变更记录建立关联，从而对CI的变化情况进行记录
• 和事件管理、问题管理的关联
  • CI应与事件记录、问题记录建立关联，从而确保对CI维护工作的统计和分析

从配置管理和其他流程关联关系来看，配置变更主要由变更管理流程发起，也就是需要提供“配置变更申请”功能给变更流程作为流程接入点，但是在实际中配置管理员需要对CMDB中数据准确性负责，然而在事件流程、问题流程或者其他流程过程中发现CMDB中记录的CI实例值更实际情况不符合（例如：CMDB中记录Sever1连接Switch1的23端口，但实际却是连接Switch2的3端口），这种情况怎么办呢？发起变更流程？工程师没有变更任何东西呀。这种情况下应该做出CI例外报告（HP这样的翻译实在不好），就设计了一个功能专门用于报告CI不可用的情况。

两个功能设计如下：

• 不可用CI报告：用于其他流程运维人员提交CMDB中记录有误的情况，用于辅助配置管理员收集错误的CI。配置管理员在收到不可用CI报告时需进一步核实CI情况，以便修改CMDB数据或者发起配置变更申请。
• 配置变更申请：为“CMDB控制和维护”子流程正常入口，用于变更流程或者配置管理员发起CI修改流程

在查看BMC Remedy IT Service Management功能之后，发现BMC中有一个“创建CI不可用性”的功能，名称好近似呀。不过BMC定义：CI 不可用性是指 CI 的实际宕机时间。您可以记录因某事件导致的意外情况引起的 CI 不可用性。看来在引入ITILV3后续流程后需要重新对不可用CI报告重新命名，以免误会。

注：转自Dominic.Xu’s 博客，原文地址：http://web2world.cn/article/2010/07/a146.html

项目的参与沟通方可能很多，最多的情况下，可能包括：网络部门、系统部门、安全部门和各个业务部门。沟通的内容主要是配置采集的实施技术方式。其中采集的安全性，风险分析是最重要的部分；在部门多的情况下，面对多种选择的时候，逐一给项目各方说清所有方案，特别是讲清楚利弊是非常耗时的。在充分沟通了所有技术可能性之后，才能做出倾向性选择。逐一这是第一轮沟通，搞清楚了倾向性而已。

特别是银行等金融企业，安全性要求特别高。安全风险方面的建议往往是最重要的，他们的建议对配置采集工具的实施具有决定性意义。在各方都充分理解了配置采集工具的架构和安全性之后，就是拍板定夺了。这种逐级的审批和决策是需要较长的周期。

在前导时间里，可能还没有部署正式的ADDM采集服务器。在这个阶段里，要配置网络，让以后的采集服务器能够处于能够扫描到所有目标服务器设备。还可能需要在每台服务器上配置相关的准备工作，主要是坚持主机的操作系统的账户、采集协议和安全配置等是否满足配置采集工具的要求。这写工作是一个群众性运动，需要让所有的系统管理员配合。此项工作的设计人员设备多，最好能尽早的开始。

用户对配置工具的期望主要是集中在深度和细度方面。其实这也不为过，只是在实施的过程中，最好还能把发现工具的一下特有的功能和特殊推广给用户。如软件和硬件的EOL信息，一些开合即用的报表和图形化展示功能，全文搜索等等功能其实都可以给客户带去意想不到的价值 。

本文转自：MartinLiu的博客，原文地址：http://martinliu.cn/2010/04/cmdb-addm-tool-implement-good-practice.html

车辆历史信息供应商CARFAX、大型零售商、基础架构服务供应商这些全然不同的企业之间有什么共同之处？答案就是他们都遵循IT基础架构库（ITIL）服务管理最佳实践，采用自动化IT管理解决方案以实现重要的业务目标，包括减少服务中断、降低成本、提高IT效率、促进合规遵从等。

对每个公司而言，IT管理战略的核心都是配置管理数据库（CMDB）。CMDB将IT基础架构的所有组件储存为配置项，不仅能维护每个配置项的详细数据，而且能维护各配置项之间的关系数据。同时，CMDB能维护各配置项中包括其事件和变更历史在内的管理数据。通过将这些数据整合到中央存储库，CMDB可为企业洞察管理数据类型之间的因果关系提供保障。

CMDB可实现IT服务支持、IT运维及IT资产管理内部及三者之间的流程整合与自动化。因而，CMDB为业务服务管理（BSM）这全面、统一的IT运行平台奠定了坚实基础。

CMDB所提供的整合服务使工作群组之间的工作流程更加流畅，并实现了端到端的流程自动化。这可以帮助IT提高服务质量，更有效地管理服务，实现持续性合规遵从。为实现这种高水平的集成度和自动化，CMDB所建于的基础架构需满足以下六条重要标准，即联合、灵活的信息模型定义、标准合规、支持内置政策、自动发现和严格的访问控制。

1.联合

CMDB提供IT环境的单一精准信息源，因此，可以将它看做是一个记录IT基础架构数据的中央存储库。但是，将所有基础架构信息存放在一个数据库中很难实现，因为基础架构的类型、各类元素类型及管理数据的类型种类繁多，且各数据类型中也存在着不同的粒度水平。

比较可行的方法是将各个CMDB和其他的数据存储统一到ITIL所定义的配置管理系统（CMS）中。这样，根据IT基础架构和运维管理的不同功能所创建的各个CMDB数据集将共同形成一个整体的企业CMDB。

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

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

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

2.灵活的信息模型定义

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

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

3.标准合规

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

4.支持内置政策

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

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

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

5.自动发现

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

车辆历史信息领先供应商CARFAX依靠自动化工具来发现IT环境中的配置项并将其反馈到CMDB。这些工具还能捕捉组件之间的逻辑依赖关系，并识别哪些IT组件包含企业应用。

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

6.严格的访问控制

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

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

配置自动化的基础

精心架构的CMDB能为IT部门奠定坚实的基础，提高服务基础架构的透明度、可靠性以及可控性。结合发现与决策支持应用，CMDB能为构建一个完整的平台提供基础。该平台将能自动化服务配置管理，同时确保IT运维持续遵从企业政策、政府法规、行业标准和最佳实践。(文/万纬科（Vick Vaishnavi），BMC软件公司企业服务管理全球市场副总裁)

本文转自eNetCIO频道：衡量有效CMDB架构的六大标准

建立、实施CMDB应该注意什么？

本人负责并参与过ITIL相关评估与研讨，配置管理与CMDB的建立一直是ITIL建设的核心与难点，在这里谈谈我个人的看法，供大家参考，并希望共同探讨！

首先强调一下配置管理的核心地位：

事件管理、问题管理、变更管理、发布管理都是与配置管理紧密相关的，试想如果CMDB对故障设备的hostname与location提供了错误描述，事件能够得到及时解决吗？如果没有配置管理的同类故障统计分析支持，如何实现主动的问题管理？如果没有配置管理提供CI之间的关系作为依据，如何针对将要进行变更的CI做风险评估？ITIL实施的难点之一就是因为这些管理，并不是相互孤立的，而是相互关联并且相互制约的，而配置管理恰恰就是这些关联的枢纽与核心。

要建立与实施配置管理，要清晰配置管理的相关概念，并避免几个误区

这些概念包括什么是配置管理、什么是CI、什么是CMDB、CMDB与DSL/DHS (V3用的是DML)的关系等，建议准备真正实施ITIL的人一定要熟练掌握（个人感觉V3的SACM（服务资产与配置管理）的相关定义比V2描述的更加清晰），在这里我不会具体赘述概念本身，但强调一些大家可能会有的误区。
误区一CMDB= Asset DB，准确说CMDB> Asset DB, 这个大于有两层含义，一 CMDB中的CI包含所有服务资产与IT组建，如设备、服务、系统、人、知识、文档等，远远大于asset db中的设备; 二CMDB是一个更大的逻辑库，更侧重CI组建的逻辑映射与关联，这些关联必定会很立体并远远复杂于Asset DB。
误区二 配置管理=CMDB，这也是很多实施ITIL的人容易有的误区，务须置疑CMDB是配置管理的核心， CMDB的范围与深度，理论上说其实是可以无限扩展和细化的。但是评估配置管理，不是要评估其CMDB有多么多么准确与详尽，而是要看，根据其当前现状（IT资源与运行状况）与管理（范围与深度）的要求，是否去规划、识别、控制、监控、验证各配置项的版本以及相互之间的关系，从而确定基础架构或服务的逻辑模型。所以配置管理≠CMDB，而是围绕CMDB开展的一系列动作。

那么，建立、实施CMDB应该注意些什么？常用工具有哪些？

第一 不要急于求成

要认识到，“罗马不是一天建成的”，实施ITIL、建立“完善”的CMDB永远是一个需要永不停息的追求过程，要充分认识到其艰难性，要做好打持久战的准备。

第二 管理范围要合理、粒度要适度

粒度要适度，是指CI的定义不能过粗，也不宜过细，如何界定过粗、过细的原则和标准呢？说到底是要应该基于管理要求出发（当然管理要求如果越高，投入CMDB初期建设的精力与成本也一定会水涨船高），例如本人在做一家知名网络公司的评估时，发现其管理要求是要细化到硬盘部件级，那CI就一定要细化到部件级，而不能是系统级（整机级）。

第三 CMDB界面要友好

何为友好，就是要可视化、易检索；

第四 要可调和、可联邦

这个有点术语话了，简单解释一下，大家如果看过V3的书会发现V3用CMDB1、CMDB2….替代了V2的CMDB，这也是实际实施ITIL中的现实情况，这就要求不同的CMDB要有集成能力（向下调和），同时要有共享能力（向上联邦）

第五 可维护、可扩展、可更新

没有绝对“完善”的CMDB，但不完善的CMDB要能够通过不断扩展、更新、验证等步骤实现相对的逐步完善。

第六 注意安全保障

无论如何针对记录了完全核心内容的CMDB，一定要注意安全保障，如设定严格的权限访问控制等。

关于CMDB模型与工具，给大家推荐BMC 的 Atrium CMDB模型，是业界普遍认可的理想CMDB模型。

本文转自：智朴人生 – 畅享博客，原文地址： [原创]关于配置管理—建立、实施CMDB应该注意什么？

CMDB的价值点分为两类：硬收益和软收益。从硬收益的角度，CMDB的用户可能会让你来描述CMDB对他们的价值点。下面的几个轶事可以作为收集CMDB可能为你的企业带来价值点的几个方向：

• 把IT环境的可视化带到更高程度 –一领先的制热和冷却系统供应商指出，他们始终无法很好的理解一个计划外停机时间对用户所造成影响。例如，当只有25个用户受到了网络中断问题的影响，IT部门必须通知用户群中的全部100个用户。这会导致一个客户满意度低的反馈。CMDB使该公司能够理解配置项之间的关系，并确切地知道在任何确定时刻什么用户会受到影响。现在用户间可信的沟通能够来自于各个IT部门，并且使IT成为业务不可分割的一部分。
• 按业务目标来安排系统变更的优先度–大型设备制造商不得不关闭了其所有的系统，后来发现不知道哪些服务器应该先启动。CMDB使公司能区分关键业务元素的优先度，确保减少计划外的停机时间，无形中降低了收入损失的风险。
• 减少软件许可证的费用的同时确保用户和服务器能整体的满足许可证遵从性 — -的半导体制造商开展了一个审计，结果另他们感到震惊：该公司支持在为大量已经报废的服务器支付支持和维护费用。实际上，该公司关于报废资产的数量已经长期和实际不符了。CMDB有助于该公司发现这一问题，并重新分配预算资金，以更好地支持现有的基础设施。
• 为加快服务器整合提供更深层次的资产和关系信息 — 一大型的金融服务提供商注意到，在其行业的公司通常在一个较短的时间内，会进行几次成功并购和整合。对于如何整合所有的IT部门是一个重大挑战（有时是次要的），他们往往是停留在相互隔离的工作状态下。然而，使用CMDB的公司就能够有效地集成新的收购，从而节省资金和为公司内部建立统一的IT业务形象。

IT要实现CMDB的硬收益，一般通过降低以下对象的相关成本来实现：人、第三方服务、软件、硬件和设施。这些方面的价值点可以通过财务方面的分析报表来反映出来。

CMDB能够实现的价值还包括哪些很难衡量的方面，例如下面的例子解释了这些软价值：

• 服务台 — CMDB可以从提高事件和问题处理和解决效率和效果的方面来体现出硬利益的成效。还可以认为，CMDB使这种改善更可行，往往服务台技术员从尖锐的客户那里来收集信息是一项非常不快的工作，CMDB可能会提高支持人员支持客户的效率，提高客户满意度。另外，通过为服务团队提供更好的信息，你可能使用较低技术水平的工作人员来完成的相同水平的服务工作，降低在工资成本上的成本。
• 变更管理 — 通过CMDB这个流程得到了很大的提升，更完善的风险评估，提供更多的信息来评价类似类型CI在过去时间里的变更成功率，并能更好的理解变更CI与其上游和下游其他基础设施组件的依存关系。其结果可能是使企业用户对IT所提供给他们的服务感到更满意，但这是难以像硬效益一样的量化的。
• 连续性管理 — CMDB的变成了持续管理的记录源泉。拥有了能准确的、更新的描述IT环境状况的信息后，灾难恢复被大大地简化了，这提高了整个组织的信心。这是一个明确的好处，但也不是那么容易量化。
• 与业务的影响与和谐 — CMDB使CI依赖关系能被更深入的了解。这种理解大大简化了连接CI到依赖于IT基础设施的业务流程或者服务的过程。使IT与业务更紧密的和谐是至关重要的，例如提升响应速度和让业务具有更好的竞争优势，但对比硬利益它也可能是难以量化。

以上内容参考了BMC出版的<<step by step to build a cmdb>>;以上软效益对于不同的企业而言可能是不同的，总的来说前两条是显而易见的，你也可能有更好的关于硬效益和软效益的总结和期望。如果有的话一定需要在项目建设前，或者初期阶段中，与CMDB项目相关的利益人和用户做细致的价值点讨论和确认是非常关键的。更进一步价值点的确认也更进一步的指导了CMDB项目实施的方案。BMC Atrium CMDB通过其完备的功能，以及那些以CMDB为核心而建立的ITSM流程应用，能很好的为企业用户实现以上的相关效益。

本文转自：Martin Liu’s blog，原文地址：http://martinliu.cn/2010/01/01/cmdb-value-points/。

在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更新之间的关系如图2所示。

在图2中，CMDB数据的任何变更都应该对应已批准的变更请求单。同时，由变更管理流程将变更信息提供给负责配置管理的相关人员进行CMDB数据的更新。其中，CMDB数据的更新主要包括以下三种情况。

一是CMDB数据结构的变更。通常发生在因管理需要而重构CMDB模型的情况下，例如新增需进行变更控制而未识别的CI，因服务调整而重新梳理CI间的关系等；二是新增或删除CI。即指对已有CI的操作，例如更换或报废设备，新采购标准的配置等。从方便管理的角度出发，IT服务供应商往往会制定标准配置清单，用户应根据实际关系需求，确定配置清单颗粒细节的符合度；三是，修改CI的属性。此类变更是针对某CI具体属性的操作，例如增加了某服务器CI的硬盘容量，就需要对其相应属性进行调整。需要注意的是，CI属性的变更通常会关联到其他CI属性的调整。例如，硬盘CI信息变更时，管理员还需要调整服务器CI的属性，将无疑会增加数据维护的成本。针对这一问题，建议企业在确定CI属性数据时，尽可能地从其他可靠数据源中获取。例如，可以将服务器需要的硬盘容量属性数据通过数据继承关系，从硬盘CI本身的属性中获取。

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

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

4．配置管理的角色安排 在政策和流程确立之后，具体的执行还是需要人来推动。因此，就进入了配置管理角色设置的环节。配置管理活动所涉及的角色主要分为四类，他们各司其职，共同协助完成CMDB的运作任务。其中，配置管理流程责任人需要对整个流程执行的结果负责，并拥有一定的流程管理权力；配置经理主要担当流程开发和管理的角色，重点确保配置信息的准确性和可用性；配置管理员负责维护配置数据，保证提供给IT部门的CMDB信息总是准确的；配置审计员则主要负责通过审计操作确认配置数据。各个配置管理角色之间的关系如图3所示。

部署CMDB：丰俭由人

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

中国工商银行在ITSM领域的实践一直处于行业领先地位，并且项目执行到位。在CMDB构建的问题上，工商银行并没有购买CMDB商业软件，而是采取了自建的方法。在解释选择自建策略的原因是，工商银行信息科技部的技术负责人表示，市场上商业化CMDB工具还不够成熟。目前，大部分的CMDB软件可以自动发现基于服务器的软件应用，并构建映射关系图，但是对于一些主机应用或企业自行开发的应用却检测不到。对于应用种类繁多，同时存在大量自有和遗留应用的金融企业，商业化CMDB工具对整个IT环境的覆盖能力有限。

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

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

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

联邦性：CMDB成熟的印记

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

联邦性是软件供应商难于攻克的部分，同时也是近期技术进展最大的CMDB特性。从2006年开始，许多厂商将CMDB的联邦能力作为产品研发的重点，并相继推出了具有联邦特性的CMDB产品。IBM在2006年6月所发布的CCMDB（变更和配置管理数据库）便强化基于开放标准的对IT资产信息的自动发现和整合能力，能够满足客户对联邦属性的需求；Managed Objects所推出CMDB 360°解决方案能够从多个厂商数据库中捕获配置信息，并自动协调相关CI和消除重复的CI，在联邦性方面取得可喜突破；另外，HP、BMC、CA、Symantec等公司都陆续推出联邦式CMDB。而围绕对Peregrine和美科利的收购，HP对三个品牌CMDB的整合工作也于今年宣告完成。

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

推进方式：由点及面

CMDB的实施自然是“条条大路通罗马”，但在现阶段，从小处入手精心设计，逐步扩大CMDB的覆盖范围还是技术专家和企业客户所青睐的项目推进方式。传统的构建方法是自下而上地推进，也就是先做一个大的CMDB，在逐步精炼CI。但这种方式的缺点是投入巨大且浪费时间，很多企业耗时数年才能完成CMDB的部署，而后期的测试和上线同样涉及面广，费时费力；已经拥有简单配置数据库的用户往往会选择自中而上的推进方式，以现有数据库为基础，添加必要的CI和CI之间的关系后，用户可以用比较短的时间就组建一个功能相对丰富的CMDB。

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

一些用户还会先期设计一个小型的试验项目，它会包含CMDB所必须的审计、控制、自动化等环节。启动这种试验项目可以帮助企业收获一些关键的CMDB部署体验，例如对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软件供应商的共同选择。

本文转自：cnw.com.cn，原文地址：CMDB配置管理数据库构建过程拆解

配置管理是ITSM实施的第一步，也是最重要的一步，它是其他流程实施的基础，并且也是整个流程的最重要的架构。配置管理实施成功。

在这篇博客，先描述一下配置管理的效益以及规划中需要注意的地方，案例将会在日后说明。

效益：

1.提供正确的信息和相关的文档。这些信息将支持所有的IT服务流程，例如：发布管理，变更管理，事故管理，问题管理，能力管理和可持续性管理等。

2.方便查询相关资料。例如：某天一台笔记本电脑被盗了，那么，通过配置管理流程可以马上找到相关资料，如电脑型号，配置信息，软件列表，购买日期，责任人，配合财务系统还可以很快找到这台电脑的残值和剩余报废年限等，为下一步的恢复工作提供重要的支持。

3.为高效率支持用户提供保障。如用户打电话进服务台，前线IT人员马上可以查询配置管理，查出用户相关电脑信息，用户信息，账户信息和受限权限分配情况，相关网络状态以及其他可能发生问题的列表等，配合话务台系统，可以限制非授权人员拨入，节省时间，提高效率。

4.配置管理可以提供全面的配置列表。这容易量化各IT设备以及设备部件的维修费用以及版权费用等一系列费用，还可以根据列表查询各套软件版权的续约日期，设备部件更换费用等。可以帮助IT经理以及财务主管安排财务计划。

5.透过IT管理，使IT投资透明化，可以让用户明白数据保护以及恢复所需要的费用，触发数据保护，版权管理等的投资。

6.指导可持续性管理计划。CMDB为日常的IT服务以及灾难过程中的IT服务恢复提供数据支持。

7.支持和提高发布管理质量和效率。通过记录各套软件系统的版本信息，清晰分析出各套软件版本和注意事项。从而支持整个发布管理流程，包括发布过程的开始到发布完成。

8.通过软硬件的版本控制，提高企业内系统的安全性。减少故障，病毒等不安全因素的影响对整个IT系统的影响。

9.可以有效减少未授权软件的使用。未授权软件以及非标准软件的使用不但降低兼容性并增加支持成本并且容易引起法律诉讼，影响企业形象。

10.根据CMDB进行风险分析，高效并安全实施变更安计划，降低因变更而引起得系统环境变化，从而降低实施风险。

11.为问题管理提供趋势分析。例如：对问题管理进行归类，分析，可以对各类问题进行趋势分析，可以作为考虑因素有针对性安排日后的支持计划，以及提供主动性支持服务

可能存在的问题

1.CMDB定义错误使得IT支持人员无法使用，或者配置信息过于详细，IT支持人员不得不花费过量的时间和精力完成不必要的整理工作的无用工作。

2.数据结构没有经过分析和设计，最终结果是，使用的CMDB并不符合企业的需要，没有办法降低企业的运营费用。

3.要实施CMDB一定要有毅力，否则将会是实施ITSM的一个瓶颈。实施过程中一定会遇到很多意料不到的困难，如果过程中不控制实施时间，不明确实施中各IT人员的义务，不能并按时根据实施时间表完成各自的任务，那么CMDB将不可能完成。

4.当变更管理和发布管理开始上线，IT人员应适应新的支持流程，降低旧的流程的影响，避免双重控制点或者控制点过多，影响ITSM的实施效果

5.IT经理与IT成员之间缺少默契，这会难于将ITSM的概念以及流程介绍给这部分IT成员，与此同时，比较差的变更管理和配置管理会误导IT经理的需要和控制要点

6.如果流程感觉太苛刻和过于官僚，个人和组织经常会用这位借口不执行相关流程

7.一些员工将尝试孤立配置管理从而提高反应速度或者有恶意企图。尝试将有可能战胜问题管理，并且可以让IT成员明白配置管理的价值。

8.流程效率过低或者由错误倾向，这会经常引起手工流程的再次发生。通常这些case都可以通过办公自动化解决。

9.不能指望有一个工具可以完成CMDB所有的一切。IT成员以及IT经理期望一个配置管理工具去提供一个整体的解决方法，最终将失败责任推卸给这套工具或者软件的不足。这种行为是不恰当的。

10.选择的工具一定要有一定的弹性。发生问题时需要进行变更时，CMDB可能不能支持所需要的变更。

11. 配置管理可能被独立施行，如果配置管理被独立实施，缺乏与变更管理或者发布管理进行互动，终将使得配置管理效率低下或者无法实施后无法获得相应的价值。

12.配置管理并非项目管理的灵丹妙药，不要指望配置管理可以保证项目可以顺令实施或者项目测试成功。同时，项目管理所需的测试环境，测试结果亦不应记录到配置管理，以免增加相关人员的工作量以及影响CMDB的数据质量。

13.对配置管理增加适当的监控点。例如，监控CMDB中用户安装的软件数量，版本等，以免CMDB与实际使用产生过多的误差，影响CMDB所能带给企业的价值

实施ITSM是一件很漫长的工作，虽然它的效益显著，但实施不当，或者规划出错，那么将直接影响到ITSM的实施效果，更有可能会被中途夭折，所以，实施过程一定要慎重。

注：本文转自思瑶雅居@CSDN博客，原文地址：ITSM的第一步:配置管理

注：本文转自TechTarget中国,原文地址，http://www.searchdatacenter.com.cn/guide/datacentercmdb.htm?info=datacentertechguide20091229。版权归TechTarget中国所有。

IT行业标准组织分布式管理任务组（DMTF）在2009年7月21日创建了配置管理数据库联盟（CMDBf）工作组规范，CMDBf规范可以帮助企业更轻松地集成多源CMDB数据，使CMDB工具集和厂商拥有更多特性。对于数据中心而言，CMDB显得更为重要。通过CMDB的使用，数据中心管理人员可以对数据中心基础设施进行备案。在有设备发生故障时，也可以通过CMDB对其进行准确而又及时的定位，从而提高运营效率。但是，CMDB的实施并不是一件容易的事。本技术手册就带领大家去认识CMDM的概念和意义，以及如何利用CMDB来对数据中心进行配置和变更管理。

CMDB概念

每个企业和公司都需要一个配置管理数据库（CMDB）。当前架构配置的精确记录对每步IT操作和过程来说都是至关重要的。如今，故障排查速度越来越快了、资源分配的分析也比以前容易了、基础设施的更改给服务带来的影响也越来越小。

CMDB联盟工作组规范加速配置管理系统集成  [本站页面]

如何判断企业需要CMDB项目决策？  [本站页面]

CMDB的意义和应用领域

如今，所有IT机构都在尽力降低自己的运营成本，试图实现绿色运营。在追求绿色运营目标的过程中，他们会采取数据中心整合、降低能耗、部署虚拟化或云计算等等策略。通常，IT都会一窝蜂似地去购买解决方案，迫不及待地点击“安装”，殊不知等待他们的却是另一次危机。

数据中心绿化 配置管理至关重要  [本站页面]

将IT变更管理作为灾难恢复的一部分  [本站页面]

如何实施CMDB

对于专家来说，确保一个管理数据库（CMDB）的成功配置意味着要经历一个缓慢而渐进的过程，并确保在IT部门中的每个人都能够在项目的成果中受益。IT配置始终处于变化之中，管理人员们需要一种方法来在任何指定的时间跟踪每一个IT资产的当前状态，以及它与其他资产之间的关系。

决定一个新CMDB项目成功与否的五大要素  [本站页面]

Puppet配置管理工具概念及其工作原理  [本站页面]

ITSM基础：执行变更管理过程  [本站页面]

注：本文转自TechTarget中国,原文地址，http://www.searchdatacenter.com.cn/showcontent_22585.htm。版权归TechTarget中国所有。

Puppet是一种开源的IT自动化工具，利用它IT组织可以对配置服务进行编码，从而形成一种管理规则，随后系统框架会对其进行审查并强制实施。

起初，系统管理人员可能会认为这种新型的配置管理工具完全没有必要。因为他可以用机器镜像文件和shell脚本来实现这一切。这就像是一个只听说过伐木机的伐木工人不明白为什么之前每个人都要带好几把斧子一样。

Puppet于2005年首次对外发布，自那以后便一发不可收拾。如今Google、Twitter、Sun、Sony、Red Hat、NewYork Stock Exchange（纽约证券交易所）、Digg、SlideShare、Shopzilla、哈佛大学和斯坦福大学都在使用Puppet管理自己的系统，他们从企业的IT业务到Web 2.0服务器的启动都使用该工具来完成。这些组织已经意识到SSH协议并不是一个可靠的解决方案。

Puppet配置管理工具的工作原理

Puppet由语言层、客户服务器进程及资源提取等多个层面组成。

语言层允许管理人员通过提取用户、群组、程序包、文件、cron、负载及服务等资源对服务器配置进行描述，并对其中一些资源进行命名。

此外，管理人员还可以指定各种资源间的关系。例如，服务类型要取决于配置文件类型、而配置文件又取决于所安装的程序包。利用这些关系Puppet可以在独立服务配置发生变更时对其进行重启。

资源还可以被整合到逻辑集合中。这里还可以使用之前提到的那个例子，将程序包、配置文件和服务集合到一起。然后就可以对该资源组重新进行利用，在其它Puppet规则下也可以将其视为是一个单一的逻辑实体。客户服务器层面提供了一种安全机制，使用户可以利用HTTP SSL编码将具体的配置从中央主机转移到单独的主机，与网银和电子商务安全SSL一样。每台主机只接收并利用其特定的配置编码。

通过对配置当前状态进行审核、与业务需求进行对比并对资源进行合理分配，用户可以对配置进行审核和利用。所应用的配置将在相应的服务器上安装操作系统。通过更新核心规则，我们可以实现对配置的更新和补丁的应用。制定规则内的系统审核和同步周期将被用来在整个生命周期内对系统进行管理。
利用审查和同步周期可以确保整个网络的连贯性。如果使用传统的技术和工具，两台机器提供同样配置服务的概率就已经很低了。随着服务器数量的增长，由于配置转移而导致的网络不连贯会引发许多问题。

架构即编码

虚拟化技术对于现代数据中心的影响是不可否认的。接下来便是APIs所导致的存储、网络及计算资源的转移。尽管说虚拟化允许大量的服务隔离和硬件利用，但每台虚拟机所需的配置是和物理机一样的。利用10台或10台以上运行在同一硬件或同一虚拟机集群里的虚拟机来提供Web服务，IT组织就可以降低在硬件方面的开支，但是，需要管理的配置数量也会越来越多。

基于镜像文件的配置管理似乎可以解决这个问题。但问题是基于镜像文件的方法起初效果就不明显，而经过几个月的镜像文件管理，有人意识到他只是在用无计划的机器镜像文件收集来取代配置转移，几乎根本没有了解二者的真实含义。

通过Puppet这样的配置管理工具，API的概念被拓展到了整个系统的配置。加密服务不仅可以提供一个系统搭建与维护的安全机制，这些密码还可以提供大约500M的服务器镜像文件。这些密码不仅可以洞察到系统中有哪些配置设备，还可以找到配置这些设备的真实意图。现在你应该明白我们在管理现有系统和设计新服务时为什么要提高决策的质量了。

进程即技术

对于大多数组织而言，业务和配置变更是导致资源浪费的最主要原因。大多数IT部门都会采用大量的变更管理进程来进行自我保护，但是企业的确需要业务变更，因为这可以推动企业的发展。对于系统变更的业务需求和IT组织对于延缓变更速度的尝试经常会使业务需求与自己IT部门的供给无法保持一致。

使用Puppet，架构即是代码，这意味着他们必须引入软件研发工具系统和进程。在软件研发过程中，对于其版本的控制和管理是不可避免的，这在系统管理中也是一项非常重要的工作。版本控制使软件研发业务更为透明，为其它软件的研发打下基础。

从版本控制开始，编码架构允许企业使用类似的服务器配置进行持续的软件整合及研发、测试和部署。特别是在使用虚拟化技术时，Puppet可以大大缩短系统变更的反馈时间。服务变更、新版本试用及新数据库的负载测试所有这些都可以被列入研发进程之中。当业务变更准备就绪之后，只要把新的代买合并到相应的规则中，就可以在产品服务器上对其进行实施。

一旦Web服务器、应用服务器及数据库服务器配置被Puppet所控制，就没必要再加入一台新的服务器了。此时需要做的是预先设定分类规则。你是否需要为Web服务器安装补丁？只需改变对核心Web服务器的编码即可，其它的Puppet会帮你完成。你是否需要配置一台新的Web服务器并添加一台负载平衡器？Puppet可以帮你解决，并不需要增加服务器的容量，你之需要使用配置有相应规则的Puppet软件即可。

这些提供变更管理进程的方法可以迅速提高系统的灵活性，与传统的慢速进程技术相比，风险也要更小。用Puppet来取代Shell脚本，你会更喜欢业务的变更，而不是绞尽脑汁使其放慢速度。

Puppet是一款开源软件，由Reductive Labs研发并提供支持，他们的目标是推动系统变更管理软件的演变。Puppet目前可以在大多数Unix或Linux版本上运行，包括Red Hat（Fedora）、CentOS、Ubuntu、Debian、SUSE、Solaris、OSX、FreeBSD、HP-UX及AIX上运行。Puppet wiki上有关于Puppet语言和具体执行方法的信息。在IRC网站上，还有一个相关的用户社区，你可以通过邮件列表进入该社区。

点击免费下载Puppet开源配置管理软件。

英文原文地址：http://searchdatacenter.techtarget.com/tip/0,289483,sid80_gci1361905,00.html

注：本文转自TechTarget中国,原文地址，http://www.searchdatacenter.com.cn/showcontent_23517.htm。版权归TechTarget中国所有。

对于专家来说，确保一个管理数据库（CMDB）的成功配置意味着要经历一个缓慢而渐进的过程，并确保在IT部门中的每个人都能够在项目的成果中受益。

CMDB的实施项目正处于一个上升阶段，这要归功于技术对于IT系统经理们的承诺，使得他们能够更为有效地应对现今数据中心极为快速的变化。

IT配置始终处于变化之中，管理人员们需要一种方法来在任何指定的时间跟踪每一个IT资产的当前状态，以及它与其他资产之间的关系。拥有了这些可靠的状态信息，就使得工作人员能够更好地根据对已有情况的了解做出决定，例如采购、维修、保密和升级。

“一个CMDB是一个包含详细目录信息的中央数据库，这些信息通常描述了IT设备间的关系，但我们不称其为‘详细目录信息’，我们称之为配置项或CI，”位于Stamford，Conn.的Gartner研究公司的分析师Patricia Adams说。我们将[CI]与问题和影响范围记录相连，并提供服务意见，如果用户需要做变更影响分析，他们可以确定有利和不利的因素。
“CMDB与IT基础设施库（ITIL）关系紧密，是一套包括了许多与CMDB相配合的不同组成部分的标准，”位于Boston，Mass.Yankee集团的副总裁、软件系统分析员Arindam Banerjee说。

“ITIL的不同组成部分包括了若干标准，诸如配置管理、事故管理和变更管理，” Banerjee说。

虽然在媒体中有着许多关于目前CMDB的说法，但是分析人士称实际的使用只处于刚刚开始阶段。公司考虑一个CMDB实施项目必须在整个规划和执行阶段谨记以下五条专家意见。

1. 处理组织问题

如今，大多数公司的IT部门分为若干个部分，Adams说，其中包括了网络、数据库和应用部分。这对于CMDB项目并不不是一个好的预兆，这些CMDB项目在定义上触及了IT行业的每一个方面。

“你需要让每个人理解他们是在一起工作，而不是保持这种分散方式，”Adams说。

但是打破筒仓是需要一个过程的，这个过程并不是意味着单单在会议室里进行一两次午餐时间的工作人员会议。

“现在的问题在于，人们长期以来一直都是在以他们特殊的方式从事工作，他们并不希望有人来告诉他们说，他们将必须改变他们思考的方式或者改变他们工作的方式，”Adams解释道。“你必须确认每个成员都能够意识到这一倡议的成功之处。”

那些未能解决组织问题的公司在最好的情况下也极有可能将一个CMDB项目搞砸，Banerjee补充道。“对于一个CMDB项目来说，最大的成功因素就是组织调整，”他说。“如果没有了好的组织调整，也许你也就不能拥有一个CMDB。”

2.实施强有力的变更和配置管理政策

如果CMDB工作在恶劣的信息环境下，那么这样的CMDB就是无用的——这就是为什么说确保所有的IT配置变更都记录在案并输入系统很重要。

Adams说市场上的软件工具已经相对饱和，这些软件工具能够协助配置管理和控制政策的所有形式。一些现有的工具包括了通用配置工具，个人电脑和服务器配置工具，虚拟化配置工具和网络配置工具。

BMC、HP、CA、IBM和众多小型公司都提供了变更管理工具。

3. 执行全面详尽的发掘过程

在处理了组织和变更管理的问题之后，下一步的工作就是准确地识别所有CMDB的数据来源，并双重保险地确保这些数据来源都是值得信赖和可靠的。那么就到了发掘的时机了。

“如果我不能相信这些数据，那么这些数据不仅是无用的，而且是危险的，因为您所做出的决策都是基于这些数据的，”位于Cambridge，Mass.Forrester研究公司的高级分析师Glenn O’Donnell说。“这里发掘过程起作用是因为发掘过程能够发现你身边世界的真相。它发现了所有服务器、所有的网络、所有应用以及你所终止的都是真实存在的。”

确保你能够相信这些数据，就意味着证实那产生数据的过程就是实际工作的过程，Adams说。公司也需要确保数据的标准化和一致性。
“通常你会有一套将数据输入CMDB的发掘工具，”Adams说，“因此你需要确保那些数据源是值得信赖的数据源。”

4. 采取渐进的方法

下一步的工作就是识别和指导CMDB项目，将其重点配置在不多于两个或三个企业服务。不要试图立即参与所有的业务。一旦那两个或三个企业服务能够成功地实施，然后挑选另外两三个或更多并重复上述过程。

“将任务分解成较小的、便于管理的任务块，而不是试图煮沸整个海洋并让每个人都感到满意，”Adams说。

在这一阶段，公司需要开始持谨慎态度，以避免Adams称之为“范围蠕动”的状况发生，“范围蠕动”是指CMDB项目在范围内从原来的一小块关注领域快速增长的一种趋势。由于在项目中有如此众多的股东，这就相对很容易让情况失去控制。公司需要对他们的方法详细筹划并严格遵守执行，并确保所有股东的需求都已随着时间的推移进入了实施日程安排表。

5.始终保持向前看

在实施CMDB以及所有相关IT项目的过程中，对于项目经理来说，不断地询问自己公司在IT所有方面所采取的方法是否能够支持未来的增长需求是非常重要的。

位于Los Angeles的军火机械制造商Equipois的CEO，Eric Golden表示他的IT部门正在着手建立自己的CMDB。

“从我们公司在两年半前成立开始，我们就一直处于变革之中，对于我们来说，变更管理的最大的一部分就是将每一个系统置于准确的位置并着眼于未来。那就包括了系统、政策、过程以及一切，”Golden说。“这是一个艰难的任务，因为你总是会有短期需求，会有你必须让其满意的客户和时间压力。但是你必须确保所有的事情都正常以便于为你服务并使你的事业步入正轨。

作者：Mark Brunelli 译者：滕晓龙

英文原文地址：http://searchdatacenter.techtarget.com/tip/0,289483,sid80_gci1364296,00.html