银行BPC系统应急处理手册.docx

1、银行BPC系统应急处理手册BPC应急处理手册银行BPC系统应急处理手册目录1 总则 11.1 适用范围 12 突发事件分级分类 12.1 突发事件分类 12.2 突发事件分级 22.3 突发事件升级 23 系统重建 23.1 备份情况 23.2 主机系统恢复与重建 34 附件： 44.1 通讯联络清单 44.1.1 突发事件快速响应电话 45 技术相关应急场景与应急处理 45.1 BPC应急预案 45.1.1 Dp应急预案 45.1.2 SP应急预案 65.1.3 Mongo迁移应急预案 75.1.4 MongoDb重启应急预案 105.1.5 BPC软件重装应急预案 115.1.6 Lice

2、nse安装应急预案 135.1.7 临时文件清理应急预案 145.1.8 BPC重启应急预案 155.1.9 配置文件恢复应急预案 165.1.10 数据积压应急预案 171 总则1.1 适用范围本预案适用于预防和处置BPC交易监控系统的突发事件。本预案所称突发事件，指BPC交易监控系统出现异常，影响业务的持续开展，需要采取应急处置措施的事件。2 突发事件分级分类2.1 突发事件分类BPC交易监控系统突发事件按事件现象分为六类：操作系统故障、应用系统故障、通讯故障、自然灾害、人为破坏、外部服务中断。(1) 主机及操作系统故障类：指由于系统硬件、系统软件、通讯链路、基础设施等故障导致系统中断、系

3、统性能大幅下降的突发事件。(2) 应用系统故障：指由于应用软件故障等导致业务中断或无法正常开展的突发事件。(3) 通讯故障：指由于通讯网络中断、网络攻击、计算机病毒爆发等原因造成系统与外围系统通讯异常，导致业务中断或无法正常开展的突发事件。(4) 自然灾害类：指由于火灾、雷击、海啸、地震、重大疫情等自然灾害引起线路中断、设备损坏等事故，导致业务中断或无法服务的突发事件。(5) 治安事件类：指由于黑客攻击、恐怖袭击等违法犯罪对生产设备造成损坏，导致系统无法正常服务的突发事件。(6) 外部服务中断：指由于第三方系统因故障或其他原因停止服务，导致系统无法正常服务的突发事件。2.2 突发事件分级BPC

4、交易监控系统突发事件依照影响业务类别及持续时间等因素，分为三级：IV级（特别重大事件）和V级（重大事件）和VI级（较大突发事件）。(1) 特别重大运营中断事件(IV级)1) BPC交易监控系统数据包泄露，导致银行客户账号信息泄露，从而对银行以及客户造成名誉和经济上的损失。(2) 重大运营中断事件(V级)1) BPC交易监控系统服务器宕机不能够正常进行登录，同时不能够对业务系统的交易进行实时监控。 2) BPC监控系统服务器因为硬件损坏或操作系统升级补丁，产生不兼容，导致服务器不能正常运行(3) 较大运营中断事件(VI级)1) BPC交易监控系统应用程序因为产品缺陷导致不能驱使应用程序正常运行，

5、同时不能够实时监管交易系统的响应时间。2) 因为人员操作失误原因导致BPC监控系统不能够正常运行，同时不能够实时监管交易系统的响应时间。2.3 突发事件升级BPC交易监控系统突发事件发生后，应依据事件影响的范围、时间等因素的变化，按上述定义进行事件级别升级。3 系统重建3.1 备份情况(1) 数据库备份情况：由于BPC交易监控产品的数据库为内嵌式数据库以配置文件形式存在，数据分两部分，一部分是监控数据，另一部分是信息数据，针对监控数据采取定期清理自动清理的模式，配置型数据采取每天夜里2点自动备份到/opt/bpc/backup目录下。(2) 配置文件备份情况：BPC交易监控系统中的/opt/b

6、pc/etc/目录配置文件包含协议目录/protocols和dp程序目录，采取定期人工备份的方法进行。(3) 探针配置文件备份：探针配置文件采取夜里自动备份的模式进行，备份目录/opt/sfi/config/。3.2 主机系统恢复与重建BPC交易监控系统的重建分主机操作系统、数据库、应用程序的重建。重建情况分析如下：1. 数据库与应用程序未做HA，不能实现系统故障自动切换；2. 数据库或应用程序出现故障，可将相关备份数据放至一台预备机器上，修改配置后即可在短时间内迅速搭建起服务；3. 数据库和应用程序同时出现异常，可将相关备份数据放至一台预备机器上，修改配置后即可在短时间内迅速搭建起服务；4.

