东华软件
页面主体部分上边框
  • 网管
主要内容部分容器上边框

            东华业务交易性能检测平台介绍

 

第1章 引言

1.1 风险案件分析

2014年7月1日,宁夏银行核心系统数据库出现故障,导致该行(含异地分支机构)存取款、转账支付、借记卡、网上银行、ATM和POS业务全部中断。 经初步分析,在此次事故中的原因如下:

  1)在季末结算业务量较大的情况下出现。

  2)CPU使用率长期处于70%-80%。 

  3)备份系统异常导致系统读写处理严重延时。

由于以上原因造成生产数据库损坏并宕机。同时宁夏银行应急恢复处置机制严重缺失,导致系统恢复工作进展缓慢,直至7月3日5点40分核心系统才恢复服务,业务系统中断长达37小时40分钟,其间完全依靠手工办理业务。

如果银行建设了业务交易性能监测平台,平台则可以在业务故障大规模发生前提示IT系统存在何种隐患,将隐患解决在萌芽状态,从而避免生产事故的扩大。

平台可从以下几点及时提示银行管理部门有针对性的处理此次事故:

  1)及时提示业务量激增。

  2)CPU使用率超高预警。

  3)数据读写延迟预警。系统进行分析,有可能是数据整体读写延迟,也有可能是某条数据读写延迟。
1.2 国内银行运维风险及解决方案
传统上,银行的风险指信贷风险、市场风险和操作风险,在运维风险管理上较为落后。当前对运维风险的预防主要放在信息科技部,当运维系统发生故障时不能及时准确的找到故障原因,只能根据使用者反应的故障现象或日志进行故障分析,甚至需要厂商进行配合查找故障原因。
现阶段,部分银行还存在以下问题:
 运维风险遭忽视。传统上,银行的对风险防范都集中在信贷风险、市场风险和操作风险上,并且都有对应的风险防范产品进行监督。而对运维风险的防范上没有相应有效的防范产品对各业务系统进行监督。
 银行的系统是由很多不同软硬件厂商的产品拼在一起运作,复杂程度远超过单独系统,因此需要各厂家进行共同维护。在运维过程中系统出现问题,需要各厂商共同查找问题,各厂商之间可能存在推脱,致使问题不能及时发现、及时处理,甚至导致问题放大。
 现代IT系统非常复杂,当系统大到一定的程度,总会有失控的状况。运维人员也无法对系统间的依赖关系、网络架构等问题进行掌握。当运维人员更换时,可能会导致这种问题更严重。
 系统问题不能及时发现。系统运行缓慢、CPU使用率过高无法及时发现,一般由系统使用者报告。
 运维风险的响应不及时。从发现问题上报到IT信息中心(或者在监控系统发现问题),IT中心的人开始查系统,定位故障原因,如果定位不清还要找相关的软硬件人员到场或者远程网络支持(基于安全原因,银行大部分都不能远程网络查看系统,维护人员到数据中心也需要时间,如果还堵车…..),找出问题的根源,一小时算超快的了 。解决问题就更不好说了,其实和大家的电脑一样,往往重启是最有效的方法,但很多业务系统部分出现问题是不能重启的(可能会影响别的业务系统)。
 运维监管手段落后。目前,国内银行对系统运维监督手段尚未完善,基本处于人工定时对系统运行参数进行查看,判断系统健康状态。随着系统不断增多、复杂度增加,如果处于人工监督的状态下,将很难满足银行对运维风险的要求。
 系统应急预案缺乏制度化的整套管理制度。大的变更一定会有预案,甚至换个硬盘,改个IP这种做过几百次的操作都会有预案。但预案与真实一般都有相当差距。上面已经提到系统非常复杂,可能出现的问题如果真全部写下来,可能有几百几千分支。而且,系统的故障并不会根据你的应急预案来发生。 人工很难根据系统运行情况分析出相应的应急预案。
