产品经理标准化数据备份及恢复操作手册.doc

产品经理原则化数据备份及恢复操作手册
1 目的
产品经理必须具有软件系统数据备份及系统恢复的操作能力，保障软件产品安全稳定运行，客户使用企业软件产品时可以安全、有序、健康、高效地开展工作，防止紧急突发事件、及时排查和迅速处理故障。
2 规定及约束
为了实现以上目的，需要多种内、外部环境和设施：
需要所有有关人员统一思想、统一认识，积极积极参与系统的建设和维护中来。形成严格的问题反馈机制。
形成高效的应急领导小组，项目经理责任制，组长把关，职责到人明确分工，在工作中管理得当、到位。实行人员工作认真、负责，规范化、流程化工作，如有原则操作手册一定要严格执行。遵守现场规定的多种系统集成、系统维护、数据库维护工作规范等。
建立高效的协调机制，由于该系统会集成其他厂家系统或数据中心数据，有关接口规定明确、沟通流畅，防止通道阻塞。其他如数据库、中间件、系统配置有关软件厂家和供应商要有交流渠道，一旦发现问题立即处理。
需要提供良好的办公环境，为集中处理问题提供便利。
需要定期召开协调会议，通报系统建设状况和存在问题。
3 组织机构与职责
产品经理牵头组织成立的运行应急处理组织机构一般应包括平常维护监控组、应急指挥中心、应急工作组，应急工作组包括程序故障应急小组、应用故障应急小组、平台故障应急小组、网络故障应急小组、后勤保障应急小组。
3.1 应急指挥中心
应急指挥中心由应急组长、项目经理、项目管控领导等构成。
企业应急指挥中心的重要职责：
（1）审定软件系统优化提高时系统的运行应急预案；
（2）宣布进入和解除应急状态，决定实行和终止软件优化提高上线、上线运行应急预案；
（3）对系统突发事件级别进行决策，并统一指挥应急处置工作；
（4）研究讨论突发事件的产生原因、处理过程、处理成果，并公布处理措施进行确认归档。
3.2 应急工作组
应急工作组按职能角色分类，应当由软件开发负责人、软件工程师，网络工程师，实行工程师，系统集成工程师，测试工程师等构成。
应急工作小组在系统应急突发事件中的重要职责：
（1）贯彻应急指挥中心布署的各项任务；
（2）负责企业软件应急预案的编制工作；
（3）监督执行应急指挥中心下达的应急指令、重大应急决策和布署，协调各方应急资源，组织各单位及故障处理小组进行应急处理；
（4）及时理解和掌握系统突发事件与应急处置工作状况，向应急指挥中心汇报应急处置过程中发现的重大问题，并协调处理；
（5）负责系统突发事件调查、总结应急处理经验和教训等后期处置工作。
（6）人员分工详见《应急组织及人员分工表》。
4 事件分级
软件故障对服务的顾客和企业生产、经营和管理的影响范围、程度、也许产生的后果和损失等原因，将系统故障分为重大事件（I级）、较大事件（II级）和一般事件（III级）三个等级。
发生一般事件（III级）企业及时规定进入系统应用III级应急状态，发生II 级突发事件企业进入II 级应急状态，发生I级系统突发事件企业进入I级应急状态。
4.1 重大事件
重大事件是指上线运行过程中，整个系统或功能模块无法运行，且持续6个小时无法恢复，严重损害客户的利益的突发事件；或者系统运行过程中的关键业务出现严重错误，对企业正常运行和监测导致严重影响和巨大经济损失的突发事件；或者网络故障导致大面积顾客服务中断的突发事件。
软件出现重大事件重要有：
Ø 应用系统宕机，导致系统无法使用和正常运转。
Ø 在IMS监控中出现数据断连状况，影响数据正常传递。
Ø 数据库中数据丢失，给客户带来重大损失、影响正常监测。
4.2 较大事件
较大事件是指割接过程中或上线运行过程中，整个系统或功能模块可以运行，不过性能大幅下降，且持续6个小时无法恢复，一定程度上损害客户利益的突发事件；或者系统运行过程中的关键业务出现较大错误，对运行监测导致较大影响和较大经济损失的突发事件；或者网络故障导致部分顾客服务中断的突发事件。
软件出现较大事件重要有：
Ø 流程无法上传下达。
Ø 无法监控项目信息异动。
4.3 一般事件
一般事件是指割接过程中或上线运行过程中，整个系统或功能模块运行正常，关键业务运行正常，不过性能有一定程度的下降；或者非关键业务可以开展，不过存在某些问题，对正常运行监测导致较小影响的突发事件；或者网络故障导致少许顾客服务中断的突发事件。
Ø 系统页面报错发生异常。
Ø 顾客信息锁死，登录异常。
Ø 系统运行缓慢，影响客户正常使用。
Ø 监控异常，指标异常，阀值异常。
Ø 部分功能模块报错无法使用。
Ø 网络连接出现异常，包括客户无法登录、数据无法传递等。
5 应急响应机制
因下列原因对系统上线或上线运行导致尤其严重影响，也许影响客户正常使用和其他工作停滞。
（1） 通道与网络故障；
（2） 主机设备、操作系统、中间件和数据库软件故障；
（3） 应用服务故障；
（4） 应用程序公布故障或应用系统数据丢失；
（5） 数据传播、接受重大错误；
（8） 机房电源、空调等重大环境故障；
（9） 大面积病毒爆发、蠕虫、木马程序、有害移动代码等；
（10） 非法入侵，或有组织的袭击；
（11） 自然灾害或人为错误操作导致数据严重破坏；
（12） 其他导致系统上线运行失败的原因。
5.1 应急启动
各应急配合单位、部门须严格按照应急预案的安排完毕有关准备工作。
应急实行期间各工作检查人，必须每日对各项工作完毕状况进行检查并签字确认，记录未完毕工作及原因；关键任务要准时间点进行检查。
发生突发事件后，事件发生单位立即向应急工作组汇报。
应急工作组接到II级应用突发事件的应急汇报后，根据事件状况，决定与否启动应急预案，并将成果上报应急指挥中心。
应急工作组接到I级应用突发事件汇报后，立即向企业应急指挥中心汇报，企业应急指挥中心根据事件状况进行应急处置决策，并启动应急预案。
5.2 事件汇报
发生支撑系统应用突发事件时，由突发事件发现单位或人员直接向应急工作组及本单位领导汇报。
汇报分为紧急汇报和详细汇报。紧急汇报是指事件发生后，各级单位或部门向应急工作组以口头和应急汇报表形式汇报事件的简要状况；详细汇报是指由应急处理机构在事件处理暂告一段落后，以书面形式提交的详细汇报。
任何单位和个人均不得缓报、瞒报、谎报或者授意他人缓报、瞒报、谎报事件。
事件汇报的内容和格式规定：
（1）口头汇报的内容重要包括事件发生的时间、概况、也许导致的影响等状况。
（2）口头汇报后应按照附件四格式用传真方式报送应急工作组，规定内容简洁、清晰、精确。
5.3 应急处置
应急故障处理流程重要包括系统正式割接过程的应急故障处理和上线运行后的应急故障处理。
假如系统异常应当先由应急故障处理领导小组进行故障等级鉴定，后由应急工作组进行故障类型鉴定及故障处理，以便在尽量短的时间内割接成功或上线成功。
当突发事件发生时，首先由应急工作组进行事件等级鉴定；假如是I级事件（重大事件）需要上报应急指挥中心进行应急处理决策，以确定详细的应急措施；假如是II级事件（较大事件），则直接上报应急指挥中心确定应急措施；假如是III级事件（一般事件），则协调应急小组进行故障处理。另一方面，在事件等级鉴定完毕后，应急工作组需要进行故障类型的鉴定，并将鉴定成果交给各分类故障处理小组进行故障处理。假如是I级事件（重大事件），则由应急指挥中心将应急措施告知分类故障处理小组即刻进行处理。最终，由分类故障处理小组完毕故障排除工作。
在正式上线运行后，假如发现系统无法运行，此时由应急故障处理领导小组进行决策，可以启用容灾中心数据库和应用服务，并修改DNS配置接管生产中心的关键业务，在系统设备或系统软件故障修复后在将数据库和应用服务回切到生产中心。假如系统性能出现问题，可以依次对网络、程序、配置、数据库及应用服务器问题逐渐进行排除，对应的措施包括优化网络、改善程序代码、修正配置、增长应用服务器分肩负荷、暂停部分非关键业务以减少业务总量、优化数据库后台操作脚本等。假如是系统缺陷，则需要修复缺陷。
当突发事件由II级发展为I级或发生I级突发事件后，应急工作组接到应急汇报后，立即上报企业应急指挥中心，企业应急指挥中心启动企业应急预案，协调企业其他应急资源支持应急处理，支持事件有关单位及时、有效地进行处理，控制事件发展。
及各单位信息网络管理维护部门负责本单位所辖的广域网及局域网的通道、设备的稳定运行。当发生病毒、非法入侵、网络袭击、有害信息传播、不符合规定的涉密信息传播等事件时，迅速调整网络安全设备的安全方略或隔离事件区域，查找源头，采用有效措施，控制事件的发展。当发生外力破坏时迅速修复，并立即启用备用通道，短时间内恢复通道正常。
5.4 应急结束
在同步满足下列条件下，应急指挥中心可决定宣布解除应急状态：
（1）突发事件已得到有效控制，状况趋缓。
（2）突发事件处理已经结束，设备、系统已经恢复运行。
应急指挥中心应及时向现场应急工作组和参与应急支援的有关单位传达解除应急状态响应的指令，恢复正常生产工作秩序。
系统上线，系统稳定运行，转入运行维护阶段。
6 后期处置
6.1 后期观测
I级信息支撑系统突发事件应急处理结束后应亲密关注、监测系统2周，确认无异常现象。
II级信息支撑系统突发事件应急处理结束后应亲密关注、监测系统1周，确认无异常现象。
III级信息支撑系统突发事件应急处理结束后应亲密关注、监测系统2天，确认无异常现象。
6.2 调查与评估
软件系统突发事件应急处理结束后，严重影响到企业利益和用电客户利益的重大、较大事件，应急工作组按照有关规定或规定，对事件产生的原因、影响进行调查和评估，对责任进行认定。调查汇报按企业规定报有关部门，同步报送营销部。
6.3 总结与整改
系统突发事件应急处理结束后，有关单位应组织研究事件发生的原因和特点、分析事件发展过程，总结应急处理过程中的经验和教训，进行应急处置知识积累，深入补充、完善和修订运行维护应急预案。
系统突发事件应急处理结束后，有关单位应会同应急工作小组结合运行过程中的异常和事件，综合分析系统应用中存在的要点和微弱点，提出该类事件的整改措施，制定整改实行方案并予以贯彻，整改措施和方案报企业运行监控中心立案。
7 应急保障措施
7.1 物资保障
应急物资重要有服务器、磁盘阵列、备品备件、常用工具和常用工具软件。
7.2 人员保障
指挥中心办公地点设置在企业总部或大区级总部（西北、西南、东北）。关键人员构成有项目经理、组长、副组长和实行人员。突发事件应急技术支持队伍的建设，保证业务和技术骨干人员可以迅速到位。技术人员由指挥中心统一调配，集中管理。
7.3 通信保证
应急期间，指挥、通信联络和信息互换的渠道重要有系统程控电话、外线电话、手机、传真、电子邮件等方式，有关应急联络的手机应保持24小时开机状态。
8 应急响应流程

