配置管理流程设计

配置管理流程设计说明书
目录
目录 (2)
1综述 (4)
1.1设计目的 (4)
1.2适用范围 (4)
1.3相关术语 (4)
2配置管理流程设计 (5)
2.1流程目的 (5)
2.2流程主要内容 (5)
2.3与其他流程的关系 (6)
2.4关键角色、职责定义 (6)
2.4.1配置管理员 (6)
2.4.2配置经理 (6)
2.4.3配置管理流程负责人 (7)
2.4.4实际岗位与方案角色的映射 (8)
2.5执行原则 (10)
2.5.1常规原则 (10)
2.5.2流程关联原则 (10)
2.5.3控制原则 (10)
2.5.4审核原则 (11)
2.5.5保密原则 (11)
2.6CMDB设计策略 (11)
2.6.1配置项层次设计和命名规则 (11)
2.6.2CI通用属性 (13)
2.6.3配置项状态 (14)
2.6.4配置项审核 (15)
2.6.5配置项的删除状态 (15)
2.6.6配置项所属系统 (15)
2.6.7厂商 (15)
2.6.8集成商 (16)
2.7流程概要设计 (16)
2.8流程详细设计 (17)
2.8.1（200.1）配置策略的制定 (21)
2.9关键衡量指标 (21)
2.10主要报表 (21)
2.10.1按统计 (21)
3附件A: CI属性设计 (22)
3.1服务器SR (22)
3.1.1小型机（EPS） (22)
3.1.2PC服务器（SPC） (23)
4附件B: CI关系对照表 (29)
5附件C: 厂商和集成商标准 (51)
5.1厂商名称标准 (51)
5.2集成商名称标准 (52)
1综述
1.1设计目的
本文档具有如下目的：
❑为某某公司建立基于ITIL的配置管理流程基本框架，提升某某公司信息技术维护管理效率
❑对某某公司和各分公司IT配置管理进行规范化、统一化管理
❑指导各分公司IT管理平台项目的实施
1.2适用范围
本文档作为本次项目的配置管理流程详细设计的交付物，读者对象为与配置管理流程相关的所有技术与管理人员。

1.3相关术语
❑ITIL（基础架构库IT Infrastructure Library ）
是英国政府在1987年制定的有关IT服务管理的方法论，现已成为事实上的IT管理标准。

❑服务台（HelpDesk）
服务台从根本上来说是提供了用户和IT部门的唯一接口。

此项功能常通过集中方式提供服务。

服务台的根本目的是提供初始支持，并通过变通方法、解决方案或升级到二线支持等手段帮助用户恢复到正常工作状态。

❑事件管理（Incident Management）
ITIL流程之一，事件管理负责解决所有的IT事件、问题和用户请求。

它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。

❑问题管理（Problem Management）
ITIL流程之一，问题管理负责解决重大紧急事件或具有相同症状的一组事件。

它的目的是找出事件的根本原因，并通过解除该根本原因从而防止类似事件的再次发生。

同时问题管理流程也负责预防事件的发生。

❑配置管理（Configuration Management）
ITIL 流程之一，配置管理负责描述，跟踪和汇报所有IT基础架构中的每一个设备或系统的管理流程。

这些设备和系统被称为配置项(CI) 。

每一个CI必须有效管理，跟踪和控制以支持公司的IT服务和基础设施成功运行。

❑配置管理数据库（CMDB - Configuration Management Database）
是在配置管理流程中用于记录企业所有IT相关配置项信息及其相互关系而建立的数据库。

❑变更管理（Change Management）
ITIL流程之一，变更管理通过控制和管理IT相关的变更，使变更对生产环境可能的影响和风险降到最小，从而提高IT环境的整体稳定性。

2配置管理流程设计
2.1流程目的
配置管理流程的总体目的是提供一个统一的、一致的流程来管理IT基础架构中的各个组成部分，以确保：
❑所有的配置项被正确识别
❑配置项当前和历史状态得到记录
❑配置项记录的完整性得到维护和确认
❑IT生产环境的稳定性
2.2流程主要内容
配置管理流程着重于管理IT环境中所有必须控制的组成元素，并为其呀相关流程（如事件管理等）提供相关信息，以使这些流程得到更有效的运行，从而保证IT环境的完整性和稳定性。

其主要流程内容如下：
❑配置管理策略的制定
确定配置管理的范围，并确定CI类别、CI属性定义、CI管理类型和CI之间的关系等。

❑配置项定义和标识
定义CI的分类，识别物理环境中的CI并予以标识，确保只有被认可的和被标识的配置项才能接受和记录，同时识别配置项实体的关系，进行CI信息的收集。

