• 快捷搜索
  • 全站搜索

研发过程防范生产运行风险问题研究

2015-08-26 15:18:40作者:中国农业银行数据中心 宋烜 陈慧卿编辑:金融咨询网 徐仲雅
生产运行稳定是软件研发的必要条件,很多生产运行所暴露的问题,在研发过程中就可加以防范。本文主要讨论在银行系统研发过程中,如何对生产安全事件防患于未然。

银行信息安全指系统的硬件、软件及其数据受到保护,不受偶然或恶意的原因遭到破坏、更改、泄露,系统运行连续正常可靠,信息服务不中断。在银行系统研发过程中,对软件、数据及通信等方面的风险重视往往大于程序投产后的生产运行。生产运行稳定是软件研发的必要条件,很多生产运行所暴露的问题,在研发过程中就可加以防范。本文主要讨论在银行系统研发过程中,如何对生产安全事件防患于未然。

一、商业银行系统研发及生产运行风险

        1.商业银行系统研发规范

        随着互联网金融的深入发展,信息科技在商业银行经营中发挥越来越重要的支撑作用,信息系统安全稳定成为稳健运营的重要前提。近年来,人民银行、银监会等监管机构纷纷出台相关指引文件,对商业银行信息科技管理、信息安全、信息系统开发及测试、信息技术外包等提出更高更全面的监管要求。然而,据互联网报道,不同时期仍有严重的银行信息系统故障发生:2010年2月民生银行出现长达4小时全国业务暂停、2014年7月宁夏银行核心系统数据库故障、2014年8月工商银行第三方存管系统异常等。事后对各类情况分析,很多异常均可在系统研发过程中加以防范。

        目前,五大国有商业银行及部分股份制银行软件研发中心均通过能力成熟度模型集成(CMMI)等级评估。CMMI为软件研发的各种过程提供一个单一的集成化指导框架,它可以实现软件开发过程改善评估。这个过程中,软件开发质量在整个软件生命周期具有非常重要的地位。此外,依据PDCA原则,系统软件质量在业务运行基础上仍需不断改进,商业银行系统研发实际是一个戴明环过程(如图1所示)。 

图片1.jpg

        新系统建设由业务部门提交需求文档开始,经项目立项、需求分析、系统设计等步骤,即投入生产运行。运行过程中,为日益提升客户体验及系统质量,业务及性能改造不断完善,依据PDCA方法,进入系统下一轮研发周期。

         2.商业银行生产运行风险简介

        生产运行风险主要包含环境风险、系统风险、数据风险、操作风险等。从系统生命周期(SLC)观点看,生产运行占据整个系统生命周期的80%。运行过程中,诸多现象具有研发及测试过程中不可预见、难以评估等特点,重大故障不仅影响业务连续性,甚至导致商业银行信誉受损。

        过去10年中,各家商业银行纷纷引入国内外先进服务管理规范,诸如ITIL服务管理、ISO20000流程管理标准、ISO27001安全管理标准等。在运维管理水平不断提升的情况下,生产异常故障仍是不可避免的。某商业银行2014年第三季度生产运行异常情况统计如图2所示。该商业银行大部分生产运行事件发生在批量板块。对银行后台运营而言,需做到风险自主可控以面对每日出现的异常情况。

图片2.jpg

