配置管理流程设计说明

1、精选优质文档-倾情为你奉上电脑资讯部配置管理流程设计2009年8月Version 2.0关于本文档文档信息文档名称电脑资讯部配置管理流程设计作者说明 本文档是电脑资讯部对于其负责建设运维的配置管理流程详细设计说明文件名称 配置管理流程设计说明.doc修订历史 (REVISION HISTORY)RevSectionTypeDateAuthorRemarks0.8All新2009-7-10IBM Team创建配置管理流程详细设计初稿。1.0All补充修订2009-7-28IBM Team配置管理角色的调整及相应流程图的调整，CI属性的补充2.0All修订2009-8-7IBM Team修订几个细

2、节2.1配置项属性、关系补充修订2009-8-14IBM Team补充了逻辑实体的一个属性；更新了关系定义目录插图目录图 11. LoVEM 图样例8图 21. 配置管理流程概述13图22. 配置管理规划14图23. 鉴别&维护配置数据模型18图24.配置数据控制21图25. 配置数据验证与审核24图26. 产生配置报表27表格目录表 2-1. 目标时间政策37表 2-2. 升级政策37表 4-1. 配置项的分类42表 4-2. CI状态45表4-3. CI状态与配置项分类的适用关系46表44. CI生产状态代码转换图（业务、渠道）47表45. CI生产状态代码转换图（应用）47表46

3、. CI生产状态代码转换图（逻辑实体）48表47. CI生产状态代码转换图（软件）48表48. CI生产状态代码转换图（硬件）49表49. CI生产状态代码转换图（文档）49表410. CI生产状态代码转换图（合同）50表 4-11.审核状态50表 4-12.审核结果51表 4-13.审核结果51表 4-14. CI项关联关系表52表 4-15.物理地址定义531 介绍配置管理流程设计说明旨在介绍和描述将在电脑资讯部实施的配置管理流程，提供对于IT生产环境IT基础架构的一个逻辑模型，并鉴别、控制、维护和验证现有配置项(Configuration Item, 简称CI)的版本等信息。配置管理包含

4、了对IT部件的版本、主要组成和相互关系等的鉴别、记录和报表的功能。配置管理数据库(Configuration Management Database, 简称CMDB)，至少应当保存各系统部件之间的关系，包括与该系统部件相关的事件、问题、变更请求和版本发布。广义来讲，CMDB还可以用于存放事件、问题、已知错误，以及人员、供应商、地点、业务部门等公司数据。配置管理不等同于资产管理。资产管理首先是一个财务方面讨论的课题，而不是技术上的课题。资产管理关注的是与PC、网络设备、服务器或者软件等相关的价值、合同、折旧、服务水平、责任人和用途等信息。在配置管理中，将列出IT基础架构中的IT设备的清单，关注于

5、这些设备是何种设备、物理位置、设备的使用者、发生过多少次变更等。通常配置管理不会关注IT部件的价值或者何时租约到期。配置管理记录了IT部件之间的关系及其从属关系，以便为其他服务管理流程提供当前的、准确的信息。1.1 本文适用对象本文作为电脑资讯部实行配置管理流程的参考，供电脑资讯部参与到配置管理流程中的人员和相关的管理层使用。1.2 前提与假设n 本文的使用者应当熟悉ITIL的术语，具有基本的流程技能。1.3 阅读指南本文所有工作流程均使用IBM Line of Visibility Engineering Methodology (LoVEM)描述。LoVEM 可提供工作流程的图形化表述。流

6、程中涉及的角色（Roles）定义于左列，还包括其他相关的流程；右侧是流程的每个步骤。流程的各个步骤分布于各角色相对应的行，各步骤从左到右排列，箭头连接各步骤并表明信息和数据的流向。每个流程步骤均以图形化表示，并以图表显示步骤的流程、执行相应步骤的角色和各项步骤的内容。图 11. LoVEM 图样例1.4 本文结构本文由以下几个章节组成：第一章，“介绍”，描述了本文的适用对象、组织，以及本文约定使用的描述方法。第二章，“配置管理流程”，定义了流程的目的和目标、概念定义、配置管理的范围、指导原则、总体流程、流程的步骤、任务，流程中涉及的角色及其职责，以及相关的报表。第三章，“政策”，定义的流程执行

7、过程中必须遵循的相应规定，如目标时间。第四章，“参考数据”，定义了流程中的重要执行参数；以及最为重要的初始的CMDB的数据模型和相关CI项的数据结构。第五章，“附录1-配置项服务分类”，列出配置项的按服务分类。第六章，“附录2-专有属性参考”，列出配置项的专有属性。第七章，“附录3-词汇对照表”，将国际通用的IT服务管理的术语与对应的中文翻译一一对应，方便查询。2 配置管理流程2.1 目的和目标配置管理的任务是记录和维护IT环境各组件的准确信息，包括这些组件之间的关系，并把这些信息提供给其他IT服务管理流程，以支持IT服务。配置管理的目标：- 管理本流程管辖范围下的电脑资讯部各IT配置项及其与

