运维服务部门管理流程

1、运维服务部管理流程说明目录1 引言 错误 ! 未定义书签。编写目的错误!未定义书签。编写说明错误!未定义书签。2 维护理念错误 ! 未定义书签。维护宗旨错误!未定义书签。维护范围错误!未定义书签。响应服务速度 错误!未定义书签。3 维护保证 错误 ! 未定义书签。提供统一接口错误!未定义书签。提供标准化的服务质量错误 !未定义书签。服务支持手段错误!未定义书签。4 维护类型错误 ! 未定义书签。主动式服务 错误 !未定义书签。维护质量审计错误!未定义书签。客户满意度调查错误!未定义书签。被动式服务错误!未定义书签。电话及邮件应答服务 错误 ! 未定义书签。远端服务错误!未定义书签。现场服务错误

2、!未定义书签。人性化服务错误!未定义书签。5 维护制度 错误 ! 未定义书签。值班制和专人维护制错误! 未定义书签。服务监督机制错误!未定义书签。客户回访制度错误!未定义书签。故障定义及报告制度错误! 未定义书签。故障级别 错误 !未定义书签。支持响应时间 错误!未定义书签。节假日服务保障制度 错误 ! 未定义书签。6 维护管理流程错误! 未定义书签。运维组周例会 错误!未定义书签。说明 错误 !未定义书签。提交文档 错误 !未定义书签。运维人员周报 错误!未定义书签。说明 错误 !未定义书签。提交文档错误!未定义书签。规范使用错误!未定义书签。维护审计错误!未定义书签。维护过程审计错误!未定

3、义书签。软件管理审计错误!未定义书签。硬件管理审计错误!未定义书签。文档审计错误!未定义书签。7 客服流程错误 ! 未定义书签。定期类维护错误!未定义书签。每日错误!未定义书签。工作内容错误!未定义书签。提交文档错误!未定义书签。每周错误!未定义书签。工作内容错误!未定义书签。提交文档错误!未定义书签。每月错误!未定义书签。工作内容错误!未定义书签。提交文档错误!未定义书签。注意事项错误!未定义书签。不定期类维护错误!未定义书签。需求变更错误!未定义书签。工作流程错误!未定义书签。提交文档错误!未定义书签。割接上线错误!未定义书签。工作流程错误!未定义书签。提交文档错误!未定义书签。程序优化错

4、误!未定义书签。工作流程错误!未定义书签。提交文档错误!未定义书签。故障类维护错误!未定义书签。故障处理流程错误!未定义书签。工作流程错误!未定义书签。提交文档错误!未定义书签。故障响应错误!未定义书签。HA切换流程错误！未定义书签。工作流程错误!未定义书签。提交文档错误！未定义书签。8 维护性能指标 错误！ 未定义书签。系统主机部分错误！未定义书签。应用系统部分错误！未定义书签。引言编写目的本文档将指导各地运维组有效、高质的实施服务。包括：维护理念、维护类型、维护制度等。在维护工作未开展之前，需各个运维主管认真阅读本文档，并对运维人员进行必要的培训，使运维人员熟悉维护的流程及相关制度。在维护

5、过程中，运维主管要严格按照此文档的流程组织维护工作，以提高、增强维护质量。在项目维护过程中，运维主管或运维人员若发现流程有缺陷或需要补充的，请及时反馈至公司，确保流程能够及时得到更新，以达到规范性、可操作性。编写说明本文档的阅读对象包括：公司领导运维主管项目组运维人员维护理念维护宗旨与客户紧密配合，尽公司所能，为客户提供快捷、优质的服务，让客户省心，让客户放心。维护范围为客户提供热线、现场服务及业务覆盖范围内的服务实施。响应服务速度在用户工作期间提供服务电话或邮件、现场支持，在系统出现严重故障时提供24小时支持。维护保证提供统一接口驻点维护作为公司服务的对外窗口，为客户提供服务，确保所有客户在

