运维服务部门管理系统流程.docx
《运维服务部门管理系统流程.docx》由会员分享，可在线阅读，更多相关《运维服务部门管理系统流程.docx（25页珍藏版）》请在冰点文库上搜索。
运维服务部门管理系统流程
运维服务部
管理流程说明
1引言
1.1编写目的
本文档将指导各地运维组有效、高质的实施服务。
包括：
维护理念、维护类型、维护制度等。
在维护工作未开展之前，需各个运维主管认真阅读本文档，并对运维人员进展必要的培训，使运维人员熟悉维护的流程与相关制度。
在维护过程中，运维主管要严格按照此文档的流程组织维护工作，以提高、增强维护质量。
在项目维护过程中，运维主管或运维人员假如发现流程有缺陷或需要补充的，请与时反响至公司，确保流程能够与时得到更新，以达到规X性、可操作性。
1.2编写说明
本文档的阅读对象包括：
●公司领导
●运维主管
●项目组运维人员
2维护理念
2.1维护宗旨
与客户严密配合，尽公司所能，为客户提供快捷、优质的服务，让客户省心，让客户放心。
2.2维护X围
为客户提供热线、现场服务与业务覆盖X围内的服务实施。
2.3响应服务速度
在用户工作期间提供服务或、现场支持，在系统出现严重故障时提供24小时支持。
3维护保证
3.1提供统一接口
驻点维护作为公司服务的对外窗口，为客户提供服务，确保所有客户在工作期间，在任何时候、任何地方、出于任何原因，都可以方便地与维护项目组进展联系，获得满意的服务。
3.2提供标准化的服务质量
客户的每次要求，都将在《维护记录库》建立，并一直被监控，直到问题得到圆满的解决。
客户不需要重复同一个问题，也不用担心自己的问题有如石沉大海。
每一类问题的处理将建立标准的时限要求，如果超出规定时限，公司会对相关人员做出处理。
公司会对维护项目组整个维护工作进展监控和定期考核。
3.3服务支持手段
4维护类型
4.1主动式服务
4.1.1维护质量审计
建议公司额外组建QA组，定期开展质量审计工作，对在用系统进展全面检查并现场分析问题，发现问题与其隐患，与时予以解决。
4.1.2客户满意度调查
通过、信函、现场、、等方式向客户发放调查问卷，了解客户对公司所开发系统的技术支持情况、系统运行情况等各方面的满意度评价，并对调查结果进展统计分析，对于存在的问题与时寻求处理解决方法，以逐步提高客户满意度。
4.2被动式服务
4.2.1与应答服务
当客户出现问题或故障后需要寻求帮助,首先可以通过或请求支持帮助和指导，与时解决问题或排除故障。
4.2.2远端服务
当客户应答服务无法排除故障时，在最终客户授权的前提下，可根据客户方提供的问题现象和故障描述，通过接入客户在用系统来指导客户方技术人员或直接处理系统故障。
在登录访问系统前，客户需给出必要的口令。
4.2.3现场服务
在维护工作中，应答服务与远端服务是解决问题、处理故障的第一步，因为在时效上应答与远程服务将明显高于现场服务。
但当应答服务与远程服务无法解决客户提出的服务请求时，我们将指定运维人员在尽可能短的时间内在现场进展服务，以求问题的最终解决。
4.3人性化服务
每个人都喜欢与众不同的东西，这是人的本性。
人性化服务就是要尊重以人为本的服务理念，尊重客户个性，尊重客户的习惯，尊重客户的喜好。
人性化服务就是要求提供的服务能被客户所承受和喜爱，超出客户的期望值。
当与无法满足客户的期望值时，需要进展分析原因并采取纠正措施，给客户一个满意的回复。
5维护制度
5.1值班制和专人维护制
运维组人员将设立值班表，每日值班人员将负责系统的日常检查与日常维护。
运维人员在接到客户服务请求或问题投诉，无论是否属于自己工作职责X围，都会做出反响，并将问题详细记录下来，与时解决，争取不让客户打第二次。
5.2服务监视机制
为保证各维护项目组的维护质量，对此工作设定关键绩效指标，每月进展考核，集中进展奖优罚劣，确保维护流程得到有效地执行，从而提高维护质量。
5.3客户回访制度
通过双方建立起良好的关系，增进与客户之间的沟通交流，收集、整理完整准确的客户资料信息，建立起客户档案库，是开展客户关系管理的重要前提，以逐步形成一套完整的客户信息平台。
确定客户类型，并针对不同类型的客户，制定相应的回访频次与回访方式。
通过、现场等方式回访客户，收集在用系统的问题与需求，了解客户对我公司维护工作的意见和建议，以逐步改善我们的软件质量和维护水平。
5.4故障定义与报告制度
根据系统维护经验，对系统故障做了明确的故障级别定义并确定相应的故障确诊时限，并采取上报制度，保证给予客户最有效的解决方案。
5.4.1.1故障级别
根据故障性质的严重性与对客户造成的影响程度，把故障分为三级：
一级故障
指非常严重的故障，如系统崩溃，主机瘫痪等，对最终客户有直接影响，系统已不能正常工作。
二级故障
指次严重的故障，如系统设备不稳定，但在客户的合理使用下可以正常工作；又如系统局部性能存在问题，但不影响系统主要功能操作；以与系统运行效率极低访问速度非常慢等情况。
三级故障
除以上故障以外的所有故障。
包括如：
由于某种原因导致应用程序或硬件设备损坏，系统局部功能不能使用，等暂时不影响系统正常运行的情况。
5.4.1.2支持响应时间
针对故障的不同级别，响应方式与时间也做进一步的明确：
一级故障：
在运维组无法解决故障时，公司立即召开技术协调会分析故障原因，如确认远程不能解决故障，立即派工程师以最快的速度，不超过24小时赶到客户现场解决故障。
二级故障：
在运维组无法解决故障时，公司立即召开技术协调会分析故障原因，采取以下三种措施解决故障：
1、通过指导运维组自己解决故障。
2、公司技术小组远程解决故障。
3、工程师到客户现场解决故障。
三级故障：
通过指导运维组自己解决。
如客户解决不了的，必须提交书面报告由我方派技术人员到用户现场解决。
具体故障上报制度可另出规如此。
5.5节假日服务保障制度
节假日主要是指国家法定假日，包括元旦、春节、五一、国庆。
在节假日期间，系统运行过程中出现问题时能够与时得到技术人员的支持，使在用系统得以正常运行，为客户提供放心周到的服务。
6维护管理流程
6.1运维组周例会
6.1.1说明
运维主管组织项目组运维人员在每周一下午14:
00召开周例会，讨论处理上周遗留问题与本周需要解决的问题。
6.1.2提交文档
序号
文档名称
命名规如此
文档说明
提交时间/承受人
1
会议纪要
项目名称_会议纪要_年月日
每次项目组的会议记录，包括：
周例会、小组讨论会
每周一下班前/公司维护经理
6.2运维人员周报
6.2.1说明
项目运维人员应于每周日晚提交项目TimeSheet给运维主管，总结本周工作。
运维主管也应于每周日晚提交项目TimeSheet给维护经理，总结本周维护组工作情况。
6.2.2提交文档
序号
文档名称
文档说明
1
问题日志
提交至运维部门经理，记录本周存在问题
2
工时记录
提交至运维部门经理，记录本周工作情况
6.3规X使用
1、文档规X
所有文档都遵循模板，文档中非标题局部全部采用正文格式。
2、会议纪要
每次运维组的讨论，需要指定人员进展会议记录，一般在例会后分发给相关人员，最晚不要超过当天。
3、备份
项目涉与的代码程序、文档、会议纪要等资料需要由各运维主管统一保管。
6.4维护审计
为帮助各运维组在维护工作上能够提高工作质量，将由QA人员不定期对各运维组进展检查与审计。
6.4.1维护过程审计
●运维组审计
1、维护组的大小是否适应系统的规模和要求。
2、维护组中人员的职责分工是否明确。
3、维护组是否有一套科学的内部管理机制和协调工作机制。
●系统总体审计
1、维护过程是否按维护规X进展。
2、运维人员的交替是否按照维护规X进展。
3、是否能把握住系统运行状况达到性能管理与资源的有效利用。
4、是否记录事故与故障内容，并向用户负责人与公司维护经理报告。
5、是否找出事故与故障的原因，并采取措施防止再次发生。
6.4.2软件管理审计
●系统需求变更审计
6、有关系统的任意修改，是否按维护规X进展修改。
7、系统的修改是否按割接计划进展，是否在得到用户负责人的同意后实施。
8、在需求修改前是否对修改内容与影响X围进展了调查与分析，明确了解需求变更后将造成的影响。
●割接上线审计
9、修改程序的测试是否按测试计划进展。
10、修改的程序是否进展了与新开发的程序同等程度的测试。
11、修改程序的测试是否由用户参加。
12、修改程序的测试结果是否得到开发、运行、维护与用户负责人的认可。
13、修改的程序的测试结果是否记录下来，并进展保管。
14、割接前是否向用户提交割接计划，割接后是否向用户反响割接报告。
●割接上线后系统的运行审计
15、是否对修改前的程序与数据做好了备份。
16、运行负责人是否验证其系统不受影响。
17、运行中假如出现问题是否与时恢复到修改前程序，是否对数据进展备份。
6.4.3硬件管理审计
1、是否有硬件的故障对策。
2、是否对硬件的利用状况进展记录，并定期进展分析。
6.4.4文档审计
●文档编制的审计要点
1、是否遵守文档编制规X。
2、文档的种类、目的、制作方法等是否明确。
●文档管理的审计要点
18、是否制定和遵守文档管理规如此。
19、文档更新是否得到相关人员认可。
20、在系统需求更新时，文档内容是否进展更新，并留下更新记录。
21、文档的拷贝与废除是否有对不正当行为的防X与某某保护的对策。
7客服流程
为了保障系统的正常、可靠运行，必须有一整套客服流程来保障系统维护的操作。
根据维护操作对于系统的影响，我将客户服务分为三类：
第一类是定期维护，其主要操作是监测系统的运行状况、对客户的支持等，但不影响和干预系统的正常运行，只执行“读〞操作；
第二类是不定期维护，其主要操作是系统有新的需求需要修改并割接到正式系统中，或因用户量、文档量增多时对程序的优化。
属于“写〞操作。
由于该操作将影响系统的运行，需要慎重对待；
第三类是故障类处理，对系统出现的故障与时予以排除。
流程图如下：
图表1软件维护流程
7.1定期类维护
定期类维护按以下阶段进展分类：
每日、每周、每月。
下面的文档提到的日报，周报，月报模板我可根据运维具体内天制定
图表2定期类维护
7.1.1每日
7.1.1.1工作内容
●系统与应用的每日检查
每天的值班人员早晨到达办公室后，首先要做所有系统的日常检查。
日常检查包括：
硬件检查与软件检查。
硬件方面主要是检查系统各项指标是否正常，软件方面主要是检查系统是否能够正常登陆，相关模块是否能够正常进入。
并填写《系统日报》。
●客户支持
接听、支持或现场解决用户提出的问题，主要工作有：
Ø当用户发生变化时，与时调整系统内部参数设置，保障系统数据的即时性；
Ø当客户流程发生变化时，与时调整配置文件，保证系统正确流转。
Ø协助用户解决在使用当中遇到的问题；
Ø发生灾难性事故时，迅速完成系统的恢复；
Ø数据的备份与恢复；
●维护记录
客户问题解决后将所解决的问题与时记入《维护记录库》中。
7.1.1.2提交文档
序号
文档名称
命名规如此
文档说明
提交时间/承受人
1
系统日报
项目名称_系统日报
系统每日运行情况
每天下班前/维护主管
维护主管每周合周报一并提交
7.1.2每周
7.1.2.1工作内容
●系统全面检查
在本周完毕时，要对系统做阶段检查。
并填写《系统周报》。
检查包括：
1、系统使用情况
ØCPU和Memo的平均空闲、利用率
Ø磁盘使用
Ø系统备份
2、应用系统的使用情况
*：
具体的软件系统具体再说，因我现在不了解具体各的服务内容。
Ø新增哪些应用和需求，割接上线后使用情况
Ø存在问题与解决方案、已解决问题
●对于用户要求的响应时间
Ø系统运行中出现的错误应立即修改；
Ø需求的变更和增加，需运维人员对其工作量进展评估后答复用户。
答复的时间不得晚于三天。
Ø*****其他，根据个地软硬件的服务内容定。
●对于应用系统在本周中存在的问题，修改时间有如下约定：
Ø系统中出现的简单错误，由运维人员自行解决，记入《维护记录库》中。
Ø对于较小程度的修改在星期一、星期二、星期三晚上进展。
Ø对于较大程度的修改在周五晚上与周末进展。
Ø属于比拟重大的问题，例如系统宕机、系统发生错误等，由运维主管安排相关人员尽快处理。
Ø故障发生后，必须查明原因，要与时将故障处理报告上报用户负责人与公司维护经理。
从中吸取经验教训，采取有效措施防止再次发生。
●更换管理员ID密码
运维人员必须每周将管理员ID文件的密码更换，以防管理员身份被他人盗用。
●管理员Admin口令使用记录
为防止admin的ID文件流失，被多人使用，必须在使用Admin口令后对此进展记录。
7.1.2.2提交文档
序号
文档名称
命名规如此
文档说明
提交时间/承受人
1
系统周报
项目名称_系统周报
系统每周运行情况
每周日之前/公司维护经理与用户负责人
2
Admin口令使用记录
项目名称_Admin口令使用记录
管理员Admin口令使用情况
7.1.3每月
7.1.3.1工作内容
●系统全面检查
在每月未要对系统做全面检查。
并填写《系统月报》。
汇总当月系统的状况，提前预见、发现可能出现的问题，并针对系统情况、问题提出合理化建议。
检查包括：
1、系统使用情况：
ØCPU和Memo的平均空闲、利用率
Ø磁盘使用
Ø系统备份
2、应用系统使用情况：
〔月统计〕
Ø受理
Ø客户端的IE升级和配置
Ø人员组织调整
Ø各应用数据库状态
Ø存在问题与解决方案、已解决问题
Ø等，具体了解了各地服务内容可增减
●统计维护记录
将本地的《维护记录库》，传送给公司维护经理，以便公司掌握各运维组的系统日常运行过程中出现问题的频率与类型，从而为优化和完善系统提供信息，维护经理将提交公司研发中心加以改良，并将改良方法通知各运维主管，使系统越来越完善。
●发布公告
将本月系统中人员调整、新增功能、问题解决方法以公告的形式在系统中向用户公布，增强客户对系统的信任度。
●月度总结
由运维人员填写《月度工作状况总结表》提交给运维主管，运维主管也需要填写，最后由运维主管以项目组的方式提交给公司维护经理。
●维护值班表
提交用户负责人下月维护值班表，和用户说明每天的值班人员。
7.1.3.2提交文档
序号
文档名称
命名规如此
文档说明
提交时间/承受人
1
系统月报
项目名称_系统月报
系统每月运行情况
每月月未/公司维护经理与用户负责人
2
统计维护记录
项目名称_维护记录_月份
以excel方式将本月的维护记录进展统计
3
月度工作状况总结表
某某_月度工作情况总结表
运维人员每月工作状况总结
4
维护值班表
项目名称_月份_维护值班表
下月运维人员值班表记录
7.1.3.3须知事项
Ø日常维护中如在工作时间假如发现系统故障，非客户要求下决不能进展更改。
非工作时间发生故障，应立即解决。
Ø假如故障影响到系统使用，在经得用户负责人同意的情况下，进展故障处理。
Ø假如故障不会对系统使用造成大的影响，故障的解决时间为当日的非工作时间。
Ø假如当日的非工作时间不能解决故障。
安排在当周的休息日进展解决。
Ø如发现办公系统的服务器进展了HA切换，如此应在用户下班后再切换回正确的服务器。
决不能在用户上班时进展切换，以防对用户的工作造成影响。
7.2不定期类维护
不定期类维护包括：
需求变更流程、割接上线流程与程序优化流程。
图表3不定期类维护
7.2.1需求变更
7.2.1.1工作流程
需求变更过程主要是依据用户或项目人员提出的需求变更请求与用户进展协调，以确认需求更改的可行性、合理性、工作量和影响X围。
图表4需求变更流程图
7.2.1.2提交文档
序号
文档名称
命名规如此
文档说明
提交时间/承受人
1
需求变更申请单
需求变更申请单
此文档由用户提供，用户在提出需求变更时需提供此单给运维人员
1
需求变更分析
项目名称_需求变更分析
运维主管根据需求变更的内容分析其对项目各个方面的影响
需求变更分析后/公司维护经理
2
需求变更记录单
项目名称_需求变更记录单
记录需求变更
需求变更修改完毕/公司维护经理
7.2.2割接上线
7.2.2.1工作流程
图表5割接上线流程
7.2.2.2提交文档
序号
文档名称
命名规如此
文档说明
提交时间/承受人
1
测试用例与报告
项目名称_测试用例与报告_年月日
在开发服务器上的对新开发功能的测试描述
新增功能测试后/用户负责人
2
割接计划
项目名称_割接计划_年月日
在生产系统上进展割接工作之前制定的割接计划
割接上线前/用户负责人与公司维护经理
3
割接申请
割接申请_年月日
申请在生产系统上进展割接工作
割接上线前/
用户负责人
4
割接报告
项目名称_割接报告_年月日
在生产系统上割接成功后向用户负责人提供的报告
割接上线后/用户负责人与公司维护经理
5
《割接失败报告》
项目名称_割接失败报告_年月日
在生产系统上割接失败后向用户负责人提供的报告
7.2.3程序优化
由于应用系统在使用过程中会不断的有需求变更和需求增加，这些增加和变更的程序迫于时间压力上线后可能会存在一些问题，为系统的稳定运行造成一些隐患。
所以要定期对运行的程序进展优化，并形成相应的版本。
定期检查各个应用数据库的大小，使用百分比。
优化首先应当在测试服务器上进展，当确定运行没有问题后，以报告形式报用户负责人批准，在用户下班后在生产系统中进展割接。
7.2.3.1工作流程
图表6程序优化流程
7.2.3.2提交文档
序号
文档名称
命名规如此
文档说明
提交时间/承受人
1
系统运行报告
项目名称_系统运行报告_年月日
在开发服务器上的对新开发功能的测试描述
程序优化后/用户负责人与公司维护经理
2
优化方法
可作为维护经验共享
7.3故障类维护
故障类维护包括：
图表8故障类维护
7.3.1故障处理流程
在系统上线后，客户将开始正式使用系统，故障将直接影响到客户的满意度，因此对于故障的发现、报告、处理、反响，将直接影响到客户对我们公司的评价，
故障定义有如下几种：
1.宕机：
是指在用户工作时间内系统服务中止，无论是系统自动停止服务还是我方因其他原因中断服务；
2.切换：
HA切换是指系统发生故障后由原应用所在服务器切换到另一台互为HA切换的服务器上。
7.3.1.1工作流程
图表9故障上报流程图
7.3.1.2提交文档
序号
文档名称
命名规如此
文档说明
提交时间/承受人
1
故障处理单
项目名称_故障处理单_年月日
在生产系统发生故障时填写，描述故障原因、现象、解决方法等。
系统发生故障15分钟内/公司维护经理与总经理
2
日志信息
项目名称_日志_年月日
系统发生故障时所产生的日志信息
3
故障报告
项目名称_故障报告_年月日
描述故障原因、现象、解决方法等。
系统故障解决后/用户负责人
7.3.1.3故障响应
系统发生应用系统软件故障响应时间为1小时，在2小时内保证恢复正常工作。
7.3.2HA切换流程
系统发生故障并HA切换后，需要按照如下流程将系统切换恢复正常状态。
7.3.2.1工作流程
图表10HA切换流程图
7.3.2.2提交文档
序号
文档名称
命名规如此
文档说明
提交时间/承受人
1
HA切换记录
项目名称_HA切换记录_年月日
系统HA切换的记录
HA切换后/公司维护经理
8维护性能指标
8.1系统主机局部
1）Linux每个文件系统的数据目录已用空间/这个文件系统的物理空间<80%；
2）主机的CPU已使用能力/CPU总能力<70%。
3）主机系统为SOLORIS的应用程序已用内存空间/内存物理空间<70%。
主机系统为AIX的应用程序已用内存空间需要从二方面去查看，一是内存空闲，一是Paging使用率，假如内存空闲小同时Paging使用率<50%时，如此内存不足。
当各个设备的CPU利用率和内存利用率满足上述要求时，我们认为设备工作正常。
假如超过上限值，设备的性能将会下降，应与时处理。
8.2应用系统局部
*这个也根据具体系统再定
升级会员 