8、IT服务的关系- 维护和验证信息技术中心的配置项信息的完整性，以及与真实环境的一致性- 为电脑资讯部的其他流程和服务提供准确信息2.2 概念定义配置项（Configuration Item，CI）指IT架构中或者直接与IT架构相关的一个组件，它是配置管理中最基本的信息单元。配置项包括：硬件、软件、系统、服务和文档。配置管理数据库（Configuration Management Database，CMDB）记录和维护配置项信息及其之间的关系的数据库。2.3 配置管理的范围配置管理是对IT组件的标识、记录和报告，包括版本信息、组成部分、状态、和其他部件的关系和用途。配置管理应该包括硬件、软件、系

9、统、服务和文档。基于以上定义，应当清楚的了解虽然配置管理与资产管理相关，但二者含义并不相同。资产管理是包括折旧在内的会计工作。与资产管理不同，配置管理维护配置项之间的关联关系。当使用不同的技术和实践时，配置管理的范围包括IT基础设施和操作的环境，还可以考虑涵盖解决方案的开发和测试环境。配置管理包括：l 确立配置项与配置项之间关系的命名规范。l 设计、创建和改进配置管理数据库。l 支持配置项审计。l 确定相互关联的配置项。l 关联配置项变更和相应的变更请求。l 确定和报告配置基线。 配置管理不包括：l 资产管理l 入库管理l 配置项的采购2.4 指导原则u 电脑资讯部应该建立一个统一的配置管理流

10、程，所有电脑资讯部管理范围的IT组件都在本流程下统一管理。u 所有对配置管理流程和工具的修改，都应该遵循变更管理流程。u 所有对配置管理信息的更改，都须经过变更管理流程的授权，或者经过指定人员审核后被授权同意更改。u 所有电脑资讯部的员工都应该遵守配置管理流程来开展与配置管理相关的工作。u 所有配置项信息都必须记录在一个数据库管理系统中，并确保信息能准确反映当前电脑资讯部的IT架构。2.5 流程概述下图从总体上描述了配置管理流程、执行步骤和各步骤执行的顺序。图 21. 配置管理流程概述配置管理流程起始于一个初始的规划和建设步骤，包括创建配置管理数据库（CMDB）。在初始化之后，该流程主要侧重于

11、日常基础的鉴别和维护配置管理数据模型，以及维护配置数据。之后，该流程还负责产生配置信息的报表、定期进行审核。配置管理规划该步骤是配置管理的起始点。其目的是规划和定义配置管理的目标、范围、目的、政策和流程步骤，以及配置管理中涉及的人员组织。初始设置、创建和发布配置管理数据库（CMDB），也是该步骤的工作内容之一。配置数据模型维护对于新的请求，为了确保配置管理数据库中现有的数据模型能够记录新的配置项的属性和关系。因此，本步骤主要考虑选择和鉴别所管辖的配置项的信息结构，包括其“责任人”、配置项属性、配置项之间的关系和配置文档等。配置项数据控制该步骤确保在数据的接收到废弃的过程中，只有经过授权的配置项

12、才能被接受和记录到配置数据库中。还应当确保对于配置项的增加、修改、替换或者删除都附有适当的控制文件，例如，审批过的变更请求、公司政策发文、经过授权认可的审核报告等。配置数据验证与审核应当定期进行配置项的回顾和审核，以确保物理环境中的部件的存在性，并检查配置项信息是否正确记录在配置管理系统中。当CMDB记录的数据与物理存在的配置项之间不一致，就出现了差异。必须调查这些差异，必要时提出变更请求。如果需要，则修改CMDB以减小存在的差异。配置管理报表该步骤定期产生报表，包括各个配置项生命周期的现存和历史数据。这使得配置项的变更历史能够被追踪，例如，可以跟踪一个配置项的状态变化，从“建设中”、“组装中

13、”到“已部署”或者“待报废”等。2.6 流程步骤描述2.6.1 配置管理规划描述:该步骤的目的是规划和定义配置管理的目标、范围、政策和步骤，以及相关的组织结构、技术手段。其主要目的是创建配置管理数据库的初始数据模型。图22. 配置管理规划输入:l 初始的配置信息输出:l 配置管理计划l 初始的CMDBl 初始的审核日志任务:1.1拟定配置管理计划1.2收集初始的配置管理数据 1.3创建初始的CMDB1.4进行初始审核1.5修正CMDB1.1拟定配置管理计划执行者：配置管理流程负责人 l 根据电脑资讯部的IT规划和其他流程计划，创建配置管理计划，包括下列内容：l 配置管理的角色和职责l CI的命