6、工作期间，在任何时候、任何地方、出于任何原因，都可以方便地与维护项目组进行联系，获得满意的服务。提供标准化的服务质量客户的每次要求，都将在维护记录库建立，并一直被监控，直到问题得到圆满的解决。客户不需要重复同一个问题，也不用担心自己的问题有如石沉大海。每一类问题的处理将建立标准的时限要求，如果超出规定时限，公司会对相关人员做出处理。公司会对维护项目组整个维护工作进行监控和定期考核。服务支持手段运雄护维护类型主动式服务维护质量审计建议公司额外组建 QA组，定期开展质量审计工作，对在用系统进行全面检查并现场分析 问题，发现问题及其隐患，及时予以解决。客户满意度调查通过电话、信函、现场、传真、e-m

7、ail等方式向客户发放调查问卷，了解客户对公司所开发系统的技术支持情况、系统运行情况等各方面的满意度评价，并对调查结果进行统计分 析，对于存在的问题及时寻求处理解决办法，以逐步提高客户满意度。被动式服务电话及邮件应答服务当客户出现问题或故障后需要寻求帮助 ,首先可以通过电话或邮件请求支持帮助和指导， 及时解决问题或排除故障。远端服务当客户应答服务无法排除故障时，在最终客户授权的前提下，可根据客户方提供的问题现象和故障描述，通过接入客户在用系统来指导客户方技术人员或直接处理系统故障。在登录访问系统前，客户需给出必要的口令。现场服务在维护工作中，电话应答服务及远端服务是解决问题、处理故障的第一步，

8、因为在时效上电话应答及远程服务将明显高于现场服务。但当电话应答服务及远程服务无法解决客户提出的服务请求时，我们将指定运维人员在尽可能短的时间内在现场进行服务，以求问题的最终解决。人性化服务每个人都喜欢与众不同的东西，这是人的本性。人性化服务就是要尊重以人为本的服务理念，尊重客户个性，尊重客户的习惯，尊重客户的喜好。人性化服务就是要求提供的服务能被客户所接受和喜爱，超出客户的期望值。当与无法满足客户的期望值时，需要进行分析原因并采取纠正措施，给客户一个满意的回复。维护制度值班制和专人维护制运维组人员将设立值班表，每日值班人员将负责系统的日常检查及日常维护。运维人员在接到客户服务请求或问题投诉，无

9、论是否属于自己工作职责范围，都会做出反应，并将问题详细记录下来，及时解决，争取不让客户打第二次电话。服务监督机制为保证各维护项目组的维护质量，对此工作设定关键绩效指标，每月进行考核，集中进行奖优罚劣，确保维护流程得到有效地执行，从而提高维护质量。客户回访制度通过双方建立起良好的关系，增进与客户之间的沟通交流，收集、整理完整准确的客户资料信息，建立起客户档案库，是开展客户关系管理的重要前提，以逐步形成一套完整的客户信息平台。确定客户类型， 并针对不同类型的客户， 制定相应的回访频次及回访方式。 通过电话、现场等方式回访客户，收集在用系统的问题及需求，了解客户对我公司维护工作的意见和建议，以逐步改

10、善我们的软件质量和维护水平。故障定义及报告制度根据系统维护经验，对系统故障做了明确的故障级别定义并确定相应的故障确诊时限，并采取上报制度，保证给予客户最有效的解决方案。故障级别根据故障性质的严重性及对客户造成的影响程度，把故障分为三级：一级故障指非常严重的故障，如系统崩溃，主机瘫痪等，对最终客户有直接影响，系统已不能正常工作。二级故障指次严重的故障，如系统设备不稳定，但在客户的合理使用下可以正常工作；又如系统 部分性能存在问题，但不影响系统主要功能操作；以及系统运行效率极低访问速度非常慢 等情况。三级故障除以上故障以外的所有故障。包括如：由于某种原因导致应用程序或硬件设备损坏，系 统部分功能不