二、商业银行生产运行案例介绍及分析

        案例一:日本证券公司大宗交易部误操作事件。2005年12月,日本某证券公司大宗交易部一名操作员将“以61万日元价格出售1股股票”误操作为“以1日元价格出售61万股股票”。2分钟后,该问题被发现,随即向东京证券交易所主机连续三次发出撤单指令,但均被交易所主机拒绝。证券公司多次努力,仍无法挽回该股票一路暴跌的局面。这一误操作卖单在跌停板57万日元价位全部成交。仅当天回购股票一项,证券公司损失便达到270亿日元。

        案例二:程序变更导致循环取系统日志号。2013年12月,某商业银行核心系统更新一支贷款还款批量程序。夜间系统批量执行至该更新程序时,系统接连发出日志号超阈值的告警通知。3分钟后,大量银行卡交易返回“后台错误”,网银交易无法正常完成。经后续分析,该批量程序在处理每笔业务时循环取日志号导致产生大量虚增情况,当日志号耗尽后,其他交易因无法取值导致交易异常。

        案例三:系统架构升级导致数据库表锁。2014年7月,某商业银行对一前置系统进行基础架构升级。由于该前置系统涉及多家第三方机构,计划对所部署第三方机构分批次迁移,因此该前置系统新旧架构在一段时期内需并行使用。投产完毕后,第二日晚闭式批量运行缓慢,数据库服务器CPU使用率长时间处于高位。分析发现,新旧环境使用同一套数据库,但在两套应用环境的crontab脚本同时对同数据库表进行操作,造成大量数据库表锁。

        除以上案例外,2011年韩国农协银行“系统侵入”、2013年光大证券“乌龙指”等事件,不仅当事机构损失惨重,而且对整个金融领域产生了巨大的负面影响。即使百密一疏,仍有可能造成银行信息系统安全故障。据统计,银行生产运行所产生的异常约有70%均可在信息系统研发过程中加以防范。深究各类异常发生原因,仅仅在流程或技术方面“多走一步”,或许就可避免事故的发生。

三、研发过程中避免生产运行风险的具体方法

        1.创新运维人员全流程参与的研发机制

        CMMI是指导整个软件开发进程的框架,并规范组织体系、架构体系、交付体系等内容。然而很多商业银行研发中心在CMMI框架下制订的流程,往往“重研发、轻运行”,缺少对后期的生产运行风险防范。有必要在系统研发初期,就由运维人员介入,提出符合安全生产标准的系统运维需求,持续推动并全流程参与。具体单向流程如图3所示。

图片3.jpg

        从提交运维需求开始至运维功能测试、验收、投产上线,运维人员全流程参与的项目研发,具备多项优势:一是有效提升运维管理水平,系统投产后,运维工具、运维技能同步跟进,系统移交做到无缝链接;二是强化风险控制能力,运维人员参与研发期间能够修正各类因系统架构、逻辑设计缺陷对运行带来的影响;三是协助人员技能提升,达到优势互补。

         2.构建全局测试过程模型,完善测试机制

        测试是程序的一种执行过程,目的是尽可能发现并改正被测软件的错误,提高软件可靠性。测试阶段主要包括单元测试、集成测试、确认测试、系统测试及验收测试;测试模型主要有V模型、W模型、H模型等。然而目前主流测试机制仍存在多种不足,比如:软件质量基本取决于技术人员个人水平、测试环境与实际生产环境耦合度不高、缺少多样化的测试用例等,导致在上线后仍需付出较大的代价对系统进行维护和优化。

        测试不应成为软件开发的一个独立阶段,而应贯穿于整个软件生命周期中。为进一步完善测试机制、降低生产运行风险,在CMMI测试过程管理中构建全局测试过程模型(GTPM),如图4所示。

