配置管理制度v1Word下载.docx
《配置管理制度v1Word下载.docx》由会员分享,可在线阅读,更多相关《配置管理制度v1Word下载.docx(14页珍藏版)》请在冰点文库上搜索。
1.4流程图 5
1.5流程说明 5
1.6配置库管理规范 7
1.6.1 概述. 7
1.6.1.1 目的 7
1.6.1.2 范围 7
1.6.1.3 术语 8
1.6.1.4角色与职责 错误!
未定义书签。
1.6.2配置管理范围. 8
1.6.3项目配置库建立与使用 8
1.6.3.1项目配置库建立 8
1.6.3.2项目配置库使用 9
1.6.4权限变更. 9
1.6.5配置库安全. 10
1.6.6配置库使用规范. 10
1.6.7配置项命名规则. 11
1.6.8配置库目录结构管理规定 11
1.6.9基线库产品清单 错误!
1.7关键指标 12
1.8支撑文件 12
1.9参考文件 12
1.配置管理
1.1目的
配置管理作为组织IT基础架构的信息中心和控制中心,必须实现以下几个
目的:
>计量组织和服务中所使用的所有IT资产和配置项的价值;
>为其它服务管理流程提供有关IT基础架构配置的准确信息;
>为事件管理、问题管理、变更管理和发布管理的运作提供支持;
>核实有关IT基础架构的配置记录的正确性并纠正发现的错误。
1.2适用范围
本流程适用于公司相关各部门,以及提供运维服务的客户;
1.3角色职责
角色
职责
职能岗位
项目经理
1、 与CCB协商确定项目起始基线里程碑;
2、 接受配置管理计划,并按相关规定贯彻
执行;
3、 接受配置控制委员会的报告。
运维服务部经理
配置控制委
员会
1) 批准、发布配置管理计划;
2) 建立、更改基线的设置,审核变更申请;
3) 根据配置管理员的报告决定相应的对策;
商务部经理
配置管理员
1) 编制配置管理计划;
2) 执行配置项管理方案;
商务部
3) 执行版本控制和变更控制方案;
4) 编制配置状态报告;
1.4流程图
1.5流程说明
活动
描述
责任人
输入
输出
规划配置
公司应确定配置管理的职责(包括配置管理经理和配置管理员),为配置管理的建设和运行进行规划,创建配置管理数据库。
由配置管理经理负责配置管理数据库的创建,包括CMDB的数据结构、CI的命名规范和支持工具。
配置管理经理根据配置项的数据
运维服务
部经理
配置项分类定义表、配置管理记录表
配置管理数
据库
流程图各步骤说明
结构,收集初始的配置数据,将配置数据导入配置库,形成初始的CMDBo
维护配置
鉴别授权的变更请求。
对变更管理流程授权的RFC成功实施完成后,确定这些变更请求对配置数据的改动。
鉴别由事件管理流程引发的请
求。
这些请求来自事件管理流程,主要是当用户报告事件时,发现CMDB中的相关的CI信息与实际情况不符。
对于授权的变更请求和由事件管理流程引发的请求,将验证其完整性;
对请求中涉及的配置数据进行检查。
如果验证发现不合要求,则该请求被拒绝。
记录拒绝的原因,并通知请求者。
如验证符合要求,则创建/更新CI信息,完成对CMDB数据的修改。
对CMDB数据的任何修改情况都应记录在“CMDB维护记录表”中。
配置变更申
请单
审核配置
配置管理应定期组织配置审核,比较CMDB中的CI数据和实际环境的物理信息,识别差异,并形成配置审核记录/报告。
配置管理应调查差异产生的原因,结果应纳入配置审核记录/报告,必要时安排适当的措施,
配置变更审
核单
避免类似的情况再次发生。
差异调整
配置管理对审核出的差异进行调查,确定哪一方的数据真实反映了CI的状态。
联系CI的责任人,并且提供使得CMDB中的数据与现实环境一致的修改方法。
一旦确定了修改方法,就需要修改CMDB或者现实环境。
如果需要修改现实环境,则在必要时提出变更请求,进入变更管理流程。
如果要修改CMDB,应准备好正确的CI数据,转入“维护配置数据”。
调整配置数
据库记录单
1.6配置库管理规范
1.6.1概述
1.6.1.1 目的
为了保证运维项目文件的安全性、机密性;
保证服务整体的完整性、有效性及可追溯性,以及加强项目的协同能力,特制订本制度。
1.6.1.2 范围
适用于公司所有运维管理项目o
术语
基线
是指最初根据在用户现场经过调研所获取的,需要进行开展运维工作的服务标的物
基线库
(baselib)
将前期调研获取的运维服务工作标的物,制作的配置数据库作为运维服务的基线库。
。
1.6.2配置管理范围
运维服务项目过程中产生的所有文档,包括:
项目管理文档、设计及技术文档、服务过程文档,工具及相关资料等。
♦项目管理文档主要:
项目合同、项目工作计划、会议沟通记录及项目过程中管理类文档等。
♦设计及技术文档主要:
需求,需求分析报告、优化设计方案、测试文档、使用说明书、技术说明书等。
♦工具及其相关资料:
运维工作过程中的工具,以及其使用文档等,如觉得有必要也纳入配置库的管理。
1.6.3项目配置库建立与使用
1.6.3.1项目配置库建立
1. 项目立项时,由项目经理申请建立项目配置库
2. 配置管理员与项目经理根据《配置管理的流程》确定《配置管理计划》。
3. 配置项:
项目经理与配置管理员共同确认运维项目的配置库目录结构,并建立配置库目录结构;
所建配置库目录结构必需按本文规定目录结构执行(目录结构参考附录二)。
4. 项目小组:
项目经理提供项目小组成员名单及联系方式,配置库权限清单
(内容应包括员工姓名、目录权限等)
5. 权限分配:
配置管理员为相关人员的设置配置权限。
配置库权限设置完成之后,由配置管理员将配置库名称、访问路径、访问权限等信息以邮件方式通知各相关人员;
配置库使用人员以各自的用户名和密码进行访问配置库。
6.配置库密码只能在服务器上设置,如配置库使用人员密码遗忘或需要修改,可以与配置管理员取得联系,进行修改密码。
1.6.3.2项目配置库使用
1、 配置库目录说明
配置库基本结构所示,以项目名称作为一级目录,二级目录包括:
devlib、testlib、PMlib>
baselib:
“devlib”:
项目小组日常活动区;
该目录包含docs(设计文档)目录。
“PMlib”:
放项目管理文档,为项目管理部门和项目经理使用;
“testlib”:
项目小组在此目录下记录项目测试中的文档。
“baselib”:
仅放置PLM发布版本,项目经理具有读权限;
运维人员在该目录下不允许对基线文件进行修改。
2、 配置库使用说明
a) 项目运维组在“devlib”进行日常运维活动。
b) 项目经理在“PMlib”中记录项目管理文档。
c) 项目进行到中试测试阶段,由项目经理通过“branch/tag”(中文为:
“分支/标记”)的方式,将“devlib”在“testlib/测试版本”中建立版本分支。
再由项目管理员从此库中“导出”,并根据PLM入库相关的规定,通过PLM相关流程进行中试测试。
中试测试过程中产生的文档记录在"
testlib”相关目录中。
d) 测试合格,在进行对项目发布前,将“testlib/测试版本”中建立的版本分支在“baselib”建立发布版本分支。
1.6.4权限变更
使用配置库的过程中需要变更配置库管理权限,由项目经理填写《配置库权限变更单》,并以邮件方式通知配置管理员,配置管理员变更之后,将变更结果以电子邮件方式通知受影响的人员、项目经理及其相关人员。
配置管理员根据配置库权限变更频率,每隔一段时间将配置库权限清单与各项目经理进行审核确认。
1.6.5配置库安全
>配置服务器系统安全:
配置管理员进行服务器的日常管理与维护,做好防入侵、防病毒工作。
>配置库备份:
配置管理员定期做好配置库的备份,以防意外,避免给公司带来严重的损失。
配置管理员每日进行硬盘备份一次,每周进行异地硬盘备份一次,每月进行光盘备份一次,备份后的光盘标记上备份日期并附上内容清单,移交公司相关部门保管。
1.6.6配置库使用规范
1、 各项目必需使用运维服务部提供的配置管理环境建立配置管理库。
2、 配置管理员由商务部任命,运维服务部负责进行配置管理的管理工作。
3、 所有立项的科研项目,都必须申请建立配置库。
服务过程中所有文档和代码必须纳入配置库管理。
4、 配置库服务器密码只有配置管理员及运维服务部领导掌握。
5、 各配置库的使用人员必须使用各自的用户名和密码进入配置库,访问各自的配置库。
各使用人员不得将自己的用户名和密码泄漏给其他人员,若因泄露密码而引起的后果将由泄漏密码者本人承担。
6、 项目组成员未经项目经理同意不得更改他人的文档和代码。
各项目的配置库用于项目组正式运维使用,项目组成员不得恶意对其进行修改、删除、增加等操作;
若因对配置工具不熟悉,需要学习,可以向配置管理员提出需求,由配置管理员为其提供可以练习的配置库。
7、 配置管理员负责定期检查配置库的使用情况,查看是否有员工进行无故删除或恶意修改文件的行为;
并对运维人员提交的文档的及时性、准确性和完整性进行检查。
8、在人员离职时,由其项目经理负责检查配置库,检查该人员提交的文档是否完全放入配置库管理,确认版本和相应文件完整无误后,项目经理在“员工离职申请单”中签字,该员工方可离职。
同时项目经理应及时通知配置管理员,取消该人员的所有权限。
若因项目经理审核不细致造成的文档移交不完整,或项目经理未及时通知配置管理员取消权限,而造成的损失,该责任完全由项目经理承担。
1.6.7配置项命名规则
配置项目命名基本要求:
唯一性;
可追溯性。
1. 项目名称命名规范:
要求项目名称不能太长,且必须要求使用该项目的英文缩写命名。
项目名称中最好不出现空格,若有空格,在建立配置库时,配置库名中将以来代替空格。
2. 配置库命名
配置库主要为基线库。
项目的基线库有多个,可以在其下建立各版本的基线库,子基线库命名规则为:
项目名称缩写+版本号
若一个项目的库有多个,可以在其下建立各版本的库,子库的命名规则为:
项目名称缩写+版本号+子库编号
3. 技术文档命名:
技术文档的标识体现在相应文件的封面上,规范如下:
文档名称+版本,由运维人员参照相应文档模板的格式要求,对技术文档进行标识。
L6.8配置库目录结构管理规定
每一个项目的配置库可分为devlib(基线库)、testlib(测试库)、PMlib
(ProjectManagementLib项目管理库)和baselib(基线库或产品库);
基线库只有配置管理员有操作权限,其他人员只有读权限。
每个项目的都按如下表目录规则规划,其中devlib、testlib、PMlib、
baselib、docs、src目录为必选项,其它目录可以根据实际情况增减:
1.7关键指标
配置项记录出现错误的比率:
配置项记录对运维服务工作开展起到重要的指导作用,所以配置项的错误可能导致工作方向出现错误,无法高效及时的开展项目工作。
配置项记录出现错误的比率=记录出现错误的配置项数量/所属类别配置项的数量x100%
新增配置项的比率:
随着项目的不断深入和运维服务工作的持续开展,配置库中所记录的配置项也可能在此期间逐步的增加,因此,统计不同类别配置项的更新情况有助于有效推进后续工作开展。
新增配置项的比率=新增配置项的数量/配置项数量(类别)X100%
修改配置项的比率:
运维工作开展过程中,在用户维护服务标的物发生变化时,需要对配置项进行一定的修改,修改的具体内容需要在配置库中进行相应的调整,以符合实际需求。
修改配置项的比率=修改配置项的数量/配置项数量(类别)x100%
1.8支撑文件
《配置管理》
《配置管理数据库》
1.9参考文件
GB/T28827.1-2012《信息技术服务运行维护第1部分:
通用要求》
GB/T29264-2012《信息技术服务分类与代码》
《信息技术服务运行维护服务能力成熟度模型》