Tag Archives: ci
BMC Atrium CMDB CI数据迁移
.png "fatureimage")
在不同的CMDB服务器之间做数据迁移之前一定要注意两点：1）保持两边的CDM相同；2）先导入CI数据在导入CI相关的关系数据。另外就是每个类导入完毕之后要做数据完整性和正确性的抽检。以下使用的工具是cmdbdriver，该命令初始化和一般性的参数介绍请参考相关文档。 CI数据导出示例 Command: xexpdt XEXPORT DATA Export instance data from all classes? (F): Classes to export data from: Class and its subclasses, From namespace (1,2) (1): Namespace (): BMC.CORE Class name (): BMC_ComputerSystem Dataset ID (): BMC.ASSET Filename for exported data: C:\DEMO\cs-ci Exporting Class BMC_ComputerSystem i=0: namespaceName = BMC.CORE, className = BMC_ComputerSystemExported without errorsExporting Class
[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数据填充-001
From 《Step by step to build a CMDB》步骤17-规划CMDB数据填充 目标 在这一CMDB关键的步骤中，会为CMDB的初始化CI数据填充，做精细的计划。需要考虑到所有CI数据，把不同CI类型对应到不同的数据集中，安排正确的顺序将这些数据集CMDB。其中定义对应的规则来调和重复数据是很重要的，不仅在CMDB初始化数据填充阶段重要，在以后的日常维护过程中也是非常重要的。做出了本阶段的详细规划后，这样在第18步即“选择自动化CMDB填充工具”时，就能考虑需要什么样的配置发现和自动化工具了。 实际上，把数据填充到CMDB中是非常基础的工作，必须事前做好充分的数据范围和类型的分析。对于一个典型的CMDB数据填过程来说，将需要做如下工作： 建立里项目程碑和高阶项目计划，以及配套的支撑数据库和操作流程。 安排项目启动会议，单周或者双周的项目进度沟通会。 识别子项目（每个数据集分为一个子项目），建立每个子项目的目标和需求清单。识别和制定项目工作活动内容，确定项目的工作流程，并且按照项目计划排程所有活动。包括： —并行开展项目（用户界面定制，DSL数据填充）； —串行开展项目（发现工具，数据调和，等等） 为每个子项目分配项目负责人，让他们来负责汇报项目的进展、问题升级和下一步的工作。 为所有项目参与人员建立一个开放的沟通平台，包括所有内部、外部人员（邮件组方式，数据库、通报） 为可能出现的紧急事件预留至少10%的时间和预算的缓冲。
资产CI的一生
在ITIL v3以后，配置管理进化为“服务资产和配置管理SACM”，换句话说，资产和配置管理不分家。两个流程应该是融合的。从微观上看资产管理设计到CI的所有生命周期状态，而这个服务资产在CMDB中出现的状态为整个生命周期中的一部分。 最好能通过资产管理为统一入口，来完成对CMDB中资产的生命周期管理。例如：一台服务器在到货以后，完成资产入库后，就应该在CMDB中自动创建CI，在上架部署了软件后，有配置资产自动采集工具，采集回详细配置信息后，资产状态就自动变为“部署”，当在运行维护中服务器宕机或者维护时，在资产管理中也能看到更新的信息。下面是建议的服务资产的生命周期状态: 编号 状态名称 状态描述 1 到货 表示为CI的物品在采购以后，被相关部门签收。 2 组装 设备的组件在被组装的过程中 3 维护 该设备处于宕机后的维护状态 4 宕机 该设备处于宕机状态，还未对其进行维护 5 终止 不在处于被部署的状态 6 转移 该设备正在被转移到其它的地点或者机房途中 7 删除 配置项被标记为删除状态 8 库存 设备处于库存中，还没有被部署 9 借出 已被其他单位或者部门借走 10 处理 该设备已经被拆卸，其本身已经不可用 11 保留 该设备已经被某单位或者部门预订，已经不再库存中了 12 返厂 由于设备已经被损坏或者过保，必须被退回厂商 13 部署 CI的默认状态，表示设备处于正常的生产运行状态 14 订购 该设备已经被订购，还未到货，仍然不可用 配置项管理和资产管理的联系和区别。 Service Asset and Configuration Management (SACM)
CMDB中存什么？
当然是配置项和它们之间的关系，即：CI 和 Relationship。 那么如何规划那些类型的CI和Relationship需要保存到CMDB中呢？可以参考的数据模型是DMTF的通用信息模型，它是以面相对象的方式来描述各类CI和关系。它是一个工具用来帮你对环境中的各种物理和逻辑的CI和关系进行分类，参考这个模型选择一些有用的类（广度），然后在参考它对每个类属性的描述（粒度）。这些类的选择只是一个初步的研究，每个CMDB厂商和工具对其实施和参考的力度都不同，也需要看您具体实施的是什么工具。例如：你需要描述银行基金业务系统，你可能选择的CI类包括：客户群、业务流程、业务活动、业务服务、IT服务、应用系统、应用、软件服务器、服务器、网络、存储等；关系包括：组件、依赖和影响。CI类和关系的选择也基本上遵循够用就好的原则；而且每个类对应的CI实例都需要有人负责管理维护，需遵循，谁负责、谁维护的原则保障其属性的精确性。对于整个CMDB来说如果存在没有Onwer的CI或者关系，如果它是由自动化配置发现工具来更新的；那么它可以存在，如果不是的话，它可能根本就不该存在。所以CMDB中保存的数据不是越多，越细越好；而是够用就好，能保证更新就好。由于数据根本就不是免费的，即使国内的人力成本低，也不应该雇用一帮专职更新CMDB的人。 综上所述：我们说明了CMDB中数据选取和存放的最基本原则和方法，在CMDB产品选型过程中需要着重考察产品的数据模型本身和其管理的能力，还包括其CI和关系的扩展和定制能力；包括数据类型的支持和界面定制的程度。那么CMDB中的CI和关系有该如何展现呢？这是CMDB系统的另外一个功能：可视化。下面是一个CI和关系展示的实例供参考： [http://media-001.yo2cdn.com/wp-content/uploads/266/26670/2009/10/s1-4-blog.swf#swf&width=320&height=320] 全屏查看或者下载Flash文件 第一代的配置展示方式是，纯数据表格方式。第二代具有一种固定格式的图形展示方式，除了那几张视图外，别的需要单独开发。下一代的具有各种视图定制功能，并且支持关系和ci的过滤等等。