14、名规范l 与其他流程的接口l 配置管理系统设计，包括配置管理的范围和关键接口，包括：l CMDB结构l 配置管理数据及其库的位置l 产生CI信息的可控制的环境，即配置管理范围内的环境l 与其他管理流程的接口l 支持工具（如，数据库构建和安装工具）l 定义配置数据模型l CI信息的系统管理、归档和数据保留周期l1.2收集初始的配置管理数据执行者：配置管理员 l 根据配置数据模型，收集初始的配置数据。这可以通过手工收集CI的物理清单，或者向流程相关人员要相关信息（如，与某个CI相关的事件记录），或者利用自动发现的工具采集信息。1.3创建初始的CMDB 执行者：配置管理员l 创建CMDB，并将初始的

15、配置数据倒入数据库l1.4进行初始审核执行者：配置管理流程负责人/配置管理员l 进行初次审核l 分析审核数据l 如果CMDB真实反映了物理现实，转入步骤2“鉴别&维护配置数据模型”任务2.1“检查与验证请求”l 如果CMDB的数据与物理现实中的数据有差异，转入任务1.5“修正CMDB”1.5修正CMDB执行者：配置管理员l 修正初始审核查出的有差异的数据2.6.2 配置数据模型维护描述:该步骤的目的是确保CMDB的数据模型能够记录所有需要维护的配置项(CI)的属性、关系及其政策等信息。因此，需要具备配置项的知识、并且及时了解对配置项的修改。对于数据模型的变更可以直接提出，或者通过变更管

16、理流程提出修改。图23. 鉴别&维护配置数据模型输入:l 当前的CMDB数据模型l 变更请求单l 系统和服务设计信息输出:l 更新的CMDB数据模型任务:2.1检查与验证请求2.2联系请求者2.3评估修改CMDB数据模型的影响2.4设计/开发对数据模型的修改2.5创建与维护配置数据结构2.1检查与验证请求执行者：配置管理员 提示：· 主要检查和验证那些新增和更新的CI数据是否将导致数据模型的修改l 收集来自变更管理流程关于修改数据模型的请求l 检查每个请求对于CMDB的影响2.2联系请求者执行者：配置管理员l 如果拒绝该请求，应有明确的理由，记录下来并通知请求者2.3评估修改

17、CMDB数据模型的影响执行者：配置管理员l 评估每个修改数据模型请求的影响：l 每个确定的请求都可能需要修改CMDB的政策或者数据模型，例如，当引入了新的基础架构项，就可能需要增加新的CI类型或者增加与新设备的关系l 记录每个请求的设计需求l 把评估结果交给配置管理流程负责人，配置管理流程负责人在变更单中审批对CMDB的变更请求。2.4设计/开发对数据模型的修改执行者：配置管理员l 创建设计。应该注意的问题：l 在整个CMDB数据模型中定位新的CI的类型（层次）l 明确与其他CI的关系l 参照命名规范定义新CI的命名l 定义新CI的标签(Label)l 记录新的设计内容l 开发真正需要的变动2

18、.5创建与维护配置数据结构执行者：配置管理员提示：· 可以通过查询等方式测试新的数据模型是否支持原有的功能，数据是否能抽取到l 创建新的数据模型l 测试新的数据模型ll 已拒绝的请求（记录成文的拒绝的理由）l2.6.3 配置数据控制描述:该步骤的目的是确保只有授权的和可以确认的CI才能记录在CMDB中。应当保障企业的数据、系统和流程的完整性。当一个CI发生变化，这个CI对应的部件将经过一系列的预先定义的状态，例如，“组装中”、“建设中”、“已部署”等。图24.配置数据控制输入:l 已授权的变更请求。这是指计划好的对于配置数据的修改，并且其差异也检查过。如果已授权变更请求成功实施，因其

19、产生的配置变化必须记录在CMDB中。输出:l 对CMDB数据的修改l 已拒绝的请求l 与请求者的沟通信息任务:3.1检查与确定请求3.2验证请求3.3拒绝请求3.4创建/更新CI信息3.1检查与确定请求执行者：配置管理员提示：· 从事件管理流程和变更管理流程转入的修改请求要检验其对CMDB的影响。l 鉴别对于电脑资讯部已授权的变更请求：对生产系统的所有变更都基于变更管理流程授权的RFC。该任务主要是当变更成功实施完成后，确定这些变更请求对配置数据的改动，在CMDB中进行相应的修改。l 如果是预授权的请求，转入任务3.4“创建/更新CI信息”l 鉴别由事件管理流程引发的请求：这些请求来

