银行卡收单系统应急手册

《银行卡收单系统应急手册》由会员分享，可在线阅读，更多相关《银行卡收单系统应急手册（10页珍藏版）》请在金锄头文库上搜索。

1、XXXX 银行卡收单系统应急手册文档状态文件状态：文件密级：草稿*机密，只对公司内部指定人员V 正式发布对公司内部公开正在修改对部门内部公开可对外公开目录1引言 - 3 -1.1 编写目的 - 3 -1.2 背景 - 3 -1.3 解释 - 3 -1.4 参考资料 - 3 -2工作原则 - 4 -2.1 统一指挥原则 - 4 -2.2 系统不间断原则 - 4 -2.3 业务连续性原则 - 4 -2.4 联机交易最大允许停顿时间 - 4 -2.5 数据完整性原则 - 4 -2.6 遇到突发事件进行系统级恢复所需时间 - 4 -2.7 可操作性原则 - 4 -2.8 公正及保密原则 - 5 -3紧

2、急事件处理方式 - 5 -4指挥体系及职责分工 - 5 -4.1 生产系统紧急处理组织结构 - 5 -4.2 紧急处理人员职责 - 5 -4.2.1 领导人职责 - 5 -4.2.2 生产系统紧急处理工作人员的职责 - 6 -5应急处理预案 - 6 -6处理流程 - 7 -6.1信息报送和处理 - 7 -6.2应急处置 - 7 -6.3应急结束 - 8 -6.4善后处置 - 8 -7系统应急操作 - 8 -1 引言1.1编写目的本文档为XXXX银行卡收单系统应急手册，旨在建立XXXX各级紧急响应事件 的范围、应急处理相关部门及应急处理流程的框架，以提高应对突发生产系统的 能力，保证公司生产系统

3、在发生紧急响应时间的情况下尽可能快恢复正常运行， 将可能造成的损失控制在最低程度内，最大程度保证生产系统的安全，文档，维 护公司形象和声誉。本文档预期读者对象为：1. 系统开发人员2. 运维领导和运维人员3. 应急人员1.2背景本手册所涉及的生产系统包括所有生产环境网络设备，所有主机，交换机等，所 有数据库系统，所有业务应用系统。各级紧急响应时间包括生产系统硬件故障，网络通信故障，数据库软件故障，应 用软件故障，病毒或者网络攻击类安全故障。1.3解释RTO：是指灾难发生后，从IT系统宕机导致业务停顿之刻开始，到IT系统恢复 至可以支持各部门运作，业务恢复运营之时，此两点之间的时间段为 RTO。

4、RPO：是指从系统和应用数据而言，要实现能够恢复至可以支持各部门业务运作, 系统及生产数据应恢复到怎样的更新程度。1.4参考资料XXXX 银行卡收单授权管理系统运维手册2 工作原则2.1统一指挥原则根据本预案规定成立相应的突发事件处置领导小组，由该领导小组统一指挥、组 织各项应对工作。一般应急小组由系统开发人员、机房管理人员相关运维技术人 员组成。2.2系统不间断原则应根据出现的生产异常及突发事件，按规定程序进行应急处理，保障系统的不间 断运行。2.3业务连续性原则应采取积极有效的措施，应根据现有的生产系统应急处理预案和生产系统数据及 应用恢复手册对出现故障的生产系统进行操作维护，以保障支付清

5、算业务的连续 性处理。2.4联机交易最大允许停顿时间面向客户的实时性业务系统及功能要求停顿时间不超过 30 分钟。内部的信息处 理业务系统停顿时间不超过 60分钟。夜晚可容忍的业务系统停顿时间不超过 60 分钟。业务量高峰期、月末、季末、年末业务系统停顿时间不超过 30 分钟。2.5数据完整性原则应尽快恢复丢失的支付清算数据，确保数据完整性和客户资金的安全。2.6遇到突发事件进行系统级恢复所需时间重要业务系统进行切换后与外部系统建立通信连接，切换时间最长不超过 60分 钟。应急处理预案应体现高效的应急处置机制，具有良好的可操作性。2.8公正及保密原则参与突发事件处置工作的人员应严守保密规定，未

6、经授权不得向外界提供与处置 有关的工作信息，不得利用工作中获得的信息牟取私利。3 紧急事件处理方式包括两大类，一类是不关闭交易，按照紧急事件处置步骤采取措施恢复正常；一 类是关闭交易，这种情况需要通报各相关单位。关闭交易适用条件：当紧急事件已经造成以下影响，并预计未来 1 小时内无法恢 复正常，经上级领导同意后，选择部分或全部关闭交易：超过发展商户三分一的数量，针对同一问题的投诉； 造成或可能造成大量单边帐或调账等账务问题； 交易成功率低于 50%。4 指挥体系及职责分工4.1 生产系统紧急处理组织结构由系统运维部的主管领导负责整个紧急处理的指挥，决定何时启动紧急处理预 案，系统运维部领导负责

7、紧急事件处理的现场指挥工作，相关系统开发负责人参 与紧急事件的处理。4.2 紧急处理人员职责4.2.1 领导人职责1. 对系统突发事件的处置研究决策。2. 统一指挥应急处置工作。4. 统一负责信息发布。5. 贯彻落实对外信息的有关工作事项。4.2.2 生产系统紧急处理工作人员的职责1.实施与职责相关的各项处置措施；2.收集、反馈生产系统紧急事件处置的相关信息以支持领导决策3. 领导制定的其他职责。5 应急处理预案应急处理预案内容包括系统概述、常用命令、常见故障分析与应急处理等三部分，其中 常见故障的分析与处理还应包括故障现象、故障定位、处理步骤、结果确认和异常处理等五 个部分。（1）系统概述应