7、 如果网络出现异常，由于采用的是双网卡绑定ip机制，如果有一个网卡能用，可以自动切换。重建步骤如下：1、 安装操作系统进行常规配置如：“规划磁盘阵列进行文件系统划分，IP地址配置、防火墙配置、服务器主从配置等”2、 安装应用程序并对应用程序进行基础信息配置。包含如下数据a) Bpc服务配置：/opt/bpc/backup，/opt/bpc/etcb) 探针配置：/opt/sfi/config/3、 恢复数据，取系统最后一次的备份数据，进行恢复。4、 对恢复后的业务系统，进行访问、业务处理、数据校验等操作。4 附件：4.1 通讯联络清单说明：列出和本预案有关各类组织和人员的联系方式。各类组织和人

8、员包括但不限于由应急领导小组办公室、突发事件领导小组、应急执行小组和应急保障小组组成的民生银行科技开发部应急响应及恢复团队，外部为民生银行科技开发部提供有关灾备服务的第三方服务商，相关的上级监管机构、相关的新闻媒体、相关员工的家属、提供各类水、电、通讯服务的运营商和供应商、提供相关设备或服务的厂商等。联系方式包括但不限于固定电话、移动电话、家庭或办公地址、电子邮件等。4.1.1 突发事件快速响应电话序号电话名称报警受理单位电话1报警电话公安分局1102火警电话消防中队1193紧急救护电话急救中心120，9994申请赔偿电话保险公司5运行管理部值班电话运行管理部6行政保卫部值班电话行政保卫部7办

9、公室值班电话办公室5 技术相关应急场景与应急处理5.1 BPC应急预案5.1.1 Dp应急预案场景 1：DP由于系统解码出现异常，进程down掉，Service dashboard多个视图出现超过10分钟的延迟:应急处理：在任意目录下执行bpc console,重启restart bpc_dp:dp,如下截图所示：结果验证查看该bpc_dp:dp进程第二列是否处在running状态5.1.2 SP应急预案场景 1：SP由于数据包乱序等异常导致sp程序出现异常停止，该页面涉及到的SP抓包系统至少会出现5条以上灰色进度。应急处理：在任意目录下执行bpc console,重启restart sp:s

10、p_eth1_pktminer如下截图所示：执行restart sp:sp_eth1_pktminer，restart sp:sp_eth3_pktminer结果验证1、 查看该sp:sp_eth1_pktminer、sp:sp_eth3_pktminer的进程是否出入RUNNING状态5.1.3 Mongo迁移应急预案场景 1 Mongodb空间导致存储磁盘满应急处理：一、 查看当前数据库目录和大小当前Mongo目录为/opt/lib/mongo, 大小为778GB二、 外挂1TB存储挂载到本地/mnt/backupdisk三、 导出备份当前的路径图及相关表执行/opt/python27/b

11、in/python /opt/bpc/scripts/backup.py -t /opt/bpc/backup/ -mongodb=bpc -sqliteroot=/opt/bpc/var/db/ -i会提示成功备份类似这样的log:2013-12-17 10:26:03 level=INFO type=backup start backup 20131217102603这时候就备份到/opt/bpc/backup/20131217102603.backup目录。四、 停止BPC进程 执行 bpc stop all五、 停止mongo，执行/etc/init.d/mongod stop六、 新

12、建一个Mongo数据库的文件夹a) 重命名数据库，将/opt/lib 重命名为 /opt/lib_backmv /opt/lib /opt/lib_backb) 创建一个新的Mongo文件夹： mkdir p /opt/lib/mongoc) 给Mongo文件夹赋予权限： chown mongod:mongod /opt/lib/mongo七、 启动mongo, /etc/init.d/mongod start八、 还原配置文件和表空间结构执行脚本，把/opt/bpc/backup/20131217102603.backup里面的文件还原回来:/opt/python27/bin/python

13、mongorestore.py /opt/bpc/backup/20131217102603.backup/九、 启动bpc,执行bpc start all，（17：45，从停止到启动20分钟。） 十、 把/opt/lib_back中的数据dump到备份磁盘上(备份盘挂载/mnt/backupdisk)，共导出180GB数据（实际1小时50分钟）。1、mkidr /mnt/backupdisk/mongoback2、nohup mongodump -dbpath /opt/lib_back/mongo/ -o /mnt/backupdisk /mongoback/ &输出log如下：Tue D

14、ec 17 18:32:03 tools all dbsTue Dec 17 18:32:04 tools command admin.$cmd command: listDatabases: 1 ntoreturn:1 keyUpdates:0 locks(micros) R:3 W:723779 r:28 reslen:174 727msTue Dec 17 18:32:04 tools DATABASE: bpc to /mnt/backupdisk/mongoback/bpcTue Dec 17 18:32:04 tools bpc.seq_gen to /mnt/backupdisk

