ERP系统交维流程与规范标准

1、【系统交维流程与规】版本拟制日期2014-07-07审核日期批准日期修订历史记录版本日期AMD修订者说明V1.02014-7-7A新增规文档（A-添加，M-修改，D-删除）仁服务目标52. ERP系统交维流程73. ERP系统交维资产淸单114. ERP系统交维文档清单145. ERP系统交维文档要求165. 1用户手册（系统功能说明书）165.2 维护手册（系统技术说明书：包括软、破件架构说明）165.3 备份災略淸单（含历史及新増）175.4 系统资产清单（含历史及新増）175.5 系统配置淸单（包括安装地点信息，含历史及新增）175.6 接口淸单（含历史及新增）185.7 系统账号清单（

2、含接口账号，新增账号）185.8 新功能清单185.9 程序部署手册185. 10回退操作手册195. 11测试报告205. 12系统测试用例205. 13源代码216. ERP交维系统的压力测试226, 1压力测试目的226.2 压力测试工具226.3 压力测试用例226.4 压力测试指标及期望值226.5 压力测试数据及场景236.6 压力测试报告247. ERP系统交维的前提条件2571交维系统转交整改的条件278. ERP统一维护组维护容28329. 时间管理1. 服务目标各应用系统、应用平台建设周期完成，正式投入使用，系统建设部门舟其移交维护部门进行运行统 一维护。为规各应用系统、应

3、用平台从建设转为运行维护的流程，减少系统故障，缩短故障处理时 间，提商各应用系统、应用平台运行的稳定性、鬲效性，提供高质量的系统支撑，特制订本管理流 程。通过开展规化，流程化，知识化的维护服务，保持各应用系统、应用平台的稳定性和服务商效性， 并实现以下期望目标： 通过各个团队在运维管理、技术支持方面的经验知识，将现有的被动服务完全转变为主动 服务，用完善的制度与合理的流程确保应用系统持续稳定地运行，提升系统运维水平和服 务质量； 梳理各应用系统、应用平台运维的工作和各类流程，总结并制定各类工作流程，完故障 处理机制，建立故障处理.日常维护的知识管理体系，以缩短问题、故障处理时间，满足 服务响应

4、时限的要求； 配合维护主管全力以赴完成公司IT规划、项目管理、系统分析.系统建设等离价值.具 备核心竞争力的工作容，外包日常维护.故障处理等相对規.固定的工作容，实现分工粘 细化，员工专业化，服务标准化：量化维护工作容，实现维护工作标准化，制度化，显性 化； 最终按照ITIL标准建立信息服务体系和运维服务团队，实现“运维服务一体化”，“平台 管理智能化”，成本结构全面优化.运营效益显著提升的最终目标。本项 目要实现的服务目标服务1标洗程化规铠化快速响应实时处31定期跟踪全容户展夯全业务支持全周期管理全过程担CM标推化 刘识化构建运维体系握供全方位股务2. ERP系统交维流程步骤流程说明：信息系

5、统建设部门填写并提交应用系统交维申请表或应用平台交维申请表，应用系统或 应用平台进入交维申请流程。根損平台组提供的平台交维工作清单，检验建设方提供的平台网络拓 朴图、资产配置淸单、平台操作丈档及风险评估列表等等，通过服务组进行预接收。2. 1 评估预接收条件根据维护组提供的交维工作清单，检验建设方提供的网络拓朴图、资产配置淸单.维护手册、 用户手册.风险评估列表等等，通过维护组进行预接收。为保证各应用系统.应用平台的稳定运行, 建设方在交维吋，必须先达到以下应用交维条件：A. 应用系统功能可以为用户提供长时间不中断的、可用的服务.保证交维祈30天无故障 发生，90天无重大故障发生。B. 需要交

6、接的应用系统必须有一个与正式环境的业务数据、技术架构、部署环境完全一 样的测试环境。C. 配合完成1-2次交维培训，讲解平台的架构.业务逻辑、数据流转、目前维护流程和 常见的故障点等；若平台存在性能隐患及遗留问题，需建设方处理达到交维要求再接。 如平台软硬件性能瓶颈.可用应急环境、数据备份及监控时效性。D. 上线后出现的紧急与严重的缺陷必须解决。E. 按本丈第3、4、5幸要求提交相关清单及验收交维文档。F. 根据建设部门提交的备份说明丈档检查应用系统、应用平台的备份情况，容包括 服务器信息，备份路径、备份容、备份的频率，保留时长等信息。G. 根据建设部门提供的资产清单，清点%更件设备及核对网络

