108天南京银行完成不可能完成的新金融DevOps转型

Posted zhaowei121

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了108天南京银行完成不可能完成的新金融DevOps转型相关的知识,希望对你有一定的参考价值。

在2018云栖大会南京峰会企业研发云专场,由南京银行研发管理负责人吴攀带来了“云效助力新金融DevOps转型——南京银行实践之路”的主题分享。首先对南京银行的研发规模与成长做了介绍,对“鑫云+”的诞生和其架构应用做了详细的讲解。

(云效公有云周年折扣活动进行中红,包年55折优惠中!)

技术分享图片

以下为精彩视频内容整理:

南京银行研发规模概况

 

技术分享图片


简单给大家介绍一下南京银行现在的规模,南京银行的科技现在有运维中心、研发中心和科技管理部,我是在科技管理部负责配置管理和研发过程管理。我们现在正式的员工有200多人,外包合作场商有600多人,在线运营的运营系统有300多个。
有人说银行不就是有柜面、网银、手机银行吗?在这里想和大家解释一下,举个例子。一个贷款的产品,除了要涉及到本身的核心柜面,贷款本身的系统以外,可能还涉及到风控,涉及到大数据,然后总账,还有账户管理,还有监管。那么银行的这种交易的特殊性,导致了每一个产品可能都有很多个系统在背后支撑,也就导致了交易的链路会非常的长。

南京银行研发管理的成长历程

 

技术分享图片


很荣幸在加入南京银行之后正好是金融快速发展的这些年,见证了南京银行科技力量不断增强的一个过程。最开始的时候银行可能只有几个系统结构简单,但还是有很多技术强人,他可能技术能力很全面,他可能一个人就把系统都做好了,把一个系统维护好。那么银行的业务不断扩展,用户可以买理财,买债券,可以融资等,这样就导致了很复杂的系统结构。这个时候如果还像原来作坊式的开发模式就行不通了。举个例子,在刚刚工作的时候有一个项目经理,他是非常负责任的,他每天下班前都会做一个excel表记录团队里每个人今天修改了哪些代码,在哪个模块上做了什么,这样手动去记。在多行研发的时候根本就不可能完成的。到2014年的时候系统已经到200套了,也就大概六七十个人,这个时候仅仅靠人是根本不能完成的。这个时候就决定要引入外部的管理,要有流程,要有质量。2014年的时候获得了CMMI ML3和ISO的体系认证。

传统金融业研发过程管理痛点

在建设这些体系的过程中也是跟传统银行业一样遇到了很多痛点,比如厂商很多,拿过来的原型也很多。原先的这种模式是外购为主,经过适配很快就能把业务连接起来。这样的弊端就是各种各样的技术架构,非常复杂,在这样复杂的系统架构里边去实施一个流水线是一件非常痛苦的事情,同时也带来了银行的业务要求需要迭代非常快。如果这么多的问题,没有一个工具来管理的话,是不能完全应付的。当时我们也做了一些统一的工作,设立了一些系统把需求管起来。架构也要统一起来,即使是一部分的统一也要尽量的保持不要浪费资源。配置管理也用了一些集成的工具,还有测试到部署。但是一个点的快并不是全流程的快,想要快速交付这个价值,需要一个完整的不能中断的流水线才能尽善尽美。这些问题怎么解决呢?接下来进行一个介绍。

“鑫云+”的诞生

2017年1月份这个思想才萌芽,真正开始进厂的时候是2017年的7月,等到上线是2017年11月,先来介绍一下“鑫云+”是一个什么概念呢?南京银行是鑫合俱乐部的一个牵头行,鑫合俱乐部有140家成员行,所有的资金在一个联盟里面。另外的一头连接的是互联网。作为这两头的桥梁,可以连接出很多种可能。

“鑫云+”项目架构变革

“鑫云+”从7月份进厂之后就对厂商原有的产品做了重构,所有的规范全部重来。拆成微服务、换数据库中间所有的这些标准全部按照阿里蚂蚁的要求做修改。在这个基础上提出来DevOps体系。

技术分享图片


云效在DevOps上落地的一些内容,从开发开始→测试→集成→部署,包括环境管理、监控。这一套整个的可视化非常的强,也简单易用的一个流水线。这样的话工作者不需要学很多,尤其是测试人员,只需要三堂课就可以将上万条案例都测试完。

“鑫云+”项目并行开发、多分支管理、持续集成

在云效值得学习的三个地方,第一个就是分支开发的这个模式,在传统端,比如有一个老的开发系统已经开发了很长时间,有一个大的模块可能半年才上。但是同时又有其他小的需求,可能一两周就要上,同时可能也有一些bug要修复,三条线并行。这时候往往出现的一种情况是虽然也分支了,但是并不能管控所有人的提交时间,可能提交的时候会产生冲突,就需要解决冲突,配管员就是解决冲突的。还有一种就是在只有一个主干的时候,上线的时候通通往上交,交到最后发现又要去解决依赖的问题。所以这个时候自动化就根本无法实施,交付的自动化当时对于我们来说是非常难解决的问题但是云上解决了。
云效首先永远有一个保持正确的主干,来了一个需求之后,会有特性分支,并行的特性分支开发完之后。如果这三个需求都要上,那就从主干上打出一个集成分支到认证环节去测。如果发现有问题有一个需求不能上,全部回滚回来把正确的两个打出集成再往下走。所有的这些自动化非常的快,不需要在里边摘代码,不需要查看冲突,都能快速的完成。

“鑫云”项目测试效能提升

 

技术分享图片


在2016年新核心上线的时候上了一个新的系统,核心系统对于一个银行来说相当于信道,它的改动会使其他系统得到改动,当时这个系统的重建也是非常巨大的一个工程。在当时的时候是没有一个这样好的自动化的测试工具,所以当时测试是一个非常耗成本的事情。到了“鑫云+”的时候我们也是核心,我们是全国首家商业银行能够实现分布式核心的银行。 “鑫云+”是一个通道式的平台,其实大部分的时候是没有界面的,靠人工测界面是测不起来的,但是又希望提前去发现这些问题。所以更多的时候测试是要分层次的,更多的是对接口的测试针对服务的测试,把这些都测掉,别切云效能够在它的系统里做自动的留痕。保证再去重新跑一遍的时候只要是修改的测过的都能够正确的上去。

“鑫云+”混合云架构的安全策略管理

在这里要感谢云效,一开始是采用混合云的架构,在公有云上测试,在私有云上面生产。
这样的话,就必须要有一个链路去通到公有云。云效在这里帮助做了一些安全策略,或多个中枢扭转的这种设计,使得我们既能满足监管要求也能够无缝对接迭代快速的开发模式。

 

本文作者:云效鼓励师

本文为云栖社区原创内容,未经允许不得转载。










以上是关于108天南京银行完成不可能完成的新金融DevOps转型的主要内容,如果未能解决你的问题,请参考以下文章

2018金融分布式架构研讨会在京成功召开

会议 | 金融分布式事务数据库项目组第六次会议在京召开

大型国有金融企业研发中心DevOps规划与实践

CCSA TC601金融分布式事务数据库项目组第五次会议在京召开

动态金融分布式事务数据库研讨会在京召开

外包环境下的 DevOps 实践