9 应急宣传及演习
9.1 应急宣传
应急工作组将应急预案发给有关单位、规定各单位加强学习。
9.2 应急演习
针对关键业务进行测试演习，关键业务包括全面监测、运行分析、协调控制、全景展示等。
10 数据备份
软件数据的安全性、完整性、可恢复性，需要建立高可靠性的备份系统，并遵照如下原则：
(1) 稳定性：备份软件需可靠、稳定；
(2) 全面性：集成了UNIX主机、Windows服务器、SAN构造磁盘系统、备份磁带库等多种产品，规定备份软件可以适应复杂的环境和扩展性能的规定，并提供多种操作系统平台、多种主机、多种备份方式的支持；
(3) 全自动备份：备份系统可以根据应用特点，制定备份方略，备份系统自动准时驱动磁带库，并完毕数据的备份，同步生成备份工作记录，供系统管理员查看；
(4) 高性能：备份系统减少对备份服务器性能产生影响，采用高速的SAN构造Lan_Free备份方式；
(5) 可管理性：规定备份系统易于维护和管理，提供图形化界面；
(6) 实时性：支持在线备份数据功能；
(7) 可恢复性：劫难或故障发生后，备份系统在最短的时间内完毕数据自动恢复到本来的状态；
(8) 高效的介质管理：备份系统支持将备份介质中自动加入电子标签，可以在备份和恢复中迅速定位磁带；
10.1 备份需求
软件数据备份详细规定为：
(1) 备份应在晚间进行，8个小时内完毕一次数据全备份操作，2小时内完毕每天增量备份操作；
(2) 可以对数据进行集中备份，根据业务需求灵活定制备份方略；
(3) 数据库采用SAN存储网络的Lan_Free备份方式，操作系统和应用程序可以采用当地磁带机备份方式；
备份范围包括系统数据（操作系统、应用程序）、数据库数据（基础业务数据、轻度汇总数据、重度汇总数据，源数据可以不做备份）和Cube文献。
10.2 备份方略
软件的备份技术规定和备份方案设计原则上，详细的备份方略如下：
表 1 软件数据备份方略表
备份内容
服务器/服务器名
备份介质
备份措施
备份时间
备份频率
保留周期
保留份数
系统备份
操作系统
所有服务器
当地磁带库
手动备份
变化系统配置后进行操作系统备份
1
数据库软件、配置文献
数据库服务器
当地磁带库
手动备份
1
应用服务器软件、配置文献、应用程序
应用服务服务器
当地磁带库
手动备份
1
数据库备份
基础业务数据
轻度汇总数据
重度汇总数据
软件数据库
磁带库/虚拟磁带库
增量备份
每天
1天
1周
2
软件数据库
磁带库/虚拟磁带库
全备份
周日
1月
2月
2
文献备份
CUBE文献
BI服务器
文献服务器
全备份
每天
1月
1周
1
11 迅速恢复方案
11.1 系统恢复方案
当发生劫难时，应针对备份方略的制定来开展数据恢复工作。恢复时间至少为24小时（包括更换受损硬件设备等操作），同步搭建临时的系统应对系统使用需求。
当发生系统应急状况时，采用如下总体计划：
n 由技术人员确定其故障原因
n 搜集数据库备份文献；
n 告知技术人员进行处理；
n 告知顾客启动应急方案；
n 执行数据恢复工作；
n 测试并由顾客验收；
数据库复制目的与原则
1)对既有生产的影响小
灾备数据复制技术的设计，不应引起生产性能的大幅下降、也不应对既有对生产环境中的系统、应用、数据类型和整体构造产生较大改动。尽量的选用适合生产环境的数据复制技术和模式，减少对生产系统的影响。
2)多对一、灾备资源共享
对性质和类型（数据类型、存储位置、数据属性）相似或相近的数据尽量的采用相似数据复制技术。采用多对一的数据复制技术，实现灾备中心资源共享，提供资源运用率、便于后期运行维护管理。
3)强健性、稳定性、容错性
数据复制技术和数据传播链路的设计要充足考虑其强健性、稳定性和容错性。数据复制链路的设计要尽量考虑高可用设计，保证数据的持续保护。
4)数据完整性、一致性
数据复制的完整性、一致性是数据复制保护的关键考量点，需要我们在设计数据复制技术的时候充足考虑，不遗漏数据。
5)精简数据、节省空间和带宽
对非业务数据，例如操作系统数据，应用程序等，不纳入灾备保护范围，以到达节省磁盘空间、减少复制带宽。在不影响生产性能的前提下，数据传播考虑启用压缩功能，提高带宽资源运用率。
6)集中复制
结合优化整合的工作，在合理的范围内，采用数据集中、存储集中、集中复制的方略。
7)数据复制安全性方略
数据已经作为现代企业的IT架构最关键的部分，其在平常备份、数据迁移和转移、数据远程传递复制过程中，数据安全须符合有关规定。
8)数据恢复、演习
灾备方案设计必须考虑数据恢复性和可演习性。
11.2 容灾中心数据库设计
容灾中心数据库设计应与总部既有数据库设备类型和操作系统版本保持一致。
表2容灾中心数据库复制软件配置
应用系统
应用模块
数据库名
GG版本
GG安装位置
GG应用进程数
复制队列大小
GG顾客
软件
软件
VAS
11
外置存储文献系统/goldengate
1
70G
System
容灾端复制区数据库的存储LUN设计
表 3容灾中心数据库复制存储配置
业务系统
子模块
主机
Volume Size(MB)
容灾复制卷Cu:Ldev
总空间
软件
软件
hbdwdb1/hbdwdb2
102400.3
01:c0
36TB
102400.3
01:c1
102400.3
01:c2
102400.3
01:c3
102400.3
01:c4
102400.3
01:c5

11.3 数据库复制链路设计
1)对于容灾复制使用端口的考虑：在保证容灾同步数据库的前提下，对既有端口数量进行优化。
2)Varidata和监控软件只在演习和容灾初始化，变动时使用。且最多支持2个原则省的同步数据验证，以此减少端口量。
3)平常的监控工作可以考虑使用goldengate命令和脚本替代，节省不必要的端口。
表5数据库复制链路
应用系统
应用模块
生产数据库名
GG捕捉进程数
GG传播进程数
容灾数据库名
GG应用进程数
复制队列大小
软件
软件
db_hbdw_data
1
1
db_hbdw_data
1
70G