7、拓朴图、网线标签、虚拟机 与应用系统对应关系。确认资产信息是否已录入CMDB中，信息是否完整。H. 检查资源分配情况（服务器资源利用率不能超过80% （CPU、存）、负载均衡配置、存 储状况及IP地址使用情况）I. 服务器监控需接入IPNET或者ZABBIX,建设部门需提交监控指标信息，以及交维祈出 现的故障报告。J. 根据交维清单，平台维护组需要核对设备及相对应配置，如有遗留问题，建设方需根 据交维报告的整改容进行修复。K. 其中对于不同架构的系统可达到的维护可用性不同： 应用、数据库及枝件服务器都是双节点冗余的系统，维护可用性目标为99.9%: 应用、数据库及碇件服务器有一个是单节点的系统

8、，维护可用性目标为99抚 无磁带备份的系统，可容忍所有数据去失； 有磁带备份的系统，毎X天进行一次备份，可容忍X天数据去失。L. 系统必须具备必要的功能：接口连接等使用的程序账号必须能够方便的修改密码； 系统必须在应用界面上具备完善的用户权限管理功能： 系统必须提供必要的网管接口。2.2 各团队进行费用评估信息室费用评估一线服务台评估系统监控组评估7676平台维护纽评估维护室费用评估应用维护组评估中间件及数据库平台维护纽评估硬件服务器维护纽评估备份系统维护组评估网菅维护组评估4A维护组评估网络维护组评估机房环境维护组评估2.3费用申请维护室综合各团队的费用评估后进行娈用申请2.4 系统转维资源

9、准备应用系统在规划建设阶段就应该详细评估系统转维过程中所需的维护资源。目前信息系统部对于每一个应用系统转维护过程中所需资源如下图所示：系统转维过程中牵涉到的维护资源如上图所示。应用系统转入运维阶段后需要一些列的资源投 入，应用系统在转维护过程中应及时知会各维护资源提供方，同时提供项目相关维护文档以便转维 工作的顺利进行。2.5 维护组对应用系统、应用平台进行预接收检验预接收的交维文档及代码；预接收检验不通过，退回信息系统建设部门进行整改或资料补 充;召开交维培训会议，由建设方进行培训，了解日常维护工作及服务对象，提出常见故障及处理 办法。维护组对信息系统进行软硬件风险、缺陷诊断评估，对于有严重

10、安全风险以及有严重缺漏的， 则退回信息系统建设部门整改。2.6 进入为期一个月的试维护阶段跟业务用户召开职责分工会议，有目的地跟业务用户确认相关服务承诺，并给出职责分工表。试运维期间如系统出现批量安全漏洞、系统BUG等符合整改条件的，运维组将该系统移交系统 建设部门整改。各个维护组签收应用系统运维移交申请表或应用平台运维移交申请表，确立应用系统、 应用平台正式移交维护组运维.进入正式维护阶段。根据应用系统.应用平台维护涉及的容，可以分为4个维护层：硬件管理硬件故障由枝件原厂或者第三方维保处理。 网络管理网络霓略配置和故障处理由网络维护组负责。 系统管理基砂轶件管理，初步故障定位及处理交由平台维

11、护纽负责。如平台维护组无 法处理，则提交相对应专业维护组进行处理。 应用管理由应用维护纽进行日常维护，出现故障后由应用维护组进行故障定位，并组 织乞团队及时解决系统故障。应用系统流程图如下:厂:开始/应用系统建设部|迅出平台运维移交 申请M佶息室费用评估：一线服务台评估系统监控组评估7676平台维护组评估维护室费用评估：应用维护组评估中间件及数抵库平台维护组评估磧件服务器维护组评估备份系统维护组评估网管维护组评估4A维护组评估网络维护组评估机房环境维护组评估不通迥通过运维团队风险评佔（包 括应急演练）风险评估不通科运维团队签收应用系统运维移交申请表沌用正式进入统一维护组维护阶段应用条统运维移交