20、自事件管理流程，主要是当用户报告事件时，发现CMDB中的相关的CI信息与实际情况不符。3.2验证请求执行者：配置管理员l 对于已授权的变更请求和由事件管理流程引发的请求，将验证其完整性、是否符合相关政策。还需要对请求中涉及的配置数据进行检查，例如，参考数据、唯一的CI标识号等。本任务还将确保相关文档的完整性以及CI责任人了解其负责的CI的变更。l 如果验证发现不合要求，则该请求被拒绝，转入任务3.3“拒绝请求”l 如果验证合格，转入任务3.4“创建/更新CI信息”3.3拒绝请求执行者：配置管理员l 拒绝修改CMDB数据的请求l 记录拒绝的原因l 通知请求者3.4创建/更新CI信息执行者：配置管

21、理员l 对于新增的CI，创建新的记录，包括下列内容：l 创建一个唯一的标识号l 记录该CI的属性及（或）与其他CI的关系l 对于已有的CI信息进行更新，包括下列内容：l 更新CI的相关属性及（或）关系l 必要时更新CI的状态（如，从“开发中”改为“测试中”，从“测试中”改为“运行中”，从“运行中”改为“归档”(Archive)等）l 必要时更新CI的责任人2.6.4 配置数据验证和审核描述:本步骤的目的是确保目前使用的CMDB中的CI信息与实际环境中的信息是一致的。可通过自动产生CI清单和/或通过手工/自动进行物理配置审核的方式，来检验CMDB中的数据与电脑资讯部生产环境是否一致，并作出差异调

22、整。图25. 配置数据验证与审核输入:l 在事件管理流程中报告的有差异的CIl 审计或验证请求l 生产环境中的物理检查结果（可能是手工，日后可能是自动工具完成）l CMDB数据输出:l 差异报告l 调整生产系统的RFCl 经过更新的CMDB数据任务:4.1获取所要审核的CI数据4.2判断差异4.3创建差异报告4.4 创建RFC4.5 根据需要更新CMDB4.1获取所要审核的CI数据执行者：配置管理员提示：· 可以利用系统监控工具自动扫描IT环境，得到IT环境中的物理清单。l 要审核的CI数据可以通过自动发现的方式得到，也可通过手工检查的方式得到。4.2判断差异执行者：配置管理员l 比

23、较生产环境的物理清单和CMDB的数据，找出差异l 调查差异产生的原因4.3创建差异报表执行者：配置管理员l 产生一份差异报告l “差异报告”是一份用于展现当前记录在CMDB中的数据与物理清单之间的差异的报表。差异报表可在任务4.5“更新CMDB数据”中作为修改的依据。l 当存在差异的情况比较严重时，通知配置管理流程负责人，由配置管理流程负责人考虑是否需要对流程的推动采取措施。l 确定了差异原因以后：l 如果需要对生产环境进行修正，则转入任务4.4“创建RFC”；l 如果需要调整CMDB的数据，则转入任务4.5“更新CMDB数据”。4.4创建RFC执行者：配置管理员l 如果需要对生产环境进行修正

24、，根据差异报告以及对生产系统进行修正的要求，创建变更请求RFC。4.5更新CMDB的配置数据执行者：配置管理员l 如果需要对CMDB 的配置数据进行修正，根据差异报表以及对CMDB配置数据进行修正的要求，更新CMDB的配置数据。2.6.5 产生配置报表描述:该步骤始于对报表的请求。首先判断所要求的报表是否为现有报表，还是新的报表，需要重新开发。如果是现有的报表和报表的产生对现有操作的影响是很小的，可立即运行。否则，需要等到最近的一次批处理窗口的时间生成。如果所要求的是一份新报表，通常要重新开发并等到最近的一次批处理窗口的时间生成。如果所要求的新报表是要加快速度产生，则当开发完成后立即运行。该步

25、骤终止于报表的分发。此步骤对当前和历史的CI数据定期产生报告/报表，例如CI的状态变化信息。图26. 产生配置报表输入:l 对报表的请求输出:l 各类配置报表任务:6.1分析对于报表的请求6.2确定报表类型6.3创建新报表6.4运行报表6.5创建新的批量报表6.6运行批量报表6.1分析对于报表的请求执行者：配置管理员 l 检查用户提出的报表的请求l 确定是现有报表还是新报表l 确定是否是紧急要求l 对于新报表，定义报表的细节：l 要展现的数据l 打印的时间段l 打印的频率l 分发对象l 报表运行所需的时间（时间长短）6.2确定报表类型执行者：配置管理员l 对于现有报表，确定对现有报表的请求是即