图片4.jpg

        在全局测试过程模型中,从系统设计之初,只要有测试需求,就提交至CMMI测试过程管理中。全局测试过程模型弥补了主流测试机制的诸多缺陷:一是丰富测试用例,在GTPM中需求分析、系统设计、编码开发等各阶段文档均是测试对象;二是测试环境多样化,上线运行后的软件仍在测试过程管理中,一旦产生运行风险即刻提交至测试管理模型中;三是各阶段定义的测试过程,均在CMMI过程管理中且涵盖了软件测试过程应遵循的原则。

        3.加快系统监控工具、运维工具建设

        数据大集中为银行金融业务的扩展和创新奠定了基础,但也形成了生产风险的高度集中。很多早期投产的系统,缺乏有效监控和运维手段,导致在系统运行过程中带来诸多风险和不足:一是故障响应时间过长,由于缺少主动报警机制,常由业务部门通知后才启动应急流程,影响处置时间;二是增加人为操作风险,直接登入后台生产系统查询,不仅与生产系统产生资源竞争,更难以避免误操作风险;三是不利于故障情况快速解决,随着商业银行的系统投入越来越多,IT部门运维人员技能难以覆盖全部系统,不能提供界面友好、操作有效的运维工具增加了异常处理的难度。

        国外具有一定规模的金融机构均已具备相对完善的运维管理系统,在实用性方面达到智能化、自动化、可视化、可控化和可量化的水平。在项目研发之初,运维人员就应当根据系统运行特性,提出贴合自身应用、符合业务发展的监控及运维需求,纳入《需求说明书》,并最终与系统同步投产。监控及运维工具的使用将大大简化系统运维操作、缩短应急响应时间,对完善运维管理及系统稳定运行具有重要意义。

        4.强化研发的运维意识

        生产运行稳定是软件研发的必要条件,然而在银行系统研发过程中,对软件、数据及网络等方面的风险重视往往大于程序投产后的生产运行。从研发人员角度出发,主要工作仍是完成业务功能设计,对后续生产运行中出现的问题,诸如:资源冲突、交易处理时长、文件系统增长、数据库清理机制等,缺少提前预判及必要的重视。在研发过程中,非常有必要对生产运行中出现的问题做到未雨绸缪,对项目研发人员的运维意识不断强化。

        第一,“最小授权”原则贯穿业务流设计思路。《商业银行信息科技风险管理指引》中所述:对不同人给予合理匹配的用户授权,做到职责分明,用户管理落实到位,并且建立完善的审批和授权机制,以此避免因用户权限管理不完善导致的系统风险。此外,对于重要数据修改、大额资金使用、系统重要操作等,都应设计为带有复核机制的双人临岗操作。

        第二,增加系统容错设计,达到程序健壮性要求。银行系统对交易连续性有很高的标准,要求研发人员在系统设计时必须周密细致,注意妥善进行系统异常的处理,在系统出现故障时能够自动恢复或忽略故障继续运行。在系统资源高度共享的情况下,很容易出现系统资源、表数据等冲突,应该避免应用程序不稳定而影响整个系统的不稳定。

        第三,完善应用系统应急管理机制。很多银行系统的应急管理方案,仅有应急场景及处置手段两部分,且案例及内容并不丰富。一个完备的应急管理机制,应当包含预防、预备、响应和恢复四大板块。在系统研发过程中,对可能预见的应急事件均应详细记录,对系统各模块间调用关系、数据流走向、上下游系统关系进行梳理,完善应急操作文档。

        除以上方式外,应用数据灾备恢复能力、关键业务数据校验及异常处理等需在研发过程中加强关注,提倡运维人员及研发人员角色互换机制。

四、总结

        根据银监会《中国银行业信息科技“十二五”发展规划监管指导意见》,明确要求商业银行进一步强化运维体系建设,提升系统服务水平,保障信息安全,保障金融服务持续稳定,形成信息科技运维体系的长效管理机制。对银行信息系统安全隐患做到防患未然,研发过程中切实关注生产运行风险是最为关键一环。

        在商业银行生产运行三大案例的介绍中,如果加入双人临岗操作规则、做到对应用程序的全局性测试、多关注一下资源使用及冲突情况等,或许均能避免异常故障的发生。后台系统稳定运行是银行业务正常开展的基础,是事关金融稳定大局的基石。很多时候,仅仅在流程或技术方面“多走一步”,就能有效防范生产安全隐患,对应用系统稳定运行做到未雨绸缪。

(文章来源:《金融电子化》杂志)
 

扫码即可手机
阅读转发此文

本文评论

相关文章