SZDB Z 32-2010 信息系统运行维护技术服务规范.pdf

《SZDB Z 32-2010 信息系统运行维护技术服务规范.pdf》由会员分享，可在线阅读，更多相关《SZDB Z 32-2010 信息系统运行维护技术服务规范.pdf（13页珍藏版）》请在麦多课文档分享上搜索。

1、ICS 35.080 L 77 深圳市标准化指导性技术文件 SZDB/Z SZDB/Z 322010 信息系统运行维护技术服务规范 Technical services specification of information system operation and maintenance 2010-12-16发布 2011-01-01实施 深圳市市场监督管理局 发布 PDF 文件使用 pdfFactory Pro 试用版本创建 SZDB/Z 322010 I 目 次 前 言.II 1 范围.1 2 规范性引用文件.1 3 术语和定义.1 4 服务体系结构.1 5 服务工作流模式.4 6 服

2、务组织结构.6 附 录 （资料性附录） 信息系统运行维护技术服务等级参考.8 参考文献.10 PDF 文件使用 pdfFactory Pro 试用版本创建 SZDB/Z 322010 II 前 言 本指导性技术文件由深圳市科技工贸和信息化委员会提出。 本指导性技术文件由深圳市诚信信息工程研究院负责起草、深圳市华威世纪科技股份有限公司参与起草。 本指导性技术文件主要起草人：唐尖兵、周楚生、王幼成、张建良、王昱人、曾云清、杨勤、 陈德元、陈坤源、高晓雷、刘海军、陈武格、喻军、叶志勇、黄伟、于国华、王双飞、杨兹豪、王文震、谢建普、张克建、贺致远、李德和、邓少斌、刘燕青、程燕、郝伟。 其他参与人员：柴

3、海军、陈纯权、逯贵升、曾志明、马中元、李炳烨。PDF 文件使用 pdfFactory Pro 试用版本创建 SZDB/Z 322010 1 信息系统运行维护技术服务规范 1 范围 本规范规定了信息系统运行维护技术服务机构的服务规范，包括服务体系结构、服务工作流模式和服务组织结构。 本规范适用于开展信息系统运行维护技术服务的基本工作规范的要求，供服务需求方（如业主、用户）在选择和评价信息系统运行维护技术服务，以及服务提供方（如系统承建商、设备供应商等有承担信息系统运行维护技术服务的单位）在开展信息系统运行维护技术服务工作过程中参照执行。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。

4、凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 GB/T 24405.1-2009 信息技术服务管理 第1部分：规范 ISO/IEC 20000-2:2005 信息技术服务管理 第2部分：实践规则 3 术语和定义 GB/T 24405.1-2009、ISO/IEC 20000-2:2005中规定的有关术语和定义以及下列术语和定义适用于本规范。 3.1 信息系统运行维护技术服务 本规范中信息系统运行维护技术服务是指在信息系统运行中，由信息系统运行维护技术服务机构提供的保障信息系统正常运行和处理信息系统非正常事件的技术性服务项

5、目。 4 服务体系结构 信息系统运行维护技术服务体系结构由服务支撑要素、服务阶段、服务内容以及服务分系统构成，各部分的组成和相互关系详见图1。 PDF 文件使用 pdfFactory Pro 试用版本创建 SZDB/Z 322010 2 图1 信息系统运行维护技术服务体系结构 4.1 服务支撑要素 服务支撑要素包括五个方面的内容：服务协议、策划与服务细则，服务部门，服务设施，服务人员，服务管理，其中： a) 服务协议是服务关联的各方利用、提供、评价、裁定服务的依据，并构成各方间有法律效力的约束关系； b) 服务协议、策划与服务细则是管理服务工作的指导文件，其中有关服务等级划分可参考本规范资料性

6、附录； c) 服务部门依照服务策划中规定的服务范围、内容和方法等编制服务实施细则，开展具体的服务工作，实现服务目标； d) 服务设施是提供服务的保障条件和实施手段或工具； e) 服务人员是实施并具体实现服务的管理者或执行者； f) 服务管理依据服务协议、策划与服务细则，借助服务设施，籍由服务人员参与，提供服务的调度、协调、监控和评价。 服务部门、服务设施、服务人员和服务管理等内容是开展服务工作的必要基础。 4.2 服务阶段 服务阶段主要包括服务响应、服务策划、服务实施和服务发布四个阶段： a) 服务响应的启动条件是服务请求，包括与服务提供内容相关的应用服务、系统事件、变更（指协议、细则之内规定

