下文为申万宏源资深研发经理王晓飞的演讲全文:
我今天要讲的是业务中台建设相关情况,分为三部分,第一个是背景介绍,第二个是建设情况,第三个是未来的总结展望。
﹀
﹀
﹀
01
#背景介绍
金融行业大家应该都比较了解了。前阵子热播剧《繁花》,中间讲到了上海第一个证券柜台,我们公司当时是公益信托旗下静安的代理的一个网点,这就是我们公司的起源,它比交易所成立时间还要稍微早一些。
现在的申万宏源证券是由最早的申银证券、万国证券以及2015年宏源证券三家合并而成。本身证券行业的系统会比较多,有合并重组这些历史渊源,再加上我们是三家集团合并到一块,那肯定更多。最新的数据应该有四五百套系统,主要分成几大类,第一个是核心业务,有账户清算、核心交易这些系统。然后是客户服务,业务办理、营销相关的,还有些是内部用的信息系统。
证券行业的特点,可能同业比较清楚,包括我了解到的一些银行、保险都有类似的情况,有不少的系统都是采用外购的形式做建设,早些年可能绝大部分都是外购的。相对应就会出现一些问题,比如说传统架构已开户业,只要是对客的渠道,形式是各种各样的。我们公司在建设中台之前就是这种情况,不同的部门、服务的不同的渠道,有不同的技术和不同的业务。有一些是传统的,有一些是新兴的。大家从头到尾自己去建流程,非常纷繁复杂。
这个只是一个典型的业务场景,通过这个场景大家能感知到这里面有一些问题。第一是烟囱式的系统会比较多,同样是开户业务,那么多线、那么多交互,又有那么多的逻辑、工作量和维护的成本。其次系统之间各自为政,是网状交互的。以及对应的自主研发这方面,多种多样的主体,多种多样的技术路线和架构,沉淀复用无从谈起。那相对应的,有这么多的主体,如果想做一些技术路线的自主可控,那它的实质成果也不显著。
基于这个现状,我们就要想办法去改变这些现状,主要的目标是三大方面,第一就是生态构建上面,是以中台化的理念,推动服务多总部、多业务领域中心化的系统建设模式。第二要把研发体系建立起来,研发过程当中所涉及到的开发框架、研发平台、制度规范、最佳实践的东西沉淀下来,不断地去持续复用。再一个就是要建好公司的技术底座,供业务层快速上线。
02
#建设情况
第二部分主要是建设计划。首先外购类的可能很难去突破,只能从自研这一部分去下手。那我们转变一下思路,比如传统烟囱式系统建设的模式,无论是客户服务、业务管理,以往烟囱式的就把它完全打散。然后换成这种模式:底下这些东西都是统一建立规划,无论从管理上、开发上、运维上,底层完全是复用的。在此公共的基础设施平台上面,上层去构建各自业务场景,这些业务场景统一规划、集中管理、高效利用,规则是统一的,同时可以积累沉淀,以及可以横向任意拓展。还是以开户场景举例,按照这种新的模式去建设之后,架构中可以加入业务中台,相对来说它的建设脉络清晰了很多,所有东西都集中在一个重要项目上。同样的这种思路和方式可以在其他业务里面去建设。
比如说产品维度,包括产品业务领域的状态,业务部门也和产品维度相关,属于业务领域里面。还包括前端的对客渠道,横向拉通依靠需求部,此外产品相关的系统里面有关于产品维度上不同的东西。产品方面有事都拉会,一拉几十个人,沟通成本很高。按这种方式做了重构,中间有一个中台,中台上面搞一个产品中心,由一个人来统筹产品中心的建设,把底层的稳态的系统里面关于产品的能力,把它抽象出来,封装成标准接口,提供统一的服务。这个人来负责这整套东西,他既跟业务部门打交道,又跟前端渠道打交道。以后再开会的时候,只需要几个人在一个地方开会。我们用类似的方式把公司里面多个业务领域的东西去做重构,常用的业务场景做整个的聚合。
更进一步的,就形成了公司层面一站式综合服务中台。最前面是一些对客户的场景,包括零售客户、企业客户、金融客户,通过各种各样的终端,APP、 H5、ETM会员机、内部的系统等等,他们都属于平台的用户。用户跟一个业务中台网关对接完了之后,底下这么多的横向拓展的业务领域,全部都可以用了。底下是传统的稳态的系统。通过这种方式至少在自研这个领域,这个方向上面,把核心的关键的业务里面东西做一些聚合。
因为这些东西是统一规划、统一建设。建设的时候就是奔着至少平台级,逐步演进成公司级的基础设施。相对应,我们选中了比较新的这些技术路线。上层的应用系统开发的时候,它所依赖的底层本身就是比较强大的、先进的、稳定的。我们刚开始的时候是基于开源的技术路线,中间还使用了不少国外的技术。最近这几年信创建设如火如荼,我们也是在公司里第一批去做系统改造的。通过两三年的建设,逐步把整个技术路线全部优化。当然我们因为前期传统的集群建设成本蛮高的,我们现在是一个异构多活的一种方式,流量可以按需随机动态分配。
除了在业务领域里面不断沉淀以外,我们的基础设施不断地扩容、更新。中间所用到的,比如开发框架,也在不断地更新迭代,不断地丰富。开发过程当中所用的工具平台也不断地建设,总体形成了一整套体系化的自研的方案。包括运行态、人群、平台、中间件以及运维监控相关的体系,以及开发态、各类开发框架,还有在研发过程当中很重要的、测试环节的重要的工具平台,单元测试、自动化相关技术等等,以及把整个流程全部打通串起来高效流转。
经过几年的持续建设,这个体系我们自认为也算是比较成熟。但是公司里面也许有些声音,老是你们一帮人在自嗨,这肯定不行。去年的时候我们还做了一个事,就是说跟行业相关的一些机构合作,做了一个DevOps认证,一次性通过了三个认证,持续交付的三级,持续测试的三级,这个测试是国内的首家,还有一个是安全及风险管理的二级。刚开始我们还不知道,是后面有相关的老师给我们反馈,说我们好像是这个认证有史以来第一个同时通过三个认证的团队。我们这个项目前后还拿了好几个奖,拿到后面领导说,你们拿奖太多不要再申报了。
03
#总结展望
#过去
我们从这几年的持续建设过程当中,自身觉得蛮有成就感,因为我们切实地为公司做到降本增效,从业务上的集中管理、系统建设过程中的节约成本,以及从价值交付上的提升效率,各方面确实对公司有些帮助。
另外一方面,因为中台好几年前特别火,各种公司、互联网公司、传统公司、金融公司都有建设中台的不同的路径。我们17年在酝酿, 18年立项在做,一点一点从小到大,从一个项目级发展成平台级,从平台级再发展公司级。这个过程也算是稳扎稳打,没出过大的乱子。相比较而言,我觉得这个实施路径现在回头看是比较稳妥的,因为金融行业很难去搞运动式的建设。
#未来
接下来就讲到了未来,就是我们现在以及之后要做的。前面讲到的都是比较好的,现在呢就是要“从无到有,从有到好,边建设边治理”。
确实客观上我们会存在一些问题,前面也讲到了系统特别多,主要是自研和外购两大类。整个中台也仅仅是自研当中比较大的一个板块,站在整个公司的角度上来说,我们仅仅是其中的一个板块而已。整个公司级有这么多的系统、这么多的接口,要去做更高维度治理的时候就会遇到一些问题。简单来说就是几个方面,大概定义了几个词。
第一个是“找到”,因为公司里面有这么多的系统,每个系统都有各自的产品经理负责人,所有的文档都各自维护,没有一个集中的管理平台。你要跟哪个系统对接,你先知道这是什么系统,谁在负责,你去联系他,发微信,他给你发个文档,然后你再去问他地址,都是通过这种方式口口相传。沟通交流的成本特别高,它经常会出现一些,你去对接,到后面发现接口文档是旧的,掉坑里了,就是这种情况。所以我们要建一个公司级的管理平台,大家要把所有的接口一站式录到一个地方,后续不需要人找,大家都在一个平台上面去登记、去查询。同时还有一个很关键的点,金融行业的接口相对来说是比较敏感的。实际上大家也都清楚,现在不少公司里面去写具体写代码的,可能都是找外包的,他们在定一些接口的时候不会想那么多,就是有个需求过来,我能把这活给干了就行了。至于数据敏感性、权限、交互是否合理,他们不考虑这么多。但是一旦要发布到了生产上面去,这个影响是很大的。因此在中间的过程化管理上面,一定要有平台承载它,不然就失控了。所以要建一个接口管理平台,实现一站式的查询或保密。
还有一个是建设公司级的网关。大家也看到了,网状交互是一个很恐怖的事情,你的系统规模体量越大,网状的交互带来的负面的影响就越大。虽然我们建设中台在一定程度上解决了很多的系统网状交互的问题,但站在整个公司的角度上来讲,仍然还存在网状交互的情况。所以我们准备建个公司级的统一网关,我们内部叫企业级组件。当然这个东西也还在建设过程当中。建设完成之后,后续各自系统就不允许直接对外服务了,所有的对外服务一定要挂在这个网关上面,哪怕说只是做一层中转也可以。也就是说所有网状交互、系统之间的直连就要断掉,各个系统跟网关进行一次对接,然后才能跟公司内的系统做交互。
同时要建公司级的监控数据大屏。我们领导经常会提起来,比如说公司里有这么多系统,业务都在正常运作,但是到底有多少系统?日访量大概是多少?每天的业务高峰是啥时候?以及哪些系统提供的接口服务又快又好,哪些系统的接口经常报错?类似这种情况是没有一个统一的平台的,如果有客户办不了的,还要一层层反馈。前阵子还听到有些大客户业务办不下去了,然后找到领导,领导再来处理。如果有一个公司级的统一的平台,流程都报错直接反馈到相应的人,这个事就会有公司的统一的标准解决方案。现在的话是各个项目团队自己建,自己做的统计。
第四点是把所有前面的这些工具、平台、实践,打包形成一套治理体系。比如定义几套公司级的标准,比如稳态类的系统,你上线要经过几套审批流程?经过谁的审批?
我们对于公司级的服务治理所规划的整体的架构图,主要分成几个维度,首先组织协同上面,我们也在公司内部的技术条线上例会上做了多次汇报,就对于这个事基本上各个部门都表态了,都很认可。所以从组织协同上面这个项目就行了,就可以实施了。从项目的具体建设的维度上来讲,我们定义那些业务相关的流程,具体定义成标准的制定阶段,制定完之后就会发布出来。以后各个项目组再去定义接口的时候,就要按照这个接口的标准做设计,不能再有拍脑袋的情况。在开发阶段有统一的查询、管理、审核、快速测试、版本管理、内容通知等等,这些都是在开发过程当中系统对接联调之间常见的痛点需求。在测试阶段,前面也提到我们有接口的自动化测试平台,管理平台的接口数据作为输入,能实现自定义的流转。再一个就是运行态和生产运行维护,通过这种方式切实地把整个接口从最早期的定义、到后面的上线、全生命周期全部连起来。当然还依赖一些协同和工具平台的支持。
最后讲到景,当然这个愿景可能80%以上我们已经做到,就是说要建公司级的大平台,底层的基础设施来不断地建设和完善,后台的稳态的系统仍然按照自己的节奏去更新迭代,中间这一层业务中台跟技术中台不断地更新迭代。现在业务中台上面已经有100多个微服务,有大概六七千个接口,大概有二三十个团队每天常态化地在上面更新迭代。技术中台把下面的研发体系、公共服务、中间件运维相关也都打通了,还在不断地更新巩固过程中。数据方面有专业的大数据团队,提供算力的支持。包括今天所讲到的AI大模型相关的,就是数据团队在做这方面的事情。前台各种各样的终端渠道会不断演进出来。
我的分享就到这里,感谢大家!