15、/mongoback/bpc/seq_gen.bsonTue Dec 17 18:32:04 tools 2 objectsTue Dec 17 18:32:04 tools Metadata for bpc.seq_gen to /mnt/backupdisk/mongoback/bpc/seq_gen.metadata.jsonTue Dec 17 18:32:04 tools bpc.main_app_datapath to /mnt/backupdisk/mongoback/bpc/main_app_datapath.bsonTue Dec 17 18:32:04 tools 14 o

16、bjectsTue Dec 17 18:32:04 tools Metadata for bpc.main_app_datapath to /mnt/backupdisk/mongoback/bpc/main_app_datapath.metadata.jsonTue Dec 17 18:32:04 tools bpc.app_datapath to /mnt/backupdisk/mongoback/bpc/app_datapath.bsonTue Dec 17 18:32:04 tools 7 objectsTue Dec 17 18:32:04 tools Metadata for bp

17、c.app_datapath to /mnt/backupdisk/mongoback/bpc/app_datapath.metadata.jsonTue Dec 17 18:32:04 tools bpc.app1_bar to /mnt/backupdisk/mongoback/bpc/app1_bar.bsonTue Dec 17 18:32:23 tools getmore bpc.app1_bar cursorid:2562018678637645326 ntoreturn:0 keyUpdates:0 numYields: 1891 locks(micros) r:1328740

18、nreturned:14262 reslen:4194327 19272msTue Dec 17 18:32:23 tools 200/348579281 0% (objects)十一、 将备份数据Restore到在线数据库（预计16个小时完成）执行nohup mongorestore /mnt/backupdisk/mongoback/ &十二、 umount外挂存储完成操作。结果验证：查看/opt/lib空间大小，空间是否已经释放。5.1.4 MongoDb重启应急预案场景 1 登陆前台浏览器时如下图报数据库状态：异常应急处理：1）ssh登陆BPC服务器后台2）后台使用service mo

19、ngod restart重置数据库进程结果验证SSH到BPC后台使用service mongod status查看mongodb的状态，正常应该是running状态。5.1.5 BPC软件重装应急预案场景 1 任何其他手段都无法恢复BPC的情况下。应急处理：1） 请根据8.1备份情况，确认数据的备份情况。建议将备份数据导出到外部存储（可以使用sftp或外挂盘）。2） Ssh到bpc后台使用“bpc stop all”停止bpc。3） “cd /opt/bpc/script/”进入BPC卸载脚本目录。4） 在卸载脚本目录下使用“./uninstall.sh”来运行卸载脚本。 5） 使用“rebo

20、ot”重启bpc服务器6） 重启完成后请按照“crossflow产品安装与维护手册”来重新安装BPC产品。7） 请按8.1备份情况的路径将备份数据导入。结果验证重启登陆bpc前台，各项功能正常。5.1.6 License安装应急预案场景 1 License过期，抓包系统全部出现灰色进度。查看前台BPC-帮助-关于，查看授权信息，确认是否过期或异常。应急处理：获取备份License或联系厂商人员获取，在bpc前台 管理解码器和授权进入License加载页面。点击更新授权文件加载License文件。结果验证查看前台BPC-帮助-关于，查看授权信息，确认已经恢复。5.1.7 临时文件清理应急预案场景

21、 1 BPC服务器磁盘满导致BPC服务停止，可以ssh到BPC后台通过df h来查看磁盘。应急处理：Ssh到BPC后台使用rm命令清理下列文件夹中的所有数据/opt/bpc/var/store/trace_archive/appx/intfx/opt/bpc/var/store/trace_archive_sp/ethx结果验证在bpc后台使用df h确认空间已经释放。5.1.8 BPC重启应急预案场景 1 BPC出现异常，无法自动恢复，并已经通过人工干预依然无法恢复。应急处理：1） 登陆bpc后台，使用bpc restart all命令重启bpc。2） 后台提示重启完成后，进入前台数据源管理

22、启动对应的数据源结果验证在后台使用BPC console,确认出splunk以外其他进程都处于running状态。并在前台确认功能。5.1.9 配置文件恢复应急预案场景 1 重新安装BPC后，导入配置文件。应急处理：(1) 配置文件备份情况：将协议配置文件夹导入到/opt/bpc/etc/protocol下将主机配置文件导入到/opt/bpc/etc/local下结果验证使用ls命令确认文件已经导入。5.1.10 数据积压应急预案场景 1 BPC数据出现15分钟以上的延迟。应急处理：1） 后台检查BPC console，确认bpc进程状态，对不处于running或exited的进程使用restart+进程名来重启。2） 使用top查看cup使用率，如果使用率异常过高（大量cpu core满载）。反馈接口人。3） 使用iostat x k 1查看硬盘使用率，如果使用率异常过高（近100%）。反馈接口人。结果验证确认进程正常，并延迟恢复。