运维服务流程和体系.pptxVIP

Copyright 2012 By Neusoft Group. All rights reserved 运维服务流程和体系 变更历史 版本号 内容 作者 审批者 0.1 起始草稿 目录 业务挑战 运维框架及流程 业务挑战 在信息技术全面深入支撑税收企业实体的同时，IT服务管理遭到了前所未有的挑战： 一，不断提高的可靠性要求 是越来越多的系统相继采取数据集中方式运行，对数据库平台、中间件、广域网络等设施的可靠性要求越来越高，加大了运维风险； 二，应用系统种类繁多 核心业务、行政办公、决策支持、外部接口，商务智能等系统之间既独立又关联，纷繁复杂交织在一起，运维过程中经常出现“牵一发而动全身”的现象，加大了运维难度； 三，不断涌现的业务需求 应用系统相应随之修改，甚至被迫“伤筋动骨”，软件升级次数多、频率高，后台数据维护大量集中在省级税务机关，加大了运维工作量； 四，用户群体十分庞大 IT 服务对象一般都在几千个以上。这些因素也正说明了系统以ITIL（信息技术基础架构库）为标准重建运维体系的时机已经成熟。 五大问题 当前在运维工作中存在着五大问题： 一是认识存在误区 这主要表现为重初始上线轻运行维护以及将运维单纯等同于排除故障； 二是缺少一支配置合理的运维队伍 信息部门的人力资源配置远远不能适应当前运维工作的需要，如运维人员过少、技术部门和业务部门分别设立的运维队伍协调配合不够以及没有形成运维人才梯队； 三是缺乏有效的故障收集渠道 由于没有统一的故障收集平台，当前用户产生运维请求后，一般既不能准确把握其故障类型，又不了解运维部门的职责分工，往往不知所措； 五大问题（续） 四是没有标准的服务操作流程 运维部门在接收服务请求后，既不对突发事件级别进行科学评估，又没有一套严格的服务流程可遵循，很难保证运维质量和效率； 五是没有完善的服务技术平台 这表现在IT服务流程的执行缺乏有效的监督机制、用户满意度调查机制不够完善以及现有的组织架构及服务支持模式无法给技术人员提供足够的发展空间，人才梯队没有形成。 目录 业务挑战 运维框架及流程 运维体系与项目的区别 传统软件开发项目生命周期 运维服务生命周期 需求调研 需求调研 设计 设计 开发 开发 测试 测试 发布 发布 运营 优化 运维体系 ITIL 将 IT 服务管理归纳为十个核心流程和一项管理职能。这十个核心流程分别是 服务级别管理 IT 服务财务管理 能力管理 IT 服务持续性管理 可用性管理、 配置管理 变更管理 发布管理 事件管理 问题管理 一项管理职能是服务台 运维体系 以下提出利用ITIL构建运维体系的基本设想基本设想： 调查服务需求，设计切合实际的服务级别 服务级别是为了实现对服务质量的规划、定义和监控管理，由服务提供者（运维部门）与用户之间签订的量化服务级别协议（简称SLA）或服务承诺。因为它涉及到主机设备、软件、线路、服务、客户端等多个方面，对于建设运维体系的初期，不宜对其设计得过细，质量要求过高。 配置高效的多线运维技术队伍 按照服务级别和层次，配备专业的运维人员。根据运维人员承担的职责和解决问题的级别不同，建立多线运维技术队伍。一般分为五层（根据运维项目可优化，最少为两级）。 一线技术人员负责记录故障报告，根据自身积累的运维经验或通过查找问题库，即时解答用户提出的问题。 二线技术人员负责上门服务，凡一线人员不能直接应用透视解决的运维请求，经评估服务级别后认为需要核实的，由二线技术人员进行现场解决。 三线技术人员分为级别评估人员、问题分析人员、问题解答人员和变更管理人员。 运维体系 四线技术人员由既懂技术又懂业务的复合型人才组成，是高素质的运维人员，负责疑难故障的会诊、提交新的业务需求。 五线技术人员配置在总部，负责将四线技术人员提交的业务需求进行审核和综合后，转交给软件开发商。 搭建运维服务台，全方位接收服务请求 运维服务台是IT 服务部门和用户之间的重要沟通渠道，它提供了一个中心联络点，对外满足所有业务部门用户的需求；对内承担着一线与二线、三线和四线技术人员之间的协调与沟通，并对问题的处理进行有效的跟踪和监控。 规范事件管理，建立完善的突发事件应对机制 一是规范突发事件的监控流程。当各环节的突发事件超过处理时限后，运维服务平台自动将其转交三线的级别评估人员。级别评估人员根据技术人员的工作能力和突发事件的复杂程度决定是否进行 升级处理，重新确定优先级。 二是建立重大突发事件公告制度。在突发事件发生时，把与系统主机和网络设备有关的危急、紧急类突发事件及时在内部网站中的IT服务专栏公告，以让相关用户及时做好应对措施。 四是建立事件跟踪监控制度。 运维体系 三是建立故障报告提交制度。突发事件解决之后，将本次故障发生的时间、地点、性质、原因、影响范围、采取的措施、后续发生的可