7、的变更）和/或配置、维修事件等请求； b) 服务策划是服务实施流程需要的输入； c) 服务实施是按照规范的服务流程完成服务请求并提交发布服务执行情况的报告； d) 服务发布是服务流程的输出。 4.3 服务内容 服务内容可以规范为两大类十一个子项，各部分内容的相互联系详见图2。 服务支撑要素 服务协议、策划与服务细则 服务部门 服务设施 服务人员 服务管理 服务阶段 响应阶段 策划阶段 实施阶段 发布阶段 服务分系统 信息系统设备运维技术服务 应用软件系统运维技术服务 系统软件运维技术服务 建筑智能化系统运维技术服务 信息系统安全运维技术服务 服务内容 持续性管理 级别管理 财务管理 可用性管理

8、 能力管理 事件管理 问题管理 配置管理 变更管理 发布管理 服务台 服务支持 服务提供 PDF 文件使用 pdfFactory Pro 试用版本创建 SZDB/Z 322010 3 图2 信息系统运行维护技术服务内容 4.3.1 服务台 服务台是提供信息系统运行维护技术服务的前台，是为客户提供联系有关技术服务部门的节点，受理客户咨询。同时，服务台也为内部服务请求事件的处理建立相关部门间的联系，是服务综合管理的一个职能部门。 服务台直接与客户请求的事件管理和服务级别管理相关，在配置管理、发布管理、变更管理中起一定的作用。 4.3.2 服务提供 级别管理、可用性管理、能力管理、持续性管理、财务管

9、理等五项直接与技术服务提供关联，是运行范畴的内容，属于服务提供类。 a) 服务级别管理 指为提供服务而进行的会商、定义、评价、管理、改进的涉及质量水平管理的流程。管理的基本内容一般应包括：服务级别协议、营运级别协议、服务支持合同和服务质量计划。 b) 服务可用性管理 “可用性”，指按照服务级别管理的相关协议，提供相应级别服务的有效性和利用率。 服务可用性管理包括：与服务级别协议关联的可用性；与营运级别协议关联的可靠性和可维护性；与支持合同关联的可服务性。可用性管理的质量一般表现为客户的稳定度和满意度。 c) 服务能力管理 指在恰当的时间，以恰当的方式，经济、节约地为服务请求提供所需要的能力的管

10、理流程。能力管理需要顾及恰当成本条件下提供最佳效率的方式；现有能力是否已经发挥到系统的最大效率；服务能力与用户需求的吻合度；能力扩展需求的预期时间和扩展程度等。 d) 服务持续性管理 与意外事件的发生不同，信息系统在“灾害”发生的情况下通常都不可能继续提供服务。服务持续性管理就是预防并尽可能避免灾害发生的管理流程。 e) 服务财务管理 指按照客户需求在服务质量与成本之间进行协调使之达到平衡的管理流程。服务财务管理的目标应该是通过对系统基础设施的成本控制与管理促进高效、合理、经济地使用系统资源。 服务 提供管理 配置管理 变更管理 发布管理 问题管理 事件管理 服务 支持管理 可用性管理 级别管

11、理 持续性管理 财务管理 能力管理 服务台 PDF 文件使用 pdfFactory Pro 试用版本创建 SZDB/Z 322010 4 4.3.3 服务支持 服务支持类与服务的平台和环境要素关联，这些要素与服务的成功提供和服务品质保障相关，是维护范畴的内容，包括：事件管理、问题管理、配置管理、变更管理、发布管理。 a) 事件管理 事件，指系统服务中存在或可能存在的影响服务的因素。事件的发生不属于标准操作，而且往往导致客户不能获得正常、有效的服务。事件管理就是为消除或减少事件发生，和/或事件发生后能尽快处理使客户能在最短时间内恢复需要的服务。 b) 问题管理 事件管理解决了维系客户在事件发生时

12、获得正常、有效服务或尽快回复服务的要求。但事件的根源未必在事件管理流程完成后予以发现并得到处理。问题管理就是调查系统基础设施和所有获得的信息并确定引起事件发生的真正的潜在原因以及服务中可能存在的隐患。 c) 配置管理 配置管理面向系统的基础设施，有两个层次的功能：一是核查并证实系统基础设施所作的变更已经如实、准确地记录在案；二是监控系统中各组成构件的运行状态并保证配置管理数据库准确反映现存基础设施的配置项与实际运行的版本吻合。 d) 变更管理 信息系统的基础设施和应用平台都可能处于不断的调整、更新、变换、增减等变更状态。系统服务也随市场变化而有相应的必要调整和更新。两方面的所有变更都必须准确管