12、申请蚕-交维文档故障诊断处理报告维护工作列表疾统资产信息应用系统运维应用平台流程如下:流程开始丿平白系统建设部门腮出平台运维移交申请平台运维移交申诒表运维团队评估预接收条件平台资产消单 应用接入规范 平台运行报告 平台隠忠列表运维团队预接收不通过备份信息表监控策路消单凶用部署衣软硬件配贸清单第三方联系表网络设备配買表系统帐号列表基础环境配呂用户乎册通过运维团队配宜维护手册平台建设部门平台整改风险评估（包 括应急演练） 风险评估:通过运维团队试运维Q个月 是”噫否符合强改.、条件”运維团队不通过签收平台运维移交中诸表应用正式进入平台组维护阶段故障诊断处理报告 耀护工作列表系统资产信息平台运维移交

13、 中诸表3.2 存储及网络设备编号设备型号序列号设备名称IP地址配置信息3.3 软件资产列表软件名称版本号1 icense软件用途使用期限数量4.应用系统、应用平台交维文档清单序号文档名称运维用途说明备注1备份策略清单提供备份疑略清单，包括所在服务 器主机名、所在服务器IP、存储路 径、备份数抿量、备份我略名称、 备份方式及备份频率、备份窗口数 据保留时间等备份情况2应用测试报告开发商应根据测试案例在开发环境 进行新功能测试.回归测试、压力 测试并出具三种测试通过的测试报 告3存储配置及分 配淸单存储配置操作文档、配置情况 及分配清单4第三方联系人 员列表平台及应用干系人管理开发商、第三方开发

14、商、破件、 业务部门等相关负责人联系方 式5回退操作手册该丈档主要是用于二线平台维护人 员进行回退部署，开发商需对本次 回退部署过程进行详细的说明6基础环境部署 配置信息支撑及管理平台运行安装部署信息及账户密码7接口清单提供系统.应用层.数据库层、及 硬件层等接口清单8平台及应用故 障及隐患清单历史故障记录和维护记录、为优化 平台及降低风险提供依据历史故障记录和隐患清单9平台监控乗略 及监控清单告警时效性、及时性监控策略及清单10平台压力评估 报告应用系统压力测试报告（测试目的、 办法、工具、用例及测试指标期望 值）需要测试压力指标及测试报告11轶件安裝部署 及操作手册指导及管理系统管理操作1

15、2软件资产清单描述软件部署的环境、使用基铀软 件的版本、网络架构尽量能提供系统拓扑图13数据库交维淸 单数据库配置情况数据库建设方案、配置文档、 管理员账户密码、配置淸单及 故障处理报告14网络设备交维 清单网络架构及网络配置网络拓朴图、配置管理文档、 设备维保、网络配置淸单及日 常维护记录15维护手册该文档主要用于二线维护人员进行 技术维护，让维护人员能够参照手 册开展职责围的所有维护工作16系统测试用例开发商应根据业务需求说明书 编写新功能测试用例、回归测试用 例17系统配置清单提供系统.应用层.数扌居库层、及 硬件层等配置清单18系统维护工作 列表开发商目前在系统维护方面的工作 描述，包

16、括月度故障率、数据提取 量、数据调整情况、数据备份疑略 等尽量能提供维护管理手册19系统账号清单提供系统.应用层、数損库层、及 披件层等账号清单20系统资产清单若涉及到新增软件的情况，需提供 系统用到的所有license,包括I icense 序列号、I icense 文件、I icense开始时间、I icense到期吋 间、I icense联系人、I icense联系 方式21新功能淸单提供本次新交接的功能淸单及简要 说明22应急演练方案及报告快速恢复业务应急演练方案及应急环境23应用系统部署配置表系统架构及部署情况，资源使用情 况应用系统部署配置24应用系统接入流程规規化管理应用接入及许