❑CMDB初始化
根据CI分类以及识别结果，导入CI数据，初步建立CMDB。

每次增加CI分类时，重复执行CMDB 初始化动作。

❑CMDB的控制和维护
包括CMDB的新CI录入和日常监控维护，采用合适的控制权限以确保CI数据与实施环境保持一致。

❑定期审核和回顾
定期审核全部或部分CMDB数据，确认和物理环境的一致性，从而确保配置信息的完整性；定期回顾审核结果，找出改进机会，包括流程和CMDB。

❑定期生成配置管理报告
定期生成配置管理报告，为其他流程配置管理回顾和领导提供管理报告流程相关定义。

2.3与其他流程的关系
❑与事件管理流程的关系
事件记录与CMDB中的配置项相关联，此外配置管理流程为事件管理提供配置项的具体信息。

❑与问题管理流程的关系
问题记录与CMDB中的配置项相关联，配置管理同时为问题管理的根本原因分析提供参考信息。

❑与变更管理流程的关系
变更管理与配置管理是紧密结合的，变更管理流程引发和控制对配置项的修改，此外配置管理为变更管理提供信息帮助变更的评估分析。

2.4关键角色、职责定义
流程的实现是通过不同的流程角色以及其所赋有的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责。

配置管理流程主要分为配置管理流程负责人、配置经理和配置管理员职责角色，分别简述如下：
2.4.1配置管理员
配置管理员分组管理和维护配置管理系统和配置管理数据库系统。

职责：
❑通过手工活自动化操作增加及更改配置项，保证所负责的关键CI的关键属性、关键CI间的关键关系完整、准确
技能要求：
❑熟悉变更管理、配置管理、事件管理和问题管理流程以及他们之间的关系
❑充分了解所辖的IT基础架构
❑有效的组织能力和表达能力
❑熟悉和了解数据库管理
❑熟悉配置管理工具
人员安排说明：
❑由各专业技术人员分别担任配置管理员，维护各自所管的设备或应用。

配置管理员可以按照基础架构的分类划分，也可以按照所属业务的类别进行划分。

2.4.2配置经理
配置经理是配置管理具体活动的负责人，包括带领执行配置项的鉴别、监控、控制、维护、审计等工
作。

配置经理将从整个信息技术中心的层面管理配置管理流程和配置管理数据库，在信息技术中心设立一人作为配置经理
职责：
❑定期对配置管理数据的内容进行审计和验证
❑定期主持配额制管理回顾会议
技能要求：
❑熟悉变更管理、配置管理、事件管理和问题管理流程及其他们之间的关系
❑了解公司的IT基础架构和环境
❑了解配置项之间的关系
❑较强的沟通技巧
❑很强的团队领导能力
人员安排说明：
❑由总公司及分公司分管硬件环境的相关领导或技术资深人员担任配置经理。

2.4.3配置管理流程负责人
配置管理流程复杂人从宏观上监控流程，确保配置管理流程在信息技术维护部门范围内被正确的执行。

当流程不能适应信息技术维护部门的情况时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进。

从而实现可持续提高。

职责：
❑确定配置管理流程的衡量指标
❑确保配置管理流程能够取得管理层的参与和支持
❑确保配置管理流程符合公司实际情况和公司IT发展战略
❑总体上管理和监控流程，建立配置管理流程实施、评估和持续优化机制
❑确保配置管理流程有效、正确地执行，当流程不能够适应公司的情况时，必须及时进行分析、找出缺陷、进行改进，从而实现可持续提高
❑保持与其他流程负责人的定期沟通
技能要求：
❑深刻理解配置管理流程
❑能够很好地理解业务对于配置管理的要求
❑对质量控制与保障有很深入的了解
❑有决策权，能够确保配置管理流程设计要求在实施项目中得到贯彻和执行
❑具有很好的沟通技能，能够取得公司高层的支持，获得所需资源
❑有很强的计划、组织、领导和控制才能，能够综合各方意见，进行流程的定期优化人员安排说明：
❑由分管硬件环境的相关领导担任配置管理流程负责人
2.4.4实际岗位与方案角色的映射
说明：配置管理员可以按照基础架构的分类划分，也可以按照所属业务的类别进行划分。