26、时报表还是批量报表，如果是即时报表，转入任务6.4“运行报表”，如果是批量报表，转入任务6.6“运行批量报表”l 对于新报表，设定开发的优先级，如果是即时报表，转入任务6.3“创建新报表”，如果是批量报表，转入任务6.5“创建新的批量报表”l6.3创建新报表执行者：配置管理员l 开发新报表：l 定义报表的表头l 定义展现的数据l 开发计算数据的公式等l 在测试环境中测试报表6.4运行报表执行者：配置管理员l 在生产环境中运行报表l 检查报表是否有错误l 重新开发和重新运行l 将报表分发给指定的使用者6.5创建新的批量报表执行者：配置管理员l 开发新的批量报表：l 定义报表的表头l 定义展现的数

27、据l 开发计算数据的公式等l 在测试环境中测试报表l 定义报表产生的频率l6.6运行批量报表执行者：配置管理员l 于指定的时间在生产环境中运行批量报表l 检查批量报表是否有错误l 重新开发和重新运行l 将报表分发给指定的使用者2.7 角色与职责本章节描述有关人员在参与执行和管理配置管理方案时的角色和责任。以下为配置管理流程中必须具有的角色：2.7.1 配置管理流程负责人配置管理流程负责人作为配置管理流程的责任人，对于整个流程执行的结果负责，并有一定的权力管理流程。这个角色作为与其他服务组的界面（如，业务系统、其他流程小组等），保障配置管理流程与其他服务相互配合，为电脑资讯部的运作提供服务。配置

28、管理流程负责人的主要职责包括：l 对整个流程的执行情况和结果负责l 发布衡量标准和目标，以提高流程的有效性和效率l 鉴别和管理关键的成功因素l 控制并领导流程改进活动l 批准或拒绝违背流程的事例l 定义配置管理团队的角色、职责和义务l 在电脑资讯部强化贯彻执行配置管理流程l 向同级的其他流程负责人以及电脑资讯部管理层汇报流程的状态l 解决跨部门的问题l 审核、抽查配置管理流程的执行情况l 对配置管理流程中投入的成本和投资负责l 作为配置管理流程的代表，与其他部门沟通同时，配置管理流程负责人肩负了一部分配置管理的日常管理工作：l 负责确保配置管理流程的日常顺利运行l 作为CMDB的责任人l 当用

29、户对配置管理流程不满意时，作为用户投诉升级的第一线l 必要时将问题升级或将例外情况报告给管理层l 制定配置管理的信息、标准、步骤、使用的工具和技术的需求l 监控配置管理流程的有效性和效率，提出改进流程的建议l 当配置管理的内容作为某个项目的重要组成部分时，作为协调者参与整理项目需求l 与其他流程负责人、经理沟通协作，制定配置管理流程的年度目标，着重于达到下列目的：n 提高流程的自动化程度以提升信息的完整性、准确性，减少差异率n 加快审核和产生报表的速度，以提高服务质量n 确保对配置管理流程的遵循，适当地为员工培训计划提供信息n 负责检查配置管理员的工作表现n 比较和分析流程的效率，提出改进流程

30、的建议2.7.2 配置管理员配置管理员负责维护配置数据的完整性和准确性，保障提供给运行管理的信息是准确的。配置管理员的主要职责包括：l 根据定义好的逻辑和物理的配置项属性和相互关系，创建配置管理数据库l 负责配置数据的可用性和更新，以及配置数据库中的关系信息，确保这些数据符合电脑资讯部的架构标准l 定期审核配置数据l 确保配置审核出的差异得到修正，配置数据库得到相应的修改l 开发并维护配置管理数据库的自动化机制，包括配置信息的插入、跟踪和删除l 当问题解决过程中需要配置专家时，负责提供配置管理方面的知识l 按照需要使用配置管理的标准、流程和步骤l 当某个项目需要配置管理信息时，作为项目的技术资

31、源提供帮助l 当问题升级/解决、项目开发、服务支持回顾会议等活动需要配置专家时，负责参与和协助l 提供改进流程的建议l 负责设计和开发各种配置管理报表l 产生批量报表和即时报表，并分发给适当的使用者l 按照需要使用配置管理的标准、流程和步骤l 获取配置管理衡量数据，并制成报表l 提供改进流程的建议2.8 重要指标和报表本章节描述配置管理流程的重要指标和报表。2.8.1 配置管理的指标类别指标配置管理质量指标未经授权而修改配置信息的次数错误变更（配置项信息不准确导致变更对象错误）导致事件、问题的数量配置项信息错误导致变更失败的数量未使用的许可证数量审核不匹配的配置项数量变更后配置项的及时更新率2

