Version 1.1 by superadmin on 2024/06/17, 12:03
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | [[返回本章节索引>>url:https://itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E7%AE%A1%E7%90%86%E8%A7%84%E8%8C%83/]] 阅读下一篇 | ||
2 | |||
3 | |||
4 | === **1 概述** === | ||
5 | |||
6 | |||
7 | 本管理制度对《配置流程管理办法》中有关配置项的管理等相关内容进行详细说明,并用于指导技术部配置数据库CMDB的使用和维护。 | ||
8 | |||
9 | |||
10 | === **2 配置项的识别和定义** === | ||
11 | |||
12 | |||
13 | 配置流程负责人负责组织相关部门识别配置项的范围,制订配置项的命名和管理规范,确定用于构建、发布、验证、安装、分发、维护、恢复、移除配置项的硬件、软件及相关文档。 | ||
14 | |||
15 | |||
16 | ===== **2.1 配置项的范围** ===== | ||
17 | |||
18 | |||
19 | 纳入有限公司信息技术服务管理范围的配置项包括: | ||
20 | |||
21 | |||
22 | 1. 信息系统和软件(包含第三方软件)的发布,相关系统文档,例如要求规范、设计、测试报告、发布文档; | ||
23 | 1. 为每个应用环境配置基线、或描述应用环境、标准硬件组成和发布; | ||
24 | 1. 最终软件库(DSL)/最终硬件库(DHL); | ||
25 | 1. 配置管理包或工具; | ||
26 | 1. 许可证; | ||
27 | 1. 安全组件,例如防火墙; | ||
28 | 1. 服务相关文档,例如服务级别协议、程序; | ||
29 | 1. 服务支持设施,例如机房电源; | ||
30 | |||
31 | |||
32 | ===== **2.2 配置项的属性** ===== | ||
33 | |||
34 | 各配置项的属性,尤其是高风险或关键性配置项的属性。 | ||
35 | |||
36 | |||
37 | ===== **2.3 配置项的生命周期** ===== | ||
38 | |||
39 | 配置项状态用于标识配置项管理的生命周期,配置项目的状态如下: | ||
40 | |||
41 | |**状态**|**定义** | ||
42 | |试运行|配置项在试运行中 | ||
43 | |库存中|配置项属于库存设备 | ||
44 | |测试中|配置项在测试环境正在开发或测试中 | ||
45 | |生产中|配置项在生产环境中处于正常运行状态 | ||
46 | |维护中|配置项正处于维护状态或在返修过程中 | ||
47 | |外借|设备被借给其他单位使用 | ||
48 | |报废|配置项已报废 | ||
49 | |||
50 | ===== **2.4 配置管理数据库设计要求** ===== | ||
51 | |||
52 | 公司配置管理数据库(CMDB)的设计应考虑以下方面: | ||
53 | |||
54 | 1.配置项层次的设计: | ||
55 | |||
56 | 配置项范围的确定应以满足运维工作对于信息的要求为基准,在此基准上尽量不要扩大,一旦配置项范围过大或者深度过深,会增加后期CDMB维护工作量和维护成本。 | ||
57 | |||
58 | 此外,配置项分层中应便于从管理角度和日常工作角度进行统计和查询,同时配置项应可以被有效的分组,同时层级不能过于复杂。 | ||
59 | |||
60 | 2.配置项搜索代码命名规则 | ||
61 | |||
62 | 每个配置项的搜索代码将作为配置项的在CMDB中的唯一标识,是配置项查询和检索的依据,同一CDMB内的配置项需要遵从统一的配置项命名规则。 | ||
63 | |||
64 | 配置项搜索代码设计重点要考虑配置项搜索代码的唯一性和逻辑性,搜索代码首先体现要处配置项层次设计(层次一般以简称形式体现),其次要体现出配置项基本含义。 | ||
65 | |||
66 | 基于以上原则,配置项的搜索代码如下:XX-YYY-CODE-MMMMMM | ||
67 | |||
68 | XX代表被管理的配置项第一层,YYY代表配置项第二层,CODE代表配置项所属地区或部门代码,MMMMMM是配置项基本含义描述。 | ||
69 | |||
70 | XX,YYY字段一般为大写英文字母,CODE字段为大写英文字母或者数字,MMMMMM字段为数字、大写英文字母和连接符,同时MMMMMM在同一类配置项中应该保持唯一。 | ||
71 | |||
72 | 例如:某小型机的命名为SRV-PC-01-UX-12345。其中,SRV代表第一层配置项分类(XX);PC代表第二层配置项分类(YYY);01代表配置项所属地区代码(CODE);UX-12345代表配置项基本含义(MMMMMM),其中UX代表小型机类型, 12345代表小型机编号,中间用连接符连接。 | ||
73 | |||
74 | 3.配置项之间关系 | ||
75 | |||
76 | 配置项层次设计和命名规则确定后,根据实际情况确定配置项之间关联关系和关联类型,并形成配置项关系说明表格。 | ||
77 | |||
78 | 4.配置项属性确定 | ||
79 | |||
80 | CMDB总体框架确定后,需要结合实际工作情况,确定每类配置项的具体属性。配置项属性应体现出运维工作对于配置项关心的重点内容,并尽量减少冗余信息,从而保证CMDB便于维护和管理。 | ||
81 | |||
82 | |||
83 | === **3 配置项的控制和维护** === | ||
84 | |||
85 | |||
86 | 配置经理在配置管理过程中负责监控配置项的整个生命周期,确保只有被授权且可识别的配置项才被接受。 | ||
87 | |||
88 | |||
89 | === **4 配置状态验证和审计** === | ||
90 | |||
91 | |||
92 | 配置经理应定期组织相关部门实施配置项及配置项之间关系的检查审计活动。检查审计活动也可由以下事件触发: | ||
93 | |||
94 | 1. 重大变更前后; | ||
95 | 1. 灾难恢复后; | ||
96 | 1. 发现未授权的配置项后; | ||
97 | 1. 其它需要进行检查审计的场景; | ||
98 | 1. 对于检查审计过程中出现的缺陷或不符合项应记录在配置检查审计报告中,并落实相应的改进计划。 | ||
99 | |||
100 | |||
101 | === **5 附则** === | ||
102 | |||
103 | |||
104 | 1. 本管理制度由技术部负责组织制定、解释和修改。 | ||
105 | 1. 本管理制度自印发之日起实行。 | ||
106 | 1. 相关文件: | ||
107 | |||
108 | 《信息技术服务管理手册》 | ||
109 | |||
110 | 《信息技术服务管理策略》 | ||
111 | |||
112 | 《配置流程管理办法》 | ||
113 | |||
114 | 《服务报告流程管理办法》 | ||
115 | |||
116 | 《记录控制管理规定》 | ||
117 | |||
118 |