Category Archives: CMS/CMDB
[ZT]ITIL V3 服务转换篇 之 资产和配置管理
为了定义和控制服务和基础设施组件。维持当前计划中、历史的服务和基础设施状况配置信息的准确性 一、先介绍几个基本概念 1、配置项（CI） 配置项是正在或将要在配置管理控制下的资产、服务组件或其他。配置项在复杂性、大小、种类有很大不同，从整个服务或系统包括硬件、软件、文档、支持人员到单独软件模块或硬件组件。配置项可以集中或分组管理。配置项可以选择使用既定的选择标准、分组、分类和识别方式在整个生命周期中管理和追溯。其包括： A) 服务CI项：服务能力资产、服务资源资产、服务模式、服务包、发布包、验收标准等 B) 组织CI项 C) 内部CI项 D) 外部CI项：包括外部客户需求和协议、供应商发布、分包商及对外服务。 E) 接口CI项：端到端的服务，跨越服务提供者的接口 2、配置管理系统（CMS） 为了管理大型复杂的IT服务和基础设施，资产和配置管理需要使用配置管理系统CMS。在指定范围内CMS掌握着所有配置项信息。CMS为所有服务组件与相关事故、问题、已知错误、变更发布、文档、公司数据、供应商、客户信息做关联。 在数据层面CMS能使数据库存在多个物理CMDB中而后共同组成一个联合的CMDB。其他数据来源也可以加入CMS中。 3、配置管理数据库(CMDB) 所有配置项的信息都包括在配置管理数据库(CMDB)中。配置管理数据库(CMDB)对所有IT 组件、组件的不同版本和状态以及组件之间的相互关系进行跟踪。在其最基本的形式下，配置管理数据库(CMDB)可能仅由一些纸质表格或一套电子表格 (Spreadsheets)组成。 4、最终介质库(DML) DML是用来存储和保护所有已授权的被确认版本介质配置项。 他们存储经过质检的主拷贝版本。这个库可以有一个或多个软件库或存放区来存放开发、测试和实时存储文件。他们包含组织所有软件的主拷贝、购买软件的副本及 受控文件的电子版。DML包含物理的拷贝存储，DML是发布管理的基础。 二、配置管理的目的： 1. 确定、控制、记录、报告、审计、验证服务资产和配置项包括版本、基线、组成成分、属性和相关关系。 2.通过服务生命周期管理保护资产完整、配置项等账户。确保只有已授权的组件被使用和已授权变更被执行。 3.通过服务生命周期保护服务资产、配置项的完整性。为了建立和维持一个准确和完整的配置管理系统，确保资产和控制服务、IT基础设施的配置需求的完整性。 三、资产、配置管理的活动 1、规划 2、识别 配置项识别过程： A) 定义和制定标准文件来选择配置项和他们的组件构成 B) 依据标准选择配置项及其组件并记录他们 C) 给配置项分配唯一的标识符 D) 指定每个配置项相关属性 E) 确认每个配置项是受配置项管理来管理 F) 确定每个配置项的责任人 3、控制 必须有效控制信息以维持配置管理数据库(CMDB)的及时更新。一旦某项活动改变了配置项已记录的特征或配置项之间的关系，则必须在配置管理数据库 (CMDB)中记录该项变动。需注意的是：只有变更管理才有权批准对配置项的特征进行变动，事件管理只能改变某个现有的配置项的状态来反映现实状况。 配置管理负责控制组织接收到的所有IT 组件并需确保这些组件被记录在系统中。硬件可在其已订购或已交付时进行记录，而软件则通常在其被纳入DML时进行记录。 4、记录 组件的生命周期可被划分成多个阶段，每个阶段都可以分配一个状态代码，但具体分成几个阶段则取决于公希望记录IT 基础设施的哪些特征。保持对每次状态变化日期的记录可以提供关于一个产品的生命周期的有用信息，如订购时间、安装时间以及所需的维护和支持。组件的状态决 定了可以对其进行操作的余地。 5、审核和报告
规划CMDB数据填充-003
From 《Step by step to build a CMDB》步骤17-规划CMDB数据填充 本文描述填充过程的任务3到任务4： 任务3 映射CI和数据源 现在拿出您的CI清单，并把每一类CI与具有相关信息的数据源映射起来。一个简单的电子数据表格，像图17.2一样的就足够了。有更复杂数据需求的大一点的企业可能需要多个数据页或者通过CI分类来连接到不同的数据页。 这项工作的最终目标不仅是识别用以填充CMDB数据源，而且还识别了流程和平台的接触点，有些平台对数据填充是有影响的。这项工作也是至关重要，用来定义数据调和规则，定义数据优先度，这些会在下面的步骤，任务7“建立调和规则”中用的。 工具映射如下图17.2所示，包括了每一个CI类，相关的属性，相关的关系数据，和数据源。 图17.2 Ci和数据源之间的对照关系图样例 您可能会发现一些s数据源之间的重叠，特别是CI库存清单的属性数据。这些数据通常包括唯一物理特性和CI的地点的说明 ，例如：型号、序列号、地点和所有者。此信息可能被存储在其他多个地方，它们也可用于CI数据填充的来源和日常维护的来源。 多种的资产和库存清单数据来源可能包括如下： 审计（资产清单或者配置发现数据库；无代理和有代理方式） 资产管理系统 采购系统和许可证管理 财会系统（采购或者收货） 合同管理系统 变更管理系统 其他财务应用和系统 任务4 访问数据源环境 为了确保数据质量，你应该访问所有的数据源环境，而不仅仅只是CMDB，还包括连接工具和相关技术，要逐一访问查看每一个数据源。在这里，“进来的是垃圾，出去的就是垃圾”这个俗语是适用的。CMDB项目的成功可能依赖于对系统或者基础架构的更新，以适应网络流量和数据量，还依赖于确保每一个数据源的数据质量。 当你规划CMDB数据填充的时候，要自问这样几个问题，是有关外部映射数据源质量的： 现在那些信息在那里、怎样被存储的？ –数据库、电子表格、Word文档？ 当前环境中有没有审计（发现）工具、软件分发、配置管理或者采购系统，用来自动的跟踪和存储这些信息？ 或者数据时被手工地收集和更新的？ 这些系统是基于开放标准还是私有技术的？ 这些系统的厂商有没有标准化的工具？或者CMDB厂商？ 需要被继承的数据源的物理位置在那里？ 在CMDB和数据源之间，通讯的方式是双向的还是单向的？ 还要考虑有关映射数据源性能相关的问题： 就当前的数据源来说，现实的性能、容量和可靠性是怎样的？ 系统上当前的活动状况怎样？ 活动用户数 其他并发继承此数据源的工具 备份、病毒扫描、报表或者数据挖掘的日程 审计工具（配置发现或者库存清单）扫描或者排队日程 其他任何将影响性能的事情 硬件和当前环境是不是能完全满足今后数据迁移所需要的附加工作量和空间需求？以及满足对于以后的日常数据同步？有没有对今后几年里增长率有做过计算？ 是不是需要考虑要满足什么约束或者特殊权限？ 厂商是否在与他们数据库集成方面有建议的最佳实践？（使用热备的生产机来降低作业压力） CMDB周边的数据集和连接技术是什么？ 网络环境中物理的限制（带宽、距离等）是否会有影响？ 当前的版本是多少？在以后的六个月或者一年里是否有升级的计划？有哪些好处？ 为当前的解决方案是否得到了足够的资料来负责架构、排错以及连接系统的维护？ 通过尽早的回答这些问题，就可以避免后续可能出现的性能问题，那些问题会影响项目的成功。如果数据源不太可靠，而且数据质量和性能方面是有问题的，这个时候，可以回到这些数据的关键利益相关者那里，与他们讨论，并确定这是否会影响到使用方面的关键需求。如果没有，需要把这部分数据需求从CMDB项目计划的第一阶段中展示放弃。这里最重要的是第一阶段的合理部署，实施结果能够获得用户全面的适应。然而，如果这些数据依然是比较关键的需求，那么需要与数据所有者，和收益者各方进行沟通，并引起各方的高度重视，共同确定一个解决方案。
规划CMDB数据填充-002
From 《Step by step to build a CMDB》步骤17-规划CMDB数据填充 本文描述填充过程的任务1到任务2： 任务1 再次回顾CMDB范围 现在进行现实检验。你能否确实交付在第2阶段即“定义需求和创建IT服务模型蓝图”中定义的CI范围涉及的相关数据？你在CI数据一旦交付以后，能否有足够的资源来维护整个系统和所有数据？这些都是重要的问题，因为您所选择的CMDB解决方案，可能很容易地就超越了您需要的范围，超出了你可以能容易维护的程度。 在规划CMDB数据填充时，您的思想应该是“少即是多“。先学会走再跑。让CMDB的首次推广得到充分验证后在考虑扩大范围。您需要帮助保持 CMDB的团队和CMDB数据用户的积极性。同时避免项目范围的蔓延，否则可能破坏的实施的效果，以及用户对新的解决方案的接受度。 请谨记这样几个考虑因素，从而来帮助您始终专注于那些核心需求上，并能对关键的限制作出反应： * 成本 – 每个人都必须面对业务现实，包括预算和费用的现实。因此，在您的CMDB项目预算范围里，对主要需求排列优先级。如果出现新的想法，那么也只是在新的预算来下了以后才考虑。 * 时间 — 您可能需要在给定的时间内实施CMDB，来使您企业在此方面的业务需求得到满足，如 Sarbanes-Oxley 法规，或支持一个非常关键的新流程。当您计划了CI数据填充的顺序后（后面介绍的这一步），不仅要对CI数据排优先级，而且还要明确时间的限制。 * 实用性 – 如果没有足够的资源用来实施和维持CMDB，以满足CMDB要求，那么您可能需要缩小实施范围，以便您可以在您实际有限的资源里运作项目。你还可以考虑分两个阶段进行实施，把非关键的要求放到第二个阶段中。 * 外部强加的优先事项 – 有些业务的运作，例如企业治理、数据保护和信息自由，可能会影响您既定的优先次序。您可以通过分阶段实施CMDB数据填充来减少外部因素的影响。如果你没有从一开始就计划足够的时间来达成最后期限，那么你可以尝试投入更多的资源来克服时间上的限制。然而，还要意识到，以后你要申请更多的资源，没有资源的保证，你可能无法充分管理好项目。 * 所有权 – 有时IT资产的负责人并不属于IT组织。如果资产所有者决定不参与的CMDB，这会严重限制了CI数据内容的提供。您可以提供CMDB部分功能的有限的访问给他们，用来消除他们顾虑，并参与进来。 * 地区 – 地理区域上的边界，可能会限制建立企业范围的CMDB。由于地理或行政上可能的边界，我们可能听过“最好再也不要从总部传来这样神经质数据库方案”。最好预防这种情况的办法是，尽可能早的让所有地区的相关人员参与到CMDB项目里来。 * 组织架构 – 很多企业把IT划分成为清晰地、各自为政的独立部门，通过这种方式来对CMDB里的不同范围负责。例如：通信部门的人可能是一个单独的组织结构，他们可能拒绝参与到项目中来，因为他们觉得这超出了他们的控制范围。这时候就要让其他的IT组织参与其中，让每个人都知道谁是项目负责人。 当你计划你的CMDB数据填充的时候，越能专注于关键受益人的需求，就越能够达成项目的业务目标，就越能让您的项目顺利。您需要就已经确定的 CMDB范围，与所有的利益方沟通它可能的影响和效果。收集他们的反馈，并对有必要方面做进一步讨论。 任务2 识别CI 使用在第15步即“设计IT服务模型蓝图”中设计的IT服务模型蓝图为基础，来生成用于CMDB数据填充的CI以及相关属性和关系数据的清单。这个清单的细节应该到数据字段级别，以便，你能够识别并且映射一个或者多个数据源到特定的CI数据。 例如，如果你把一个实际的服务器CI的属性和关系数据都列出清单，你就可以找出一些现有的能提供属性数据的数据源，可能包括库存管理的数据库和发现或者网络管理工具。但是另外一些数据字段可能没有现成的数据源。你将在第18步“选择自动化CMDB数据填充工具”中用到以上差距分析。或者您可能决定使用手工的方式来填充和更新这个字段，这里还需要仔细的考虑到数据的负责人，和在21步“建立CI生命周期管理流程”中需要支持的流程。 至此，你需要专注于用来满足项目目标的要求。在步骤11到14，你定义了与其他流程的结合点，明确的CI需求。专注于那些能直接对流程收益人产生直接影响的CI数据。
规划CMDB数据填充-001
From 《Step by step to build a CMDB》步骤17-规划CMDB数据填充 目标 在这一CMDB关键的步骤中，会为CMDB的初始化CI数据填充，做精细的计划。需要考虑到所有CI数据，把不同CI类型对应到不同的数据集中，安排正确的顺序将这些数据集CMDB。其中定义对应的规则来调和重复数据是很重要的，不仅在CMDB初始化数据填充阶段重要，在以后的日常维护过程中也是非常重要的。做出了本阶段的详细规划后，这样在第18步即“选择自动化CMDB填充工具”时，就能考虑需要什么样的配置发现和自动化工具了。 实际上，把数据填充到CMDB中是非常基础的工作，必须事前做好充分的数据范围和类型的分析。对于一个典型的CMDB数据填过程来说，将需要做如下工作： 建立里项目程碑和高阶项目计划，以及配套的支撑数据库和操作流程。 安排项目启动会议，单周或者双周的项目进度沟通会。 识别子项目（每个数据集分为一个子项目），建立每个子项目的目标和需求清单。识别和制定项目工作活动内容，确定项目的工作流程，并且按照项目计划排程所有活动。包括： —并行开展项目（用户界面定制，DSL数据填充）； —串行开展项目（发现工具，数据调和，等等） 为每个子项目分配项目负责人，让他们来负责汇报项目的进展、问题升级和下一步的工作。 为所有项目参与人员建立一个开放的沟通平台，包括所有内部、外部人员（邮件组方式，数据库、通报） 为可能出现的紧急事件预留至少10%的时间和预算的缓冲。
联邦的CMDB–神话/现实/需求/还是策略？
来自：Jonathan Markworth（CompuCom Systems有限公司管理顾问，探讨联邦数据库的优点） 使用一个具有单一的、全知的、万能的和自维护功能的工具，来管理IT基础架的方方面面信息，是否是最好的方案呢？使用一个能做所有工作的全集成平台，来替换您积累下来的所有管理工具是否是最佳方式？现实情况是，大多数组织都已经实施了几十种应用程序、工具、实用程序、数据存储、硬件平台和管理框架，它们一起运行着一个或更多的IT服务管理功能。它们中的每一个应用都有自己的数据库，对当前环境中的一些关键管理功能提供信息支持。在CMDB应用场景中，这些工具相关的数据库中，其实也包含了大量关键的CI属性，这些属性可以用于识别CI之间的关系。重要的问题是，如何利用现有的投资和资源来建立一个底层共享的数据库，比如一个CMDB。