17、源申请应用接入规25应用系统清单及吋响应应用系统维护，通知对应 千系人部署在平台上的应用系统清 单，包括应用用途、业务部门、 业务主管、维护商、维护人员、 开发商、开发人员等信息26应用虚拟机备 份我略表备份管理备份策略及备份清单27披件资产清单平台部署使用的披件资源提供网络拓扑图、网络布线（网 络及光纤）标签图、Z更件维保 信息28用户手册该文档供普通用户.维护人员及其 他需要了解系统功能的人员阅读29源代码开发商在交接前必须提供程序的源 代码，并保证源代码的完整性30资产信息录入CMDB 中配置管理5.应用系统、应用平台交维文档要求5.1用户手册（系统功能说明书）该文档供普通用户、维护人员

18、及其他需要了解系统功能的人员阅读，让上述人员能够全面掌握 系统所有功能的使用。新增版本的文档中应包括系统全部功能的使用说明，同时标注本次新增或变 更的容，基本要求如下：有结构、有层次的对系统支撑的业务场景及业务流程进行描述；有结构、有层次的对各用户界面的功能及各信息字段的含艾及限定进行详细说明：文档的详细程度要做到具备基本业务知识的但未接触过系统的用户通过阅读文档即可使用系 统。5.2 维护手册（系统技术说明书：包括软、夜件架构说明）该文档主要用于二线维护人员进行技术维护，让维护人员能够参照手册开展职责围的所有维护 工作。新增版本的丈档中应包括系统软硬件的技术架构说明，同时标注本次新增或变更的

19、容。该文档必须包括以下容：系统技术架构的说明：对应用系统的硬件服务器、数据库、中间件及流程引擎等其它软件 平台架构进行详细说明。系统核心逻辑的说明：针对主要的业务逻辑，结合程序进行详细说明。应用程序的模块架构说明：对各模块功能及相互间的逻辑联系进行说明，并分析数据的流 向。系统业务需求的技术实现方案说明：针对菜些常见和特殊业务进行的处理，通过该文档掌 握业务流程的处理。数据库表结构说明：对数据庠表的结构进行详细说明，并提供详细的数据字典和ER图。接口说明：针对于每个系统的接口进行说明，包括交互方式、交互数据源、交互频率等。定时器等专用服务的说明：说明其工作原理，使用说明等。脚本说明：针对常用脚

20、本、数据操作脚本、报表脚本等进行详细说明。程序包变更的说明，针对新增和修改的地方进行说明。提供操作系统、数据库、中间件及流程引擎等其它软件平台的主要配置及特殊配置要求；提供详细的应用程序各配置项及初始配置列表：提供应用程序预置账号及初始密码列表，提供数据库等平台访问账号及初始密码列表，提 供各系统接口账号及初始密码列表：文档的详细程度要做到具备基本技术知识的但未接触过系统的维护人员通过闻读文档即可进行 系统维护。5.3 操作配置手册（软件功能说明书）该文档供维护人员阅读，能够全面掌握系统所有功能的使用。应包括系统全部功能的使用说明, 同时标注本次新增或变更的容，基本要求如下：有结构、有层次的对

21、平台软取件操作场景及业务流程进行描述：有结构、有层次的对各用户界面的功能及各信息字段的含艾及限定进行详细说明；文档的详细程度要做到具备基本业务知识的但未接触过系统的用户通过阅读文档即可使用 系统。5.4 平台维护手册（系统技术说明书：包括软、域件架构说明）该文档主要用于平台维护人员进行技术维护，能够参照手册开展职责围的所有维护工作。该文 档必须包括以下容：系统技术架构的说明：对应用系统的硬件服务器、数据库、中间件及流程引擎等其它软件 平台架构进行详细说明。系统核心逻辑的说明：针对主要的业务逻辑，结合程序进行详细说明。系统业务需求的技术实现方案说明：针对菜些常见和特殊业务进行的处理，通过该文档掌

22、 握业务流程的处理。提供操作系统、数据库、中间件及流程引擎等其它软件平台的主要配置及特殊配置要求；提供详细的应用程序冬配置项及初始配置列表：提供应用程序预置账号及初始密码列表，提供数据库等平台访问账号及初始密码列表，提 供各系统接口账号及初始密码列麦：5.5 备份策略清单（含历史及新增）提供备份我略清单，包括所在服务器主机名、所在服务器IP、存储路径、备份数据量、备份疑 略名称、备份方式及备份频率、备份窗口数据保留时间等备份情况。若涉及到变更或者新增要标注并说明情况。5.6 软件资产清单含历史及新增）若涉及到新增软件的请况，需提供系统用到的所有I icense,包括I i cense序列号、l

