某公司运维服务部管理流程说明28853.docx

上传人:you****now 文档编号:62742576 上传时间:2022-11-22 格式:DOCX 页数:40 大小:379.01KB
返回 下载 相关 举报
某公司运维服务部管理流程说明28853.docx_第1页
第1页 / 共40页
某公司运维服务部管理流程说明28853.docx_第2页
第2页 / 共40页
点击查看更多>>
资源描述

《某公司运维服务部管理流程说明28853.docx》由会员分享,可在线阅读,更多相关《某公司运维服务部管理流程说明28853.docx(40页珍藏版)》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

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.11维护质质量审计计64.1.22客户满满意度调调查64.2被被动式服服务74.2.11电话及及邮件应应答服务务74.2.22远端服服务74.2.33现场服服务74.3人人性化服服务75维护制制度85.1值值班制和和专人维维护制85.2服服务监督督机制85.3客客户回访访制度85.4

2、故故障定义义及报告告制度85.4.11.1故障级级别85.4.11.2支持响响应时间间95.5节节假日服服务保障障制度96维护管管理流程程106.1运运维组周周例会106.1.11说明106.1.22提交文文档106.2运运维人员员周报106.2.11说明106.2.22提交文文档106.3规规范使用用116.4维维护审计计116.4.11维护过过程审计计116.4.22软件管管理审计计126.4.33硬件管管理审计计126.4.44文档审审计127客服流流程137.1定定期类维维护147.1.11每日147.1.11.1工作内内容147.1.11.2提交文文档157.1.22每周157.1.

3、22.1工作内内容157.1.22.2提交文文档167.1.33每月177.1.33.1工作内内容177.1.33.2提交文文档187.1.33.3注意事事项187.2不不定期类类维护187.2.11需求变变更197.2.11.1工作流流程197.2.11.2提交文文档207.2.22割接上上线227.2.22.1工作流流程227.2.22.2提交文文档247.2.33程序优优化247.2.33.1工作流流程257.2.33.2提交文文档257.3故故障类维维护267.3.11故障处处理流程程267.3.11.1工作流流程277.3.11.2提交文文档297.3.11.3故障响响应297.3.

4、22HA切换换流程297.3.22.1工作流流程307.3.22.2提交文文档308维护性性能指标标308.1系系统主机机部分308.2应应用系统统部分311 引言1.1 编写目的本文档将指指导各地地运维组组有效、高高质的实实施服务务。包括括:维护护理念、维维护类型型、维护护制度等等。在维维护工作作未开展展之前,需需各个运运维主管管认真阅阅读本文文档,并并对运维维人员进进行必要要的培训训,使运运维人员员熟悉维维护的流流程及相相关制度度。在维维护过程程中,运运维主管管要严格格按照此此文档的的流程组组织维护护工作,以以提高、增增强维护护质量。在项目维维护过程程中,运运维主管管或运维维人员若若发现流

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

6、司服务的的对外窗窗口,为为客户提提供服务务,确保保所有客客户在工工作期间间,在任任何时候候、任何何地方、出出于任何何原因,都都可以方方便地与与维护项项目组进进行联系系,获得得满意的的服务。3.2 提供标准化化的服务务质量客户的每次次要求,都都将在维维护记录录库建建立,并并一直被被监控,直直到问题题得到圆圆满的解解决。客客户不需需要重复复同一个个问题,也也不用担担心自己己的问题题有如石石沉大海海。每一类问题题的处理理将建立立标准的的时限要要求,如如果超出出规定时时限,公公司会对对相关人人员做出出处理。公公司会对对维护项项目组整整个维护护工作进进行监控控和定期期考核。 3.3 服务支持手手段4 维

7、护类型4.1 主动式服务务4.1.1 维护质量审审计建议公司额额外组建建QA组组,定期期开展质质量审计计工作,对对在用系系统进行行全面检检查并现现场分析析问题,发发现问题题及其隐隐患,及及时予以以解决。4.1.2 客户满意度度调查通过电话、信信函、现现场、传传真、ee-maail等等方式向向客户发发放调查查问卷,了了解客户户对公司司所开发发系统的的技术支支持情况况、系统统运行情情况等各各方面的的满意度度评价,并并对调查查结果进进行统计计分析,对对于存在在的问题题及时寻寻求处理理解决办办法,以以逐步提提高客户户满意度度。4.2 被动式服务务4.2.1 电话及邮件件应答服服务当客户出现现问题或或故

