运维服务部门管理流程179399.docx

运维服务部部管理流程说说明维护管理流程说明 目录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故故障定义及及报告制度度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.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.22HA切换流流程297.3.22.1工作流程程307.3.22.2提交文档档308维护性性能指标308.1系系统主机部部分308.2应应用系统部部分311 引言1.1 编写目的本文档将指指导各地运运维组有效效、高质的的实施服务务。包括：维护理念念、维护类类型、维护护制度等。在在维护工作作未开展之之前，需各各个运维主主管认真阅阅读本文档档，并对运运维人员进进行必要的的培训，使使运维人员员熟悉维护护的流程及及相关制度度。在维护护过程中，运运维主管要要严格按照照此文档的的流程组织织维护工作作，以提高高、增强维维护质量。在项目维维护过程中中，运维主主管或运维维人员若发发现流程有有缺陷或需需要补充的的，请及时时反馈至公公司，确保保流程能够够及时得到到更新，以以达到规范范性、可操操作性。1.2 编写说明本文档的阅阅读对象包包括：l 公司领导l 运维主管l 项目组运维维人员2 维护理念2.1 维护宗旨与客户紧密密配合，尽尽公司所能能，为客户户提供快捷捷、优质的的服务，让让客户省心心，让客户户放心。2.2 维护范围为客户提供供热线、现场场服务及业业务覆盖范范围内的服服务实施。2.3 响应服务速速度在用户工作作期间提供供服务电话或或邮件、现现场支持，在系系统出现严严重故障时时提供244小时支持持。3 维护保证3.1 提供统一接接口驻点维护作作为公司服服务的对外外窗口，为为客户提供供服务，确确保所有客客户在工作作期间，在在任何时候候、任何地地方、出于于任何原因因，都可以以方便地与与维护项目目组进行联联系，获得得满意的服服务。3.2 提供标准化化的服务质质量客户的每次次要求，都都将在维维护记录库库建立，并并一直被监监控，直到到问题得到到圆满的解解决。客户户不需要重重复同一个个问题，也也不用担心心自己的问问题有如石石沉大海。每一类问题题的处理将将建立标准准的时限要要求，如果果超出规定定时限，公公司会对相相关人员做做出处理。公公司会对维维护项目组组整个维护护工作进行行监控和定定期考核。 3.3 服务支持手手段4 维护类型4.1 主动式服务务4.1.1 维护质量审审计建议公司额额外组建QQA组，定期开开展质量审审计工作，对对在用系统统进行全面面检查并现现场分析问问题，发现现问题及其其隐患，及及时予以解解决。4.1.2 客户满意度度调查通过电话、信信函、现场场、传真、e-mail等方式向客户发放调查问卷，了解客户对公司所开发系统的技术支持情况、系统运行情况等各方面的满意度评价，并对调查结果进行统计分析，对于存在的问题及时寻求处理解决办法，以逐步提高客户满意度。4.2 被动式服务务4.2.1 电话及邮件件应答服务务当客户出现现问题或故故障后需要要寻求帮助助,首先可以以通过电话话或邮件请求求支持帮助助和指导，及及时解决问问题或排除除故障。4.2.2 远端服务当客户应答答服务无法法排除故障障时，在最最终客户授授权的前提提下，可根根据客户方方提供的问问题现象和和故障描述述，通过接接入客户在在用系统来来指导客户户方技术人人员或直接接处理系统统故障。在在登录访问系统前，客客户需给出出必要的口口令。4.2.3 现场服务在维护工作作中，电话应答服服务及远端端服务是解解决问题、处处理故障的的第一步，因因为在时效效上电话应答及及远程服务务将明显高高于现场服服务。但当当电话应答服服务及远程程服务无法法解决客户户提出的服服务请求时时，我们将将指定运维维人员在尽尽可能短的的时间内在在现场进行行服务，以以求问题的的最终解决决。4.3 人性化服务务每个人都喜喜欢与众不不同的东西西，这是人人的本性。人人性化服务务就是要尊尊重以人为为本的服务务理念，尊尊重客户个个性，尊重重客户的习习惯，尊重重客户的喜喜好。人性性化服务就就是要求提提供的服务务能被客户户所接受和和喜爱，超超出客户的的期望值。当当与无法满满足客户的的期望值时时，需要进进行分析原原因并采取取纠正措施施，给客户户一个满意意的回复。5 维护制度5.1 值班制和专专人维护制制运维组人员员将设立值值班表，每每日值班人人员将负责责系统的日日常检查及及日常维护护。运维人员在在接到客户户服务请求求或问题投投诉，无论论是否属于于自己工作作职责范围围，都会做做出反应，并并将问题详详细记录下下来，及时时解决，争争取不让客客户打第二二次电话。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 说明运维主管组组织项目组组运维人员员在每周一一下午144:00召召开周例会会，讨论处处理上周遗遗留问题及及本周需要要解决的问问题。6.1.2 提交文档序号文档名称命名规则文档说明提交时间/接受人1会议纪要项目名称_会议纪要要_年月日日每次项目组组的会议记记录，包括括：周例会会、小组讨讨论会每周一下班班前/公司司维护经理理6.2 运维人员周周报6.2.1 说明项目运维人人员应于每每周日晚提提交项目TTime Sheeet给运维维主管，总总结本周工工作。运维维主管也应应于每周日日晚提交项项目Timme Shheet给给维护经理理，总结本本周维护组组工作情况况。6.2.2 提交文档序号文档名称文档说明1问题日志提交至运维维部门经理理，记录本本周存在问问题2工时记录提交至运维维部门经理理，记录本本周工作情情况6.3 规范使用1、 文档规范所有文档都都遵循模板板，文档中中非标题部部分全部采采用正文格格式。2、 会议纪要每次运维组组的讨论，需需要指定人人员进行会会议记录，一一般在例会会后分发给给相关人员员，最晚不不要超过当当天。3、 备份项目涉及的的代码程序序、文档、会会议纪要等等资料需要要由各运维维主管统一一保管。6.4 维护审计为帮助各运运维组在维维护工作上上能够提高高工作质量量，将由QQA人员不不定期对各各运维组进进行检查及及审计。6.4.1 维护过程审审计l 运维组审计计1、 维护组的大大小是否适适应系统的的规模和要要求。2、 维护组中人人员的职责责分工是否否明确。3、 维护组是否否有一套科科学的内部部管理机制制和协调工工作机制。l 系统总体审审计1、 维护过程是是否按维护护规范进行行。2、 运维人员的的交替是否否按照维护护规范进行行。3、 是否能把握握住系统运运行状况达达到性能管管理及资源源的有效利利用。4、 是否记录事事故及故障障内容，并并向用户负负责人及公公司维护经经理报告。5、 是否找出事事故及故障障的原因，并并采取措施施防止再次次发生。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 文档编制的的审计要点点1、 是否遵守文文档编制规规范。2、 文档的种类类、目的、制制作方法等等是否明确确。l 文档管理的的审计要点点1、 是否制定和和遵守文档档管理规则则。2、 文档更新是是否得到相相关人员认认可。3、 在系统需求求更新时，文文档内容是是否进行更更新，并留留下更新记记录。4、 文档的拷贝贝及废除是是否有对不不正当行为为的防范及及机密保护护的对策。7 客服流程为了保障系系统的正常常、可靠运运行，必须须有一整套套客服流程程来保障系系统维护的的操作。根根据维护操操作对于系系统的影响响，我将客客户服务分分为三类：第一类是定定期维护，其其主要操作作是监测系系统的运行行状况、对对客户的支支持等，但但不影响和和干涉系统统的正常运运行，只执执行“读”操操作；第二类是不不定期维护护，其主要要操作是系系统有新的的需求需要要修改并割割接到正式式系统中，或或因用户量量、文档量量增多时对对程序的优优化。属于于“写”操操作。由于于该操作将将影响系统统的运行，需需要谨慎对对待；第三类是故故障类处理理，对系统统出现的故故障及时予予以排除。流程图如下下：图表1 软件维护护流程7.1 定期类维护护定期类维护护按以下阶阶段进行分分类：每日日、每周、每每月。下面的文档档提到的日日报，周报报，月报模模板我可根根据运维具具体内天制制定图表2 定定期类维护护7.1.1 每日7.1.1.1 工作内容l 系统及应用用的每日检检查每天的值班班人员早晨晨到达办公公室后，首首先要做所所有系统的的日常检查查。日常检检查包括：硬件检查查及软件检检查。硬件件方面主要要是检查系系统各项指指标是否正正常，软件件方面主要要是检查系系统是否能能够正常登登陆，相关关模块是否否能够正常常进入。并并填写系系统日报。l 客户支持接听电话、邮邮件支持或或现场解决决用户提出出的问题，主主要工作有有：Ø 当用户发生生变化时，及及时调整系系统内部参参数设置，保保障系统数数据的即时时性；Ø 当客户流程程发生变化化时，及时时调整配置置文件，保保证系统正正确流转。Ø 协助用户解解决在使用用当中遇到到的问题；Ø 发生灾难性性事故时，迅迅速完成系系统的恢复复；Ø 数据的备份份及恢复；l 维护记录客户问题解解决后将所所解决的问问题及时记记入维护护记录库中中。7.1.1.2 提交文档序号文档名称命名规则文档说明提交时间/接受人1系统日报项目名称_系统日报报系统每日运运行情况每天下班前前/维护主主管维护主管每每周合周报报一并提交交7.1.2 每周7.1.2.1 工作内容l 系统全面检检查在本周结束束时，要对对系统做阶阶段检查。并并填写系系统周报。检检查包括：1、系统使使用情况Ø CPU和MMemo的的平均空闲闲、利用率率Ø 磁盘使用Ø 系统备份2、应用系系统的使用用情况 *：具具体的软件件系统具体体再说，因因我现在不不了解具体体各的服务务内容。Ø 新增哪些应应用和需求求，割接上上线后使用用情况Ø 存在问题及及解决方案案、已解决决问题l 对于用户要要求的响应应时间Ø 系统运行中中出现的错错误应立即即修改；Ø 需求的变更更和增加，需需运维人员员对其工作作量进行评评估后答复复用户。答答复的时间间不得晚于于三天。Ø *其他，根根据个地软软硬件的服服务内容定定。l 对于应用系系统在本周周中存在的的问题，修修改时间有有如下约定定：Ø 系统中出现现的简单错错误，由运运维人员自自行解决，记记入维护护记录库中中。Ø 对于较小程程度的修改改在星期一一、星期二二、星期三三晚上进行行。Ø 对于较大程程度的修改改在周五晚晚上及周末末进行。Ø 属于比较重重大的问题题，例如系系统宕机、系系统发生错错误等，由由运维主管管安排相关关人员尽快快处理。Ø 故障发生后后，必须查查明原因，要要及时将故故障处理报报告上报用用户负责人人及公司维维护经理。从从中吸取经经验教训，采采取有效措措施防止再再次发生。l 更换管理员员ID密码运维人员必必须每周将将管理员IID文件的的密码更换换，以防管管理员身份份被他人盗盗用。l 管理员Addmin口口令使用记记录为防止addmin的的ID文件流流失，被多多人使用，必必须在使用用Admiin口令后后对此进行行记录。7.1.2.2 提交文档序号文档名称命名规则文档说明提交时间/接受人1系统周报项目名称_系统周报报系统每周运运行情况每周日之前前/公司维维护经理及及用户负责责人2Adminn口令使用用记录项目名称_ Admmin口令令使用记录录管理员Addmin口口令使用情情况7.1.3 每月7.1.3.1 工作内容l 系统全面检检查在每月未要要对系统做做全面检查查。并填写写系统月月报。汇汇总当月系系统的状况况，提前预预见、发现现可能出现现的问题，并并针对系统统情况、问问题提出合合理化建议议。检查包包括：1、系统使使用情况：Ø CPU和MMemo的的平均空闲闲、利用率率Ø 磁盘使用Ø 系统备份2、应用系系统使用情情况：（月月统计）Ø 电话受理Ø 客户端的IIE升级和和配置Ø 人员组织调调整Ø 各应用数据据库状态Ø 存在问题及及解决方案案、已解决决问题Ø 等，具体了了解了各地地服务内容容可增减l 统计维护记记录将本地的维维护记录库库，传送送给公司维维护经理，以以便公司掌掌握各运维维组的系统统日常运行行过程中出出现问题的的频率及类类型，从而而为优化和和完善系统统提供信息息，维护经经理将提交交公司研发发中心加以以改进，并并将改进方方法通知各各运维主管管，使系统统越来越完完善。l 发布公告将本月系统统中人员调调整、新增增功能、问问题解决办办法以公告告的形式在在系统中向向用户公布布，增强客客户对系统统的信任度度。l 月度总结由运维人员员填写月月度工作状状况总结表表提交给给运维主管管，运维主主管也需要要填写，最最后由运维维主管以项项目组的方方式提交给给公司维护护经理。l 维护值班表表提交用户负负责人下月月维护值班班表，和用用户说明每每天的值班班人员。7.1.3.2 提交文档序号文档名称命名规则文档说明提交时间/接受人1系统月报项目名称_系统月报报系统每月运运行情况每月月未/公司维护护经理及用用户负责人人2统计维护记记录项目名称_维护记录录_月份以exceel方式将将本月的维维护记录进进行统计3月度工作状状况总结表表姓名_月度度工作情况况总结表运维人员每每月工作状状况总结4维护值班表表项目名称_月份_维维护值班表表下月运维人人员值班表表记录7.1.3.3 注意事项Ø 日常维护中中如在工作作时间若发发现系统故故障，非客客户要求下下决不能进进行更改。非非工作时间间发生故障障，应立即即解决。Ø 若故障影响响到系统使使用，在经经得用户负负责人同意意的情况下下，进行故故障处理。Ø 若故障不会会对系统使使用造成大大的影响，故故障的解决决时间为当当日的非工工作时间。Ø 若当日的非非工作时间间不能解决决故障。安安排在当周周的休息日日进行解决决。Ø 如发现办公公系统的服服务器进行行了HA切换，则则应在用户户下班后再再切换回正正确的服务务器。决不不能在用户户上班时进进行切换，以以防对用户户的工作造造成影响。7.2 不定期类维维护不定期类维维护包括：需求变更更流程、割割接上线流流程及程序序优化流程程。图表3 不不定期类维维护7.2.1 需求变更7.2.1.1 工作流程需求变更过过程主要是是依据用户户或项目人人员提出的的需求变更更请求与用用户进行协协调，以确确认需求更更改的可行行性、合理理性、工作作量和影响响范围。图表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. 切换：HAA切换是指指系统发生生故障后由由原应用所所在服务器器切换到另另一台互为为HA切换的的服务器上上。7.3.1.1 工作流程图表9 故故障上报流流程图7.3.1.2 提交文档序号文档名称命名规则文档说明提交时间/接受人1故障处理单单项目名称_故障处理理单_年月月日在生产系统统发生故障障时填写，描描述故障原原因、现象象、解决方方法等。系统发生故故障15分分钟内/公公司维护经经理及总经经理2日志信息项目名称_日志_年月月日系统发生故故障时所产产生的日志志信息3故障报告项目名称_故障报告告_年月日日描述故障原原因、现象象、解决方方法等。系统故障解解决后/用用户负责人人7.3.1.3 故障响应系统发生应应用系统软软件故障响响应时间为为1小时，在在2小时内保保证恢复正正常工作。7.3.2 HA切换流流程系统发生故故障并HAA切换后，需需要按照下下列流程将将系统切换换恢复正常常状态。7.3.2.1 工作流程图表10 HA切切换流程图图7.3.2.2 提交文档序号文档名称命名规则文档说明提交时间/接受人1HA切换记记录项目名称_ HA切换换记录_年月日系统HA切切换的记录录HA切换后后/公司维维护经理8 维护性能指指标8.1 系统主机部部分1) LLinuxx 每个文文件系统的的数据目录录已用空间间/这个文件件系统的物物理空间 <80%；2) 主机机的CPUU已使用能能力/CPPU总能力力 <700%。3) 主机机系统为SSOLORRIS的应应用程序已已用内存空空间/内存物理理空间 << 70%。主机系统为为AIX的应应用程序已已用内存空空间需要从从二方面去去查看，一一是内存空空闲，一是是Pagiing使用用率，若内内存空闲小小同时Paagingg使用率< 50%时，则则内存不足足。当各个设备备的CPUU利用率和和内存利用用率满足上上述要求时时，我们认认为设备工工作正常。若若超过上限限值，设备备的性能将将会下降，应应及时处理理。8.2 应用系统部部分 * 这个个也根据具具体系统再再定 第31页