上表”配置管理员“可以进行扩充
2.5执行原则
2.5.1常规原则
❑配置管理数据库将为所有IT运行及服务管理流程提供所需信息，特别是针对事件和变更管理流程；所有事件、问题、变更流程触发后，均需要判断是否涉及到配置项信息的变化，如果涉及，则需要根据配置管理流程维护其信息和CMDB信息的一致性
❑所有配置项信息必须存储在一个数据库管理系统中
❑CMDB准确反应当前已知的IT架构状态
❑应该每半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进配置管理流程
2.5.2流程关联原则
❑和变更管理的关联
➢变更主管在变更计划阶段必须制定配置项更新计划，对计划修改的配置项进行说明
➢变更实施完后，由变更主管汇总相应的配置项修改的情况，并通知相应的配置管理员，配置管理员接收到配置项修改请求后，与CI实体进行核对，核对无误后方可修改CI属性以
及关系
➢对应风险等级为高和重大的变更，CAB中应该包括配置经理，以确保对CMDB的适当控制
➢CI应与变更记录建立关联，从而对CI的变化情况进行记录
❑和事件管理，问题管理的关联
➢CI应与事件记录、问题记录建立关联，从而确保对CI维护工作的统计和分析
2.5.3控制原则
❑所有有关生产环境配置项的更改都需要通过变更管理流程进行控制
❑只有得到授权的人员（配置管理员）才能对CMDB中的配置项信息进行修改，修改之前需要对物理CI的属性进行核实
❑任何设备进机房前或系统投入使用前必须启动配置管理流程，以确保配置项信息与物理环境的一致
❑其他流程会引发对配置项的修改，日常使用中发现的配置项信息的不准确需要相应的修改，CMDB审核也会引发对配置项的修改，以上均需要通过变更管理流程的控制，发起配置项修改需求的人将作为变更请求者，通过变更管理流程进行相应的审批，实现对CI信息的修改控制（在变更结束阶段通知相关的配置管理员修改配置项）。

❑在CMDB建设的初期，由于数据仍然处于调整中，可以有配置经理定义一个时间段，该时间段内的数据调整可以不经过变更管理流程控制
❑当确认配置项信息不需要在CMDB中保留时，进行配置项的删除，配置项的删除不在CMDB中进行物理删除，通过删除状态属性来标识其被删除与否。

❑需要至少每季度通过计算配置项的“服务到期日期”来对配置项是否过保进行预警
2.5.4审核原则
❑配置管理流程必须每半年对IT环境进行审核、跟踪监测，以保证CMDB的信息收集准确、完整，并与实际IT环境的状态高度统一。

该工作由配置经理负责
❑应该定期根据变更的执行情况对变更引发的配置项的修改情况进行审核
2.5.5保密原则
❑各公司只能看到本公司的配置项信息
❑公司相关领导及配置经理可以看到本公司的全部配置项信息
❑配额制管理员只能看到本人所管类别的配置项信息
❑其他人只可看到授权后的配置项信息
❑配置管理员可以设置哪些配置项属性是共享的，哪些是私有的
❑配置管理员可以将某一配置项授权给某人，授权后其人可以对授权的配置项进行修改
2.6CMDB设计策略
CMDB设计策略将从CI的层次设计、CI命名规则和CI关系等方面对CMDB的架构进行描述；
2.6.1配置项层次设计和命名规则
CMDB的层次按照三层设计，三层即保证CI可以被有效地分组，又可以保证层级不会过于复杂从而导致CMDB难以维护和管理。

各个分公司可以在此表的基础上，自行扩充CMDB的层次结构和CI类别。

具体CI属性参见附件A：CI属性设计
每个CI的搜索代码作为CI的名称，在CMDB层次设计中，每个CI类均标注了简写，作为CI命名依据，搜索代码的命名规则如下：
配置项的搜索代码组成共17位：XX-YYY-ZZZ-mmmmmm
自行扩充CI时，CI简写（XX-YYY-ZZZ）要求为大写英文字母，mmmmmm为数字或为小写字母。

XX代表被管理的配置项第一层，YYY代表配置项第二层，ZZZ代表配置项第三层，具体定义参见上表。

Mmmmmm(六位)在同一类CI中应该保持唯一，可以是顺序编号，也可以是CI实体的名称等。

注：为保证搜索代码的长度一致，没有第三层的CI项的相应位置统一填写”ZZZ”
如：某一台小型机的命名为HW-EPS-ZZZ-123456
配置项间的关系
利用CI之间的关系可以有效地将相关的CI连接起来，从而为故障和问题的解决、变更的佳话和执行提供更好的参考，下表是常用的配置项之间的关系。

配置项关系类型按照此定义，根据各个分公司的实际情况可以在此技术上进行扩充。

配置项关系可以通过两种方式实现；第一种是在CI属性中增加对相关联CI的引用，从而实现CI的关系；第二种是采用关系表的方式，记录相关联的CI以及关系类型，从而实现CI的关系。

