- 快捷搜索
- 全站搜索
清算业务是社会资金流转的桥梁和纽带，是银行业最基础的业务之一，本文根据多年从事支付系统开发和运维的相关工作经验，对支付系统安全生产中的风险点进行了分析，从风险管理、安全事件监控、事件响应等方面展开讨论。
一、安全生产风险管理
风险管理的目的就是避免预期风险，把风险发生的概率减至最低，并提供有效的应急处理方式，把灾难发生后损失的程度降到最低，做到居安思危，思则有备，有备而无患。
1．识别支付系统的运维关键点
结合支付系统的特点，一般来说运维关键点主要有以下三点。在日常维护中，如果生产问题对关键点产生负面影响，则应优先解决该生产问题，以确保目标能够达成。
(1)银行的资金风险。支付系统在对外支付时，都会用到银行内部账户，应避免系统故障造成的银行内部账户对账不符和资金损失。
(2)法律风险和社会舆论风险。客户通过支付系统进行汇款完成资金转账，如果转账失败，则会对客户生活产生重大影响，甚至可能关乎一个企业的生存。银行的客户服务目标应该是：能够让客户快速、安全、准确地完成自己的汇划交易；如果客户汇划因为系统故障导致失败，在操作合规的前提下，应尽量通过技术或者业务操作，完成客户的汇划交易，无需客户进行二次干预；如果客户汇划没有成功，也没有手段能够补救，则应及时通过技术或者人工手段通知客户汇划失败；如果出现系统异常，客户账户资金被扣款，但未及时发送报文，或者来报资金未及时入账的情况时，若短时问内不能排除故障，也可以考虑通过体外调账的处理方式及时入账，避免客户利息损失等。
(3)监管和业务合规性的风险。支付系统对外涉及审计署、人民银行、外管局等合规合法性的监督管理，包括反洗钱、跨境人民币等业务均要合乎法律法规的监管要求。对于监管机构和总行业务部门提出的合规性要求，应给予最高的重视程度，在开发设计运维时，要严格满足监管要求，避免引起法律纠纷和不利的社会舆论，以及资金和形象损失。
2．如何预警风险
(1)通过分析监控报告来预警可能的风险
通过数据中心定期提供的对数据库和交易中间件的监控报告，可以揭示系统运行情况，分析运行缓慢的交易，寻找解决办法。暂时无法解决的问题，需要考虑其是否影响业务开展，是否影响其他交易的执行，是否影响系统的正常运行。
通过数据中心提供的当期主机监控报告与上一期的对比，找到变化的部分，分析资源消耗线性增长的相关模块，通过数据分析找到需要优化的交易、需要调整的数据清理方式、需要调整的TWS批量作业步执行顺序等。
(2)通过数据分析来预警可能的风险
谷歌公司可以根据某个地区使用搜索引擎查询“流感治疗”等若干个关键字的频度信息，建立数学模型，远期准确预测未来可能爆发流感的区域。结合到支付系统运维特点来说，中国银行有意识地收集了相关的生产数据信息，通过以下几个指标的数据分析统计，多次有效地预警运维风险点，并通过调整CICS，MQ等参数和安装应用系统升级包，避免了危及安全生产的事件。
①直入账率：通过统计该数据指标，可以分析出支付类直入账功能是否正常运行，能否满足自动化处理需要。
②收到退汇报文的数据量、收到查询报文的数据量、借记报文成功回执率：通过统计这几个指标，可以发现发起报文是否存在共性的不规范数据，是否大面积影响对手行入账处理。
③每月业务渠道高峰日：通过统计某个渠道的每日交易量，找到业务高峰日，在每月该日重点监控该类业务的成功率，如出现异常情况，可能需要调整该渠道业务的流量控制参数大小，以保障渠道业务顺利开展。
此外，对现有生产数据(客户、账户、交易等信息)进行深入分析和挖掘，并引入数据分析模型，也可以分析更多用户的使用习惯，并远期预测业务量增长率，以帮助对系统特定功能进行优化，应对远期业务需求，并可以支持业务人员进行客户细分和精准营销。
3．预先设定应急预案
凡事预则立，不预则废。支付系统日均交易量为百万级甚至千万级，在实际生产中有可能会出现以下情况：内存耗尽，CICS中间件交易堆积，联机交易缓慢；某类交易量突增，处理时间超时；硬盘损坏交易数据丢失；MQ故障消息丢失等极端问题。
通常支付系统对外与其他交易系统和核心账务系统均有接口，并使用到了CICS、MQ、WAS、DB2、ORACLE等众多系统软件和中间件产品，可能出现问题的风险点较多。针对工作中曾经遇到过的问题，例如外围应用系统故障后支付系统如何应对、系统中间件或硬件故障时系统如何恢复、支付系统故障后对外围可能带来的影响，要编写相应的解决方案，用来指导应急处理。本文用以下的实际问题进行举例说明。
问题场景：在日常维护中，突然出现某功能交易处理缓慢，业务无法正常处理。
绕行方案：面对问题，首先寻找临时性的绕行方案，以保障业务运行的持续性。如小额支付有问题，可以使用大额支付代替；如果回执自动处理有问题，可采用柜台手工回执处理完成交易，如果对外提供的批量文本接口临时故障，可以使用与本系统相连的其他系统联机转账接口等，原则就是将无法正常使用的功能产生的影响降到最低。
问题分析：从后台日志监控找出有问题的应用程序，并抓取涉及此类业务的数据表的数据量变化情况，梳理该类业务流程，对所有SQL语句，尤其是访问大数据表的SQL进行分析，再次梳理是否存在数据表数据量的异常增长，或者是否重新BIND后，造成访问路径变化等可能的问题。
应急方案：需要紧急组织专家组和应急小组成员。如只是某类功能不能正常使用，并未造成大面积交易积压，则无需任何操作；当有大面积交易积压，如CICS的CEMT功能还能使用，则可以建议暂停缓慢交易对应的程序，如CEMT功能已经不能使用，交易积压严重，AOR报错“MAX TASK”，则建议轮流重启有交易积压的AOR，短时间内缓解问题，然后迅速将有问题的程序暂时关闭。
问题解决：抓取出错现场数据库日志和CICS日志，定位问题点后，把修改好的程序或者索引，在支持生产问题解决的模拟环境中进行测试，并及时对外提交版本。如属于某数据表数据量突增导致的问题，也可以通过修改该数据表的清理周期降低该表数据量。
4．建立产品技术应急小组和产品相关联系人机制
为快速处理生产中出现的问题，应在产品项目组中建立有丰富维护经验的产品技术应急小组。维护一份系统相关的业务人员和技术人员的联系人清单，对于紧急状况下快速解决问题将大有帮助。
(1)建立产品技术应急小组。每一个产品项目组为了应对本系统安全生产问题，均应考虑选拔组内的精英成员，组成专门的应急小组分析和解决该类问题。主管部门也应协调相关资源组成专家组，作为应急小组的支撑，负责分析较为复杂的技术和业务问题，同时成立应急领导小组，负责涉及外部门的沟通协调和向上汇报工作。
(2)建立相关联系人名录。支付系统出现了技术性问题，要联系数据中心或者人民银行技术人员加以解决；出现了业务性问题，要根据需要联系总分行业务人员，或人民银行业务人员。将该领域专家的座机，E—mail，手机等信息进行收集和维护，有助于迅速定位问题并解决问题。
5．应急演练
为了应急小组全体成员能够快速应对生产中出现的问题，可以将生产上出现过的实际问题，编排成若干应急案例，对应急小组成员进行单盲演练，考核组内成员如何分析，如何沟通，如何上报，并将演练过程和结果记录成文，组织全员进行学习。通过演练和学习，应急小组全体成员均掌握了紧急情况下的问题分析方法和规章制度流程，并运用到若干次生产紧急情况的处置中，取得了良好的效果。
二、安全生产事件监控
1．业务人员人工监控
开发系统时已经向业务人员提供了相关监控功能，例如：如果当日全辖机构最大汇款限额提升则会实时向主管部门进行短信预警，避免内部安全问题。业务人员可以根据实际生产需要，提交新的监控需求，系统支持动态SQL注入的方式，完成新增的监控内容。
因人民银行系统升级造成支付系统停运再启用后，业务人员需关注跨行支付系统运行情况，第一场清算报文处理情况，避免系统环境异常而造成大面积的业务失败或延迟。
2．数据中心对系统健康度的监控
通过NMON等监控工具，数据中心针对MQ队列深度、网络流量、CICS最大TASK数、内存使用率、CPU使用率等系统重要健康指标进行实时监控，出现异常值时，可在数据中心监控台上进行报警，并短信通知相关技术人员，及时进行人工干预。将DB2、MQ等子系统的运行情况形成报告，定期与产品项目组通过会议进行沟通，及时形成系统健康报告，提供给产品项目组进行分析处理。
3．产品项目组对应用系统健康度监控
人民银行系统升级造成支付系统停运再启用后，或应用系统功能升级后，产品项目组应提供涉及变更功能的监控脚本，扫描数据表或交易日志，抓取交易异常信息，在故障造成更大损失前，提示技术人员进行有效干预。
根据应用版本变更类型，可参照如表1所示的内容进行必要的监控。
ITIL是一套方法论，能为IT服务提供良好的指导思想，将工作中习惯的以技术为
农业银行高度重视信息化建设，近些年特别强化了安全生产工作，加强了IT运维