8、障后后需要寻寻求帮助助,首先先可以通通过电话话或邮件件请求支支持帮助助和指导导,及时时解决问问题或排排除故障障。4.2.2 远端服务当客户应答答服务无无法排除除故障时时,在最最终客户户授权的的前提下下,可根根据客户户方提供供的问题题现象和和故障描描述,通通过接入入客户在在用系统统来指导导客户方方技术人人员或直直接处理理系统故故障。在在登录访问问系统前,客客户需给给出必要要的口令令。4.2.3 现场服务在维护工作作中,电话话应答服服务及远远端服务是是解决问问题、处处理故障障的第一一步,因因为在时时效上电电话应答答及远程程服务将将明显高高于现场场服务。但但当电话话应答服服务及远远程服务务无法解解决

9、客户户提出的的服务请请求时,我我们将指指定运维维人员在在尽可能能短的时时间内在在现场进进行服务务,以求求问题的的最终解解决。4.3 人性化服务务每个人都喜喜欢与众众不同的的东西,这这是人的的本性。人人性化服服务就是是要尊重重以人为为本的服服务理念念,尊重重客户个个性,尊尊重客户户的习惯惯,尊重重客户的的喜好。人人性化服服务就是是要求提提供的服服务能被被客户所所接受和和喜爱,超超出客户户的期望望值。当当与无法法满足客客户的期期望值时时,需要要进行分分析原因因并采取取纠正措措施,给给客户一一个满意意的回复复。5 维护制度5.1 值班制和专专人维护护制运维组人员员将设立立值班表表,每日日值班人人员将

10、负负责系统统的日常常检查及及日常维维护。运维人员在在接到客客户服务务请求或或问题投投诉,无无论是否否属于自自己工作作职责范范围,都都会做出出反应,并并将问题题详细记记录下来来,及时时解决,争争取不让让客户打打第二次次电话。5.2 服务监督机机制为保证各维维护项目目组的维维护质量量,对此此工作设设定关键键绩效指指标,每每月进行行考核,集中进行奖优罚劣,确保维护流程得到有效地执行,从而提高维护质量。5.3 客户回访制制度 通通过双方方建立起起良好的的关系,增增进与客客户之间间的沟通通交流,收收集、整整理完整整准确的的客户资资料信息息,建立立起客户户档案库库,是开开展客户户关系管管理的重重要前提提,

11、以逐逐步形成成一套完完整的客客户信息息平台。确定客户类型,并针对不同类型的客户,制定相应的回访频次及回访方式。通过电话、现场等方式回访客户,收集在用系统的问题及需求,了解客户对我公司维护工作的意见和建议,以逐步改善我们的软件质量和维护水平。5.4 故障定义及及报告制制度根据系统维维护经验验,对系系统故障障做了明明确的故故障级别别定义并并确定相相应的故故障确诊诊时限,并并采取上上报制度度,保证证给予客客户最有有效的解解决方案案。5.4.1.1 故障级别根据故障性性质的严严重性及及对客户造成成的影响响程度,把把故障分为为三级:一级故障指非常常严重的的故障,如如系统崩崩溃,主主机瘫痪痪等,对对最终客

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

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

14、假日期期间,系系统运行行过程中中出现问问题时能能够及时时得到技技术人员员的支持持,使在在用系统统得以正正常运行行,为客客户提供供放心周周到的服服务。6 维护管理流流程6.1 运维组周例例会6.1.1 说明运维主管组组织项目目组运维维人员在在每周一一下午114:000召开开周例会会,讨论论处理上上周遗留留问题及及本周需需要解决决的问题题。6.1.2 提交文档序号文档名称命名规则文档说明提交时间/接受人人1会议纪要项目名称_会议纪纪要_年年月日每次项目组组的会议议记录,包包括:周周例会、小小组讨论论会每周一下班班前/公公司维护护经理6.2 运维人员周周报6.2.1 说明项目运维人人员应于于每周日日

15、晚提交交项目TTimee Shheett给运维维主管,总总结本周周工作。运运维主管管也应于于每周日日晚提交交项目TTimee Shheett给维护护经理,总总结本周周维护组组工作情情况。6.2.2 提交文档序号文档名称文档说明1问题日志提交至运维维部门经经理,记记录本周周存在问问题2工时记录提交至运维维部门经经理,记记录本周周工作情情况6.3 规范使用1、 文档规范所有文档都都遵循模模板,文文档中非非标题部部分全部部采用正正文格式式。2、 会议纪要每次运维组组的讨论论,需要要指定人人员进行行会议记记录,一一般在例例会后分分发给相相关人员员,最晚晚不要超超过当天天。3、 备份项目涉及的的代码程程