32、.8.2 配置数据信息报表注：详细的报表设计在另一份交付件报表设计中说明。这类报表可以用手工或者自动的方式产生，存放在可访问的服务器上。以下报表为建议，电脑资讯部应当根据实际的管理要求，选择其中的部分或全部。配置数据信息报表主要包括：l 按照类型(CTI三层分类)统计CI的数量l 按日期段列出所有的修改及其日期l 按照类型统计没有指定负责人的CI的数量l 审核查出的差异的配置项数量l 报告的差异的数量（有自动发现工具以后）使用者：配置管理员频率：部分报表可自动生成，由配置报表管理员创建。其他报表必须是手工统计。以日报、周报、月报、年报的频率生成，也可根据需要生成即时报表。用途：需要管理配置信息

33、或需要这些信息帮助分析的人员均可申请使用这些报表，例如：问题经理、变更受理者、变更经理、配置管理员等。2.8.3 配置状态报表状态报表将对管理范围内的CI状况列出清单，包括它们的版本、状态等信息。状态统计报表包括下列报表：l 状态清单，主要包括CI的唯一标识号和状态（如，“测试中”、“运行中”等）l 审核状态清单，根据CI类型、审核状态分类统计的CI数量使用者：变更管理员、配置管理流程负责人、配置管理员频率：部分报表可自动生成，由配置报表管理员创建。其他报表必须是手工统计。以月报、年报的频率生成。也可根据需要，随时产生。3 政策3.1 常规政策l 电脑资讯部内部应当使用统一的配置管理流程，并且

34、使用标准的文档记录和汇报机制。l 对于受管理的IT部件，将使用唯一的配置管理流程。l 应当设立一个配置管理流程负责人，管理整个流程以及对流程的变更，并且与其他流程联系和协作。l 在电脑资讯部整个组织的参与下，所有在配置管理范围内的部件的信息应当集中管理。这些信息应当在其他流程需要的时候随时可用，如，服务台、问题管理、变更管理。l 如果条件具备，应当采用自动的方式从生产环境中获取配置数据。尽量减少或避免手工采集配置数据，因为在大量数据的情况下，手工采集容易导致错误。l 只有配置管理流程负责人和配置管理员有权修改配置信息。l 所有通过变更管理流程来管理的部件均在配置管理范围之内。l 对配置管理信息

35、的请求可以通过服务请求、信息咨询、事件管理、问题管理或变更管理提出。l 应该定期审核和验证配置项、属性、相互关系等信息。3.2 目标时间政策目标时间政策主要针对配置流程中的关键步骤。目标时间政策定义了流程中关键步骤所应该完成的时间。关键步骤目标时间配置项信息更新3工作日配置项审核22工作日表 2-1. 目标时间政策3.3 升级政策当配置管理过程中发生问题，而且相关层次的人员无法解决，需要通过升级来获得更高层的管理人员的关注和支持。升级可以通过手工或自动的方式。升级的政策仅用于配置管理流程范围内发生的问题（issue）。下列事件可以采用升级政策：主要事件目标时间配置管理流程负责人配置项信息更新3

36、工作日5工作日配置项审核22工作日22工作日表 2-2. 升级政策3.4 审核政策应当定期对配置数据进行审核，建议电脑资讯部每半年进行一次审核活动。注：在系统中设定审核周期或审核时间，一旦达到规定的审核时间，配置项的审核状态自动变为“未审核”。当配置项状态为“未审核”时，须在指定的升级时间（参见“升级政策”）内完成审核。3.5 数据备份和恢复政策应当定期对配置数据库进行备份。可以采用下列备份策略：l 每周进行一次全备份l 每天进行增量备份，从周一到周日，每天使用一盘磁带，下一周重复使用电脑资讯部应根据CMDB改动的频率调整备份策略，例如，如果每个月对CMDB的改动不多，可考虑每周进行增量备份，

37、每月进行一次全备份。4 参考数据4.1 配置项分类配置项CTI分类指配置项的三层分类Category、Type 和Item，这是由高到低的对配置项进行逐层分类的方式。在确定配置项的三层结构时，需要考虑以下几个因素：n 配置项的详细程度三层结构的层次分类直接确定了配置项的详细程度，例如，如CTI分类的最低一层定位到主机，则是将一台主机作为一个配置项；如CTI分类的最低一层定位到CPU、MEM等，则是将一台主机的CPU也作为一个独立的配置项进行管理。n 配置管理的成本配置项定义的过粗，则达不到管理的要求，如果定义的过细，则大大增加管理的成本和负担。n 配置项的检索CTI的定义应当本着方便检索配置项

