某公司运维服务部管理流程说明(DOC32页)[最新实用型资料]

1、运维服务部管理流程说明目录1 引言 41.1 编写目的 41.2 编写说明 42 维护理念 42.1 维护宗旨 42.2 维护范围 42.3 响应服务速度 53 维护保证 53.1 提供统一接口 53.2 提供标准化的服务质量 53.3 服务支持手段 64 维护类型 64.1 主动式服务 6维护质量审计 6客户满意度调查 64.2 被动式服务 7电话及邮件应答服务 74.2.2 远端服务 74.2.3 现场服务 74.3 人性化服务 75 维护制度 85.1 值班制和专人维护制 85.2 服务监督机制 85.3 客户回访制度 85.4 故障定义及报告制度 85.4.1.1 故障级别 85.4.

2、1.2 支持响应时间 95.5 节假日服务保障制度 96 维护管理流程 106.1 运维组周例会 10说明 10提交文档 106.2 运维人员周报 10说明 10提交文档 106.3 规范使用 116.4 维护审计 116.4.1 维护过程审计 116.4.2 软件管理审计 126.4.3 硬件管理审计 12文档审计 127 客服流程 137.1 定期类维护 14每日 147.1.1.1 工作内容 147.1.1.2 提交文档 15每周 157.1.2.1 工作内容 157.1.2.2 提交文档 16每月 177.1.3.1 工作内容 177.1.3.2 提交文档 187.1.3.3 注意事项

3、 187.2 不定期类维护 18需求变更 197.2.1.1 工作流程 197.2.1.2 提交文档 20割接上线 227.2.2.1 工作流程 227.2.2.2 提交文档 24程序优化 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 故障响应 29HA 切换流程 297.3.2.1 工作流程 307.3.2.2 提交文档 308 维护性能指标 308.1 系统主机部分 308.2 应用系统部分 311 引言1.1 编写目的本文档将指导各地运维组有

4、效、高质的实施服务。包括：维护理念、维护类型、维护 制度等。在维护工作未开展之前，需各个运维主管认真阅读本文档，并对运维人员进行必 要的培训，使运维人员熟悉维护的流程及相关制度。在维护过程中，运维主管要严格按照 此文档的流程组织维护工作，以提高、增强维护质量。在项目维护过程中，运维主管或运维人员若发现流程有缺陷或需要补充的，请及时反 馈至公司，确保流程能够及时得到更新，以达到规范性、可操作性。1.2 编写说明本文档的阅读对象包括：公司领导运维主管项目组运维人员2 维护理念2.1 维护宗旨与客户紧密配合，尽公司所能，为客户提供快捷、优质的服务，让客户省心，让客户 放心。2.2 维护范围为客户提供

5、热线、现场服务及业务覆盖范围内的服务实施。2.3 响应服务速度在用户工作期间提供服务电话或邮件、 现场支持， 在系统出现严重故障时提供 24 小时 支持。3 维护保证3.1 提供统一接口驻点维护作为公司服务的对外窗口， 为客户提供服务， 确保所有客户在工作期间， 在任何时候、任何地方、出于任何原因，都可以方便地与维护项目组进行联系，获得 满意的服务。3.2 提供标准化的服务质量客户的每次要求，都将在维护记录库建立，并一直被监控，直到问题得到圆 满的解决。客户不需要重复同一个问题，也不用担心自己的问题有如石沉大海。每一类问题的处理将建立标准的时限要求，如果超出规定时限，公司会对相关人 员做出处理

6、。公司会对维护项目组整个维护工作进行监控和定期考核。3.3服务支持手段4维护类型4.1主动式服务维护质量审计建议公司额外组建 QA组，定期开展质量审计工作，对在用系统进行全面检查并现场 分析问题，发现问题及其隐患，及时予以解决。客户满意度调查通过电话、信函、现场、传真、e-mail等方式向客户发放调查问卷，了解客户对公司所开发系统的技术支持情况、系统运行情况等各方面的满意度评价，并对调查结果进行统计分析，对于存在的问题及时寻求处理解决办法，以逐步提高客户满意度。4.2 被动式服务4.2.1 电话及邮件应答服务当客户出现问题或故障后需要寻求帮助, 首先可以通过电话或邮件请求支持帮助和指导，及时解

7、决问题或排除故障。4.2.2 远端服务当客户应答服务无法排除故障时，在最终客户授权的前提下，可根据客户方提供的问 题现象和故障描述，通过接入客户在用系统来指导客户方技术人员或直接处理系统故障。 在登录访问系统前，客户需给出必要的口令。4.2.3 现场服务在维护工作中，电话应答服务及远端服务是解决问题、处理故障的第一步，因为在时 效上电话应答及远程服务将明显高于现场服务。但当电话应答服务及远程服务无法解决客 户提出的服务请求时，我们将指定运维人员在尽可能短的时间内在现场进行服务，以求问 题的最终解决。4.3 人性化服务每个人都喜欢与众不同的东西，这是人的本性。人性化服务就是要尊重以人为本的服 务