11、能使用，等暂时不影响系统正常运行的情况。支持响应时间针对故障的不同级别，响应方式及时间也做进一步的明确：一级故障：在运维组无法解决故障时，公司立即召开技术协调会分析故障原因，如确认远程不能解决故障，立即派工程师以最快的速度，不超过24小时赶到客户现场解决故障。二级故障：在运维组无法解决故障时，公司立即召开技术协调会分析故障原因，采取以下三种措施解决故障：1、通过电话指导运维组自己解决故障。2、公司技术小组远程解决故障。3、工程师到客户现场解决故障。三级故障：通过电话指导运维组自己解决。如客户解决不了的，必须提交书面报告由我方派技术人 员到用户现场解决。具体故障上报制度可另出规则。节假日服务保障

12、制度节假日主要是指国家法定假日，包括元旦、春节、五一、国庆。在节假日期间，系统运行过程中出现问题时能够及时得到技术人员的支持，使在用系统得以正常运行，为客户提供 放心周到的服务。维护管理流程运维组周例会说明运维主管组织项目组运维人员在 每周一下午14:00召开周例会，讨论处理上周遗留问题及 本周需要解决的问题。提交文档序 号文档名称命名规则文档说明提交时间/接受人1会议纪要项目名称会议纪 要年月日每次项目组的会议记录， 包 括：周例会、小组讨论会每周一下班前/公司维护 经理运维人员周报说明项目运维人员应于 每周日晚 提交项目Time Sheet给运维主管，总结本周工作。运维主管也 应于每周日晚

13、提交项目Time Sheet给维护经理，总结本周维护组工作情况。提交文档序号文档名称文档说明1问题日志提交至运维部门经理，记录本周存在问题2工时记录提交至运维部门经理，记录本周工作情况规范使用文档规范所有文档都遵循模板，文档中非标题部分全部采用正文格式。会议纪要每次运维组的讨论，需要指定人员进行会议记录，一般在例会后分发给相关人员，最晚不 要超过当天。备份项目涉及的代码程序、文档、会议纪要等资料需要由各运维主管统一保管。维护审计为帮助各运维组在维护工作上能够提高工作质量，将由QA人员不定期对各运维组进行检查及审计。维护过程审计运维组审计维护组的大小是否适应系统的规模和要求。维护组中人员的职责分

14、工是否明确。维护组是否有一套科学的内部管理机制和协调工作机制。系统总体审计维护过程是否按维护规范进行。运维人员的交替是否按照维护规范进行。是否能把握住系统运行状况达到性能管理及资源的有效利用。是否记录事故及故障内容，并向用户负责人及公司维护经理报告。是否找出事故及故障的原因，并采取措施防止再次发生。软件管理审计系统需求变更审计有关系统的任意修改，是否按维护规范进行修改。系统的修改是否按割接计划进行，是否在得到用户负责人的同意后实施。在需求修改前是否对修改内容与影响范围进行了调查与分析，明确了解需求变更后将造成的影响。割接上线审计修改程序的测试是否按测试计划进行。修改的程序是否进行了与新开发的程

15、序同等程度的测试。修改程序的测试是否由用户参加。修改程序的测试结果是否得到开发、运行、维护及用户负责人的认可。修改的程序的测试结果是否记录下来，并进行保管。割接前是否向用户提交割接计划，割接后是否向用户反馈割接报告。割接上线后系统的运行审计是否对修改前的程序及数据做好了备份。运行负责人是否验证其系统不受影响。运行中若出现问题是否及时恢复到修改前程序，是否对数据进行备份。硬件管理审计是否有硬件的故障对策。是否对硬件的利用状况进行记录，并定期进行分析。文档审计文档编制的审计要点是否遵守文档编制规范。文档的种类、目的、制作方法等是否明确。文档管理的审计要点是否制定和遵守文档管理规则。文档更新是否得到