23、icense文 件、license开始时间、license到期时间、license联系人、license联系方式。5.7 系统配覺清单包括安装地点信息，含历史及新增）提供操作系统、数扌居库、中间件及流程引擎等其它软件平台的主要配置及特殊配置要求：提供详细的应用程序各配置项及初始配置列表；提供应用程序预置账号及初始密码列表，提供数据库等平台访问账号及初始密码列表，提供各 系统接口账号及初始密码列表；若涉及到变更或者新增要标注并说明情况。5.8 接口清单（含历史及新增）提供数据库新增接口清单，包括接口提供方、消费方、调用频率、同步程序、调用方式、调用 配置（用户名、密码）、接口约定（报错代码、报错

24、提示、报错含狡等）、接口视图。提供Webservice新增接口清单，包括接口提供方、消费方、调用频率、同步程序、调用地址、 调用配置（用户名、密码）、接口约定（报错代码、报错提示、报错含义等）。若涉及到变更或者新增要标注并说明情况。5.9系统账号清单（含接口账号，新增账号）提供新增的数据库账号清单，包括其在数据库中的账号名、对应权限、对应角邑、对应表权限。提供新增的应用账号淸单，包括其在应用系统中的用户名、对应权限、对应角色。提供新增的操作系统账号清单，包括其在操作系统中的用户名，对应的用户组，对应角色、对 应权限。5. 10新功能清单提供本次新交接的功能淸单及简要说明。5. 11程序部署手册

25、提供详细的系统回退步骤如在部署有额外操作名要求，也要写入手册5. 12回退操作手册该步骤主要是用于二线平台维护人员进行回退部署，开发商需对本次回退部署过程进行详细的 说明。在系统回退部署前，如果有涉及数損库回退的，开发商须提供的用于回退的回退脚本，如果 没有，须在部署文档中说明。回退部署步骤应包含程序卸載（停中间件）、数据库回退、旧程序安装、 程序启动.程序启动后检查项.以上几个步骤的具体要求如下：程序卸載：需描述淸楚程序知载的详细步骤。数据库回退：多个回退SQL脚本，需要集中到一个SQL脚本中，平台组只需执行汇总后的一个回退SQL脚本:在执行脚本之前，需要平台维护组备份的数据库对象（备份函数

26、、存储过程，表等）或需要停 止的对象（如停止触发器等），需事先说明，并提供详细的对象备份脚本与对象停止启动脚本：回退脚本需说明脚本在PL/SQL工具下的命令模式，如COMMAND或者SQL WINDOW下执行：回退脚本如有执行顺序要求，需在部署文档中标明回退脚本的执行顺序，数扌居脚本执行后，结 果中存在正常的异常，需先说明；回退脚本所有的命令均要求自动提交。旧程序安装：需描述淸楚旧程序安装的详细步探。程序启动：需描述清楚程序启动的详细步骤。例如，有些部署需要莹启中间件，请在文档中说 明。程序启动后检查项：需描述启动成功后检查步腺。5.13测试报告开发商应根据测试案例在开发环境进行新功能测试.回

27、归测试、压力测试并出具三种测试通过 的测试报告。该文档应按照业务需求说明书编写，至少应包括以下容测试用例编号及名称测试环境地址测试人及测试测试路径或活动测试场景说明有可能影响到的功能点测试步骤测试期望结果测试实际结呆测试结果确认（签字）5. 14系统测试用例开发商应根据业务需求说明书编写新功能测试用例、回归测试用例。5. 15源代码开发商在交接前必须提供程序的源代码，并保证源代码的完整性。5. 16第三方联系人员列表开发商、第三方开发商、硬件、业务部门等相关负责人联系方式5. 17存储配置及分配清单存储配置操作文档、配置情况及分配淸单5. 18基础环境部署配覺信息安装部署信息及账户密码以支撑及