8、包括所涉及的系统功能简介、系统软硬件情况、网络连接及其端口设置情 况、对应系统主机的机柜详细分布图示等描述。（2）常用命令是对该套系统上经常使用的命令及其功能逐一列举，并且可按需要附上命令 正确执行后的屏幕显示，供一线人员操作时参考。（3）故障现象是对故障发生时所呈现出来的异常现象的描述，应该详细、准确，对业务影 响范围做出界定，保证一线人员对应急预案的选择能够及时、到位，为顺利解决故障赢得宝 贵的时间。（4）故障定位是根据故障现象来准确判断故障点所要进行的检查、询问，应该详细到命令 行或具体的行动方法。（5）处理步骤是解决故障的最直接的方法，应该详细到命令行。如果命令行较多，还应该 尽可能固

9、化成脚本或函数，以提高故障处理的效率。为了方便一线人员对故障处理方法的理 解，应该对处理步骤进行归纳，明确解决故障的思路。（6）结果确认是指处理步骤执行完之后需要验证的结果。如果结果得到验证，表明故障已 经得到解决并且业务处理已经恢复正常。对结果确认的描述也应该准确、到位，做到简单、 明了，保证在很短时间内能够顺利完成。（7）异常处理是指当结果得不到验证时应该遵循的解决方法，一般是寻求二线人员的支持。 二线人员需要落实到具体的人员，并明确具体的联系方式。（8）生产系统应急处理预案制定之后，需要进行定期的审核检验，保证应急处理预案的有 效性，原则上应急演练的时间每年不少于一次，每次应急演练应涉及

10、演练计划、风险评估、 演练记录、演练报告、问题整改报告等相关部分。（9）应急处理预案需紧密结合生产系统突发事件的特点，通过应急处理预案演练等活动， 使生产系统的运营人员能够有效地根据应急处理预案及时处理生产系统出现的各种生产故 障。6 处理流程6.1信息报送和处理生产系统紧急事件依据其性质、危害程度及范围等划分为以下等级；较大事件：生产系统仍能提供服务，但是性能、资源出现急速下降的事件；重大事件：导致生产系统出现业务中断的事件。发生较大或重大的生产系统紧急事件后，应当在10 分钟内向运维主管和运维领 导报告。由运维领导根据交易中断事件和业务影响范围是否启定相关应急预案。如果情况紧急或重大，20

11、 分钟内无法联系到运维主管和运维领导的，运维值班 人员根据初步判断启动应急预案。6.2应急处置应急处置包括事件处理、系统恢复以及交易数据合并等工作。相关系统开发人员 要参加应急处置过程，共同保证业务持续性以及稳定性。相关技术人员在现场，按如下步骤进行：生产系统出现紧急事件后，值班人员应立即通知相关开发人员及时到位，并通知 运维主管领导，值班人员配合监督记录开发人员的操作。相关开发人员判断可否在 30 分钟内解决，如不能解决，则由开发人员决定，是 启动子系统应急预案还是整个系统应急预案，报运维领导同意后，启动相关应急 预案。应急预案的实施由开发人员严格按照相关系统的应急预案进行操作处理，运维人

12、员做好配合监督记录的工作。相关技术人员不在现场，操作步骤如下：生产系统出现紧急事件后，值班人员应立即通知运维主管和运维领导，根据运维 手册进行交易恢复处理，如交易无法恢复，通知相关系统负责人进行支持处理。 相关技术人员无法赶到现场，在技术开发人员的指导下，由运维人员根据应急预 案进行相关判断，判定可否在 30 分钟内解决，如不能解决，报运维领导同意后， 如能判定是子系统故障，启动该子系统应急预案，否则，启动整个系统应急预案。应急预案的实施由运维人员严格按照相关系统的应急预案进行操作处理。6.3应急结束对应紧急响应时间的处理，运维主管进行评估后，宣布应急处理结束。6.4善后处置应急处置结束后，根

13、据需要可保留相关部门人员负责善后工作：必需在当日日切 之前完成当天交易数据合并工作，并查找原系统故障原因，如故障解决，当天将 系统切换回原机。应急处置全部结束后，应将相关文件、资料及档案进行归档管理。7 RTO / RPO每日定时由系统运行人员将当天生产系统的数据通过专线传送到该同城数据备份系统上，并 定期刻录成光盘进行永久保管。若使用同城备份数据进行数据恢复，恢复时间不超过 1 个 小时，恢复点不超过3个小时，即RTOvl小时、RPOv3小时。8 系统应急操作生产主机为两台相同配置服务器构成的双机系统，可保证长时间稳定无故障运行。当生 产数据库发生灾难性事故，确认无法恢复时，应考虑采用文件数

14、据同档案、账户信息、客户 信息、当前交易表、终端商户门店等基础资料表等）进行全量备份，而对历史交易表等数据 量较大的表，进行增量备份，卸出当日新增的数据；该文件后援备份存储在当前活动的主机 的 expdata 目录，文件名为：fullyyyymmdd.dmp.gz - 日期 yyyymmdd 基础档案全量备份increyyyymmdd.dmp.gz - 清算日期为 yyyymmdd 的历史交易数据增量备份文件；采用该备份恢复数据，可将数据恢复到最近一次日终处理结束后的状态，仅在没有其他 方法恢复联机交易的情况下采用；在备份机上解压fullyyyymmdd.dmp.gz文件，将备份机上所有表truncate,并使用命令:imp /TNS file=fullyyyymmdd.dmp fromuser=cec touser=cec2 ignore=y确认备份机上各存储过程，触发器状态正常；修改备份服务器应用用户的etc下的dbparam.ini文件，将其由连接生产数据库改为备 份恢复的数据库。将生产主机shutdown，由备份机接管运行。9总体应急预案框架图