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

H:\精品资料\建筑精品网原稿ok（删除公文）\建筑精品网5未上传百度

【系统交维流程与规范】

版本 <V1.0>

拟制

日期
-07-07
审核

日期

批准

日期

修订历史记录

版本
日期
AMD
修订者
说明
V1.0
-7-7
A

新增规范文档

( A-添加, M-修改, D-删除)
目录

1. 服务目标 5
2. ERP系统交维流程 7
3. ERP系统交维资产清单 11
4. ERP系统交维文档清单 14
5. ERP系统交维文档要求 16
5.1 用户手册( 系统功能说明书) 16
5.2 维护手册( 系统技术说明书: 包括软、 硬件架构说明) 16
5.3 备份策略清单( 含历史及新增) 17
5.4 系统资产清单( 含历史及新增) 17
5.5 系统配置清单( 包括安装地点信息, 含历史及新增) 17
5.6 接口清单( 含历史及新增) 18
5.7 系统账号清单( 含接口账号 , 新增账号 ) 18
5.8 新功能清单 18
5.9 程序部署手册 18
5.10 回退操作手册 19
5.11 测试报告 20
5.12 系统测试用例 20
5.13 源代码 21
6. ERP交维系统的压力测试 22
6.1 压力测试目的 22
6.2 压力测试工具 22
6.3 压力测试用例 22
6.4 压力测试指标及期望值 22
6.5 压力测试数据及场景 23
6.6 压力测试报告 24
7. ERP系统交维的前提条件 25
7.1 交维系统转交整改的条件 27
8. ERP统一维护组维护内容 28
9. 时间管理 32

1. 服务目标
各应用系统、 应用平台建设周期完成, 正式投入使用, 系统建设部门将其移交维护部门进行运行统一维护。为规范各应用系统、 应用平台从建设转为运行维护的流程, 减少系统故障, 缩短故障处理时间, 提高各应用系统、 应用平台运行的稳定性、 高效性, 提供高质量的系统支撑, 特制订本管理流程。
经过开展规范化, 流程化, 知识化的维护服务, 保持各应用系统、 应用平台的稳定性和服务高效性, 并实现以下期望目标:
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利用率

内存利用率

存储IO

3， 数据库级别测试指标。
数据库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、 对平台的服务器设备以及各配置参数按实际情况进行登记, 并录入CMDB
2、 针对每个应用的配置数据进行收集并录入到资产明细表, 并针对每次的应用配置变化及时更新到CMDB
3、 每次设备扩容以及新设备上架与旧设备下架进行实时的硬件配置数据更新
4、 每次应用以及系统软件的配置发生变化时我们以配置变更的方式进行更新配置
中间层
事件管理
工单处理
日常各个维