8、理念，尊重客户个性，尊重客户的习惯，尊重客户的喜好。人性化服务就是要求提供的 服务能被客户所接受和喜爱，超出客户的期望值。当与无法满足客户的期望值时，需要进 行分析原因并采取纠正措施，给客户一个满意的回复。5 维护制度5.1 值班制和专人维护制运维组人员将设立值班表，每日值班人员将负责系统的日常检查及日常维护。 运维人员在接到客户服务请求或问题投诉，无论是否属于自己工作职责范围，都会做出反 应，并将问题详细记录下来，及时解决，争取不让客户打第二次电话。5.2 服务监督机制为保证各维护项目组的维护质量，对此工作设定关键绩效指标，每月进行考核，集中 进行奖优罚劣，确保维护流程得到有效地执行，从而提

9、高维护质量。5.3 客户回访制度通过双方建立起良好的关系，增进与客户之间的沟通交流，收集、整理完整准确的客 户资料信息，建立起客户档案库，是开展客户关系管理的重要前提，以逐步形成一套完整 的客户信息平台。确定客户类型， 并针对不同类型的客户， 制定相应的回访频次及回访方式。 通过电话、 现场等方式回访客户，收集在用系统的问题及需求，了解客户对我公司维护工作的意见和 建议，以逐步改善我们的软件质量和维护水平。5.4 故障定义及报告制度根据系统维护经验， 对系统故障做了明确的故障级别定义并确定相应的故障确诊时限， 并采取上报制度，保证给予客户最有效的解决方案。5.4.1.1 故障级别根据故障性质的

10、严重性及对客户造成的影响程度，把故障分为三级：一级故障指非常严重的故障，如系统崩溃，主机瘫痪等，对最终客户有直接影响，系统已不能正 常工作。二级故障指次严重的故障，如系统设备不稳定，但在客户的合理使用下可以正常工作；又如系统 部分性能存在问题，但不影响系统主要功能操作；以及系统运行效率极低访问速度非常慢 等情况。三级故障除以上故障以外的所有故障。包括如：由于某种原因导致应用程序或硬件设备损坏，系 统部分功能不能使用，等暂时不影响系统正常运行的情况。5.4.1.2 支持响应时间针对故障的不同级别，响应方式及时间也做进一步的明确：一级故障：在运维组无法解决故障时，公司立即召开技术协调会分析故障原因

11、，如确认远程不能解 决故障，立即派工程师以最快的速度，不超过 24 小时赶到客户现场解决故障。 二级故障：在运维组无法解决故障时，公司立即召开技术协调会分析故障原因，采取以下三种措施 解决故障：1、通过电话指导运维组自己解决故障。2、公司技术小组远程解决故障。3、工程师到客户现场解决故障。三级故障：通过电话指导运维组自己解决。如客户解决不了的，必须提交书面报告由我方派技术人 员到用户现场解决。具体故障上报制度可另出规则。5.5 节假日服务保障制度节假日主要是指国家法定假日，包括元旦、春节、五一、国庆。在节假日期间，系统 运行过程中出现问题时能够及时得到技术人员的支持，使在用系统得以正常运行，为

12、客户提供放心周到的服务。6维护管理流程6.1运维组周例会说明运维主管组织项目组运维人员在每周一下午14:00召开周例会，讨论处理上周遗留问题及本周需要解决的问题。提交文档序号文档名称命名规则文档说明提交时间/接受人1会议纪要项目名称_会议纪要_年月日每次项目组的会议记录， 包括：周例会、小组讨论会每周一下班前 /公司维护经理6.2运维人员周报说明项目运维人员应于 每周日晚提交项目Time Sheet给运维主管，总结本周工作。运维主管也应于 每周日晚 提交项目Time Sheet给维护经理，总结本周维护组工作情况。提交文档序号文档名称文档说明1问题日志提交至运维部门经理，记录本周存在问题2工时记

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

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

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

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

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

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

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

20、负责人及公司维护经理。从中吸取经验教训，采取有效措施防止再次发生。更换管理员ID密码运维人员必须每周将管理员ID文件的密码更换，以防管理员身份被他人盗用。管理员Admin 口令使用记录为防止admin的ID文件流失，被多人使用，必须在使用Admin 口令后对此进行记录。7.122提交文档序号文档名称命名规则文档说明提交时间/接受人1系统周报项目名称_系统周报系统每周运行情况每周日之前/公司维护经理及2Admin 口令使用记录项目名称_ Admin口令使用记录管理员Admin 口令使用情况用户负责人每月7.1.3.1 工 作内容系统全面检查在每月未要对系统做全面检查。并填写系统月报 。汇总当月系

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

