在提供高可靠的IT服务方面,IT部门面临巨大的挑战。实施IT服务管理,首先需要良好的配置管理策略:
因此配置管理实施是IT服务管理的一个关键。
配置管理的目标是:落实组织的所有IT资产和配置及其相关服务;提供准确的配置信息和配置相关的文档信息来支持所有别的服务管理流程;提供一种事件管理、问题管理,变更管理和发布管理的坚实基础;根据配置记录验证基础设施的正确性,并纠正任何异常。
当达到这些目标之后,您的组织才能够感受到显著的、可衡量的IT服务的好处。
1. CMDB的定位
CMDB作为一个信息管理平台,定义了IT运维管理对象的基础信息的标准,包含了对象本身的描述属性,与其他对象的关系,信息的规范等; 同时提供了一系列数据整合、加工手段,并配合流程管理,确保数据的准确性; 并作为信息桥梁,通过标准接口对外提供统一的数据服务,支撑多场景、多视角消费。 所以总的来说,CMDB定位为:数据标准制定者、数据加工厂 、信息桥梁。
2.数据标准的制定者
CMDB的数据标准主要包括以下三个方面:
· 确定配置数据模型的整体框架,特别是以应用为导向的端到端模型框架 , 确定配置项的分类、关系的分类
· 确定数据的规范,如属性的命名规则、数据字典、唯一标识
· 确定数据生产和消费的原则,包括生产职责、生产手段,消费方式
3. 数据加工厂
CMDB从多个视角提供配置信息,信息来自多个数据源,CMDB整合并处理不同的数据,统一数据的规范、构建数据之间的互联关系。其中部分数据通过接口同步到CMDB中,部分数据不进入CMDB,但在CMDB中建立关联。下图以服务器配置项为例,描述其数据组成及流向:

那么如何才能实施落地好配置管理了?下面我们针对配置管理整个实施过程中关键的步骤进行详细解析,本节主要内容目录如下:
需求定义及实施
需求定义方法
确定消费场景
定义CI颗粒度
定义配置模型
定义CI关系
制定CMDB服务蓝图
数据采集校验
配置管理的需求梳理从使用场景入手,综合考虑不同运维团队视角,梳理出CMDB需要提供的信息视图,形成系统展现功能和数据需求。
基于上述需求,进一步分析、确定配置信息的数据结构,最终以面向对象的方法设计出配置数据模型,包括CI分类、属性、关系 。

在ITIL整个实践体系中配置管理主要用于支撑以下四方面的使用场景需求:
变更管理:各团队在进行变更规划时,在变更单中需要关联配置项,查询变更对象的详细信息,分析变更可能产生的影响范围;变更完成后,需要手工更新管理类的属性,如状态;同时,在变更单关闭前,需要比对变更前后配置项的信息变化,确认变更导致的配置信息变化是否及时体现到CMDB中;
故障分析:各团队在进行故障分析时,在事件/问题单中需要关联表象配置项,查询对象的详细信息,了解上下游关系,了解近期变更情况;在找到问题根源后,在事件/问题单中需要关联根源配置项;
精细化/标准化管理:从各个视角出发,细化CMDB的管理粒度,对配置项进行层次划分,对于可以通过自动化手段能获取的细粒度配置项作为二级配置项纳入管理范围;通过CMDB支撑数据中标准化工作(如通过CMDB管理标准化的服务目录,基于配置信息生成标准化的管理报表),同时从CMDB自身数据质量出发,明确数据规范,如CI命名规范、属性数据字典、数据来源等。
可用性/容量管理:支撑可用性管理,通过CMDB管理应用及IT基础架构的可用性指标,并与监控系统集成,快速查看配置项的当前可用性状态;支撑容量管理,通过CMDB管理应用及IT基础设施的额定容量数据,并结合监控系统历史数据,为容量模型数据库提供信息输入。
我们通过下面这张视图结合IT部门设置和团队职责分工来总结出符合当前企业的消费场景:

定义CI颗粒度即梳理确认你实施配置管理最终要管理的CI范围,包含两方面:广度和深度。说简单点就是定义要管理的CI分类和属性、关系。


分类的定义:根据实际情况梳理出计划管理的CI类别,参考示例如下:

属性的定义:针对不同的分类需要管理的属性分别是什么,定义分类和属性时需要考虑这些属性是否可被管理,数据采集的方式,作用等要综合评估,这些决定了实施的工作量和复杂度,也关系了整个实施的成败。
属性通常分为两部分:一部分公有属性,如名称,编号,分类,状态,管理对象、使用对象、创建人、创建时间、修改人和修改时间等 ,另一部份为私有根据不同分类的不同定义。
#  | 属性名称  | 属性类型  | 数据类型  | 格式要求  | 场景描述  | 
1  | 参考命名规范  | 系统自动生成-作为唯一标识供前台识别搜索  | |||
2  | 配置项编码  | 系统属性  | 文本  | 参考编码规范  | 系统自动生成-作为唯一标识系统后台使用  | 
3  | 配置项描述  | 通用属性  | 文本  | 长度<512  | 基本描述  | 
4  | 备注  | 通用属性  | 文本  | 长度<255  | 备注  | 
5  | 一级分类  | 通用属性  | 文本  | 标准选项:模型数据字典  | |
6  | 二级分类  | 通用性  | 文本  | 标准选项:模型数据字典  | |
7  | 三级分类  | 通用属性  | 文本  | 标准选项:模型数据字典  | |
8  | 状态  | 通用属性  | 文本  | 标准选项:菜单  | 所有CI的活动情况记录  | 
9  | 配置项管理员  | 通用属性  | 文本  | 搜索选择  | 供联络的配置项负责人  | 
10  | 配置项创建人  | 系统属性  | 文本  | 长度<255  | 系统自动记录-CI录入的人  | 
11  | 配置项创建时间  | 系统属性  | 时间  | 年-月-日 时:分:秒  | 系统自动记录-CI录入的时间  | 
12  | 最后更新人  | 系统属性  | 文本  | 长度<255  | 系统自动记录-CI修改的人  | 
13  | 最后更新时间  | 系统属性  | 时间  | 年-月-日 时:分:秒  | 系统自动记录-CI修改的时间  | 
14  | 最后审计时间  | 通用属性  | 时间  | 年-月-日 时:分:秒  | 审计时间记录  | 
公有属性参考
#  | 属性名称  | 属性类型  | 数据类型  | 格式要求  | 维护方式  | 
1  | 设备序列号  | 主键  | 文本  | 长度<255  | 手工  | 
2  | 设备名称  | 基础属性  | 文本  | 长度<255  | 手工  | 
3  | 厂商  | 基础属性  | 文本  | 标准选项:菜单  | 手工  | 
4  | 设备型号  | 基础属性  | 文本  | 长度<255  | 手工  | 
5  | 物理CPU数  | 基础属性  | 整型  | >0  | 手工  | 
6  | 内存总量(G)  | 基础属性  | 整型  | >0  | 手工  | 
7  | 磁盘容量(G)  | 基础属性  | 文本  | 长度<256  | 手工  | 
8  | 管理IP  | 基础属性  | 文本  | 长度<256  | 手工  | 
9  | 维保厂商  | 基础属性  | 文本  | 标准选项:菜单  | 手工  | 
10  | 维保截止日期  | 基础属性  | 日期  | 年-月-日 时:分:秒  | 手工  | 
11  | 所在地点  | 基础属性  | 文本  | 长度<255  | 手工  | 
12  | 所在机房  | 基础属性  | 文本  | 标准选项:菜单  | 手工  | 
13  | 所在机柜编号  | 基础属性  | 文本  | 长度<255  | 手工  | 
14  | 部署U位  | 基础属性  | 文本  | 长度<255  | 手工  | 
15  | 电源1  | 基础属性  | 文本  | 长度<256  | 手工  | 
16  | 电源2  | 基础属性  | 文本  | 长度<256  | 手工  | 
17  | 固定资产编号  | 基础属性  | 文本  | 长度<256  | 手工  | 
私有属性参考
配置管理的整体模型需要涵盖IT管理的多个领域,同时覆盖各个团队的相关工作,模型的主线是业务、应用、服务器、环境同时兼顾与批量、中间件、数据库、网络、存储的关联,对于配置项的相关过程信息、实时信息则通过外部的流程、容量、可用性数据体现,实现系统间的联邦集成。
利用CI之间的关系可以有效地将相关的CI连接起来,形成结构模型,从而为故障和问题的解决、变更的计划和执行提供更直观的参照,下图是推荐模型构建的原则及构建示例:

