东华业务交易性能检测平台介绍
第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这种做过几百次的操作都会有预案。但预案与真实一般都有相当差距。上面已经提到系统非常复杂，可能出现的问题如果真全部写下来，可能有几百几千分支。而且，系统的故障并不会根据你的应急预案来发生。 人工很难根据系统运行情况分析出相应的应急预案。
为了解决银行面临的以上问题，澳门威斯尼斯人8040app下载股份公司提供的业务交易性能监测平台引入了国际领先的网络数据采集还原技术，集物理主机监测、网络环境监测、应用监测、业务监测、数据库监控、中间件监控、操作系统监测于一体的计算机辅助监测管理系统，实现了对接入系统的实时监测分析与统计，替代银行原有的运维模式，逐步实现了运维风险防控的自动化。
第2章 系统综述
2.1 系统概述
交易性能监测系统基于网络报文俘获还原技术或实时转发技术，实时、非耦合的实现网络数据流的获取，在专用设备完成网络传输包的时间标记等工作，实现业务交易数据业务信息及运维信息的实时监听及数据还原。通过获取到的业务数据及网络传输数据来进行全交易的端到端的可视化、交易故障定位、以及对交易数据的统计分析，对业务交易应用的完全仿真与可视化，可以让运维工作者站在业务运营的角度，提前发现交易或系统瓶颈，定位故障发生根源，指导设备与系统的运维。
2.2 建设目标
（1）改进运维模式 实施业务交易性能监测平台后，将改变系统运维模式： a)从事后查找问题向事前风险控制迁移。 b)从可用性管理向性能管理迁移。 c)从故障被动式处理向主动式监控迁移。
（2）实现运维决策分析 实施业务交易性能监测平台后，对被监测系统进行集中监控管理，实现自动化分析风险。根据监控情况进行分析，生成决策报告。协助运维人员改进或生成应急预案。 （3）信息科技风险动态监管 实现信息科技部对运维风险的动态监管。其中包括物理主机监测、网络环境监测、应用监测、业务监测、数据库监控、中间件监控、操作系统监测等要素。
第3章 系统功能示意图
HAPM是一种高速网络数据专用综合处理平台，整套系统包括应用性能与交易数据分析平台、服务业务管理平台和经营决策数据分析平台，其中应用性能与交易数据分析平台包括三大处理系统(应用还原数据处理系统、应用组件深度探查数据处理系统、性能与交易数据指标存储与分析系统)。各处理模块间采用先进、标准的松耦合架构整合，确保了整套系统具备先进的数据处理能力、可伸缩性和可整合性。
第4章 解决方案比较
4.1 方案比较
目前国内相关产品一般有两种解决方案：监测平台运维和传统运维。
监测平台运维是以网络报文俘获还原技术或实时转发技术为轴心实现的，系统数据实时获取分析统计，提供给运维部门使用。
传统运维一般是在系统发生故障之后后，由使用者向运维人员提供故障现象，运维人员进行故障分析或请相关厂商进行故障分析，对故障处理。
两种方案主要区别如下：
项目 性能监测平台 传统运维
响应时效性 过程导向。能够实时回去业务系统运行的现状，进行健康性评估，系统单笔或连续交互出现异常时，系统可以对运维部门及时进行预警和提示，达到问题早发现、早介入的目的 结果导向。传统运维一般都是业务人员发现系统问题后，科技部门，运维部门再去寻找问题根源。
故障定位准确性 通过对业务交易实时跟踪，能够快速定位故障发生环节，定位高效准确。 业务交易涉及相关业务系统复杂时，需要对层层系统逐步进行分析诊断，故障定位效率低下。
业务系统可视化 对业务系统的运行状态做到全局可视化，能直观掌握所有业务系统的运行状态。 运维人员对于业务系统的运行情况无法确切了解，业务系统对外处于黑盒模式下。
数据多维分析 能够对交易量、交易类型、返回码、响应时间、响应率等进行多层次多维度的分析统计 无法进行多维分析
交易场景重现 对业务交易场景会话数据进行记录，当出现性能问题时进行场景重现，帮助问题分析。 无法场景重现分析
异常交易归档管理 自动保存原始数据，管理员可随时检索并调出所需数据； 人工记录异常交易，无法进行归档管理
应用服务优化 通过对多维分析数据进行分析，找出性能低下的服务，并可以对其进行优化。 系统上线后，当问题比较严重时由业务人员进行反映。开发人员优化周期长。
决策支撑性 精细化运维可以用长期运维数据勾画出系统性能曲线，如服务器响应速度、处理速度变化等，此曲线可以作为技术部门产品硬件升级或扩展的决策依据，利于前瞻化设计。 无
4.2 我们的优势
1、 国际领先的网络数据采集还原技术
a)采用本技术获取被监测业务系统的交易数据，不需要被监测系统提供接口，不需要在被监测系统安装转发代理程序，系统完全在不影响被监测业务系统安全、性能及系统资源的基础上，通过网络数据采集还原等自有核心技术获取交易信息，然后由处理引擎结合预警模型进行处理，实现事中监督目的。
b)公司采用的网络数据采集还原技术在国内外达到领先水平且完全自主可控，为行业内多家合作伙伴公司产品提供底层数据支撑，在银行也有众多使用案例。
c)支持所有常见应用协议与报文格式，如：HTTP、FTP、TELNET、SMTP、POP3、JSON、XML、ISO8583、TUXEDO、ORACLE、MYSQL、MQ、SOAP等。
2、 提升自动化监测能力
业务交易性能监测平台根据不同的监测模型对被监测系统进行自动监控。存在异常情况后，会以异常等级以应用视图、邮件、短信等不同方式进行预警。
3、 监测覆盖范围广、要素全
对数据中心基础环境、服务器、网络、操作系统、数据库、中间件、应用、业务交易等提供全面监测手段。 a)物理主机监测： CPU、内存、进程、文件系统、网络接口、磁盘IO、系统日志、交换空间、进程、硬件错误信息。 b)网络环境监测：网络拓扑自动发现、网路故障监控、网络性能监控、网络状态监控。 c)应用监测：对LDAP、FTP、HTTP、DNS、SMTP等各类应用层服务进行监控。 d)业务监测：以旁路监听获取交易报文并解析进行交易追踪、业务分析、性能监测、服务架构自动学习等业务分析监控。 e)数据库监控：监控Oracle、Sybase、Microsoft SQL Server等运行参数，如共识内存、SQL响应时间、表空间使用率等。 f)中间件监控：监控WebSphere、Weblogic、Tuxedo、MQ等指标，如连接数、服务数、并发数等。 g)操作系统监测：用户、IP、系统版本、工作状态日志、进程、AIX、Solaris、HP/UX、Linux、Windows监控管理
4、 自动分析网络架构、依赖关系
系统具备数据流向自学习功能，自动通过系统数据流向梳理出系统网络架构和系统间的依赖关系。并形成网络架构图和系统依赖图。
5、 业务流程自梳理
系统具备交易路径自学习功能，自动识别交易路径，防控伪造交易提高风险管理水平。并形成业务流程图。
6、 变事后控制为事前预警
性能监测平台对系统通过分析交易流程各环节的处理时间，发现性能低下环节，进行实时预警，及时提醒运维人员。
7、 实时掌握业务交易运营状态
以应用视图为导向，基于服务路径规划功能，实时在应用架构图上展示业务运营状态数据。包括对交易类型、交易量、交易金额、交易渠道、交易机构的动态统计与分析。
8、 快速定位系统异常
从服务路径图查看交付组件状态、再到应用性能指标统计、再到交易追踪/单笔交易追踪，自动锁定异常节点，发出告警信息，并通过应用组件深度探查系统实现交易异常与异常组件之间的关联分析，快速定位底层故障原因。
9、 多维矩阵分析
针对交易要素（交易类型、交易渠道、交易地域、交易量、交易路径、应用节点、性能数据、成功/失败等），围绕金融业务的诸多组件与因素，动态构建多维矩阵与影响因子。多角度、全面、动态分析业务运营与应用性能的关系。
10、 协助运维人员生成应急预案
经过长时间运行后，系统会对异常信息进行数据分析，为运维人员生成分析报告，其中分析报告包含日后可能会出现什么故障及故障点等信息，帮助运维人员及早做好应急方案，甚至提前解决风险隐患。
11、 交易历史数据的再利用展望
历史数据构建成一个交易矩阵，可以将历史数据抽象出生产环境交易基线，用来评估开发/测试环境下的数据与性能一致性问题。或者直接将历史数据打入开发/测试环境，用来验证系统的性能。
12、 其它
运维优势：数据采集设备、数据解析还原、上层应用均可通过系统可视化界面进行配置。 经济优势：无需人工干预，自动监测各系统，节省大量人力成本。 可扩展性：支持集群及负载均衡，处理效率高，支持数据完整采集，支持大业务量应用场景。
