银行支付清算系统维护方式的思考_运维管理

清算业务是银行业最基础的业务之一笔者根据多年从事支付系统开发和运维的相关工作经验，对支付系统安全生产中的风险点进行了分析，从风险管理、安全事件监控、事件响应等方面展开讨论。

三、安全生产事件响应

1．日常生产问题的沟通和汇报

当维护人员遇到生产问题后，首先依据《中国银行软件中心重大生产事件应急处理管理暂行办法》分析认定问题级别，对于不满足该办法认定的生产问题，产品组可根据支付系统问题分级标准作为上述管理办法的有效补充，判断认定问题级别，展开相关应急处置工作。支付系统的问题分级认定标准如表2所示。

商业银行支付清算系统维护方式的思考-表2.jpg

针对不同级别的生产问题，由相应的组织者进行对外沟通和向上汇报，不恰当的对外沟通可能会影响问题解决速度和放大事件本身的负面影响，对于本层级不能把控的问题应及时向上汇报，由更高级别的管理层来进行资源配置和危机处理。

2．问题分析处理

生产中会出现不同类型的问题，可以通过以下步骤进行分析处理。

(1)针对批量中断、交易大面积死锁等影响系统全面服务的突发情况，应首先考虑恢复系统正常运行，不应纠结于一点，因为系统全面瘫痪远比数量可控的异常交易更影响业务开展。

针对系统批量层面出现的批量异常中断，可在断点重新提交，如短时间内无法成功，应考虑跳过该步骤继续进行后续批量步骤的方式解决。

针对系统联机层面的超时死锁等问题，可针对CICS上长挂的交易，分析出可能死锁的交易，采用从后台CEMT P TASK的方式将死锁TASK杀掉，防止产生大面积交易死锁超时，并将问题交易对应的程序属性改为DIS，确保无后续问题交易产生，减少系统压力；如果CICS短时间内无法通过PURGE TASK等方式解决，可与数据中心主机团队协商，在其他AOR可以继续提供服务前提下，采取重启问题AOR的方式解决。

(2)提示数据中心加强监控，事后获取出错现场的CICS、DB2等系统日志，针对系统日志反映的问题，结合支付系统与核心系统的日志表，定位到是哪一个交易、哪一个程序、哪一个SQL，哪一行代码造成问题，后续通过结合代码分析解决问题。针对无法从CICS、DB2等系统日志得出结论的问题，在可能出问题时段，请求系统维护人员现场监控，或者短时间打开平常关闭的日志，通过现场监控的方式抓取出问题场景，供后续分析。

(3)结合代码分析处理。通过版本管理员，从版本管理系统中提出可能涉及问题的代码，并更新到测试环境中，结合从生产中抓取的问题数据场景，重现问题，通过调试工具，找到问题原因。根据问题的轻重缓急，决定形成优化版本或紧急PTF，对外提交版本。

支付系统复杂度较高，应事前分析出系统运维的风险点，在突发事件下首先要确保风险点不爆发；将以前出现过的问题和解决方式编制成应急预案；不断完善日常监控；建立起产品应急小组，并不断训练应急小组的分析、沟通、上报、处理问题的意识和能力。

随着我国经济发展，支付系统更新换代不断提速，应该总结原有支付系统的运维经验、监控方式、解决问题的方式方法，并将之运用到后续新系统的运维工作中。

（文章来源：《中国金融电脑》杂志）

首页上一页 1 2