天旦BPC保障某城商行灾备切换演练

城市商业银行由城市信用社发展而来，随着业务转型、业务规模壮大，城商行的信息系统在不断建设与完善，业务对于信息系统的依赖性也越来越高，信息系统的安全稳定运转已经成为保证城商行业务有效性与连续性的关键。

为加强商业银行风险管理，保障金融业务连续性，促进商业银行有效履行社会责任，维护公众信心和银行业正常的运营秩序，银监会在2011年12月28日制定并颁发了《商业银行业务连续性监管指引》银监发〔2011〕104 号条例。该条例“第五章 业务连续性演练与持续改进“中第四十九及五十条规定了，“商业银行应当至少每三年对全部重要业务开展一次业务连续性计划演练。在重大业务活动、重大社会活动等关键时点，或在关键资源发生重大变化之前，也应当开展业务连续性计划的专项演练。商业银行应当加强业务应急预案的演练，重点加强业务和信息科技部门的协调、配合；应当注重以真实业务接管为目标，确保灾备系统能够有效接管生产系统并具备安全回切能力。”

因此，保证银行业务切换的连续性成为商业银行运维保障工作的重点之一。

然而，当前运维保障主要面临以下三大挑战：

1、故障感知较为被动，传统方式排障困难且繁琐；

故障感知被动且滞后，多数情况是由前端业务人员发现问题，通知后台进行处理；与此同时，运维通过日志进行排查，多依赖经验判断，耗时较长，一旦排查难度较高就需要专家协助；此外，银行所开发的专用监控工具，开发周期很长，每次也只能针对一套业务系统。

2、缺少实时业务数据，灾备切换演练数据报告只能做到“T+1”；

业务切换过程中，人工查询成本过高且无法保证实时性：后台人员需要在多台应用主机之间来回切换操作执行脚本、查看日志等，反复确认验证没有问题后，才能执行下一步操作；

3、监控视图不够灵活，无法满足重大业务保障场景(如双十一、灾切重保)的快速调整需求。

市场上部分产品的监控视图除了存在界面单调、操作复杂、配置繁琐、不够灵活等问题外，其绘图控件的功能极为有限，扩展性较差，无法满足用户日益增长的业务需求。

因此，建设完善的应用监控体系，实时感知多数据中心业务变化带来的影响，建立生产及灾备系统的故障发现与IT运维预警机制，提高对生产和灾备系统故障的及时发现以及快速排障能力，对保证银行信息系统的稳定运行和业务持续发展具有重大意义。

天旦BPC

助力某城商行业务连续性同城灾备切换演练

天旦业务性能管理BPC 采用互联数据技术，利用旁路的部署方式，实现业务性能监控的即刻落地。通过实时的故障告警、自动定位与根因分析功能，天旦BPC可以帮助银行运维技术人员快速排障，对业务交易进行实时、全量、精准监控。同时，由于天旦在金融行业积累了大量的成功落地案例，针对城商行的主要应用场景可以提供模板化的部署。譬如，天旦 BPC场景化的 APPMall视图功能和第三方RESTful API 接口，可以充分适配城商行的应用需求，助力银行业务实时平稳切换过渡，并对切换过程中触发的问题进行及时告警，自动定位问题根源，显著节约了城商行信息科技团队宝贵的时间和人力资源。

2020年6月，某城商行客户接到银监局视察该行同城灾备切换演练的通知。该行准备将多套支付业务及核心系统于主数据中心切换至同城灾备数据中心，并采用天旦BPC对切换演练实施保障。

天旦BPC在该行的部署架构

天旦BPC采用分布式架构部署，监控范围覆盖主备数据中心。通过交换机旁路镜像至流量汇聚设备TAP，再统一输送给BPC服务器。（该行配置流量镜像的交换机主要包括核心交换机、服务器接入交换机等。）

（天旦BPC在该行的部署示意图）

天旦BPC对主备中心切换过程进行实时监控

2020年6月28日上午9:53分，主中心核心业务切换操作开始，天旦BPC对整个切换过程进行实时监控。9点55分灾备中心开始出现交易数据，从主中心切换至灾备中心大概花费2分钟时间，灾备中心正式开始运行。

（灾备切换过程中的天旦BPC监控视图）

切换过程保障

1、切换过程中的异常发现

切换过程中，BPC发现主中心负载均衡业务分发机制问题，在核心系统停止主中心应用后，主中心负载均衡并没有发生切换，而是根据其配置算法把业务转发至灾备中心，而该行运维技术人员希望此时业务应根据链路变化选择走灾备负载均衡，以缓解主中心负载均衡压力。

（主备中心核心业务服务路径监控图）

通过上图可以看出，在切换过程中的任意1分钟，主中心的核心应用是停止状态，主中心负载均衡把收到的91笔交易转发到了灾备中心的核心应用，加上灾备的负载均衡收到的3笔交易，刚好等于灾备核心应用的94笔交易。而通过BPC的实时监控视图，该行运维人员即时发现问题所在，事后也对负载均衡配置算法进行了优化调整。

2、告警配置

为了保障切换后系统在灾备中心的稳定运行，一方面，运维技术人员对天旦BPC进行场景化告警配置；另一方面，他们通过源IP、目的IP、源端口、目的端口、访问类型、返回码等任何已经解码提取的单一或组合字段信息，又对告警条件进行了精细化配置，双管齐下，以达到更准确更精确告警的目的。

（场景化告警选择界面）

配置完善的告警后，运维技术人员一旦收到告警，通过天旦BPC的交易追踪功能，快速进行异常告警排查；通过自动故障定位功能，BPC的内置算法还会根据相邻两个服务组件的指标变化情况自动化地定位根因业务组件，并对发生故障的业务节点进行自动标识；一键成因分析与追踪功能，5秒定位导致告警发生的维度层次和纬度值，减少人工查询的操作步骤，将分析耗时缩短至原来的8%甚至更低。

（天旦BPC自动定位故障节点并告警）

天旦BPC对灾备回切状态进行实时监控

2020年6月28日下午19:25，该行核心业务在灾备中心实时运行9.5小时后，开始执行回切操作，主中心在19:28分出现交易指标，根据天旦BPC交易追踪记录时间戳计算，大概经过1分50秒主中心正式开始接管运行。

（主中心核心业务BPC应用层监控视图）

天旦BPC对主备中心切换演练进行分析总结

根据天旦BPC交易追踪功能中交易时间戳统计，核心系统从主数据中心到灾备数据中心切换时间约2分种，回切过程约1分50秒，同时在灾备数据中心运行约9.5小时。

（主备中心核心业务APPMall监控视图）

运维技术人员通过天旦BPC应用层快照功能发现核心业务整体平均响应时间为116.6ms，其中交易码耗时相对比较久的交易TOP3分别是6073、4003及0016。

（天旦BPC应用层快照功能）

主备中心切换演练核心交易响应对比如下，主中心整体响应时间比灾备中心略微偏高。

同时，运维技术人员根据灾备核心运行9.5个小时的历史数据进行不同维度的回溯分析，例如按照响应时间对灾备核心交易码进行排名，以便为核心交易响应时间优化提供数据支撑。

（天旦BPC多维统计功能）

更多产品了解

欢迎扫码加入云巴巴企业数字化交流服务群

产品交流、问题咨询、专业测评

都在这里！