通用模型结构如下图所示:

开放系统模型

CI关系类型如下表所示,包括:包含、依赖、安装、接入、存储链路五种关系,CI关系主要用于图形化展示及影响分析,常见主要关系类型如下表所示:
#  | 关系名称  | 源CI对象  | 目标CI对象  | 
1  | 包含  | 服务  | 活动  | 
应用系统  | 应用服务  | ||
应用系统  | 数据库服务  | ||
应用系统  | 操作流程  | ||
应用服务  | 交易  | ||
应用服务  | 数据库服务  | ||
数据库服务  | Oracle实例  | ||
数据库服务  | SQL Server实例  | ||
数据库服务  | My SQL实例  | ||
资源组  | 资源  | ||
资源组  | 集群  | ||
集群  | 逻辑服务器  | ||
逻辑服务器  | 应用服务  | ||
逻辑服务器  | 数据库服务  | ||
逻辑服务器  | IP地址  | ||
逻辑服务器  | 网络端口  | ||
磁盘阵列  | LUN  | ||
物理服务器  | 逻辑服务器  | ||
网络设备  | 网络板卡  | ||
网络设备  | 网络端口  | ||
网络板卡  | 网络端口  | ||
物理服务器  | HBA卡端口  | ||
SAN交换机  | SAN端口  | ||
磁盘阵列  | 存储池  | ||
磁带库  | 存储池  | ||
2  | 依赖  | 应用系统  | 应用服务  | 
应用系统  | 数据库服务  | ||
应用子系统  | 集群  | ||
应用子系统  | 软件实例  | ||
软件实例  | 软件产品  | ||
数据库实例  | 表空间  | ||
逻辑服务器  | 物理服务器  | ||
表空间  | 数据文件  | ||
3  | 安装  | 工具软件  | 逻辑服务器  | 
Weblogic  | 逻辑服务器  | ||
Tuxedo  | 逻辑服务器  | ||
Oracle  | 逻辑服务器  | ||
物理服务器  | 机柜  | ||
磁盘阵列  | 机柜  | ||
带库  | 机柜  | ||
SAN交换机  | 机柜  | ||
交换机  | 机柜  | ||
路由器  | 机柜  | ||
防火墙  | 机柜  | ||
负载均衡  | 机柜  | ||
机柜  | 机房  | ||
配电柜  | 机房  | ||
空调  | 机房  | ||
UPS  | 机房  | ||
4  | 接入  | 逻辑服务器  | 网络端口  | 
5  | 存储链路  | 数据库实例  | 表空间  | 
表空间  | 文件系统  | ||
文件系统  | LV  | ||
LV  | VG  | ||
VG  | PV  | ||
PV  | LUN  | ||
LUN  | 存储前端口  | ||
存储前端口  | SAN端口  | ||
SAN端口  | SAN交换机  | ||
SAN交换机  | HBA卡  | 
CMDB的建设是一个长期而复杂的过程,需要分阶段规划实施不可一蹴而就,要制定清晰的服务蓝图,如下:

配置管理数据来源主要有以下几种方式:
通过工具自动发现
通过模板批量导入数据
其他系统数据联邦
手工录入数据
具体数据工具及使用在此不做详细说明,在通过以上方式将数据采集后还需要进行严格的数据校验调和过程再转入到生产环境消费,


                          