38、的目的进行设计，尽量把性质相近的配置项归类在一起。CategoryTypeItem业务（BS）业务n/a子业务n/a渠道（CH）渠道n/a子渠道n/a应用（AP）业务交易系统子系统业务支撑系统子系统非业务应用系统子系统逻辑实体（LE）数据库实例n/a数据库n/a应用平台实例n/a中间件实例n/a接口实例n/a存储池n/aLANn/aWANn/a作业n/a证书n/a群集n/a软件（SW）应用软件n/a管理工具n/a开发工具n/a媒体工具n/a通讯工具n/a图文工具n/a网络工具n/a系统工具n/a系统安全n/a硬件（HW）服务器AS400服务器RS6000服务器PC服务器LPAR虚拟机刀箱n/a

39、服务器组件主机柜扩展柜IOPCPU内存硬盘语音卡HA切换卡阵列卡存储磁带库虚拟带库磁带机SAN交换机磁盘阵列SAN交换机端口NAS刻录设备网络设备路由器交换机负载均衡设备KVM租用线路网络终端设备网卡网络设备模块及附件视音频设备布线系统安全设备入侵检测漏洞扫描动态令牌防火墙门禁设备内容安全设备防病毒网关VPN网关安全综合网关机房设施机架电源设备空调设备配套设施机房设备附件媒体设备终端设备PDA笔记本电脑台式机自助服务设备输入输出设备CRTLCD电子公告栏多功能一体机激光打印机喷墨打印机热敏打印机针式打印机扫描仪电视机（屏）DVD播放机扩音器触摸屏设备终端配件内存移动存储硬盘耳机摄像头键盘鼠标模

40、块附件文档（DC）管理文档n/a操作文档n/a合同（CT）服务合同n/a产品购买合同n/a此分类还待IAM确认表 4-1. 配置项的分类4.2 配置项的颗粒度配置项的颗粒度决定了配置管理的详细程度，同时也导致了配置管理的成本。当配置项的颗粒度太粗时，会是配置项的信息产生的使用和参考价值不够大；当配置项的颗粒度太细时，会导致维护配置管理数据库的成本过高。建议采用如下的颗粒度（颗粒度可以随着IT服务管理的工作开展，在未来进行调整）：业务类配置项：业务类配置项主要是对业务进行一个定义，以便在配置管理提供配置项及关系而进行的影响分析中，反映出配置项对业务的影响，因此颗粒度不必过细。建议最多两层，到子业

41、务的颗粒度。例如，一个业务配置项为“产品交易”，另外有三个子业务配置项为“产品销售”、“普通退货”、“特殊退货”，它们是“产品交易”的子业务。建议“产品销售”、“普通退货”、“特殊退货”为目前业务类配置项的最小颗粒度。渠道类配置项：渠道类配置项反映了业务通过哪些渠道来接入到IT服务。与业务类配置项类似，建议渠道类配置项的颗粒度最细到子渠道。目前，产品销售渠道有四个：“店铺下单”、“网上下单”、“电话下单”、“PDA下单”。暂时不细分到子渠道。应用类配置项：应用类配置项是提供的应用服务，一般采用的最小颗粒度为应用模块。例如，一个应用配置项为“信息发布平台”，它包含了多个子应用：“研发中心博客”、

42、“知识管理系统”、“阶段式培训系统”、等等。这些应用模块就是最小的应用类配置项颗粒度。软件类配置项：软件类配置项的最小颗粒度为有独立许可证（License）的软件。硬件类配置项：硬件类配置项，按厂商提供独立保修的硬件实体为最小颗粒度。注意：当发生变更时，如果变更的对象不是CI（例如一个网卡，由于粒度过细，没有作为CI来维护），则有两种方法进行变更与配置信息的关联：（1）往上一层粒度的CI。（此例子，即为网卡所安装的服务器）（2）对应虚拟CI。（或者设置一个虚拟CI，它代表某一类的无须进行管理的CI）虚拟的CI：目的是对于变更的对象不是CI时，可以与虚拟CI关联，而又不必导致维护CI的粒度过细。

43、4.3 配置项的编号规则目前，对于IT资产，CIID由财务部提供的编号。在配置管理的情况下，对于IT资产，仍然保持财务部的编号；对于非IT资产的配置项，则沿用下面的编码规则。建议非IT资产的配置项的CIID，CIID的编号规则：CI的编号由10位字符组成；编号规则建议： CC-nnnnnnnnCC2位字母，第一层CI分类的代码nnnnnnnn8位数字，配置项计数编号例子：一台AS400服务器，它的CI编号为：HW-4.4 配置项状态代码下列状态码表示配置项的生命周期中的不同阶段的状态：状态 描述 已订购 发出配置项订单，进入采购流程 已接收 配置项已购入并存放在媒体库（物理库房，或媒体介质等）

