《运维服务部门管理流程图》由会员分享，可在线阅读，更多相关《运维服务部门管理流程图（32页珍藏版）》请在金锄头文库上搜索。
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.1运维组周
2、例会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.2.1.2提交文档
3、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 响应服务速度在用户工作期间提供服务或、现场支持，在系统出现严重故障时提供24小时支持。3 维
5、护保证3.1 提供统一接口驻点维护作为公司服务的对外窗口，为客户提供服务，确保所有客户在工作期间，在任何时候、任何地方、出于任何原因，都可以方便地与维护项目组进行联系，获得满意的服务。3.2 提供标准化的服务质量客户的每次要求，都将在维护记录库建立，并一直被监控，直到问题得到圆满的解决。客户不需要重复同一个问题，也不用担心自己的问题有如石沉大海。每一类问题的处理将建立标准的时限要求，如果超出规定时限，公司会对相关人员做出处理。公司会对维护项目组整个维护工作进行监控和定期考核。 3.3 服务支持手段4 维护类型4.1 主动式服务4.1.1 维护质量审计建议公司额外组建QA组，定期开展质量审计工作
6、，对在用系统进行全面检查并现场分析问题，发现问题及其隐患，及时予以解决。4.1.2 客户满意度调查通过、信函、现场、传真、等方式向客户发放调查问卷，了解客户对公司所开发系统的技术支持情况、系统运行情况等各方面的满意度评价，并对调查结果进行统计分析，对于存在的问题及时寻求处理解决办法，以逐步提高客户满意度。4.2 被动式服务4.2.1 及应答服务当客户出现问题或故障后需要寻求帮助,首先可以通过或请求支持帮助和指导，及时解决问题或排除故障。4.2.2 远端服务当客户应答服务无法排除故障时，在最终客户授权的前提下，可根据客户方提供的问题现象和故障描述，通过接入客户在用系统来指导客户方技术人员或直接处
7、理系统故障。在登录访问系统前，客户需给出必要的口令。4.2.3 现场服务在维护工作中，应答服务及远端服务是解决问题、处理故障的第一步，因为在时效上应答及远程服务将明显高于现场服务。但当应答服务及远程服务无法解决客户提出的服务请求时，我们将指定运维人员在尽可能短的时间在现场进行服务，以求问题的最终解决。4.3 人性化服务每个人都喜欢与众不同的东西，这是人的本性。人性化服务就是要尊重以人为本的服务理念，尊重客户个性，尊重客户的习惯，尊重客户的喜好。人性化服务就是要求提供的服务能被客户所接受和喜爱，超出客户的期望值。当与无法满足客户的期望值时，需要进行分析原因并采取纠正措施，给客户一个满意的回复。5
8、 维护制度5.1 值班制和专人维护制运维组人员将设立值班表，每日值班人员将负责系统的日常检查及日常维护。运维人员在接到客户服务请求或问题投诉，无论是否属于自己工作职责围，都会做出反应，并将问题详细记录下来，及时解决，争取不让客户打第二次。5.2 服务监督机制为保证各维护项目组的维护质量，对此工作设定关键绩效指标，每月进行考核，集中进行奖优罚劣，确保维护流程得到有效地执行，从而提高维护质量。5.3 客户回访制度 通过双方建立起良好的关系，增进与客户之间的沟通交流，收集、整理完整准确的客户资料信息，建立起客户档案库，是开展客户关系管理的重要前提，以逐步形成一套完整的客户信息平台。确定客户类型，并针
9、对不同类型的客户，制定相应的回访频次及回访方式。通过、现场等方式回访客户，收集在用系统的问题及需求，了解客户对我公司维护工作的意见和建议，以逐步改善我们的软件质量和维护水平。5.4 故障定义及报告制度根据系统维护经验，对系统故障做了明确的故障级别定义并确定相应的故障确诊时限，并采取上报制度，保证给予客户最有效的解决方案。5.4.1.1 故障级别根据故障性质的严重性及对客户造成的影响程度，把故障分为三级：一级故障指非常严重的故障，如系统崩溃，主机瘫痪等，对最终客户有直接影响，系统已不能正常工作。二级故障指次严重的故障，如系统设备不稳定，但在客户的合理使用下可以正常工作；又如系统部分性能存在问题，
10、但不影响系统主要功能操作；以及系统运行效率极低访问速度非常慢等情况。三级故障除以上故障以外的所有故障。包括如：由于某种原因导致应用程序或硬件设备损坏，系统部分功能不能使用，等暂时不影响系统正常运行的情况。5.4.1.2 支持响应时间针对故障的不同级别，响应方式及时间也做进一步的明确：一级故障：在运维组无法解决故障时，公司立即召开技术协调会分析故障原因，如确认远程不能解决故障，立即派工程师以最快的速度，不超过24小时赶到客户现场解决故障。二级故障：在运维组无法解决故障时，公司立即召开技术协调会分析故障原因，采取以下三种措施解决故障：1、 通过指导运维组自己解决故障。2、 公司技术小组远程解决故障
11、。3、 工程师到客户现场解决故障。三级故障：通过指导运维组自己解决。如客户解决不了的，必须提交书面报告由我方派技术人员到用户现场解决。具体故障上报制度可另出规则。5.5 节假日服务保障制度节假日主要是指国家法定假日，包括元旦、春节、五一、国庆。在节假日期间，系统运行过程中出现问题时能够及时得到技术人员的支持，使在用系统得以正常运行，为客户提供放心周到的服务。6 维护管理流程6.1 运维组周例会6.1.1 说明运维主管组织项目组运维人员在每周一下午14:00召开周例会，讨论处理上周遗留问题及本周需要解决的问题。6.1.2 提交文档序号文档名称命名规则文档说明提交时间/接受人1会议纪要项目名称_会
12、议纪要_年月日每次项目组的会议记录，包括：周例会、小组讨论会每周一下班前/公司维护经理6.2 运维人员周报6.2.1 说明项目运维人员应于每周日晚提交项目Time Sheet给运维主管，总结本周工作。运维主管也应于每周日晚提交项目Time Sheet给维护经理，总结本周维护组工作情况。6.2.2 提交文档序号文档名称文档说明1问题日志提交至运维部门经理，记录本周存在问题2工时记录提交至运维部门经理，记录本周工作情况6.3 规使用1、 文档规所有文档都遵循模板，文档中非标题部分全部采用正文格式。2、 会议纪要每次运维组的讨论，需要指定人员进行会议记录，一般在例会后分发给相关人员，最晚不要超过当天
13、。3、 备份项目涉及的代码程序、文档、会议纪要等资料需要由各运维主管统一保管。6.4 维护审计为帮助各运维组在维护工作上能够提高工作质量，将由QA人员不定期对各运维组进行检查及审计。6.4.1 维护过程审计l 运维组审计1、 维护组的大小是否适应系统的规模和要求。2、 维护组中人员的职责分工是否明确。3、 维护组是否有一套科学的部管理机制和协调工作机制。l 系统总体审计1、 维护过程是否按维护规进行。2、 运维人员的交替是否按照维护规进行。3、 是否能把握住系统运行状况达到性能管理及资源的有效利用。4、 是否记录事故及故障容，并向用户负责人及公司维护经理报告。5、 是否找出事故及故障的原因，并
14、采取措施防止再次发生。6.4.2 软件管理审计l 系统需求变更审计1、 有关系统的任意修改，是否按维护规进行修改。2、 系统的修改是否按割接计划进行，是否在得到用户负责人的同意后实施。3、 在需求修改前是否对修改容与影响围进行了调查与分析，明确了解需求变更后将造成的影响。l 割接上线审计1、 修改程序的测试是否按测试计划进行。2、 修改的程序是否进行了与新开发的程序同等程度的测试。3、 修改程序的测试是否由用户参加。4、 修改程序的测试结果是否得到开发、运行、维护及用户负责人的认可。5、 修改的程序的测试结果是否记录下来，并进行保管。6、 割接前是否向用户提交割接计划，割接后是否向用户反馈割接报告。l 割接上线后系统的运行审计1、 是否对修改前的程序及数据做好了备份。2、 运行负责人是否验证其系统不受影响。3、 运行中若出现问题是否及时恢复到修改前程序，是否对数据进行备份。6.4.3 硬件管理审计1、 是否有硬件的故障对策。2、 是否对硬件的利用状况进行记录，并定期进行分析。6.4.4 文档审计l 文档编制的审