28、管理平台运行5. 19平台及应用故障及隐患清单历史故障记录、隐患清单和维护记录、为优化平台及降低风险提供依据5.20平台.应用监控策略及监控清单监控災略及监控指标淸单5.21数据库交维清单数据库建设方案、配置文档、管理员账户密码、配置清单及故障处理报告5.22网络设备交维清单网络拓朴图、配置管理文档、设备维保、网络配置淸单及日常维护记录5. 23应急演练方案及报告应急演练方案及应急环境5.24应用系统接入流程规规化管理应用接入及资源申请5.25系统维护工作列表开发商目前在系统维护方面的工作描述，包括月度故障率、数据提取莹、数損调整情况.数据 备份疑略等5.26应用系统清单部署在平台上的应用系统

29、清单，包括应用用途、业务部门、业务主管、维护商、维护人员、开发商、开发人员等信息5. 27夜件资产清单提供网络拓扑因、网络布线（网络及光纤）标签图、硬件维保信息5. 28平台压力评估报告应用系统压力测试报告（测试目的、办法、工具、用例及测试指标期望值）5. 29应用系统部署配置表系统架构及部署情况，资源使用情况5.30资产信息录入CMDB中应用系统、应用平台需录入到CMDB中6. 应用系统、应用平台交维系统的压力测试6. 1 压力测试目的压力测试的目的就是检验系统的最大呑吐董，检验现行的业务系统在各种压力交易量下的运行 状况，检验系统的运行瓶颈，获取系统的处理能力等等。6.2 压力测试工具美科

30、利公司（Mercury）的性能测试软件Load Runner微软公司的性能测试软件Web Application Stress工具（简称WAS）6.3 压力测试用例现行的应用系统进行脚本录制、测试回放.逐步加压和跟踪记录。测试过程中，由Load Runner 或WAS的管理平台调用各台测试前台，发是各种组合的交易请求，并跟踪记录服务器端的运行情况 和返回给客户端的运行结果。根据测试系统的硬件条件.选择满负荷的压力，在系统的资源使用基本维持在90%左右的状况 下，测试数据库的处理能力。6.4 压力测试指标及期望值1, 网络级别测试指标。呑吐董：单位时间网络传输数据董冲突率：在以太网上监测到的每秒

31、冲突数2, 服务器操作系统级别指标。标准平均峰值CPU利用率存利用率存储I03, 数据库级别测试指标。数据库I/O的流量大小数据库锁许源的使用数董数据库的并发连接数6.5 压力测试数据及场景1, 测试数据库需具备与真实环境成一定比例或基本一致的数据。2, 测试环境分4个，使用逐步加压的模式。查看并记录运行情况。査看并记录运行情况。査看并记录运行情况。查看并记录运行情况。A, 每隔2秒增加1个用户连接，最多增加到100个用户B, 每隔2秒增加2个用户连接，罠多增加到200个用户C, 每隔2秒增加1个用户连接，眾多增加到300个用户D, 每隔3秒增加1个用户连接，灵多增加到400个用户每个场景都包

32、括：用户登录-业务操作-业务完成-退出系统，所有用例都按以上场景进行测 试，由于pc性能限制，为了更准确模拟现场环境，将运行的所有脚本部署在8台Load Runner或 WAS终端上，主要目的就是检查在不同的压力的情况下，业务系统的性能表现。申请10台虚拟机,配置为Windows 2003、2. 50GHz双核CPU、4G存。在10台虚拟机上部署釆 集客户端，每台部署15个终端，每个测试终端隔1秒生成一个条码模拟丈件，即模拟每秒并发量 150 次。6.6 压力测试报告执行每个场景时记录以下相应的数据：1. 数据库（Oracle）服务器上主机上的CPU利用率：2. I0和CPU利用率对照表如下：

33、3. DB服务器上监控的网络流量；4. 运行的并发用户数目：5. 测试中完成各操作的平均响应时间：（单位：秒）；6. 测试中每秒的点击率如下：7. 交易的呑吐率（每秒处理数据量）。7. ERP系统交维的前提条件必须提供第3. 4、5幸节中说明的所有文档，文档的容必须完整、全面和属实：配合完成1-2次交维培训.讲解交维系统的架构、业务逻辑、数据流转、目前维护流程和常见 的故障点等：若交维系统存在性能隐患及遗留问題，需建设方处理达到交维要求再接。如交维系统软z更件性 能瓶颈、可用应急环境、数据备份及监控吋效性。根据交维淸单，维护组需要核对设备及相对应配置，如有遗留问題，建设方需根据交维报告的 整改

