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

车辆历史信息供应商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/。

已经知道的问题有哪些？

请阅读 已知问题 V2.0。（本站翻译中文版本：OneCMDB已知问题 V2.0）

OneCMDB是什么？

OneCMDB是一个配置管理数据库引擎。它用于创建和维护ITIL (IT Infrastructure Library)最佳实践中定义的配置管理数据库（CMDB）。OneCMDB是根据一个包含像配置项（CI）、属性、引用这类对象的面向对象数据模型而设计的。OneCMDB包含一个CMDB引擎（OneCMDB Core）和一个用户及设计者界面（OneCMDB Desktop），这个界面可以用于创建和维护CMDB数据模型，也可以浏览CMDB数据。

OneCMDB Core是什么？

OneCMDB Core是一个CMDB引擎，它包含维护和管理用于创建CMDB的面向对象数据模型（CI、属性、引用等）的业务逻辑 。OneCMDB Core是一个独立的服务，用来处理前端应用程序或者服务管理应用程序（例如：服务台、配置管理等）的请求。

OneCMDB Desktop是什么？

OneCMDB Desktop是一个使用OneCMDB Core的Web应用程序，它允许用户浏览和修改CMDB。它让CMDB设计者不需要编码就可以创建和维护CMDB，不需要懂得SQL，不需要懂得C/C++或Java，所有工作都可以通过点击完成。

OneCMDB 为什么开放源代码？

OneCMDB起初由Lokomo Systems作为Lokomo公司的 Servicenter 服务管理解决方案一部分开发的。Lokomo Servicenter 提供了许多支持ITIL流程的功能，CMDB引擎仅仅是其中的一个组件。Lokomo公司的CMDB引擎被证明是轻量级的、简单的但也是强大的、灵活的。2007年Lokomo决定将这个CMDB引擎开放源代码，并命名为OneCMDB。

原文见：http://www.onecmdb.org/wiki/index.php?title=FAQ，由OneCMDB中文站翻译，完成于2009年12月31日。

概述

一个独特的CMDB

使用OneCMDB不需要任何数据库模型相关知识。

OneCMDB从配置项（CI）如何储存中提炼出CMDB设计器，这个设计器让我们更关注配置项的组织和他们的属性和关系，而不是SQL查询和类似的C/C++/Java代码。配置项、属性、关系等等都可以在一个图形用户界面中管理。模板的使用和近似面向对象过程使得设计和维护CMDB更容易。最后，CMDB的结构在投入使用后以后也能够很容易扩展和修改。

OneCMDB由一个后端服务（OneCMDB Core）和一个基于Web的用户界面（OneCMDB Desktop）组成。用户界面允许用户查看、修改、浏览CMDB，也允许设计者管理CMDB的数据模型。

OneCMDB有开放的API，则使得他很容易被其他应用（向服务台、变更管理）程序使用。作为开发者，OneCMDB让你专心于应用程序开发，而不是考虑数据库接口和SQL语句。

为什么选择 OneCMDB？

开放源代码

• OneCMDB是免费下载并包含源代码，你可以在这个版权协议范围内 使用、修改和重新分发OneCMDB

容易且完全可配置

• OneCMDB允许你创建和使用最适合你的CMDB模型。OneCMDB也有一些现成的数据模型，并且都可以改动。

简单而不复杂

• OneCMDB能让ITIL开发者更快速、更容易开始工作。OneCMDB新引进一个近似面向对象特性到配置管理中，开发者不需要写一行代码就可以创建一个CMDB模型。OneCMDB将开发者从 底层存储配置项关系数据库中解放出来，而不需要任何一个SQL语句。

可选择的数据库

• OneCMDB能够使用不同类型的关系数据库。

最佳技术方案

• OneCMDB使用像Spring、Hibernate这样成熟框架用Java语言完成开发。

原文见：http://www.onecmdb.org/wiki/index.php?title=Features，本文为OneCMDB中文站翻译，完成于2009-12-30。

在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配置管理数据库构建过程拆解

注：本文转自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_23581.htm。版权归TechTarget中国所有。

当IT组织努力提高效率和效果之时，他们必需在提高商业IT服务质量的同时减少无计划的反馈性工作。来自管理方面的压力如此之大，IT前辈面对这种局面也很无奈，关于管理有无数的陈词滥调，听起来不错，但投资收益却毫无改善。而变更管理却是一个能真正起作用的关键IT服务管理（ITSM）过程。

有一点很清楚，变更管理并不是一个能解决所有问题的神奇药剂。然而它在提高可用性、安全性和灵活性的同时的确可以大大减少无计划的工作，这样能使更多的员工从事有计划的项目。有可靠的证据证实，这绝不是一个仅仅听起来不错而不能被实现的的陈词滥调。

