《运维服务部门管理流程》由会员分享,可在线阅读,更多相关《运维服务部门管理流程(31页珍藏版)》请在金锄头文库上搜索。
1、运维服务部管理流程说明目录1引言41.1编写目的41.2编写说明42维护理念42.1维护宗旨42.2维护范围42.3响应服务速度53维护保证53.1提供统一接口53.2提供标准化的服务质量53.3服务支持手段64维护类型64.1主动式服务64.1.1维护质量审计64.1.2客户满意度调查64.2被动式服务74.2.1电话及邮件应答服务74.2.2远端服务74.2.3现场服务74.3人性化服务75维护制度85.1值班制和专人维护制85.2服务监督机制85.3客户回访制度85.4故障定义及报告制度85.4.1.1故障级别85.4.1.2支持响应时间95.5节假日服务保障制度96维护管理流程106.
2、1运维组周例会106.1.1说明106.1.2提交文档106.2运维人员周报106.2.1说明106.2.2提交文档106.3规范使用116.4维护审计116.4.1维护过程审计116.4.2软件管理审计126.4.3硬件管理审计126.4.4文档审计127客服流程137.1定期类维护147.1.1每日147.1.1.1工作内容147.1.1.2提交文档157.1.2每周157.1.2.1工作内容157.1.2.2提交文档167.1.3每月177.1.3.1工作内容177.1.3.2提交文档187.1.3.3注意事项187.2不定期类维护187.2.1需求变更197.2.1.1工作流程197.
3、2.1.2提交文档207.2.2割接上线227.2.2.1工作流程227.2.2.2提交文档247.2.3程序优化247.2.3.1工作流程257.2.3.2提交文档257.3故障类维护267.3.1故障处理流程267.3.1.1工作流程277.3.1.2提交文档297.3.1.3故障响应297.3.2HA切换流程297.3.2.1工作流程307.3.2.2提交文档308维护性能指标308.1系统主机部分308.2应用系统部分311 引言1.1 编写目的本文档将指导各地运维组有效、高质的实施服务。包括:维护理念、维护类型、维护制度等。在维护工作未开展之前,需各个运维主管认真阅读本文档,并对运维
4、人员进行必要的培训,使运维人员熟悉维护的流程及相关制度。在维护过程中,运维主管要严格按照此文档的流程组织维护工作,以提高、增强维护质量。在项目维护过程中,运维主管或运维人员若发现流程有缺陷或需要补充的,请及时反馈至公司,确保流程能够及时得到更新,以达到规范性、可操作性。1.2 编写说明本文档的阅读对象包括:l 公司领导l 运维主管l 项目组运维人员2 维护理念2.1 维护宗旨与客户紧密配合,尽公司所能,为客户提供快捷、优质的服务,让客户省心,让客户放心。2.2 维护范围为客户提供热线、现场服务及业务覆盖范围内的服务实施。2.3 响应服务速度在用户工作期间提供服务电话或邮件、现场支持,在系统出现
5、严重故障时提供24小时支持。3 维护保证3.1 提供统一接口驻点维护作为公司服务的对外窗口,为客户提供服务,确保所有客户在工作期间,在任何时候、任何地方、出于任何原因,都可以方便地与维护项目组进行联系,获得满意的服务。3.2 提供标准化的服务质量客户的每次要求,都将在维护记录库建立,并一直被监控,直到问题得到圆满的解决。客户不需要重复同一个问题,也不用担心自己的问题有如石沉大海。每一类问题的处理将建立标准的时限要求,如果超出规定时限,公司会对相关人员做出处理。公司会对维护项目组整个维护工作进行监控和定期考核。 3.3 服务支持手段4 维护类型4.1 主动式服务4.1.1 维护质量审计建议公司额
6、外组建QA组,定期开展质量审计工作,对在用系统进行全面检查并现场分析问题,发现问题及其隐患,及时予以解决。4.1.2 客户满意度调查通过电话、信函、现场、传真、e-mail等方式向客户发放调查问卷,了解客户对公司所开发系统的技术支持情况、系统运行情况等各方面的满意度评价,并对调查结果进行统计分析,对于存在的问题及时寻求处理解决办法,以逐步提高客户满意度。4.2 被动式服务4.2.1 电话及邮件应答服务当客户出现问题或故障后需要寻求帮助,首先可以通过电话或邮件请求支持帮助和指导,及时解决问题或排除故障。4.2.2 远端服务当客户应答服务无法排除故障时,在最终客户授权的前提下,可根据客户方提供的问
7、题现象和故障描述,通过接入客户在用系统来指导客户方技术人员或直接处理系统故障。在登录访问系统前,客户需给出必要的口令。4.2.3 现场服务在维护工作中,电话应答服务及远端服务是解决问题、处理故障的第一步,因为在时效上电话应答及远程服务将明显高于现场服务。但当电话应答服务及远程服务无法解决客户提出的服务请求时,我们将指定运维人员在尽可能短的时间内在现场进行服务,以求问题的最终解决。4.3 人性化服务每个人都喜欢与众不同的东西,这是人的本性。人性化服务就是要尊重以人为本的服务理念,尊重客户个性,尊重客户的习惯,尊重客户的喜好。人性化服务就是要求提供的服务能被客户所接受和喜爱,超出客户的期望值。当与
8、无法满足客户的期望值时,需要进行分析原因并采取纠正措施,给客户一个满意的回复。5 维护制度5.1 值班制和专人维护制运维组人员将设立值班表,每日值班人员将负责系统的日常检查及日常维护。运维人员在接到客户服务请求或问题投诉,无论是否属于自己工作职责范围,都会做出反应,并将问题详细记录下来,及时解决,争取不让客户打第二次电话。5.2 服务监督机制为保证各维护项目组的维护质量,对此工作设定关键绩效指标,每月进行考核,集中进行奖优罚劣,确保维护流程得到有效地执行,从而提高维护质量。5.3 客户回访制度 通过双方建立起良好的关系,增进与客户之间的沟通交流,收集、整理完整准确的客户资料信息,建立起客户档案
9、库,是开展客户关系管理的重要前提,以逐步形成一套完整的客户信息平台。确定客户类型,并针对不同类型的客户,制定相应的回访频次及回访方式。通过电话、现场等方式回访客户,收集在用系统的问题及需求,了解客户对我公司维护工作的意见和建议,以逐步改善我们的软件质量和维护水平。5.4 故障定义及报告制度根据系统维护经验,对系统故障做了明确的故障级别定义并确定相应的故障确诊时限,并采取上报制度,保证给予客户最有效的解决方案。5.4.1.1 故障级别根据故障性质的严重性及对客户造成的影响程度,把故障分为三级:一级故障指非常严重的故障,如系统崩溃,主机瘫痪等,对最终客户有直接影响,系统已不能正常工作。二级故障指次
10、严重的故障,如系统设备不稳定,但在客户的合理使用下可以正常工作;又如系统部分性能存在问题,但不影响系统主要功能操作;以及系统运行效率极低访问速度非常慢等情况。三级故障除以上故障以外的所有故障。包括如:由于某种原因导致应用程序或硬件设备损坏,系统部分功能不能使用,等暂时不影响系统正常运行的情况。5.4.1.2 支持响应时间针对故障的不同级别,响应方式及时间也做进一步的明确:一级故障:在运维组无法解决故障时,公司立即召开技术协调会分析故障原因,如确认远程不能解决故障,立即派工程师以最快的速度,不超过24小时赶到客户现场解决故障。二级故障:在运维组无法解决故障时,公司立即召开技术协调会分析故障原因,
11、采取以下三种措施解决故障:1、 通过电话指导运维组自己解决故障。2、 公司技术小组远程解决故障。3、 工程师到客户现场解决故障。三级故障:通过电话指导运维组自己解决。如客户解决不了的,必须提交书面报告由我方派技术人员到用户现场解决。具体故障上报制度可另出规则。5.5 节假日服务保障制度节假日主要是指国家法定假日,包括元旦、春节、五一、国庆。在节假日期间,系统运行过程中出现问题时能够及时得到技术人员的支持,使在用系统得以正常运行,为客户提供放心周到的服务。6 维护管理流程6.1 运维组周例会6.1.1 说明运维主管组织项目组运维人员在每周一下午14:00召开周例会,讨论处理上周遗留问题及本周需要
12、解决的问题。6.1.2 提交文档序号文档名称命名规则文档说明提交时间/接受人1会议纪要项目名称_会议纪要_年月日每次项目组的会议记录,包括:周例会、小组讨论会每周一下班前/公司维护经理6.2 运维人员周报6.2.1 说明项目运维人员应于每周日晚提交项目Time Sheet给运维主管,总结本周工作。运维主管也应于每周日晚提交项目Time Sheet给维护经理,总结本周维护组工作情况。6.2.2 提交文档序号文档名称文档说明1问题日志提交至运维部门经理,记录本周存在问题2工时记录提交至运维部门经理,记录本周工作情况6.3 规范使用1、 文档规范所有文档都遵循模板,文档中非标题部分全部采用正文格式。
13、2、 会议纪要每次运维组的讨论,需要指定人员进行会议记录,一般在例会后分发给相关人员,最晚不要超过当天。3、 备份项目涉及的代码程序、文档、会议纪要等资料需要由各运维主管统一保管。6.4 维护审计为帮助各运维组在维护工作上能够提高工作质量,将由QA人员不定期对各运维组进行检查及审计。6.4.1 维护过程审计l 运维组审计1、 维护组的大小是否适应系统的规模和要求。2、 维护组中人员的职责分工是否明确。3、 维护组是否有一套科学的内部管理机制和协调工作机制。l 系统总体审计1、 维护过程是否按维护规范进行。2、 运维人员的交替是否按照维护规范进行。3、 是否能把握住系统运行状况达到性能管理及资源
14、的有效利用。4、 是否记录事故及故障内容,并向用户负责人及公司维护经理报告。5、 是否找出事故及故障的原因,并采取措施防止再次发生。6.4.2 软件管理审计l 系统需求变更审计1、 有关系统的任意修改,是否按维护规范进行修改。2、 系统的修改是否按割接计划进行,是否在得到用户负责人的同意后实施。3、 在需求修改前是否对修改内容与影响范围进行了调查与分析,明确了解需求变更后将造成的影响。l 割接上线审计1、 修改程序的测试是否按测试计划进行。2、 修改的程序是否进行了与新开发的程序同等程度的测试。3、 修改程序的测试是否由用户参加。4、 修改程序的测试结果是否得到开发、运行、维护及用户负责人的认可。5、 修改的程序的测试结果是否记录下来,并进行保管。6、 割接前是否向用户提交割接计划,割接后是否向用户反馈割接报告。l 割接上线后系统的运行审计1、 是否对修改前的程序及数据做好了备份。2、 运行负责人是否验证其系统不受影响。3、 运行中若出现问题是否及时恢复到修改前程序,是否对数据进行备份。6.4.3 硬件管理审计1、 是否有