44、中 组装中 配置项（设备）正在组装中 已部署 配置项正在使用中。例如：生产系统中运行。维修中 配置项发生故障，正在维修或等待替换 不可用配置项（设备）处于不正常停机状态 待报废 配置项已提交固定资产报废申请 已转移 配置项已提交固定资产转移申请删除 配置项（文档、实例等）已被删除 建设中 配置项（软件等）正在开发建设当中 出借 配置项（设备）被借用 已处理 配置项（设备）已报废 库存 配置项（设备）正在库存中 退回厂商 配置项（设备）已退回给厂商 可用配置项（文档等）可用 过期配置项（文档、软件等）过期 表 4-2. CI状态 不同状态适用于不同的配置项分类，下表说明了配置项状态与配置项分类的

45、适用关系。 CI分类状态 业务 渠道 应用 逻辑实体 软件 硬件 文档 合同 已订购 YY已接收 YY组装中 Y已部署 YYY维修中 YY不可用 YYY待报废 YY已转移 Y删除 YYYYY建设中 Y出借 YY已处理 YY库存 YY退回厂商 YY可用 YYYY过期 YYY表4-3. CI状态与配置项分类的适用关系下列状态转换表注明了可能的状态转换。这个表后所列的是状态变化的使用场景，以确保在工具客户化时对这些逻辑流向能够有正确的理解。 to from 可用 删除 可用 Y删除 Y表44. CI生产状态代码转换图（业务、渠道） to from 建设中 已部署 维修中 不可用 删除 建设中 Y已部

46、署 YYY维修中 YY不可用 YYY删除 YYY表45. CI生产状态代码转换图（应用） to from 已部署 不可用 删除 已部署 YY不可用 YY删除 Y表46. CI生产状态代码转换图（逻辑实体） to from 已订购 已接收 库存 待报废 已处理 过期 退回厂商 已订购 YYY已接收 YYYY库存 YYYY待报废 Y已处理 过期 Y退回厂商 YYYY表47. CI生产状态代码转换图（软件） to from 已订购 已接收 组装中 已部署 维修中 不可用 待报废 已转移 出借 已处理 库存 退回厂商 已订购 Y 已接收 Y Y Y Y Y Y Y Y 组装中 Y Y Y Y Y Y

47、已部署 Y Y Y Y Y Y Y Y 维修中 Y Y Y Y Y Y Y 不可用Y Y Y Y Y Y Y Y 待报废 Y Y Y Y Y 已转移 Y Y Y Y Y Y 出借 Y Y Y Y Y 已处理 库存 Y Y Y Y Y Y Y 退回厂商 Y 表48. CI生产状态代码转换图（硬件） to from 可用 过期 出借 删除 可用 YYY过期 YY出借 YYY删除 表49. CI生产状态代码转换图（文档） to from 可用 过期 可用 Y过期 Y表410. CI生产状态代码转换图（合同）4.5 审核状态代码审核状态审核状态（英）描述已审核AUDITEDCI完成审核未审核UNAUD

48、ITEDCI尚未完成审核表 4-11.审核状态状态转换已审核未审核已审核当CI达到规定的审核时间时，审核状态自动变为“未审核”未审核完成审核后，配置管理员把CI的审核状态转为“已审核”表 4-12.审核结果审核结果审核状态（英）描述匹配MATCHEDCI成功通过审核不匹配UNMATCHEDCI审核不通过，CI信息与实际不符丢失LOSTCI审核不通过，在实际环境中找不到对应的CI 表 4-13.审核结果4.6 生产状态与审核状态的关系当审核完成后，根据差异情况来决定如何进行调整，并确保审核过程中确认为“不匹配”或“丢失”的CI，要同步更新CI的生产状态。4.7 关联关系配置管理主要是为了问题诊断

49、和变更评估时，能兼顾考虑与某个CI直接连接的CI是否会受影响。因此，配置管理数据库中展现的“CI间的关系”是针对该CI而言，与其相邻并连接的CI项。配置管理数据库的目的并不是要展现整个IT系统的拓扑关系。IBM建议将CI分为物理和逻辑两个层面看待，Hostname（逻辑主机）、操作系统、数据库、应用等都是逻辑层面，而服务器、存储等物理设备属于物理层面。关系逻辑物理包含适用某集群包含多个服务器适用某服务器包含多个网卡运行于适用某应用运行于某个集群上适用数据库实例运行于主机上依赖适用某业务系统依赖中间件适用虚拟磁带库依赖某磁盘阵列连接适用服务器和磁带库适用主机连接路由器双机（并行）适用一个DB Cluster内的两个数据库适用两台机器、网络设备互为备份关联适用某应用与某文档关联某逻辑实体与软件关联适用某系统与某文档关联接入适用某业务从某渠道接入不适用n/a表 4-14. CI项关联关系表注：CI 关系除了表明上述的关系定