• 人为误差在设计、编码和操作中蔓延。任何对系统的变更都会造成某种程度的风险，并将产生一个消极的结果。
• 据IDC的最新研究表明，近80%的网络可用性事故来源于人为误差。一些组织甚至超过了这个数字。不管怎样，当事件发生时，项目被搁置、资源被调换，直到危机得以缓解。这会导致项目积压和管理失败。
• 所有的事情都是一样的，一个系统事故很可能起源于一个变化。是的，环境问题和硬件故障可能是一种原因，但是其概率要低一些。人们往往将百分之八十的维修时间花在试图寻找究竟发生了什么变化。如果能够尽快解决，你数据中心的可用性会变得更高，IT职员将会有更多的时间去关注计划性工作。
• 尽管证据表明变更管理和规范的流程是有效的，但在IT行业里有一个很普遍的“牛仔”心态，即员工不喜欢被告知他们必须遵循一个过程。要执行变更管理，或关于它的任何过程，必须有意识地去改变这种文化。

执行变更管理需要考虑的内容

在这里我就不重复《ITIL服务转变》中提到的有关变更管理的内容了，我想回顾一下我们真正遇到的一些问题，并对那些在设计和执行变更操作过程中经常出现的问题进行解释。

• 促进文化变革。文化变革的需求并没有得到太多的重视。事实上，正种心态往往也导致了失败。在一个进程的设计和执行期间，要注意寻找合适的人选。对其进行培训，提供交流和预警机制。要及时对工作描述和补偿计划进行更新，使其适合整个进程。最后但同样重要的是，IT管理、ITSM管理和变更管理过程中用户和经理必须努力学习，不断增强对变更管理的需求。
• 为什么要有一位变更经理？必须有一个人来为平衡风险或规避风险负责。这个人必须具有大局观，确保在局部层面看起来不错但更高层面可能出问题的变更不被执行。例如，某个网络管理人员可能认为升级一台交换机是低风险的，因为他没有意识到这个改变发生在周末的账户统计期间，这也就暗藏了一份风险。
• 要有重点！最好是设计一个过程并在一个特定的IT层面执行，在这一层面业务和IT部门都愿意以该过程为原型并对它进行调试。在一个小范围内变更一个过程比追求一个全有或全无的方法更容易且政治风险更小。
• 从点滴做起。随着复杂性的增加，文化转换的难度和长期持续的变更管理风险也增加了。此时，需要对持续过程改进进行规划，同时要制定发展蓝图以确定过程将随着新版本进行演变。但是，一定要确保从简单做起逐步改进。有时侯变更管理的开始可能是最艰难的。
• 多模式。ITIL的变更管理过程可识别多模式的用途：标准的、紧急的、次要的、正规的和主要的。这些仅仅是适当平衡风险、成本和时间的工作流程。事实上，一个组织可以有多种模式，只要这些模式有实际意义且它们清楚何时遵循何种模式。实施变更管理的组织要适应他们的各种模式，从而具备适当的灵活性和风险管理能力。
• 标准的变更模式是至关重要的。谈到模式，标准的模式使低风险、可预测的变更得以被记录和实施。这些变更不需要提交变更顾问委员会（CAB），这样IT部门就有了更高的灵活性。它们仍然需要仅在授权变更窗口被执行，同时必须被记录以便人们能轻易地回答这个问题“有什么改变吗？” 随着时间的推移，符合必要标准的变更应该经过正式审核并遵循这个模式。组织中的大多数变更应该遵循这个模式。备注：如果变更因为任何原因出现明显的问题，那么必须有一种方式来正式撤销变更的标准等级。
• 注意紧急变更。对组织而言，紧急变更所承担的风险是最大的。特别注意不要让IT人员认为紧急变更是一个为了弥补计划缺乏而对生产做匆促变更的好方法。紧急变更应该是一个为紧急事件，随后会被CAB、相关副主席或CIO所检测和调查，从而确定为什么企业会陷入危险当中。
• 判定变更失败的标准。许多人经常争论是什么导致了一次失败的变更，他们经常将个人、团队行为目标和报酬联系在一起。如果发生偶然事件或变更无法按计划完成，就将一个变更应被视为失败。注意这两个因素——如果一个IT服务产生负面的影响,这种变更是失败的。当变更发生，但不能严格地按计划去执行，它被标记为一个失败的变更，同时会执行相反的计划。失败一定不能被糖衣所包裹。变更的能力必须随着时间的流逝不断提高。如果变更结果是不可预知的，就说明有些事情是常错误的，必须立即改正。
• 变更探测。自动化工具可以帮助检测并与一项配置中核准配置的变更进行通信。利用这些工具，一个团体可以从字面上保证系统未被以任何方式修改，且变更管理过程正在被跟踪。这是非常重要的，因为业务运营和信息安全需要及时了解是否有变更发生。
• 责任。IT人员必须遵循变更管理过程，如果他们没有遵循，则必须有明确的处理办法。质量专家W. Edwards Deming说在一个过程中你只能做两件事——或者遵循它或者正式变更它，没有其他的选项。并且人们不能自发地偏离过程，管理上对过程的确认是很有必要的，这可以降低风险。

变更管理对IT行业而言是一个关键的控制过程。它绝不是一个用于满足监管机构官僚控制的程序，事实证明对所有组织而言它都是有好处的，包括提高可用性、降低成本、服从管理、减少安全漏洞等。

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

注：本文转自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