13、理以避免因变更而导致服务不能有效提供甚至失效。变更管理就是管理变更的全过程，以使任何变更都不会导致错误和引发与变更有关的事件。 e) 发布管理 新增的配置项或变更后的配置项通过发布记录下来并在这些配置项经过测试验证后引入实际的运行环境。发布管理关注变更管理的实施结果。 4.4 服务分系统 根据当前信息系统运行维护技术服务的实际情况，对信息系统运行维护技术服务分系统可以规范为五大类：信息系统设备运维技术服务、应用软件系统运维技术服务、系统软件运维技术服务、建筑智能化系统运维技术服务和信息系统安全运维技术服务，其中： a) 信息系统设备运维技术服务是指对计算机系统设备、外围设备、网络设备及其它相关

14、电气设备的运维技术服务； b) 应用软件系统运维技术服务是指对信息系统中的应用软件及中间件的运维技术服务； c) 系统软件运维技术服务是指对信息系统中的操作系统、数据库管理系统的运维技术服务； d) 建筑智能化系统运维技术服务是指对建筑智能化集成系统、信息设施系统、建筑设备管理系统、公共安全系统、机房工程等的运维技术服务； e) 信息系统安全运维技术服务是指对为保障信息系统安全涉及的安全技术（物理安全、网络安全、主机安全、应用安全和数据安全所需的软、硬件安全设备、设施）的运维技术服务。 各分系统定义工作流程时可以参考但不限定按本规范具公用性的模式化结构进行规划，原则上依据各分系统的技术服务特点

15、，以服务内容为流程分划，以服务阶段为时间序，安排适合各分系统的支撑要素，实现协议、策划和细则，规划服务管理的流程。 对于不便按以上方式划分系统类型的信息系统，可根据其特点，综合参考各系统类型的运维技术服务要求执行。 5 服务工作流模式 信息系统运行维护技术服务的工作流模式与服务的体系结构相关，其中服务管理则是服务的基础核心结构。 PDF 文件使用 pdfFactory Pro 试用版本创建 SZDB/Z 322010 5 关于信息系统运行维护技术服务工作流程设计可参考图 3，以尽可能规范工作流程的设计、调度和评价。 图3 通用流程模型 通用流程模型说明了启动及执行规范的服务流程时，需要考虑的外

16、部因素：输入、流程的目标、所需服务资源等外部条件；需要考虑的内部因素：服务活动、子流程和人员的岗位及其相关的责任。即：信息系统运行维护技术服务工作流程是包含流程控制和推动条件的业务流程。 图4是按照通用流程模型规范的外部及内部因素关联工作流程设计模式构建的基本流程架构参考模型，是工作流程设计的通用参考范例。 流程负责人 流程目标服务质量考核指标流程控制输入 输出流程服务活动/ 子流程服务资源 岗位责任流程推动PDF 文件使用 pdfFactory Pro 试用版本创建 SZDB/Z 322010 6 图4 信息系统运行维护技术服务工作流程基本架构参考模型 6 服务组织结构 为实现以流程为导向、

17、客户满意和服务品质为核心的信息系统运行维护技术服务管理，并适应不同服务模式的管理需要，信息系统运行维护技术服务提供方需采取合理、高效的技术服务组织结构。一般情况下，服务组织由服务执行组和服务管理组构成。 信息系统运行维护技术服务组织结构的构成要素应与信息系统运行维护技术服务活动角色相对应，其中，服务管理组对应服务管理者，成员主要由项目经理、各流程管理人员构成；服务执行组对应服务提供者，成员主要由客服人员、技术支持团队构成。 信息系统运行维护技术服务组织结构如图5所示： PDF 文件使用 pdfFactory Pro 试用版本创建 SZDB/Z 322010 7 图5 信息系统运行维护技术服务组

18、织结构 6.1 信息系统运行维护技术服务提供方 综合利用各种信息技术工具提供并确保信息系统设施和应用系统正常、安全、高效、经济运行的服务组织。 6.2 服务总监 负责服务和管理的统一组织、协调、实施及监督整个服务质量的人员。 6.3 服务管理组 负责服务体系的维护与执行监督，及所有服务资源调配的部门。 6.4 服务执行组 负责实施执行已签订的服务内容的部门。 6.5 项目经理 负责实施服务提供的项目管理。 6.6 流程管理人员 为支持信息系统运行维护技术服务的实现和提供，以确定的方式执行或发生的一系列有规律的行动或活动的人员。 6.7 客服人员 接受客户服务请求并协调相应技术人员处理客户服务活