16、相关人员认可。在系统需求更新时，文档内容是否进行更新，并留下更新记录。文档的拷贝及废除是否有对不正当行为的防范及机密保护的对策。客服流程为了保障系统的正常、可靠运行，必须有一整套客服流程来保障系统维护的操作。根据维 护操作对于系统的影响，我将客户服务分为三类：第一类是定期维护，其主要操作是监测系统的运行状况、对客户的支持等，但不影响和干 涉系统的正常运行，只执行“读”操作；第二类是不定期维护，其主要操作是系统有新的需求需要修改并割接到正式系统中，或因 用户量、文档量增多时对程序的优化。属于“写”操作。由于该操作将影响系统的运行， 需要谨慎对待；第三类是故障类处理，对系统出现的故障及时予以排除。

17、流程图如下：图表1软件维护流程 定期类维护定期类维护按以下阶段进行分类：每日、每周、每月。下面的文档提到的日报，周报，月报模板我可根据运维具体内天制定定期类维护图表2定期类维护每日工作内容系统及应用的每日检查每天的值班人员早晨到达办公室后，首先要做所有系统的日常检查。日常检查包括：硬件 检查及软件检查。硬件方面主要是检查系统各项指标是否正常，软件方面主要是检查系统 是否能够正常登陆，相关模块是否能够正常进入。并填写系统日报 。客户支持接听电话、邮件支持或现场解决用户提出的问题，主要工作有：当用户发生变化时，及时调整系统内部参数设置，保障系统数据的即时性；当客户流程发生变化时，及时调整配置文件，

18、保证系统正确流转。协助用户解决在使用当中遇到的问题；发生灾难性事故时，迅速完成系统的恢复；数据的备份及恢复；维护记录客户问题解决后将所解决的问题及时记入维护记录库中。提交文档序 号文档名称命名规则文档说明提交时间/接受人1系统日报项目名称系统日报系统每日运行情况每天卜班前/维护主管 维护主管每周合周报一 并提交每周工作内容系统全面检查在本周结束时，要对系统做阶段检查。并填写系统周报。检查包括：1、系统使用情况CPU和Memo的平均空闲、利用率磁盘使用系统备份2、应用系统的使用情况*:具体的软件系统具体再说，因我现在不了解具体各的服务内容。新增哪些应用和需求，割接上线后使用情况存在问题及解决方案

19、、已解决问题对于用户要求的响应时间系统运行中出现的错误应立即修改；需求的变更和增加，需运维人员对其工作量进行评估后答复用户。答复的时间不得晚于三 天。*其他，根据个地软硬件的服务内容定。对于应用系统在本周中存在的问题，修改时间有如下约定：系统中出现的简单错误，由运维人员自行解决，记入维护记录库中。对于较小程度的修改在星期一、星期二、星期三晚上进行。对于较大程度的修改在周五晚上及周末进行。属于比较重大的问题，例如系统宕机、系统发生错误等，由运维主管安排相关人员尽快处 理。故障发生后，必须查明原因，要及时将故障处理报告上报用户负责人及公司维护经理。从 中吸取经验教训，采取有效措施防止再次发生。更换

20、管理员ID密码运维人员必须每周将管理员ID文件的密码更换，以防管理员身份被他人盗用。管理员Admin 口令使用记录为防止admin的ID文件流失，被多人使用，必须在使用Admin 口令后对此进行记录。提交文档序号文档名称命名规则文档说明提交时间/接受人1系统周报项目名称系统 周报系统每周运行情况每周日之前/公司维护经理及2Admin 口令使用记录项目名称Admin 口令使用记录管理员Admin 口令使 用情况用户负责人每月工作内容系统全面检查在每月未要对系统做全面检查。并填写系统月报 。汇总当月系统的状况，提前预见、发现可能出现的问题，并针对系统情况、问题提出合理化建议。检查包括：1、系统使用

21、情况：CPU和Memo的平均空闲、利用率磁盘使用系统备份2、应用系统使用情况：（月统计）电话受理客户端的IE升级和配置人员组织调整各应用数据库状态存在问题及解决方案、已解决问题等，具体了解了各地服务内容可增减统计维护记录将本地的维护记录库，传送给公司维护经理， 以便公司掌握各运维组的系统日常运行过程中出现问题的频率及类型，从而为优化和完善系统提供信息，维护经理将提交公司研发中心加以改进，并将改进方法通知各运维主管，使系统越来越完善。发布公告将本月系统中人员调整、新增功能、问题解决办法以公告的形式在系统中向用户公布，增强客户对系统的信任度。月度总结由运维人员填写月度工作状况总结表提交给运维主管，

