ERP系统交维流程与规范.doc

H:精品资料建筑精品网原稿ok（删除公文）建筑精品网5未上传百度【系统交维流程与规范】版本 拟制日期 -07-07审核日期批准日期修订历史记录版本日期AMD修订者说明V1.0 -7-7A新增规范文档( A-添加, M-修改, D-删除) 目录1.服务目标52.ERP系统交维流程73.ERP系统交维资产清单114.ERP系统交维文档清单145.ERP系统交维文档要求165.1用户手册( 系统功能说明书) 165.2维护手册( 系统技术说明书: 包括软、 硬件架构说明) 165.3备份策略清单( 含历史及新增) 175.4系统资产清单( 含历史及新增) 175.5系统配置清单( 包括安装地点信息, 含历史及新增) 175.6接口清单( 含历史及新增) 185.7系统账号清单( 含接口账号 , 新增账号 ) 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系统交维的前提条件257.1交维系统转交整改的条件278.ERP统一维护组维护内容289.时间管理321. 服务目标各应用系统、 应用平台建设周期完成, 正式投入使用, 系统建设部门将其移交维护部门进行运行统一维护。为规范各应用系统、 应用平台从建设转为运行维护的流程, 减少系统故障, 缩短故障处理时间, 提高各应用系统、 应用平台运行的稳定性、 高效性, 提供高质量的系统支撑, 特制订本管理流程。经过开展规范化, 流程化, 知识化的维护服务, 保持各应用系统、 应用平台的稳定性和服务高效性, 并实现以下期望目标: u 经过各个团队在运维管理、 技术支持方面的经验知识, 将现有的被动服务完全转变为主动服务, 用完善的制度与合理的流程确保应用系统持续稳定地运行, 提升系统运维水平和服务质量; u 梳理各应用系统、 应用平台运维的工作和各类流程, 总结并制定各类工作流程, 完善故障处理机制, 建立故障处理、 日常维护的知识管理体系, 以缩短问题、 故障处理时间, 满足服务响应时限的要求; u 配合维护主管全力以赴完成公司IT规划、 项目管理、 系统分析、 系统建设等高价值、 具备核心竞争力的工作内容, 外包日常维护、 故障处理等相对规范、 固定的工作内容, 实现分工精细化, 员工专业化, 服务标准化; 量化维护工作内容, 实现维护工作标准化, 制度化, 显性化; u 最终按照ITIL标准建立信息服务体系和运维服务团队, 实现”运维服务一体化”, ”平台管理智能化”, 成本结构全面优化、 运营效益显著提升的最终目标。2. ERP系统交维流程步骤流程说明: 信息系统建设部门填写并提交应用系统交维申请表或应用平台交维申请表, 应用系统或应用平台进入交维申请流程。根据平台组提供的平台交维工作清单, 检验建设方提供的平台网络拓朴图、 资产配置清单、 平台操作文档及风险评估列表等等, 经过服务组进行预接收。2.1 评估预接收条件根据维护组提供的交维工作清单, 检验建设方提供的网络拓朴图、 资产配置清单、 维护手册、 用户手册、 风险评估列表等等, 经过维护组进行预接收。为保证各应用系统、 应用平台的稳定运行, 建设方在交维时, 必须先达到以下应用交维条件: A. 应用系统功能能够为用户提供长时间不中断的、 可用的服务, 保证交维前30天无故障发生, 90天内无重大故障发生。 B. 需要交接的应用系统必须有一个与正式环境的业务数据、 技术架构、 部署环境完全一样的测试环境。C. 配合完成1-2次交维培训, 讲解平台的架构、 业务逻辑、 数据流转、 当前维护流程和常见的故障点等; 若平台存在性能隐患及遗留问题, 需建设方处理达到交维要求再接。如平台软硬件性能瓶颈、 可用应急环境、 数据备份及监控时效性。D. 上线后出现的紧急与严重的缺陷必须解决。E. 按本文第3、 4、 5章要求提交相关清单及验收交维文档。F. 根据建设部门提交的备份说明文档检查应用系统、 应用平台的备份情况, 内容包括服务器信息, 备份路径、 备份内容、 备份的频率, 保留时长等信息。 G. 根据建设部门提供的资产清单, 清点硬件设备及核对网络拓朴图、 网线标签、 虚拟机与应用系统对应关系。确认资产信息是否已录入CMDB中, 信息是否完整。H. 检查资源分配情况( 服务器资源利用率不能超过80( CPU、 内存) 、 负载均衡配置、 存储状况及IP地址使用情况) 。I. 服务器监控需接入IPNET或者ZABBIX, 建设部门需提交监控指标信息, 以及交维前出现的故障报告。J. 根据交维清单, 平台维护组需要核对设备及相对应配置, 如有遗留问题, 建设方需根据交维报告的整改内容进行修复。K. 其中对于不同架构的系统可达到的维护可用性不同: u 应用、 数据库及硬件服务器都是双节点冗余的系统, 维护可用性目标为99.9%; u 应用、 数据库及硬件服务器有一个是单节点的系统, 维护可用性目标为99%; u 无磁带备份的系统, 可容忍所有数据丢失; u 有磁带备份的系统, 每X天进行一次备份, 可容忍X天数据丢失。L. 系统必须具备必要的功能: u 接口连接等使用的程序账号必须能够方便的修改密码; u 系统必须在应用界面上具备完善的用户权限管理功能; u 系统必须提供必要的网管接口。2.2 各团队进行费用评估信息室费用评估一线服务台评估系统监控组评估7676平台维护组评估维护室费用评估应用维护组评估中间件及数据库平台维护组评估硬件服务器维护组评估备份系统维护组评估网管维护组评估4A维护组评估网络维护组评估机房环境维护组评估2.3 费用申请维护室综合各团队的费用评估后进行费用申请2.4 系统转维资源准备应用系统在规划建设阶段就应该详细评估系统转维过程中所需的维护资源。当前信息系统部对于每一个应用系统转维护过程中所需资源如下图所示: 系统转维过程中牵涉到的维护资源如上图所示。应用系统转入运维阶段后需要一些列的资源投入, 应用系统在转维护过程中应及时知会各维护资源提供方, 同时提供项目相关维护文档以便转维工作的顺利进行。2.5 维护组对应用系统、 应用平台进行预接收 检验预接收的交维文档及代码; 预接收检验不经过, 退回信息系统建设部门进行整改或资料补充; 召开交维培训会议, 由建设方进行培训, 了解日常维护工作及服务对象, 提出常见故障及处理办法。维护组对信息系统进行软硬件风险、 缺陷诊断评估, 对于有严重安全风险以及有严重缺漏的, 则退回信息系统建设部门整改。2.6 进入为期一个月的试维护阶段跟业务用户召开职责分工会议, 有目的地跟业务用户确认相关服务承诺, 并给出职责分工表 。试运维期间如系统出现批量安全漏洞、 系统BUG等符合整改条件的, 运维组将该系统移交系统建设部门整改。各个维护组签收应用系统运维移交申请表或应用平台运维移交申请表, 确立应用系统、 应用平台正式移交维护组运维, 进入正式维护阶段。根据应用系统、 应用平台维护涉及的内容, 能够分为4个维护层: u 硬件管理硬件故障由硬件原厂或者第三方维保处理。u 网络管理网络策略配置和故障处理由网络维护组负责。u 系统管理基础软件管理, 初步故障定位及处理交由平台维护组负责。如平台维护组无法处理, 则提交相对应专业维护组进行处理。u 应用管理由应用维护组进行日常维护, 出现故障后由应用维护组进行故障定位, 并组织各团队及时解决系统故障。 应用系统流程图如下: 应用平台流程如下: 流程 3. 应用系统、 应用平台交维资产清单3.1 硬件资产列表物理服务器( 详见资产清单) 编号设备型号序列号设备名称IP地址配置信息虚拟服务器设备名称IP地址配置信息项目名称设备用途联系人联系电话3.2 存储及网络设备编号设备型号序列号设备名称IP地址配置信息3.3 软件资产列表软件名称版本号license软件用途使用期限数量4. 应用系统、 应用平台交维文档清单序号文档名称运维用途说明备注1备份策略清单提供备份策略清单, 包括所在服务器主机名、 所在服务器IP、 存储路径、 备份数据量、 备份策略名称、 备份方式及备份频率、 备份窗口数据保留时间等备份情况2应用测试报告开发商应根据测试案例在开发环境进行新功能测试、 回归测试、 压力测试并出具三种测试经过的测试报告3存储配置及分配清单存储配置操作文档、 配置情况及分配清单4第三方联系人员列表平台及应用干系人管理开发商、 第三方开发商、 硬件、 业务部门等相关负责人联系方式5回退操作手册该文档主要是用于二线平台维护人员进行回退部署, 开发商需对本次回退部署过程进行详细的说明6基础环境部署配置信息支撑及管理平台运行安装部署信息及账户密码7接口清单提供系统、 应用层、 数据库层、 及硬件层等接口清单8平台及应用故障及隐患清单历史故障记录和维护记录、 为优化平台及降低风险提供依据历史故障记录和隐患清单9平台监控策略及监控清单告警时效性、 及时性监控策略及清单10平台压力评估报告应用系统压力测试报告( 测试目的、 办法、 工具、 用例及测试指标期望值) 需要测试压力指标及测试报告11软件安装部署及操作手册指导及管理系统管理操作12软件资产清单描述软件部署的环境、 使用基础软件的版本、 网络架构尽量能提供系统拓扑图13数据库交维清单数据库配置情况数据库建设方案、 配置文档、 管理员账户密码、 配置清单及故障处理报告14网络设备交维清单网络架构及网络配置网络拓朴图、 配置管理文档、 设备维保、 网络配置清单及日常维护记录15维护手册该文档主要用于二线维护人员进行技术维护, 让维护人员能够参照手册开展职责范围内的所有维护工作16系统测试用例开发商应根据业务需求说明书编写新功能测试用例、 回归测试用例17系统配置清单提供系统、 应用层、 数据库层、 及硬件层等配置清单18系统维护工作列表开发商当前在系统维护方面的工作描述, 包括月度故障率、 数据提取量、 数据调整情况、 数据备份策略等尽量能提供维护管理手册19系统账号清单提供系统、 应用层、 数据库层、 及硬件层等账号清单20系统资产清单若涉及到新增软件的情况, 需提供系统用到的所有license, 包括license序列号、 license文件、 license开始时间、 license到期时间、 license联系人、 license联系方式21新功能清单提供本次新交接的功能清单及简要说明22应急演练方案及报告快速恢复业务应急演练方案及应急环境23应用系统部署配置表系统架构及部署情况, 资源使用情况应用系统部署配置24应用系统接入流程规范规范化管理应用接入及资源申请应用接入规范25应用系统清单及时响应应用系统维护, 通知对应干系人部署在平台上的应用系统清单, 包括应用用途、 业务部门、 业务主管、 维护商、 维护人员、 开发商、 开发人员等信息26应用虚拟机备份策略表备份管理备份策略及备份清单27硬件资产清单平台部署使用的硬件资源提供网络拓扑图、 网络布线( 网络及光纤) 标签图、 硬件维保信息28用户手册该文档供普通用户、 维护人员及其它需要了解系统功能的人员阅读29源代码开发商在交接前必须提供程序的源代码, 并保证源代码的完整性30资产信息录入CMDB中配置管理5. 应用系统、 应用平台交维文档要求5.1 用户手册( 系统功能说明书) 该文档供普通用户、 维护人员及其它需要了解系统功能的人员阅读, 让上述人员能够全面掌握系统所有功能的使用。新增版本的文档中应包括系统全部功能的使用说明, 同时标注本次新增或变更的内容, 基本要求如下: 有结构、 有层次的对系统支撑的业务场景及业务流程进行描述; 有结构、 有层次的对各用户界面的功能及各信息字段的含义及限定进行详细说明; 文档的详细程度要做到具备基本业务知识的但未接触过系统的用户经过阅读文档即可使用系统。5.2 维护手册( 系统技术说明书: 包括软、 硬件架构说明) 该文档主要用于二线维护人员进行技术维护, 让维护人员能够参照手册开展职责范围内的所有维护工作。新增版本的文档中应包括系统软硬件的技术架构说明, 同时标注本次新增或变更的内容。该文档必须包括以下内容: u 系统技术架构的说明: 对应用系统的硬件服务器、 数据库、 中间件及流程引擎等其它软件平台架构进行详细说明。u 系统核心逻辑的说明: 针对主要的业务逻辑, 结合程序进行详细说明。u 应用程序的模块架构说明: 对各模块功能及相互间的逻辑联系进行说明, 并分析数据的流向。u 系统业务需求的技术实现方案说明: 针对某些常见和特殊业务进行的处理, 经过该文档掌握业务流程的处理。u 数据库表结构说明: 对数据库表的结构进行详细说明, 并提供详细的数据字典和ER图。u 接口说明: 针对于每个系统的接口进行说明, 包括交互方式、 交互数据源、 交互频率等。u 定时器等专用服务的说明: 说明其工作原理, 使用说明等。u 脚本说明: 针对常见脚本、 数据操作脚本、 报表脚本等进行详细说明。u 程序包变更的说明, 针对新增和修改的地方进行说明。u 提供操作系统、 数据库、 中间件及流程引擎等其它软件平台的主要配置及特殊配置要求; u 提供详细的应用程序各配置项及初始配置列表; u 提供应用程序预置账号及初始密码列表, 提供数据库等平台访问账号及初始密码列表, 提供各系统接口账号及初始密码列表; 文档的详细程度要做到具备基本技术知识的但未接触过系统的维护人员经过阅读文档即可进行系统维护。5.3 操作配置手册( 软件功能说明书) 该文档供维护人员阅读, 能够全面掌握系统所有功能的使用。应包括系统全部功能的使用说明, 同时标注本次新增或变更的内容, 基本要求如下: u 有结构、 有层次的对平台软硬件操作场景及业务流程进行描述; u 有结构、 有层次的对各用户界面的功能及各信息字段的含义及限定进行详细说明; u 文档的详细程度要做到具备基本业务知识的但未接触过系统的用户经过阅读文档即可使用系统。5.4 平台维护手册( 系统技术说明书: 包括软、 硬件架构说明) 该文档主要用于平台维护人员进行技术维护, 能够参照手册开展职责范围内的所有维护工作。该文档必须包括以下内容: u 系统技术架构的说明: 对应用系统的硬件服务器、 数据库、 中间件及流程引擎等其它软件平台架构进行详细说明。u 系统核心逻辑的说明: 针对主要的业务逻辑, 结合程序进行详细说明。u 系统业务需求的技术实现方案说明: 针对某些常见和特殊业务进行的处理, 经过该文档掌握业务流程的处理。u 提供操作系统、 数据库、 中间件及流程引擎等其它软件平台的主要配置及特殊配置要求; u 提供详细的应用程序各配置项及初始配置列表; u 提供应用程序预置账号及初始密码列表, 提供数据库等平台访问账号及初始密码列表, 提供各系统接口账号及初始密码列表; 5.5 备份策略清单( 含历史及新增) 提供备份策略清单, 包括所在服务器主机名、 所在服务器IP、 存储路径、 备份数据量、 备份策略名称、 备份方式及备份频率、 备份窗口数据保留时间等备份情况。若涉及到变更或者新增要标注并说明情况。5.6 软件资产清单( 含历史及新增) 若涉及到新增软件的情况, 需提供系统用到的所有license, 包括license序列号、 license文件、 license开始时间、 license到期时间、 license联系人、 license联系方式。5.7 系统配置清单( 包括安装地点信息, 含历史及新增) 提供操作系统、 数据库、 中间件及流程引擎等其它软件平台的主要配置及特殊配置要求; 提供详细的应用程序各配置项及初始配置列表; 提供应用程序预置账号及初始密码列表, 提供数据库等平台访问账号及初始密码列表, 提供各系统接口账号及初始密码列表; 若涉及到变更或者新增要标注并说明情况。5.8 接口清单( 含历史及新增) 提供数据库新增接口清单, 包括接口提供方、 消费方、 调用频率、 同步程序、 调用方式、 调用配置( 用户名、 密码) 、 接口约定( 报错代码、 报错提示、 报错含义等) 、 接口视图。提供Webservice新增接口清单, 包括接口提供方、 消费方、 调用频率、 同步程序、 调用地址、 调用配置( 用户名、 密码) 、 接口约定( 报错代码、 报错提示、 报错含义等) 。若涉及到变更或者新增要标注并说明情况。5.9 系统账号清单( 含接口账号 , 新增账号 ) 提供新增的数据库账号清单, 包括其在数据库中的账号名、 对应权限、 对应角色、 对应表权限。提供新增的应用账号清单, 包括其在应用系统中的用户名、 对应权限、 对应角色。提供新增的操作系统账号清单, 包括其在操作系统中的用户名, 对应的用户组, 对应角色、 对应权限。5.10 新功能清单提供本次新交接的功能清单及简要说明。5.11 程序部署手册提供详细的系统回退步骤如在部署有额外操作名要求, 也要写入手册5.12 回退操作手册该步骤主要是用于二线平台维护人员进行回退部署, 开发商需对本次回退部署过程进行详细的说明。在系统回退部署前, 如果有涉及数据库回退的, 开发商须提供的用于回退的回退脚本, 如果没有, 须在部署文档中说明。回退部署步骤应包含程序卸载( 停中间件) 、 数据库回退、 旧程序安装、 程序启动、 程序启动后检查项, 以上几个步骤的具体要求如下: 程序卸载: 需描述清楚程序卸载的详细步骤。数据库回退: 多个回退SQL脚本, 需要集中到一个SQL脚本中, 平台组只需执行汇总后的一个回退SQL脚本; 在执行脚本之前, 需要平台维护组备份的数据库对象( 备份函数、 存储过程, 表等) 或需要停止的对象( 如停止触发器等) , 需事先说明, 并提供详细的对象备份脚本与对象停止启动脚本; 回退脚本需说明脚本在PL/SQL工具下的命令模式, 如COMMAND或者SQL WINDOW下执行; 回退脚本如有执行顺序要求, 需在部署文档中标明回退脚本的执行顺序, 数据脚本执行后, 结果中存在正常的异常, 需先说明; 回退脚本所有的命令均要求自动提交。旧程序安装: 需描述清楚旧程序安装的详细步骤。程序启动: 需描述清楚程序启动的详细步骤。例如, 有些部署需要重启中间件, 请在文档中说明。程序启动后检查项: 需描述启动成功后检查步骤。5.13 测试报告开发商应根据测试案例在开发环境进行新功能测试、 回归测试、 压力测试并出具三种测试经过的测试报告。该文档应按照业务需求说明书编写, 至少应包括以下内容测试用例编号及名称测试环境地址测试人及测试帐号测试路径或活动测试场景说明有可能影响到的功能点测试步骤测试期望结果测试实际结果测试结果确认( 签字) 5.14 系统测试用例开发商应根据业务需求说明书编写新功能测试用例、 回归测试用例。5.15 源代码开发商在交接前必须提供程序的源代码, 并保证源代码的完整性。5.16 第三方联系人员列表开发商、 第三方开发商、 硬件、 业务部门等相关负责人联系方式5.17 存储配置及分配清单存储配置操作文档、 配置情况及分配清单5.18 基础环境部署配置信息安装部署信息及账户密码以支撑及管理平台运行5.19 平台及应用故障及隐患清单历史故障记录、 隐患清单和维护记录、 为优化平台及降低风险提供依据5.20 平台、 应用监控策略及监控清单监控策略及监控指标清单5.21 数据库交维清单数据库建设方案、 配置文档、 管理员账户密码、 配置清单及故障处理报告5.22 网络设备交维清单网络拓朴图、 配置管理文档、 设备维保、 网络配置清单及日常维护记录5.23 应急演练方案及报告应急演练方案及应急环境5.24 应用系统接入流程规范规范化管理应用接入及资源申请5.25 系统维护工作列表开发商当前在系统维护方面的工作描述, 包括月度故障率、 数据提取量、 数据调整情况、 数据备份策略等5.26 应用系统清单部署在平台上的应用系统清单, 包括应用用途、 业务部门、 业务主管、 维护商、 维护人员、 开发商、 开发人员等信息5.27 硬件资产清单提供网络拓扑图、 网络布线( 网络及光纤) 标签图、 硬件维保信息5.28 平台压力评估报告应用系统压力测试报告( 测试目的、 办法、 工具、 用例及测试指标期望值) 5.29 应用系统部署配置表系统架构及部署情况, 资源使用情况5.30 资产信息录入CMDB中应用系统、 应用平台需录入到CMDB中6. 应用系统、 应用平台交维系统的压力测试6.1 压力测试目的压力测试的目的就是检验系统的最大吞吐量, 检验现行的业务系统在各种压力交易量下的运行状况, 检验系统的运行瓶颈, 获取系统的处理能力等等。6.2 压力测试工具美科利公司( Mercury) 的性能测试软件Load Runner微软公司的性能测试软件Web Application Stress工具( 简称WAS) 6.3 压力测试用例现行的应用系统进行脚本录制、 测试回放、 逐步加压和跟踪记录。测试过程中, 由Load Runner或WAS的管理平台调用各台测试前台, 发起各种组合的交易请求, 并跟踪记录服务器端的运行情况和返回给客户端的运行结果。根据测试系统的硬件条件, 选择满负荷的压力, 在系统的资源使用基本维持在90%左右的状况下, 测试数据库的处理能力。6.4 压力测试指标及期望值1， 网络级别测试指标。吞吐量: 单位时间内网络传输数据量冲突率: 在以太网上监测到的每秒冲突数2， 服务器操作系统级别指标。标准平均峰值CPU利用率内存利用率存储IO3， 数据库级别测试指标。数据库I/O的流量大小数据库锁资源的使用数量数据库的并发连接数6.5 压力测试数据及场景1， 测试数据库需具备与真实环境成一定比例或基本一致的数据。2， 测试环境分4个, 使用逐步加压的模式。A， 每隔2秒增加1个用户连接, 最多增加到100个用户, 查看并记录运行情况。B， 每隔2秒增加2个用户连接, 最多增加到200个用户, 查看并记录运行情况。C， 每隔2秒增加1个用户连接, 最多增加到300个用户, 查看并记录运行情况。D， 每隔3秒增加1个用户连接, 最多增加到400个用户, 查看并记录运行情况。每个场景都包括: 用户登录-业务操作-业务完成-退出系统, 所有用例都按以上场景进行测试, 由于pc性能限制, 为了更准确模拟现场环境, 将运行的所有脚本部署在8台Load Runner或WAS终端上, 主要目的就是检查在不同的压力的情况下, 业务系统的性能表现。申请10台虚拟机, 配置为Windows 、 2.50GHz双核CPU、 4G内存。在10台虚拟机上部署采集客户端, 每台部署15个终端, 每个测试终端隔1秒生成一个条码模拟文件, 即模拟每秒并发量150次。6.6 压力测试报告执行每个场景时记录以下相应的数据: 1. 数据库( Oracle) 服务器上主机上的CPU利用率; 2. IO和CPU利用率对照表如下; 3. DB服务器上监控的网络流量; 4. 运行的并发用户数目; 5. 测试中完成各操作的平均响应时间: ( 单位: 秒) ; 6. 测试中每秒的点击率如下; 7. 交易的吞吐率( 每秒处理数据量) 。7. ERP系统交维的前提条件必须提供第3、 4、 5章节中说明的所有文档, 文档的内容必须完整、 全面和属实; 配合完成1-2次交维培训, 讲解交维系统的架构、 业务逻辑、 数据流转、 当前维护流程和常见的故障点等; 若交维系统存在性能隐患及遗留问题, 需建设方处理达到交维要求再接。如交维系统软硬件性能瓶颈、 可用应急环境、 数据备份及监控时效性。根据交维清单, 维护组需要核对设备及相对应配置, 如有遗留问题, 建设方需根据交维报告的整改内容进行修复; 1， 数据备份, 满足备份交维需求, 包括备份环境、 备份需求, 如: ( 1) 备份环境前期准备包括以下方面: 备份环境备份架构网络环境备份系统接入备份资源接入前提1、 尽量选用统一备份维护现有架构( 赛门铁克备份架构) ; 2、 如需加入新的备份架构( 如微软、 IBM等) , 需要完成新架构接入的所有投资工作; 3、 需要提供该架构稳定使用及使用优势的评估, 以及经过领导审批获得人员后续维护资源。1、 网络端口、 防火墙策略放通; 2、 实现设备与现有备份设备的物理、 网络连接。1、 对需备份的各设备进行备份系统( 客户端) 安装; 2、 配合备份组完成各备份结点的配置、 调通。1、 整理自有备份资源情况, 提交文档; 2、 检查各设备状态, 确保设备使用正常, 无硬件故障, 设备版本已升级到最新或最稳定状态; 3、 转移设备维保情况, 将设备资产信息录入CMDB。( 2) 备份需求接入时, 接入方备份组备份需求接入处理1、 整理备份数据类型, 数据大小, 日增长量及相应恢复需求; 2、 提供系统数据历史增长情况及预测两年增长量; 3、 提出详细备份路径, 相应备份策略需求。1、 评估可用备份资源是否满足接入方备份需求, 按需调整; 2、 根据备份恢复要求, 综合网络速度, 系统IO限制, 对备份架构进行调优; 3、 根据备份恢复要求, 对各类型备份数据指定备份介质。4、 结合系统业务情况, IO/并发, 制定精确备份策略( 时间点、 并行窗口、 任务排序等) 。2， 恢复演练, 平台需要有应急环境, 应用系统或者虚拟机交维前做备份恢复演练, 双机配置网络设备需要做切换演练。3， 平台监控, 监控策略及监控对象梳理, 严重告警信息需发到对应维护人员手机, 做到及时性。4， 配置管理, 平台对应设备及应用系统全部录入CMDB中管理。5， 平台隐患, 梳理多次出现的故障及存在隐患点, 给出对应的处理办法及报告。6， 硬件维护商、 操作系统维护商、 网络维护商、 中间件维护商、 数据库维护商需提供5*8小时现场支持服务和7*24小时远程支持服务。7.1 交维系统转交整改的条件运维期间如交维系统存在批量安全漏洞、 系统BUG等, 维护组将该系统移交系统建设部门整改, 移交整改条件如下: 1， 操作系统安全扫描有5个或以上严重漏洞; 2， 应用系统渗透测试, 应用软件漏洞类型多于2种且漏洞数量大于10个, 需业务部门要求开发商做安全整改。3， 应用系统出现全局性功能缺陷及BUG, 导致系统不能正常使用, 或者主要功能流程不能正常扭转。4， 应用系统常见功能出现功能缺陷致占用资源不释放, 影响平台稳定性及其它应用系统使用, 需业务部门要求开发商优化应用。( 如CPU达到75、 内存达到85及存储IO读写过高) 。5， 应用系统存在性能问题( 页面响应缓慢类报障50例/周) , 并确定需经过软/硬件升级/扩容解决。8. 维护组维护内容8.1 应用维护组为确保各应用系统、 应用平台稳定高效的运行, 统一维护组维护服务主要内容如下: 维护大类维护小类详细内容服务类系统使用咨询与指导用户在日常使用系统过程遇到各类操作及系统逻辑咨询问题, 能够经过维护单的形式告知维护人员, 维护人员对遇到的问题进行解答及指导。数据后台调整由于用户操作失误导致的错误数据, 经相关负责人同意后, 维护人员需要为用户修改为正确的数据。后台数据导出在系统没有提供功能的情况下, 维护组能够给用户提供部分数据导出服务, 但数据导出仅限于按照数据库表结构导出系统原有数据, 维护不进行复杂逻辑的处理及数据整理工作。系统设置除用户角色、 权限以及审批流程之外的设置进行维护。维护类组织故障处理本系统及本系统与其它系统的接口出现故障时, 应用维护组对故障进行初步判断, 将故障提交给相关团队进行处理, 在整个故障处理过程负责协调各方团队共同解决并及时向维护主管汇报情况。系统BUG及性能问题定位系统出现BUG及性能问题, 应用维护组应预先对现象进行确认, 并提交开发商处理。数据问题查证及处理与其它ERP外围系统如出现系统间数据不一致的情况, 应用维护组应配合用户进行排查并给出合理解释; 如确定为系统BUG, 维护组提交至开发商处理。应用层日常巡检及性能监控每日对应用系统登录、 数据库主要业务表、 总条数及总容量进行巡检, 并利用工具随时对应用系统的运行进行性能监控。应用层主动维护操作:完成备份、 重启、 测试环境的管理等工作系统备份收集系统相关信息, 进行风险评估, 确定需要备份的数据源及备份需求与平台组及备份组共同确定备份策略配合备份组及平台组完成系统数据恢复测试和演练系统重启与平台组共同制定系统重启计划系统重启后对系统进行登陆验证测试环境的管理提出测试环境克隆需求测试环境的使用管理保证测试环境的正常使用定期更新测试环境数据系统运行情况的总结及分析根据系统每月的运行情况出具总结月报及系统可用率数据。组织新功能、 补丁上线审核开发商提供的上线文档对原有功能进行简单的验证, 以减少新的程序包对原有功能的影响在整个上线过程中如出现故障时负责协调各方团队共同解决并向维护主管汇报情况。系统配置管理负责日常配置变更的实施、 配置资料制作及保管、 配置相关管理办法及流程的制定。帐号管理数据库业务帐号管理: 负责数据库层业务帐号的设置及变更、 维护帐号管理相关表格、 帐号相关管理办法及流程的制定应用层支撑帐号管理: 负责应用层支撑帐号的设置及变更、 维护帐号管理相关表格、 帐号相关管理办法及流程的制定安全管控工作的配合审计管理: 配合各项审计工作, 并按照要求提供相应的样本。按照各项安全管控要求开展日常维护工作配合各项安全管控工作的开展提出系统优化建议根据系统性能监控结果及用户反馈的性能缓慢或不可用情况, 提出性能优化建议。月结/年结支持月结支持8.2 平台维护组层次工作类别工作项工作细项基础层定期服务每日巡检每天进行巡检: SCOM监控健康巡检、 SQL Server集群健康巡检, Oracle数据库健康巡检, SCVMM健康检查每周巡检1、 检查负载均衡应用系统站点配置情况2、 检查域控与地市公司的同步复制情况3、 DNS服务健康情况月度巡检机房每月硬件常规检查, 包括服务器、 交换机,负载均衡以及存储设备的健康检查补丁升级平台每两个月windows服务器安全补丁升级安全加固每个季度配合服务器设备的安全扫描以及针对扫描结果的安全加固( 重要应用系统) 资源管理基础组件资源维护服务服务器的操作系统重新安装及定期重启维护处理服务器硬件故障报修及检查测试WSUS补丁分发、 KMS服务器管理、 协助地市服务器经过KMS激活SCVMM系统管理: 1)、 虚拟主机管理2)、 虚拟机增加、 修改、 删除等操作管理3)、 虚拟机资源管理等其它SCVMM的管理操作VMware vSphere管理: 1)、 虚拟主机和群集管理2)、 数据存储和数据存储群集资源管理3)、 虚拟网络连接和管理4)、 虚拟机增加、 修改、 删除等操作管理5)、 虚拟机资源配置和资源监控管理SVC管理: 1)、 存储机头管理2)、 存储资源的分配3)、 存储监控管理负载均衡配置管理: 1)、 负载均衡网络配置2)、 负载均衡运行状态检查3)、 负载均衡的切换维护配置管理基础配置信息管理1、 对平台的服务器设备以及各配置参数按实际情况进行登记, 并录入CMDB2、 针对每个应用的配置数据进行收集并录入到资产明细表, 并针对每次的应用配置变化及时更新到CMDB3、 每次设备扩容以及新设备上架与旧设备下架进行实时的硬件配置数据更新4、 每次应用以及系统软件的配置发生变化时我们以配置变更的方式进行更新配置中间层事件管理工单处理日常各个维