16、序、文文档、会会议纪要要等资料料需要由由各运维维主管统统一保管管。6.4 维护审计为帮助各运运维组在在维护工工作上能能够提高高工作质质量,将将由QAA人员不不定期对对各运维维组进行行检查及及审计。6.4.1 维护过程审审计l 运维组审计计1、 维护组的大大小是否否适应系系统的规规模和要要求。2、 维护组中人人员的职职责分工工是否明明确。3、 维护组是否否有一套套科学的的内部管管理机制制和协调调工作机机制。l 系统总体审审计1、 维护过程是是否按维维护规范范进行。2、 运维人员的的交替是是否按照照维护规规范进行行。3、 是否能把握握住系统统运行状状况达到到性能管管理及资资源的有有效利用用。4、

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

18、、 修改程序的的测试是是否由用用户参加加。4、 修改程序的的测试结结果是否否得到开开发、运运行、维维护及用用户负责责人的认认可。5、 修改的程序序的测试试结果是是否记录录下来,并并进行保保管。6、 割接前是否否向用户户提交割割接计划划,割接接后是否否向用户户反馈割割接报告告。l 割接上线后后系统的的运行审审计1、 是否对修改改前的程程序及数数据做好好了备份份。2、 运行负责人人是否验验证其系系统不受受影响。3、 运行中若出出现问题题是否及及时恢复复到修改改前程序序,是否否对数据据进行备备份。6.4.3 硬件管理审审计1、 是否有硬件件的故障障对策。2、 是否对硬件件的利用用状况进进行记录录,并

19、定定期进行行分析。6.4.4 文档审计l 文档编制的的审计要要点1、 是否遵守文文档编制制规范。2、 文档的种类类、目的的、制作作方法等等是否明明确。l 文档管理的的审计要要点1、 是否制定和和遵守文文档管理理规则。2、 文档更新是是否得到到相关人人员认可可。3、 在系统需求求更新时时,文档档内容是是否进行行更新,并并留下更更新记录录。4、 文档的拷贝贝及废除除是否有有对不正正当行为为的防范范及机密密保护的的对策。7 客服流程为了保障系系统的正正常、可可靠运行行,必须须有一整整套客服服流程来来保障系系统维护护的操作作。根据据维护操操作对于于系统的的影响,我我将客户户服务分分为三类类:第一类是定

20、定期维护护,其主主要操作作是监测测系统的的运行状状况、对对客户的的支持等等,但不不影响和和干涉系系统的正正常运行行,只执执行“读”操作;第二类是不不定期维维护,其其主要操操作是系系统有新新的需求求需要修修改并割割接到正正式系统统中,或或因用户户量、文文档量增增多时对对程序的的优化。属属于“写”操作。由由于该操操作将影影响系统统的运行行,需要要谨慎对对待;第三类是故故障类处处理,对对系统出出现的故故障及时时予以排排除。流程图如下下:图表1 软件件维护流流程7.1 定期类维护护定期类维护护按以下下阶段进进行分类类:每日日、每周周、每月月。下面的文档档提到的的日报,周周报,月月报模板板我可根根据运维

21、维具体内内天制定定图表2 定定期类维维护7.1.1 每日7.1.1.1 工作内容l 系统及应用用的每日日检查每天的值班班人员早早晨到达达办公室室后,首首先要做做所有系系统的日日常检查查。日常常检查包包括:硬硬件检查查及软件件检查。硬硬件方面面主要是是检查系系统各项项指标是是否正常常,软件件方面主主要是检检查系统统是否能能够正常常登陆,相相关模块块是否能能够正常常进入。并并填写系系统日报报。l 客户支持接听电话、邮邮件支持持或现场场解决用用户提出出的问题题,主要要工作有有: 当用户发生生变化时时,及时时调整系系统内部部参数设设置,保保障系统统数据的的即时性性; 当客户流程程发生变变化时,及及时调