19、动的人员。 6.8 技术支持团队 由不同级别的技术人员组成，为客户提供相应的技术支持及服务。 信息系统运行维护技术服务提供方 服务管理组 服务执行组 项目经理 流程管理人员 客服人员 技术支持团队 服务总监 PDF 文件使用 pdfFactory Pro 试用版本创建 SZDB/Z 322010 8 附 录 （资料性附录） 信息系统运行维护技术服务等级参考 参考行业市场惯例对信息系统运行维护技术服务进行等级划分，根据所提供服务质量要求不同将服务划分为四个等级（详见表 1），用户可根据系统的运维服务内容和服务经费预算选择不同的服务等级，或从不同的服务等级中选择需要的服务指标及进行细化。 表1 信

20、息系统运行维护技术服务等级参考 服务等级 服务指标 一级（白金）服务 二级（金牌）服务 三级（银牌）服务 四级（标准）服务 服务受理时间 724小时 724小时 524小时 58小时 服务响应时间 常驻，即时响应 1小时 4小时 8小时 人员到场时间 常驻，即时到场 2小时 6小时 可下一工作日 上门 故障恢复时间 2小时 4小时 8小时 24小时 现场及远程 支持人员 现场：系统集成或软件开发人员 远程：系统分析、架构设计人员、技术专家 现场：系统集成或软件开发人员 远程：系统分析、架构设计人员 现场：系统专业维修人员 远程：系统集成或软件开发人员 现场：普通维修人员 远程：系统集成或软件开

21、发人员 系统备件 关键部件（现场提供）及备件库 关键部件、备件库 备件库 备件库 巡检周期 每日或每周定期 每月一次 每季度一次 每半年一次 表 1 中将信息系统运行维护技术服务划分为四个等级，级别最高为“一级（白金）服务”，级别最低为“四级（标准）服务”。其中： a) “服务受理时间”指服务台（客服人员）能够受理客户服务请求的工作时间，如“724小时”指1星期（7天）全天候（24小时）均能受理客户服务请求，“58小时”指1星期有5天（5个工作日）的日常工作时间（8小时）能受理客户服务请求； b) “服务响应时间”指服务提供方在该规定的时限内指派了人员通过现场或远程协助的方式，开始着手为客户提

22、供服务，其中“常驻”指服务提供方指派人员在客户方常驻（常驻的方式以满足客户对运维人员能即时到场的需求为准），提供随时响应服务。“8小时”指服务提供方在服务受理之后8小时之内指派了人员响应客户的服务请求； c) “人员到场时间”指服务提供方响应了客户的服务请求后，需要在该规定的时限内指派人员并到达客户现场提供服务，其中“常驻”指服务提供方指派人员在客户方常驻，保证能够即时到达系统现场提供服务，“6小时”指服务提供方在服务响应之后6小时之内指派人员并到达客户现场； d) “故障恢复时间”指服务提供方通过现场或远程协助的方式，在该规定的时限内为用户解决系统故障问题，其中“2小时”指服务提供方应在服务

23、响应之后2小时内完成系统故障PDF 文件使用 pdfFactory Pro 试用版本创建 SZDB/Z 322010 9 修复（对于无法修复的，需根据服务等级要求提供备件服务，以临时保障客户系统的正常使用），其中故障恢复时间为标准参考值，具体的指标（如应用软件的故障恢复）由协议双方根据系统的自身特点进一步商定； e) “现场及远程支持人员”指服务提供方在为客户提供服务时根据服务等级的不同，指派不同资历或技能级别的人员为服务提供现场或远程支持； f) “系统备件”指服务提供方针对在客户现场无法修复的系统故障，通过提供备件服务的方式，以临时保障客户系统的正常使用，其中“关键部件”指服务提供方必须在

24、日常配有特定客户系统所需的关键部件，以便现场随时能够提供备件服务，保障系统的不间断运行；而“备件库”指服务提供方为满足大部分客户的系统需要提供备件服务而预备的备件库，此备件库不一定含包所有特定客户系统所需的关键部件； g) “巡检周期”指服务提供方根据服务协议的具体要求为客户系统提供不同周期的系统巡检，分析系统运行状况并提出改进建议。其中“每日或每周定期”指完全为满足客户系统的需要而设定巡检周期，如“每日”、“每周”等。 该服务等级的划分适用于客户按一定周期（如包年、包季）的形式购买信息系统运行维护技术服务时参考，对于客户按次数购买服务的方式，其单次服务的质量要求亦可参考该服务等级划分。 PDF 文件使用 pdfFactory Pro 试用版本创建 SZDB/Z 322010 10 参考文献 1 中国IT服务管理指南 北京大学出版社 主编：左天祖 副主编:刘伟 2 中国IT服务管理指导规范研究 北京邮电大学出版社 主编：北京神州泰岳软件股份有限公司 _ PDF 文件使用 pdfFactory Pro 试用版本创建