34、容进行修复：1, 数据备份，满足备份交维需求，包括备份环境、备份需求，如：（1）备份环境前期准备包括以下方面：备份环境备份架构网络环境备份系统接入备份资源接入前提1、尽量选用统一备份维护现有架 构（賽门铁克备份架构）；2、如需加入新的备份架构（如微 软、IBM等），需要完成新架构接 入的所有投资工作；3、需要提供该架构稳定使用及使 用优势的评估，以及通过领导审批 获得人员后续维护资源。J网络端口、防火墙策略放通：2、实現设备与现 有备份设备的物 理、网络连接。1、对需备份的各设备进行备份系统（客户端）安装；2、配合备份组完 成各备份结点的 配置、调通。1、整理自有备份资源情 况，提交文档：2、

35、检查各设备状态，确 保设备使用正常，无破件 故障，设备版本已升级到 最新或最稳定状态；3、转移设备维保情况， 将设备资产信息录入CMDBo（2）备份需求接入时,接入方备份组备份需求接入处理1、整理备份数据类型，数据大小，日增 长量及相应恢复需求：2、提供系统数据历史增长情况及预测两 年增长董；3、提出详细备份路径，相应备份棗略需 求。1、评估可用备份资源是否满足接入方备份需求，按需调整：2、根据备份恢复要求，综合网络速度，系统I0限制，对 备份架构进行调优；3、根抵备份恢复要求，对各类型备份数据指定备份介质。4、结合系统业务情况，10/并发，制定精确备份策略（时间点、并行窗口、任务排序等）。2

36、, 恢复演练，平台需要有应急环境，应用系统或者虚拟机交维前做备份恢复演练，双机配置 网络设备需要做切换演练。3, 平台监控，监控疑略及监控对象梳理，严重告警信息需发到对应维护人员手机，做到及时 性。4, 配置管理，平台对应设备及应用系统全部录入CMDB中管理。5, 平台隐患，梳理多次出现的故障及存在隐患点，给出对应的处理办法及报告。6, 碇件维护商、操作系统维护商、网络维护商、中间件维护商、数据库维护商需提供5*8小 时现场支持服务和7*24小时远程支持服务。7.1 交维系统转交整改的条件运维期间如交维系统存在批量安全漏洞、系统BUG等，维护组将该系统移交系统建设部门整改,移交整改条件如下：1

37、, 操作系统安全扫描有5个或以上严重漏洞：2, 应用系统渗透测试，应用软件漏洞类型多于2种且漏洞数量大于10个，需业务部门要求开 发商做安全整改。3, 应用系统出现全局性功能缺陷及BUG,导致系统不能正常使用，或者主要功能流程不能正常 扭转。4, 应用系统常用功能出现功能缺陷致占用资源不释放，影响平台稳定性及其他应用系统使用, 需业务部门要求开发商优化应用。（如CPU达到75%、存达到85%及存储10读写过离）。5, 应用系统存在性能问题（页面响应缓慢类报障50例/周），并确定需通过较”更件升级/扩容解决。8. 维护组维护容8. 1 应用维护组为确保各应用系统、应用平台稳定高效的运行，统一维护

38、组维护服务主要容如下:维护大类维护小类详细容服务类系统使用咨询与指导用户在日常使用系统过程遇到各类扌桑作及系统逻辑咨询 问题，可以通过维护单的形式告知维护人员，维护人员 对遇到的问题进行解答及指导。数据后台调整由于用户操作失误导致的错误数据，经相关负责人同意 后，维护人员需要为用户修改为正确的数据。后台数据导出在系统没有提供功能的情况下，维护组可以给用户提供 部分数据导出服务，但数摇导出仅限于按照数据库表结 构导出系统原有数扌色 维护不进行复杂逻辑的处理及数 据整理工作。系统设置除用户角色、权限以及审批流程之外的设置进行维护。维护类组织故障处理本系统及本系统与其他系统的接口出现故障时，应用维