22、整整配置文文件,保保证系统统正确流流转。 协助用户解解决在使使用当中中遇到的的问题; 发生灾难性性事故时时,迅速速完成系系统的恢恢复; 数据的备份份及恢复复;l 维护记录客户问题解解决后将将所解决决的问题题及时记记入维维护记录录库中中。7.1.1.2 提交文档序号文档名称命名规则文档说明提交时间/接受人人1系统日报项目名称_系统日日报系统每日运运行情况况每天下班前前/维护护主管维护主管每每周合周周报一并并提交7.1.2 每周7.1.2.1 工作内容l 系统全面检检查在本周结束束时,要要对系统统做阶段段检查。并并填写系系统周报报。检检查包括括:1、系统使使用情况况 CPU和MMemoo的平均均空

23、闲、利利用率 磁盘使用 系统备份2、应用系系统的使使用情况况 *:具具体的软软件系统统具体再再说,因因我现在在不了解解具体各各的服务务内容。 新增哪些应应用和需需求,割割接上线线后使用用情况 存在问题及及解决方方案、已已解决问问题l 对于用户要要求的响响应时间间 系统运行中中出现的的错误应应立即修修改; 需求的变更更和增加加,需运运维人员员对其工工作量进进行评估估后答复复用户。答答复的时时间不得得晚于三三天。 *其他,根根据个地地软硬件件的服务务内容定定。l 对于应用系系统在本本周中存存在的问问题,修修改时间间有如下下约定: 系统中出现现的简单单错误,由由运维人人员自行行解决,记记入维维护记录

24、录库中中。 对于较小程程度的修修改在星星期一、星星期二、星星期三晚晚上进行行。 对于较大程程度的修修改在周周五晚上上及周末末进行。 属于比较重重大的问问题,例例如系统统宕机、系系统发生生错误等等,由运运维主管管安排相相关人员员尽快处处理。 故障发生后后,必须须查明原原因,要要及时将将故障处处理报告告上报用用户负责责人及公公司维护护经理。从从中吸取取经验教教训,采采取有效效措施防防止再次次发生。l 更换管理员员ID密密码运维人员必必须每周周将管理理员IDD文件的的密码更更换,以以防管理理员身份份被他人人盗用。l 管理员Addminn口令使使用记录录为防止addminn的IDD文件流流失,被被多人

25、使使用,必必须在使使用Addminn口令后后对此进进行记录录。7.1.2.2 提交文档序号文档名称命名规则文档说明提交时间/接受人人1系统周报项目名称_系统周周报系统每周运运行情况况每周日之前前/公司司维护经经理及用用户负责责人2Adminn口令使使用记录录项目名称_ Addminn口令使使用记录录管理员Addminn口令使使用情况况7.1.3 每月7.1.3.1 工作内容l 系统全面检检查在每月未要要对系统统做全面面检查。并并填写系系统月报报。汇汇总当月月系统的的状况,提提前预见见、发现现可能出出现的问问题,并并针对系系统情况况、问题题提出合合理化建建议。检检查包括括:1、系统使使用情况况:

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

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

28、录进进行统计计3月度工作状状况总结结表姓名_月度度工作情情况总结结表运维人员每每月工作作状况总总结4维护值班表表项目名称_月份_维护值值班表下月运维人人员值班班表记录录7.1.3.3 注意事项 日常维护中中如在工工作时间间若发现现系统故故障,非非客户要要求下决决不能进进行更改改。非工工作时间间发生故故障,应应立即解解决。 若故障影响响到系统统使用,在在经得用用户负责责人同意意的情况况下,进进行故障障处理。 若故障不会会对系统统使用造造成大的的影响,故故障的解解决时间间为当日日的非工工作时间间。 若当日的非非工作时时间不能能解决故故障。安安排在当当周的休休息日进进行解决决。 如发现办公公系统的的

29、服务器器进行了了HA切切换,则则应在用用户下班班后再切切换回正正确的服服务器。决决不能在在用户上上班时进进行切换换,以防防对用户户的工作作造成影影响。7.2 不定期类维维护不定期类维维护包括括:需求求变更流流程、割割接上线线流程及及程序优优化流程程。图表3 不不定期类类维护7.2.1 需求变更7.2.1.1 工作流程需求变更过过程主要要是依据据用户或或项目人人员提出出的需求求变更请请求与用用户进行行协调,以以确认需需求更改改的可行行性、合合理性、工工作量和和影响范范围。图表4 需需求变更更流程图图7.2.1.2 提交文档序号文档名称命名规则文档说明提交时间/接受人人1需求变更申申请单需求变更申

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