22、运维主管也需要填写，最后由运维主管以项目组的方式提交给公司维护经理。维护值班表提交用户负责人下月维护值班表，和用户说明每天的值班人员。提交文档序号文档名称命名规则文档说明提交时间/接受人1系统月报项目名称系统月 报系统每月运行情况每月月未/公司维护经理及 用户负责人2统计维护记录项目名称维护记 录月份以excel方式将本月 的维护记录进行统计3月度工作状况总 结表姓名月度工作情 况总结表运维人员每月工作状 况总结4维护值班表项目名称月份维 护值班表下月运维人员值班表 记录注意事项日常维护中如在工作时间若发现系统故障，非客户要求下决不能进行更改。非工作时间发 生故障，应立即解决。若故障影响到系统

23、使用，在经得用户负责人同意的情况下，进行故障处理。若故障不会对系统使用造成大的影响，故障的解决时间为当日的非工作时间。若当日的非工作时间不能解决故障。安排在当周的休息日进行解决。如发现办公系统的服务器进行了HA切换，则应在用户下班后再切换回正确的服务器。决不能在用户上班时进行切换，以防对用户的工作造成影响。不定期类维护不定期类维护包括：需求变更流程、割接上线流程及程序优化流程。图表3 需求变 工作流 需求变程主据用户用 例 及 招 告 或项禽:接计剧割接申请割接报告以确认需、工祚重和影响范围。需求变更申请单需求变更评估报告图表4需求变更流程图 提交文档序 号文档名称命名规则文档说明提交时间/接

24、受人1需求变更 树!单需求变更申请 单此文档由用户提供， 用户在提出需求变 更时需提供此单给 运维人员1需求变更 分析项目名称需求 义更分析运维主管根据需求 义更的内容分析其 对项目各个方面的 影响需求变更分析后/公司维护经理2需求变更 记录单项目名称需求 义更记录单记录需求变更需求变更修改完毕/公司维护经理割接上线工作流程图表5割接上线流程 提交文档序号文档名称命名规则文档说明提交时间/接受人1测试用例及报 告项目名称测试用例 及报告年月日在开发服务器上的对新 开发功能的测试描述新增功能测试后/用户负 责人2割接计划项目名称割接计划 年月日在生产系统上进行割接 工作之前制定的割接计 划割接上

25、线前/用户负责人 及公司维护经理3割接申请割接申请年月日申请在生产系统上进行 割接工作割接上线前/ 用户负责人4割接报告项目名称割接报告 年月日在生产系统上割接成功 后向用户负责人提供的 报告割接上线后/用户负责人 及公司维护经理5割接失败报 告项目名称割接失败 报告年月日在生产系统上割接失败 后向用户负责人提供的 报告程序优化由于应用系统在使用过程中会不断的有需求变更和需求增加，这些增加和变更的程序迫于 时间压力上线后可能会存在一些问题，为系统的稳定运行造成一些隐患。所以要定期对运 行的程序进行优化，并形成相应的版本。定期检查各个应用数据库的大小，使用百分比。 优化首先应当在测试服务器上进行，当确定运行没有问题后，以报告形式报用户负责人批 准，在用户下班后在生产系统中进行割接。工作流程图表6程序优化流程 提交文档序 号文档名称命名规则文档说明提交时间/接受人1系统运行报 告项目名称系统运行 报告年月日在开发服务器上的对新 开发功能的测试描述程序优化后/用户负责 人及公司维护经理2优化方法可作为维护经验共享故障类维护故障类维护包括:8 故障类维护 故障处理流程在系统上线后，客户将开始正式使用系统，故障将直接影响到客户的满意度，因