银行BPC系统应急处理手册.docx
《银行BPC系统应急处理手册.docx》由会员分享,可在线阅读,更多相关《银行BPC系统应急处理手册.docx(17页珍藏版)》请在冰豆网上搜索。
![银行BPC系统应急处理手册.docx](https://file1.bdocx.com/fileroot1/2023-5/27/fa792b2b-549d-4d2b-8707-0dc7f1c2f5e6/fa792b2b-549d-4d2b-8707-0dc7f1c2f5e61.gif)
银行BPC系统应急处理手册
BPC应急处理手册
银行BPC系统应急处理手册
目录
1总则1
1.1适用范围1
2突发事件分级分类1
2.1突发事件分类1
2.2突发事件分级2
2.3突发事件升级2
3系统重建2
3.1备份情况2
3.2主机系统恢复与重建3
4附件:
4
4.1通讯联络清单4
4.1.1突发事件快速响应电话4
5技术相关应急场景与应急处理4
5.1BPC应急预案4
5.1.1Dp应急预案4
5.1.2SP应急预案6
5.1.3Mongo迁移应急预案7
5.1.4MongoDb重启应急预案10
5.1.5BPC软件重装应急预案11
5.1.6License安装应急预案13
5.1.7临时文件清理应急预案14
5.1.8BPC重启应急预案15
5.1.9配置文件恢复应急预案16
5.1.10数据积压应急预案17
1总则
1.1适用范围
本预案适用于预防和处置BPC交易监控系统的突发事件。
本预案所称突发事件,指BPC交易监控系统出现异常,影响业务的持续开展,需要采取应急处置措施的事件。
2突发事件分级分类
2.1突发事件分类
BPC交易监控系统突发事件按事件现象分为六类:
操作系统故障、应用系统故障、通讯故障、自然灾害、人为破坏、外部服务中断。
(1)主机及操作系统故障类:
指由于系统硬件、系统软件、通讯链路、基础设施等故障导致系统中断、系统性能大幅下降的突发事件。
(2)应用系统故障:
指由于应用软件故障等导致业务中断或无法正常开展的突发事件。
(3)通讯故障:
指由于通讯网络中断、网络攻击、计算机病毒爆发等原因造成系统与外围系统通讯异常,导致业务中断或无法正常开展的突发事件。
(4)自然灾害类:
指由于火灾、雷击、海啸、地震、重大疫情等自然灾害引起线路中断、设备损坏等事故,导致业务中断或无法服务的突发事件。
(5)治安事件类:
指由于黑客攻击、恐怖袭击等违法犯罪对生产设备造成损坏,导致系统无法正常服务的突发事件。
(6)外部服务中断:
指由于第三方系统因故障或其他原因停止服务,导致系统无法正常服务的突发事件。
2.2突发事件分级
BPC交易监控系统突发事件依照影响业务类别及持续时间等因素,分为三级:
IV级(特别重大事件)和V级(重大事件)和VI级(较大突发事件)。
(1)特别重大运营中断事件(IV级)
1)BPC交易监控系统数据包泄露,导致银行客户账号信息泄露,从而对银行以及客户造成名誉和经济上的损失。
(2)重大运营中断事件(V级)
1)BPC交易监控系统服务器宕机不能够正常进行登录,同时不能够对业务系统的交易进行实时监控。
2)BPC监控系统服务器因为硬件损坏或操作系统升级补丁,产生不兼容,导致服务器不能正常运行
(3)较大运营中断事件(VI级)
1)BPC交易监控系统应用程序因为产品缺陷导致不能驱使应用程序正常运行,同时不能够实时监管交易系统的响应时间。
2)因为人员操作失误原因导致BPC监控系统不能够正常运行,同时不能够实时监管交易系统的响应时间。
2.3突发事件升级
BPC交易监控系统突发事件发生后,应依据事件影响的范围、时间等因素的变化,按上述定义进行事件级别升级。
3系统重建
3.1备份情况
(1)数据库备份情况:
由于BPC交易监控产品的数据库为内嵌式数据库以配置文件形式存在,数据分两部分,一部分是监控数据,另一部分是信息数据,针对监控数据采取定期清理自动清理的模式,配置型数据采取每天夜里2点自动备份到/opt/bpc/backup目录下。
(2)配置文件备份情况:
BPC交易监控系统中的/opt/bpc/etc/目录配置文件包含协议目录/protocols和dp程序目录,采取定期人工备份的方法进行。
(3)探针配置文件备份:
探针配置文件采取夜里自动备份的模式进行,备份目录/opt/sfi/config/。
3.2主机系统恢复与重建
BPC交易监控系统的重建分主机操作系统、数据库、应用程序的重建。
重建情况分析如下:
1.数据库与应用程序未做HA,不能实现系统故障自动切换;
2.数据库或应用程序出现故障,可将相关备份数据放至一台预备机器上,修改配置后即可在短时间内迅速搭建起服务;
3.数据库和应用程序同时出现异常,可将相关备份数据放至一台预备机器上,修改配置后即可在短时间内迅速搭建起服务;
4.如果网络出现异常,由于采用的是双网卡绑定ip机制,如果有一个网卡能用,可以自动切换。
重建步骤如下:
1、安装操作系统进行常规配置如:
“规划磁盘阵列进行文件系统划分,IP地址配置、防火墙配置、服务器主从配置等”
2、安装应用程序并对应用程序进行基础信息配置。
包含如下数据
a)Bpc服务配置:
/opt/bpc/backup,/opt/bpc/etc
b)探针配置:
/opt/sfi/config/
3、恢复数据,取系统最后一次的备份数据,进行恢复。
4、对恢复后的业务系统,进行访问、业务处理、数据校验等操作。
4附件:
4.1通讯联络清单
说明:
列出和本预案有关各类组织和人员的联系方式。
各类组织和人员包括但不限于由应急领导小组办公室、突发事件领导小组、应急执行小组和应急保障小组组成的民生银行科技开发部应急响应及恢复团队,外部为民生银行科技开发部提供有关灾备服务的第三方服务商,相关的上级监管机构、相关的新闻媒体、相关员工的家属、提供各类水、电、通讯服务的运营商和供应商、提供相关设备或服务的厂商等。
联系方式包括但不限于固定电话、移动电话、家庭或办公地址、电子邮件等。
4.1.1突发事件快速响应电话
序号
电话名称
报警受理单位
电话
1
报警电话
公安分局
110
2
火警电话
消防中队
119
3
紧急救护电话
急救中心
120,999
4
申请赔偿电话
保险公司
5
运行管理部值班电话
运行管理部
6
行政保卫部值班电话
行政保卫部
7
办公室值班电话
办公室
5技术相关应急场景与应急处理
5.1BPC应急预案
5.1.1Dp应急预案
场景1:
DP由于系统解码出现异常,进程down掉,
Servicedashboard多个视图出现超过10分钟的延迟:
应急处理:
在任意目录下执行bpcconsole,重启restartbpc_dp:
dp,如下截图所示:
结果验证
查看该bpc_dp:
dp进程第二列是否处在running状态
5.1.2SP应急预案
场景1:
SP由于数据包乱序等异常导致sp程序出现异常停止,该页面涉及到的SP抓包系统至少会出现5条以上灰色进度。
应急处理:
在任意目录下执行bpcconsole,重启restartsp:
sp_eth1_pktminer如下截图所示:
执行restartsp:
sp_eth1_pktminer,restartsp:
sp_eth3_pktminer
结果验证
1、查看该sp:
sp_eth1_pktminer、sp:
sp_eth3_pktminer的进程是否出入RUNNING状态
5.1.3Mongo迁移应急预案
场景1Mongodb空间导致存储磁盘满
应急处理:
一、查看当前数据库目录和大小
当前Mongo目录为/opt/lib/mongo,大小为778GB
二、外挂1TB存储挂载到本地/mnt/backupdisk
三、导出备份当前的路径图及相关表
执行/opt/python27/bin/python/opt/bpc/scripts/backup.py-t/opt/bpc/backup/--mongodb=bpc--sqliteroot=/opt/bpc/var/db/-i
会提示成功备份
类似这样的log:
[2013-12-1710:
26:
03]level=INFOtype=backupstartbackup20131217102603
这时候就备份到/opt/bpc/backup/20131217102603.backup目录。
四、停止BPC进程执行bpcstopall
五、停止mongo,执行/etc/init.d/mongodstop
六、新建一个Mongo数据库的文件夹
a)重命名数据库,将/opt/lib重命名为/opt/lib_back
mv/opt/lib/opt/lib_back
b)创建一个新的Mongo文件夹:
mkdir–p/opt/lib/mongo
c)给Mongo文件夹赋予权限:
chownmongod:
mongod/opt/lib/mongo
七、启动mongo,/etc/init.d/mongodstart
八、还原配置文件和表空间结构
执行脚本,把/opt/bpc/backup/20131217102603.backup里面的文件还原回来:
/opt/python27/bin/pythonmongorestore.py/opt/bpc/backup/20131217102603.backup/
九、启动bpc,执行bpcstartall,(17:
45,从停止到启动20分钟。
)
十、把/opt/lib_back中的数据dump到备份磁盘上(备份盘挂载/mnt/backupdisk),共导出180GB数据(实际1小时50分钟)。
1、mkidr/mnt/backupdisk/mongoback
2、nohupmongodump--dbpath/opt/lib_back/mongo/-o/mnt/backupdisk/mongoback/&
输出log如下:
TueDec1718:
32:
03[tools]alldbs
TueDec1718:
32:
04[tools]commandadmin.$cmdcommand:
{listDatabases:
1}ntoreturn:
1keyUpdates:
0locks(micros)R:
3W:
723779r:
28reslen:
174727ms
TueDec1718:
32:
04[tools]DATABASE:
bpcto/mnt/backupdisk/mongoback/bpc
TueDec1718:
32:
04[tools]bpc.seq_gento/mnt/backupdisk/mongoback/bpc/seq_gen.bson
TueDec1718:
32:
04[tools]2objects
TueDec1718:
32:
04[tools]Metadataforbpc.seq_gento/mnt/backupdisk/mongoback/bpc/seq_gen.metadata.json
TueDec1718:
32:
04[tools]bpc.main_app_datapathto/mnt/backupdisk/mongoback/bpc/main_app_datapath.bson
TueDec1718:
32:
04[tools]14objects
TueDec1718:
32:
04[tools]Metadataforbpc.main_app_datapathto/mnt/backupdisk/mongoback/bpc/main_app_datapath.metadata.json
TueDec1718:
32:
04[tools]bpc.app_datapathto/mnt/backupdisk/mongoback/bpc/app_datapath.bson
TueDec1718:
32:
04[tools]7objects
TueDec1718:
32:
04[tools]Metadataforbpc.app_datapathto/mnt/backupdisk/mongoback/bpc/app_datapath.metadata.json
TueDec1718:
32:
04[tools]bpc.app1_barto/mnt/backupdisk/mongoback/bpc/app1_bar.bson
TueDec1718:
32:
23[tools]getmorebpc.app1_barcursorid:
2562018678637645326ntoreturn:
0keyUpdates:
0numYields:
1891locks(micros)r:
1328740nreturned:
14262reslen:
419432719272ms
TueDec1718:
32:
23[tools]200/3485792810%(objects)
十一、将备份数据Restore到在线数据库(预计16个小时完成)
执行nohupmongorestore/mnt/backupdisk/mongoback/&
十二、umount外挂存储完成操作。
结果验证:
查看/opt/lib空间大小,空间是否已经释放。
5.1.4MongoDb重启应急预案
场景1
登陆前台浏览器时如下图报数据库状态:
异常
应急处理:
1)ssh登陆BPC服务器后台
2)后台使用servicemongodrestart重置数据库进程
结果验证
SSH到BPC后台使用servicemongodstatus查看mongodb的状态,正常应该是running状态。
5.1.5BPC软件重装应急预案
场景1
任何其他手段都无法恢复BPC的情况下。
应急处理:
1)请根据8.1备份情况,确认数据的备份情况。
建议将备份数据导出到外部存储(可以使用sftp或外挂盘)。
2)Ssh到bpc后台使用“bpcstopall”停止bpc。
3)“cd/opt/bpc/script/”进入BPC卸载脚本目录。
4)在卸载脚本目录下使用“./uninstall.sh”来运行卸载脚本。
5)使用“reboot”重启bpc服务器
6)重启完成后请按照“crossflow产品安装与维护手册”来重新安装BPC产品。
7)请按8.1备份情况的路径将备份数据导入。
结果验证
重启登陆bpc前台,各项功能正常。
5.1.6License安装应急预案
场景1
License过期,抓包系统全部出现灰色进度。
查看前台BPC-帮助-关于,查看授权信息,确认是否过期或异常。
应急处理:
获取备份License或联系厂商人员获取,在bpc前台管理——解码器和授权进入License加载页面。
点击更新授权文件加载License文件。
结果验证
查看前台BPC-帮助-关于,查看授权信息,确认已经恢复。
5.1.7临时文件清理应急预案
场景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.8BPC重启应急预案
场景1
BPC出现异常,无法自动恢复,并已经通过人工干预依然无法恢复。
应急处理:
1)登陆bpc后台,使用bpcrestartall命令重启bpc。
2)后台提示重启完成后,进入前台数据源管理启动对应的数据源
结果验证
在后台使用BPCconsole,确认出splunk以外其他进程都处于running状态。
并在前台确认功能。
5.1.9配置文件恢复应急预案
场景1
重新安装BPC后,导入配置文件。
应急处理:
(1)配置文件备份情况:
将协议配置文件夹导入到/opt/bpc/etc/protocol下
将主机配置文件导入到/opt/bpc/etc/local下
结果验证
使用ls命令确认文件已经导入。
5.1.10数据积压应急预案
场景1
BPC数据出现15分钟以上的延迟。
应急处理:
1)后台检查BPCconsole,确认bpc进程状态,对不处于running或exited的进程使用restart+进程名来重启。
2)使用top查看cup使用率,如果使用率异常过高(大量cpucore满载)。
反馈接口人。
3)使用iostat–x–k1查看硬盘使用率,如果使用率异常过高(近100%)。
反馈接口人。
结果验证
确认进程正常,并延迟恢复。