31、割接计划项目名称_割接计计划_年年月日在生产系统统上进行行割接工工作之前前制定的的割接计计划割接上线前前/用户户负责人人及公司司维护经经理3割接申请割接申请_年月日日申请在生产产系统上上进行割割接工作作割接上线前前/用户负责人人4割接报告项目名称_割接报报告_年年月日在生产系统统上割接接成功后后向用户户负责人人提供的的报告割接上线后后/用户户负责人人及公司司维护经经理5割接失败败报告项目名称_割接失失败报告告_年月月日在生产系统统上割接接失败后后向用户户负责人人提供的的报告7.2.3 程序优化由于应用系系统在使使用过程程中会不不断的有有需求变变更和需需求增加加,这些些增加和和变更的的程序迫迫于

32、时间间压力上上线后可可能会存存在一些些问题,为为系统的的稳定运运行造成成一些隐隐患。所所以要定定期对运运行的程程序进行行优化,并并形成相相应的版版本。定定期检查查各个应应用数据据库的大大小,使使用百分分比。优优化首先先应当在在测试服服务器上上进行,当当确定运运行没有有问题后后,以报报告形式式报用户户负责人人批准,在在用户下下班后在在生产系系统中进进行割接接。7.2.3.1 工作流程图表6 程程序优化化流程7.2.3.2 提交文档序号文档名称命名规则文档说明提交时间/接受人人1系统运行报报告项目名称_系统运运行报告告_年月月日在开发服务务器上的的对新开开发功能能的测试试描述程序优化后后/用户户负

33、责人人及公司司维护经经理2优化方法可作为维护护经验共共享7.3 故障类维护护故障类维护护包括:图表8 故故障类维维护7.3.1 故障处理流流程在系统上线线后,客客户将开开始正式式使用系系统,故故障将直直接影响响到客户户的满意意度,因因此对于于故障的的发现、报报告、处处理、反反馈,将将直接影影响到客客户对我我们公司司的评价价,故障定义义有如下下几种:1. 宕机:是指指在用户户工作时时间内系系统服务务中止,无无论是系系统自动动停止服服务还是是我方因因其他原原因中断断服务;2. 切换:HAA切换是是指系统统发生故故障后由由原应用用所在服服务器切切换到另另一台互互为HAA切换的的服务器器上。7.3.1

34、.1 工作流程图表9 故故障上报报流程图图7.3.1.2 提交文档序号文档名称命名规则文档说明提交时间/接受人人1故障处理单单项目名称_故障处处理单_年月日日在生产系统统发生故故障时填填写,描描述故障障原因、现现象、解解决方法法等。系统发生故故障155分钟内内/公司司维护经经理及总总经理2日志信息项目名称_日志_年年月日系统发生故故障时所所产生的的日志信信息3故障报告项目名称_故障报报告_年年月日描述故障原原因、现现象、解解决方法法等。系统故障解解决后/用户负负责人7.3.1.3 故障响应系统发生应应用系统统软件故故障响应应时间为为1小时时,在22小时内内保证恢恢复正常常工作。7.3.2 HA

35、切换流流程系统发生故故障并HHA切换换后,需需要按照照下列流流程将系系统切换换恢复正正常状态态。7.3.2.1 工作流程图表10 HAA切换流流程图7.3.2.2 提交文档序号文档名称命名规则文档说明提交时间/接受人人1HA切换记记录项目名称_ HAA切换记记录_年年月日系统HA切切换的记记录HA切换后后/公司司维护经经理8 维护性能指指标8.1 系统主机部部分1) LLinuux 每个文文件系统统的数据据目录已已用空间间/这个文文件系统统的物理理空间 800%;2) 主机机的CPPU已使使用能力力/CPPU总能能力 70%。3) 主机机系统为为SOLLORIIS的应应用程序序已用内内存空间间/内存物物理空间间 70%。主机系统为为AIXX的应用用程序已已用内存存空间需需要从二二方面去去查看,一一是内存存空闲,一一是Paaginng使用用率,若若内存空空闲小同同时Paaginng使用用率 50%时,则则内存不不足。当各个设备备的CPPU利用用率和内内存利用用率满足足上述要要求时,我我们认为为设备工工作正常常。若超超过上限限值,设设备的性性能将会会下降,应应及时处处理。8.2 应用系统部部分 * 这个个也根据据具体系系统再定定 第39页

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 管理文献 > 管理手册

本站为文档C TO C交易模式,本站只提供存储空间、用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。本站仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知淘文阁网,我们立即给予删除!客服QQ:136780468 微信:18945177775 电话:18904686070

工信部备案号:黑ICP备15003705号© 2020-2023 www.taowenge.com 淘文阁