22、系统中人员调整、 新增功能、 问题解决办法以公告的形式在系统中向用户公布， 增强客户对系统的信任度。月度总结由运维人员填写月度工作状况总结表提交给运维主管，运维主管也需要填写，最后由 运维主管以项目组的方式提交给公司维护经理。维护值班表提交用户负责人下月维护值班表，和用户说明每天的值班人员。7.132提交文档序号文档名称命名规则文档说明提交时间/接受人1系统月报项目名称_系统月报系统每月运行情况2统计维护记录项目名称_维护记录月份以excel方式将本月的维护记录进行统计每月月未/公司维护经理及3月度工作状况总结表姓名_月度工作情况总结表运维人员每月工作状况总结用户负责人4维护值班表项目名称_月

23、份_维护值班表下月运维人员值班表记录7.133注意事项? 日常维护中如在工作时间若发现系统故障，非客户要求下决不能进行更改。非工作时间发生故障，应立即解决。? 若故障影响到系统使用，在经得用户负责人同意的情况下，进行故障处理。? 若故障不会对系统使用造成大的影响，故障的解决时间为当日的非工作时间。? 若当日的非工作时间不能解决故障。安排在当周的休息日进行解决。? 如发现办公系统的服务器进行了HA切换，则应在用户下班后再切换回正确的服务器。决不能在用户上班时进行切换，以防对用户的工作造成影响。7.2不定期类维护不定期类维护包括：需求变更流程、割接上线流程及程序优化流程。图表3不定期类维护721需

24、求变更721.1工作流程需求变更过程主要是依据用户或项目人员提出的需求变更请求与用户进行协调，以确认需 求更改的可行性、合理性、工作量和影响范围。1T交研发部门1处理一需求变更单位提出需需求变更申请单求变更1F用户方负责人认可F项目维护经理进行需 求变更评估分析需求变更评估报告否报维护经理项目维护经理安排人 员完成并记录人天。技术实现报维护经理需求变更记录单是t图表4需求变更流程图721.2提交文档序文档名称命名规则文档说明提交时间/接受人号1需求变更申请单需求变更申请单此文档由用户提供， 用户在提出需求变 更时需提供此单给 运维人员1需求变更分析项目名称需求变更分析运维主管根据需求 变更的内

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

26、上割接成功后向用户负责人提供的报告割接上线后/用户负责人及公司维护经理5割接失败报告项目名称_割接失败报告_年月日在生产系统上割接失败后向用户负责人提供的报告723程序优化由于应用系统在使用过程中会不断的有需求变更和需求增加，这些增加和变更的程序 迫于时间压力上线后可能会存在一些问题，为系统的稳定运行造成一些隐患。所以要定期 对运行的程序进行优化，并形成相应的版本。定期检查各个应用数据库的大小，使用百分 比。优化首先应当在测试服务器上进行，当确定运行没有问题后，以报告形式报用户负责 人批准，在用户下班后在生产系统中进行割接。723.1工作流程图表6程序优化流程723.2提交文档序号文档名称命名

27、规则文档说明提交时间/接受人1系统运行报项目名称_系统运行在开发服务器上的对新程序优化后/用户负责告报告_年月日开发功能的测试描述人及公司维护经理2优化方法可作为维护经验共享7.3故障类维护故障类维护包括:故障处理HA切换-IIIA切换记处故障类维护图表8故障类维护故障处理流程在系统上线后，客户将开始正式使用系统，故障将直接影响到客户的满意度，因此对于故障的发现、报告、处理、反馈，将直接影响到客户对我们公司的评价，故障定义有如下几种：1. 宕机：是指在用户工作时间内系统服务中止，无论是系统自动停止服务还是我方因其他原因中断服务；2. 切换:HA切换是指系统发生故障后由原应用所在服务器切换到另一

28、台互为HA切换的服务器上7.3.1.1 工作流程15分钟内1故障处理单项目维护经理收集日志信息报告维护经理No障件设备故Yes上报客户协调硬件工程师解决故障设备更换网络故障Yes上报并协调网 络工程师解决申请资源No障件系统故Yes交产品核心组解决No图表9故障上报流程图731.2提交文档序号文档名称命名规则文档说明提交时间/接受人1故障处理单项目名称_故障处理单_年月日在生产系统发生故障时 填写，描述故障原因、现 象、解决方法等。系统发生故障15分钟内/公司维护经理及总经理2日志信息项目名称_日志年月日系统发生故障时所产生的日志信息3故障报告项目名称_故障报告_年月日描述故障原因、现象、解