在实现配置项之间的关系时，当选定某CI时，可以自动调出与其存在关系的所有其他CI，从而实现Ci之间信息的关联，方便操作和对CI的使用。

具体配置项之间的关系参见附件B。

2.6.2CI通用属性
此处列举大部分CI均具有的属性、相关说明以及适用的CI类别：
2.6.3配置项状态
配置项状态用于标识配置管理的生命周期，各类配置项的状态代码和说明。

2.6.4配置项审核
配置项属性以及配置项之间的关系必须被定期审核，以确保其与实际的物理环境保持一致，配置审核活动需要对配置项信息与配置项物理存在性进行双向验证。

在审核的过程中，配置项有不同的审核状态。

配置审核工作可以按照各分公司自行定义的审核范围和周期来进行，当总公司提出审核要求时，也需要发起配置审核工作。

考虑到实际的工作量，CI的审核范围不宜在整个CMDB中进行，每次安照CMDB的第一层进行，如单次审核仅审核所有硬件类CI及其相互关系；
对CMDB的审核同时可以参照变更的情况进行，根据一定时间内的变更记录，来检查这些变更中改变的CI属性是否被适当地修改，以确保CI属性和实际物理环境的一致。

审核周期安照CMDB建设的情况和流程的完善程度在配置管理测率中指定并定期更新。

在审核前，将所有需要审核的CI状态设置为“未审核”，根据审核结果，将CI的状态相应的改变为“已审核”“不匹配”“流失”同时记录更新审核时间；对“不匹配”“丢失”审核状态的CI信息进行纠正后，相应的将其状态修改为“已审核”至此一个审核周期结束。

应该在审核工作结束后，CI信息纠正之前统计流程衡量指标。

2.6.5配置项的删除状态
配置项的删除状态用于标明该配置项是否被删除，删除状态定义如下：
2.6.6配置项所属系统
配置项所属系统是配置项的重要属性，用于标明该配置项所属的业务系统，目前的配置项所属系统
2.6.7厂商
CI中定义了“厂商”属性，用于填写各个CI的原厂商。

为了在填写过程中保证厂商名称的统一从而利于统计，在此定义厂商名称填写的标准，各分公司可以在此技术上进行扩充，其它流程的厂商填写也参照厂商名称标准。

厂商名称标准参见附件C。

2.6.8集成商
部分CI中定义了“集成商”属性，用于填写相关CI的集成商。

为了在填写过程中保证集成商名称的统一从而利于统计，在此定义集成商名称填写的标准，各分公司可以在此基础上进行扩充，其他流程的集成商填写也参照集成商名称标准。

集成商名称标准参见附件C
2.7流程概要设计
2.8流程详细设计
2.8.1（200.1）配置策略的制定
流程描述如下
2.8.2（200.2）配置项的定义和标识
流程描述如下
2.8.3（200.3）CMDB初始化
流程描述如下
2.9关键衡量指标
为了较好地控制流程的质量，必须为流程设置衡量指标，通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。

配置管理流程的主要衡量指标如下：
2.10主要报表
2.10.1按统计
指标说明：
3附件A: CI属性设计
以下列出CI的详细属性设计，作为各个分公司CI设计的基础，同时作为上报总公司的要求，各分公司可以在此基础上，自行扩充CI的属性。

表格中红色字体的字段为通用属性。

3.1服务器SR
3.1.1小型机（EPS）
3.1.2PC服务器（SPC）
3.2存储设备（RD）3.2.1磁盘阵列（RAD）
3.2.2磁带库（TAR）
3.2.3其它存储设备（OTR）
3.3网络（SWT）
3.3.1交换机
3.3.1.1 网络交换机（SWT）
3.3.1.2 光纤交换机（SWT）
3.3.2路由器
3.3.3防火墙
3.3.4VPN网关
3.3.5安全网关
3.3.6链路
3.3.7其它网络设备
3.4终端
3.4.1台式机
3.4.2笔记本
3.4.3字符终端
3.4.4图形终端
3.5外设及其它3.5.1外设
3.5.1.1 打印机
3.5.1.2 扫描仪
3.5.1.3 绘图仪
3.5.1.4 其它
3.5.2机房3.5.2.1 监控系统
3.5.2.2 消防系统
3.5.2.3 其它
3.6软件
3.6.1应用软件
3.6.2系统软件3.6.2.1 数据库
3.6.2.2 操作系统
3.6.2.3 中间件
3.7文档
3.7.1管理文档
3.7.2技术文档
3.7.3维护文档
3.7.4工程文档
3.7.5合同
3.8应用系统
3.8.1应用系统名称
3.8.2应用系统模块。