为了解决银行面临的以上问题,上海蕊恺电子有限公司提供的业务交易性能监测平台引入了国际领先的网络数据采集还原技术,集物理主机监测、网络环境监测、应用监测、业务监测、数据库监控、中间件监控、操作系统监测于一体的计算机辅助监测管理系统,实现了对接入系统的实时监测分析与统计,替代银行原有的运维模式,逐步实现了运维风险防控的自动化。
第2章 系统综述
2.1 系统概述
交易性能监测系统基于网络报文俘获还原技术或实时转发技术,实时、非耦合的实现网络数据流的获取,在专用设备完成网络传输包的时间标记等工作,实现业务交易数据业务信息及运维信息的实时监听及数据还原。通过获取到的业务数据及网络传输数据来进行全交易的端到端的可视化、交易故障定位、以及对交易数据的统计分析,对业务交易应用的完全仿真与可视化,可以让运维工作者站在业务运营的角度,提前发现交易或系统瓶颈,定位故障发生根源,指导设备与系统的运维。
2.2 建设目标
(1)改进运维模式      实施业务交易性能监测平台后,将改变系统运维模式:      a)从事后查找问题向事前风险控制迁移。      b)从可用性管理向性能管理迁移。      c)从故障被动式处理向主动式监控迁移。
(2)实现运维决策分析      实施业务交易性能监测平台后,对被监测系统进行集中监控管理,实现自动化分析风险。根据监控情况进行分析,生成决策报告。协助运维人员改进或生成应急预案。     (3)信息科技风险动态监管      实现信息科技部对运维风险的动态监管。其中包括物理主机监测、网络环境监测、应用监测、业务监测、数据库监控、中间件监控、操作系统监测等要素。
第3章  系统功能示意图
 
HAPM是一种高速网络数据专用综合处理平台,整套系统包括应用性能与交易数据分析平台、服务业务管理平台和经营决策数据分析平台,其中应用性能与交易数据分析平台包括三大处理系统(应用还原数据处理系统、应用组件深度探查数据处理系统、性能与交易数据指标存储与分析系统)。各处理模块间采用先进、标准的松耦合架构整合,确保了整套系统具备先进的数据处理能力、可伸缩性和可整合性。
第4章 解决方案比较
4.1 方案比较
目前国内相关产品一般有两种解决方案:监测平台运维和传统运维。
监测平台运维是以网络报文俘获还原技术或实时转发技术为轴心实现的,系统数据实时获取分析统计,提供给运维部门使用。
传统运维一般是在系统发生故障之后后,由使用者向运维人员提供故障现象,运维人员进行故障分析或请相关厂商进行故障分析,对故障处理。
两种方案主要区别如下:
项目 性能监测平台 传统运维
响应时效性 过程导向。能够实时回去业务系统运行的现状,进行健康性评估,系统单笔或连续交互出现异常时,系统可以对运维部门及时进行预警和提示,达到问题早发现、早介入的目的 结果导向。传统运维一般都是业务人员发现系统问题后,科技部门,运维部门再去寻找问题根源。
故障定位准确性 通过对业务交易实时跟踪,能够快速定位故障发生环节,定位高效准确。 业务交易涉及相关业务系统复杂时,需要对层层系统逐步进行分析诊断,故障定位效率低下。
业务系统可视化 对业务系统的运行状态做到全局可视化,能直观掌握所有业务系统的运行状态。 运维人员对于业务系统的运行情况无法确切了解,业务系统对外处于黑盒模式下。
数据多维分析 能够对交易量、交易类型、返回码、响应时间、响应率等进行多层次多维度的分析统计 无法进行多维分析
交易场景重现 对业务交易场景会话数据进行记录,当出现性能问题时进行场景重现,帮助问题分析。 无法场景重现分析
异常交易归档管理 自动保存原始数据,管理员可随时检索并调出所需数据; 人工记录异常交易,无法进行归档管理
应用服务优化 通过对多维分析数据进行分析,找出性能低下的服务,并可以对其进行优化。 系统上线后,当问题比较严重时由业务人员进行反映。开发人员优化周期长。
决策支撑性 精细化运维可以用长期运维数据勾画出系统性能曲线,如服务器响应速度、处理速度变化等,此曲线可以作为技术部门产品硬件升级或扩展的决策依据,利