29、决方法等。系统故障解决后/用户负 责人731.3故障响应系统发生应用系统软件故障响应时间为1小时，在2小时内保证恢复正常工作。切换流程系统发生故障并 HA切换后，需要按照下列流程将系统切换恢复正常状态。7.321工作流程图表10 HA切换流程图7.322提交文档序号文档名称命名规则文档说明提交时间/接受人1HA切换记录项目名称_ HA切换记录_年月日系统HA切换的记录HA切换后/公司维护经理8维护性能指标8.1系统主机部分1）Linux每个文件系统的数据目录已用空间/这个文件系统的物理空间<80% ；2）主机的CPU已使用能力/CPU总能力<70%。3）主机系统为SOLORIS的应

30、用程序已用内存空间 /内存物理空间 < 70%。是内存空闲，一是主机系统为AIX的应用程序已用内存空间需要从二方面去查看,Paging 使用率，若内存空闲小同时 Paging 使用率 < 50% 时，则内存不足。当各个设备的 CPU 利用率和内存利用率满足上述要求时， 我们认为设备工作正常。 若 超过上限值，设备的性能将会下降，应及时处理。8.2 应用系统部分* 这个也根据具体系统再定每个人都有潜在的能量，只是很容易被习惯所掩盖，被时间所迷离，被惰性所消磨。把命运寄托在自己身上，这是这个世界上最美妙的心思。为此努力，拼搏，不舍昼夜。每个人的内心都 充满了魔鬼，学会控制他。如果你还认

31、为自己还年轻，还可以蹉跎岁月的话，你终将一事无成，老来叹息。在实现理想的路途中，必须排除一切干扰，特别是要看清那些美丽的诱惑。忍一 时之气，免百日之忧信心、毅力、勇气三者具备，则天下没有做不成的事改变自己是自救，影响别人是救人。当你感到无助的时候，还有一种坚实的力量可以依靠，那就是你自己。想过去 是杂念，想未来是妄想，最好把握当下时刻。幸福不在得到多，而在计较少。改变别人，不如先改变自己。一个人能走多远，要看他有谁同行；一个人有多优秀，要看他有谁指点；一个人 有多成功，要看他有谁相伴。同样的一瓶饮料，便利店里 2 块钱，五星饭店里 60 块，很多的时候，一个人的价值取决于所在的位置。忙碌是一种

32、幸福，让我们没时间体会痛苦；奔波是一 种快乐，让我们真实地感受生活；疲惫是一种享受，让我们无暇空虚。 10 、我是世界上独一无二的，我一定会成功！成功者往往有个计划，而失败者往往有个托辞。成功者会说： “我帮你 做点什么吧！而失败者说：那不是我的事。成功三个条件：机会；自己渴望改变并非常努力；贵人相助亿万财富买不到一个好的观念；好的观念却能让你赚到亿万财富。一个讯息从地球这 一端到另一端只需要 0.05 秒，而一个观念从脑外传到脑里却需要一年，三年甚至十年。要改变命运，先改变观念。人生的成败往往就在于一念之差。鸟无翅膀不能飞，人无志气不成功。成功 99%是心志， 1%是能力。 一个人不成功是因

33、为两个字恐惧。 一个会向别人学习的人就是一个要成功的人。 人要是惧怕痛苦， 惧怕种种疾病， 惧怕不测的事情， 惧怕生命的危险和死亡， 他就什么也不能忍受了，人格的完善是本，财富的确立是末。傲不可长，欲不可纵，乐不可极，志不可满。在人之上，要把人当人；在人之下，要把自己当人。锲而舍之，朽木不折；锲而 不舍，金石可镂。真者，精诚之至也，不精不诚，不能动人。我觉得坦途在前，人又何必因为一点小障碍而不走路呢？对时间的慷慨，成功不是将来才有的，而是从决定去做的那一刻起， 持续累积而成。天下之事常成于困约，而败于奢靡。企业家收获着梦想，又在播种着希望；原来一切辉煌只代表过去，未来永远空白。一个最困苦、最卑贱、最为命运所屈辱的人，只要还 抱有希望，便无所怨惧。你生而有翼，为何一生匍匐前进，形如蝼蚁世界上只有想不通的人，没有走不通的路。世上那有什么成功，那只是努力的另一个代名词罢了。所谓英雄，其实是指 那些无论在什么环境下都能够生存下去的人。微笑不用本钱，但能创造财富。赞美不用花钱，但能产生