39、护组对故障进行初步判斯.将故澤提交给相关团队进行 处理，在整个故障处理过程负责协调各方团队共同解决 并及时向维护主管汇报情况。系统BUG及性能问题定位系统出现BUG及性能问题，应用维护组应预先对现象进 行确认，并提交开发商处理。数据问题查证及处理与其它ERP外围系统如出现系统间数据不一致的情况， 应用维护组应配合用户进行排查并给出合理解释：如确 定为系统BUG,维护纽提交至开发商处理。应用层日常巡检及性能监控每日对应用系统登录、数据库主要业务表、总条数及总 容量进行巡检，并利用工具随时对应用系统的运行进行 性能监控。应用层主动维护操作：完成备 份、莹启、测试环境的管理等 工作系统备份收集系统相

40、关信息，进行风险评估.确定需要备份的 数据源及备份需求与平台组及备份组共同确定备份疑略配合备份组及平台纽完成系统数据恢复测试和演练系统重启与平台组共同制定系统重启计划 系统重启后对系统进行登陆验证测试环境的管理提出测试环境克隆需求 测试环境的使用管理 保证测试环境的正常使用 定期更新测试环境数据系统运行情况的总结及分析根据系统毎月的运行请况出具总结月报及系统可用率数 据。组织新功能、补丁上线审核开发商提供的上线文档对原有功能进行简单的验证，以减少新的程序包对原有 功能的影响在整个上线过程中如出现故障时负责协调各方团队共同 解决并向维护主管汇报情况。系统配置管理负责日常配置变更的实施、配置资料制

41、作及保管、配置 相关管理办法及流程的制定。管理数扌居庠业务管理：负责数据库层业务的设置及变更、维 护管理相关表格、相关管理办法及流程的制定应用层支撑管理：负责应用层支撑的设置及变更、维护 管理相关表格.相关管理办法及流程的制定安全管控工作的配合审计管理：配合各项审计工作，并按照要求提供相应的 样本。按照各项安全管控要求开展日常维护工作配合各项安全管控工作的开展提出系统优化建议根据系统性能监控结呆及用户反馈的性能缓慢或不可用 情况,提出性能优化建议。月结/年结支持月结支持8.2 平台维护组属次工作矣别工作项工作细项基础层定期服务每日巡检每天进行巡检：SCOM监控健康巡检.SQL Server集群

42、健康巡检， Oracle数据库健康巡检，SCVMM健康检查每周巡检1、检查负载均衡应用系统站点配置情况2、检查域控与地市公司的同步复制情况3、DNS服务健康情况月度巡检机房每月硬件常规检査，包括服务器、交换机，负載均衡以及存 储设备的健康检查补丁升级平台每两个月windov/s服务器安全补丁升级安全加固每个季度配合服务器设备的安全扫描以及针对扫描结果的安全 加固（重要应用系统）资源管理基屁组件 资源维 护服务服务器的操作系统重新安装及定期重启维护处理服务器硬件故障报修及检查测试WSUS补丁分发、KMS服务器管理、协助地市服务器通过KMS激 活SCVMM系统管理:1）、虚拟主机管理2）、虚拟机增

43、加.修改、删除等操作管理3）、虚拟机资源管理等其他SCVMM的管理操作VMv/are vSphere 管理：1）、虚拟主机和群集管理2）、数据存储和数据存储群集资源管理3）、虚拟网络连接和管理4）、虚拟机增加、修改、刪除等操作管理5）、虚拟机资源配置和资源监控管理SVC管理：1）存储机头管理2）、存储资源的分配3）、存储监控管理负载均衡配置管理：1）负载均衡网络配置2）、负载均衡运行状态检查3）、负载均衡的切换维护配置管理基础配置 信息管理1对平台的服务器设备以及各配置参数按实际情况进行登记， 并录入CMDB2、针对每个应用的配置数据进行收集并录入到资产明细表，并 针对每次的应用配置变化及时更新到CMDB3、毎次设备扩容以及新设备上架与旧设备下架进行实时的硬件 配置数据更新4、毎次应用以及系统软件的配置发生变化时我们以配置变更的 方式进行更新配置中间层事件管理工单处理日常各个维护服务团队、开发商等服务咨询各服务器维护账户的申请审批、延期