@gaoxiaoyunwei2017
2020-07-15T11:24:44.000000Z
字数 6811
阅读 898
彭小阳
作者简介
刘芝,93年加入中国农业银行,多年来主要从事软件项目管理、敏捷、DevOps相关工作,经验丰富,目前担任中国农业银行研发中心项目管理办公室总经理 。
本文主要讲三个方面,第一方面银行业面临的挑战,第二方面DevOps助力数字化转型,第三方面业技融合再创辉煌。
Bank4.0来了,什么是 Bank4.0?有众多业界大咖都阐述过,再次不去说它的定义是什么,实际上银行已经从物理网点为主转为拥抱金融生态圈的开放银行,就个人感受来说,我刚到农行的时候是90年代初期,农行最引人为傲的是什么?网点做多遍布全乡,这极大的优势,如今再看现在的各种新技术新应用,大数据互联网金融数字货币等等,猝不及防,扑面而来。
不知道从什么时候开始我们每天必须要打开微信工作、工作、沟通甚至与孩子相关的学校、老师、作业都不能幸免,进而支付转账微信缴费统统搞定,2018年一季度支付宝和微信已经占据了移动支付92.71%的市场份额,作为一个银行人,我们也偏偏在用,它已经渗透到我们生活当中,离不开了。
可是从银行角度去看的话,细思极恐。用户、数据、市场脱媒,怎么应对?农行提出数字化转型的战略目标,2019年初农行党委确定了数字化转型,再造一个中国农业银行的整体思路就是要依托我行城乡联动,点多面广,客户资源丰富的传统优势。
按照互联网化、数字化、智能化开放化的思路,坚持以客户为中心,以金融科技和业务创新为驱动,推进产品、营销、渠道、运营、风控、决策的全面数字化转型,线上线下一体化深度融合,着力打造客户体验一流的智慧银行,在农普惠领域最佳数字生态银行。
作为科技人如何响应呢?大数据、区块链、5G、云计算、人工智能等这些新技术的应用,推动了金融服务模式的创新,同时也促使银行数字化产品研发流程,追求更快更灵活。
如何做?业界有很多理论体系的支持,敏捷研发、设计思维、数字化产品运营、DevOps,从农行近几年应用的情况来看,我认为 DevOps 覆盖面最广,它提供端到端的解决方案,可落地实操性强,有非常明确具体的要求。
DevOps 能带来什么?这里做了一些列示,一站式研发、自动化执行、自助式服务、过程可追溯、质量有保证。
农行作为大型传统银行,IT系统架构复杂,前端变化快,要能适应市场节奏,后端变化慢要保持稳定与安全,同时作为大型传统银行企业,业务总类繁多,产品结构复杂,传统集中式与新型分布式技术架构并存,瀑布与敏捷开发模式兼顾,如何脚踏实地站在已有基础上走出具备组织级特色 DevOps 建设之路,是我们面临最大的挑战。
DevOps 建设可能并没有现存的经验可供借鉴,只有一点点的摸索和实践初步修正和改建,才能真正使用真正发展阶段组织结构以及信息系统特色的 DevOps 体系。
这是研发体系的示意图,依托 DevOps 建设重塑研发体系,以价值交付为终极目标,以基础架构和应有架构为基石,通过工具、流程、规范三大支柱来支撑我行的精益敏捷研发体系。参考业界先进实践和 DevOps 能力成熟度模型,结合我行应用研发过程的实际情况,我行 DevOps 实施工作从工具、流程、规范三个层面进行持续推进。
首先我们对我行在这三个方面的差距进行了分析,研发工具很多,工具之间无法联动导致流程衔接依赖手工操作,无法保证效率和效果,研发过程中用户需要同时掌握多项工具使用技能,学习使用成本高,研发数据部分数据容于存储,造成数据不一致及资源浪费。
数据存在多个工具,数据试图不统一,工具之间的数据同步依赖人工执行,时间成本高,可靠性差,在工具协作方面开发、测试、运维角色之间缺乏线上沟通工具,沟通成本高,信息获取周期比较长,无法形成一个快速的反馈。
在流程方面,持续交付流水线上,需求、编码、构建单测主要流程无法衔接,环节中的服务无法联动,比如说代码检查是单独的,规范无法内置于流程之中,导致部分组织规范无法充分落实。
在自动化测试方面,测试环境交付周期长,测试用例分散管理,可维护性差,在测试数据管理方面,规范性低,存在手工实例填充。
另外是运营监控方面,监控体系需要规范和完善,监控数据分析能力存在明显的不足,数据价值无法充分挖掘,发布的方式也缺乏差异化,难以支持灰度等模式。
在规范方面的差距,研发质量规范方面,一是未形成完备的研发质量视图指标体系,研发过程无法对研发质量进行准确判断;二是尚无明确的研发改进模型,无法针对已有质量数据进行反馈调整,三是未对研发质量形成统一的数据视图,无法快速直观获取研发质量情况。
在组织规范方面 DevOps 推进需要在组织内进行 DevOps 组织文化建设和推广,加强团队间的协作和融合,逐步建立适应我行研发模式的 DevOps 管理和运行体系,建设 DevOps 能力成熟度模型,加强对于实施效果的评估和度量。
为此我们建设思路就是参考业界先进的实践和 DevOps 成熟度模型,结合我行应用开发过程的实际情况,主要分三个层面,工具层面要打造 DevOps 集成平台,贯穿研发和运营;在流程层面构建持续交付的流水线,推进分层自动化测试,同时完善运营监控;在规范层面建设统一质量并持续进行 DevOps 组织规范建设。
通过平台建设构建研发过程的总体视图,以基础设施以支撑工具为基础,TFS和ITA为纽带,构建团队级和组织级的研发项目视图,我们对于整个工具的建设目标就是以现有工具为基础,以重要工具为中心,集成各环节流程工具,统一助力视图形成研发闭环,自动化全流程,形成满足持续集成、持续交付、运营反馈的工具链。
整合的原则数据整合为主,服务整合为辅。重点实现数据的共享、流动、统一。统一数据视图方面是研发数据统一管理,研发质量整体把控,避免数据重复或分散存储造成的数据不一致及应用不充分,从而形成研发闭环,需求研发运维全生命周期管理加速需求到产品以及产品到需求的方向反馈,同时还要实现自动化的全流程,面向研发过程各个角色实现自动化研发流程,减少人工干预,提高研发效率。
整个工具的整合思路就是通过工具平台间的数据共享调动集成,双向反馈,逐步形成具体领域的中心工具级并实现工具级之间的互联互通,功能联动,在管理上以ITA为中心,组织级流程审批管理和度量数据的一个展现平台,在开发链是TFS为中心形成项目级过程管理、配置管理、测试管理、持续交付的一个平台,在运营链上以星云为中心形成应用部署、监控、分析运维平台。
首先看一下工具集成,将代码检查、单元测试、漏洞扫描、环境管理构建部署等开发相关工具集成到PFS,统一ATP平台做自动化测试和数据管理。生产变更统一到星云,打通管理工具 ITA,研发工具TFS、ATP,运维工具星云,实现后结果就是这样的,开发测试过程都是通过TFS定义流水线来调度TFS CHECK、CHECKMAX,这个是ACMS以及ATP自动测试工具。
星云是技术运营的一站式平台,支持灰度等复杂方式发布,实现发布过程标准化、流程化以及发布环节自动化、可视化,提升发布质量,内建持续高频发布能力,实现应用监控的数据规范,标准统一,指标明确,部署高效,确保问题及时发现、准确定位打造一个标准化、智能化、自动化、可持续化的应用监控体系。
通过研发运营相关工具联通形成完整的一个工具链,建设 DevOps 集成平台,覆盖研发和运营的全周期实现数据贡献统一,团队协同联合。
流程方面构建持续交付流水线,打通研发全流程,实现全程无断点,提高产品的交付效率,推进分层的自动化测试来统一测试用地和测试数据管理,提高自动化测试的覆盖率,保证产品交付质量,完善生产运营环节提供多样化发布方式,降低产品发布风险,提高运营监控和分析能力,通过不同流水线的设计和质量门禁的要求,逐步晋级最后投产。
流水线之间通过质量门禁,包括一些人工的执行进行控制,对于瀑布和敏捷两种不同的开发模式,根据项目特点进行流水线的定制和配置,满足中心双模双架构的研发要求。
在实施 DevOps 之前,项目研发过程中存在一些痛点,首先是需求价值交互的周期较长,传统项目采用瀑布模式,需求从提出到上线严格按需求分析开发测试等阶段划分,所有需求最终一次投产,价值交付时效性差。
其次,代码质量问题反馈滞后。所有研发流程没有引入持续集成的理念,个性分支存在的时间长,积累的个性代码多,在集成阶段才合入主干,出现代码冲突的概率大。在人工干预环节也比较多,代码标记、分支合并、构建部署、品管理等等操作未串联起来,需要专职的管理员手工操作,不仅存在遗漏或误操作的风险,而且关键操作对于配置管理员依赖度过高,成为研发过程中的瓶颈。
缺乏体系化的交付流程,需求分析、功能开发、系统测试、投产上线等过程,也没有通过流水线串联起来,需求、代码、制品、测试报告追溯能力差,缺少可视化的交付流程和度量反馈机制。
为了解决这些痛点我们采取了一些手段来进行落地,第一落地敏捷研发管理的流程,一方面组建特性团队改变业务开发测试各管一段、各自为战的工作方式,重构开发测试的流程,组织和文化,并逐步向业务端拓展,推进技术和业务更深度的连接和整合。
组建以用户为中心的全功能个性团队,实现从业务部门原始需求到技术研发和持续运维的端到端的交付,并通过运营数据反馈到业务部门进行迭代优化,从而形成业务价值生命周期闭环管理,实现业务与技术的深层次融合。
另一方面落实迭代管理,形成了迭代计划会,每日晨会,迭代验收会为主体的迭代管理制度,迭代周期从最初的以投产窗口划分依据两周一迭代,逐步改进为可按需发布一周一迭代的模式。
另外还打造持续交付的工具链,通过充分挖掘现有工具的能力,打造以持续部署流水线为核心的开发测试一体化工具链,将单元测试代码合规检查、安全扫描、自动化接口测试等质量控制过程内化到流水线中自动触发,设置质量门禁尽早反馈质量问题,实现了对代码质量的刚性控制。
在图上也有列示各个流水线,在此也简略介绍一下。
持续集成的流水线是利用组织级工具的拉取请求功能实现各径分支的持续集成,开发人员可直接在需求卡片上创建分支,完成代码与需求自动关联,开发完成后开发人员将本地代码推送到远程,发起到主干分支的拉取请求,此时会自动触发单元测试、合规检查、代码线上评审等步骤,以及设置在主干分支上的一系列校验。
如是否关联了工作项,拉取请求所有校验通过后完成分支合并,自动触发构建形成初级制品上传到制品库。再说明一下开发布局流水线的过程,
初级制品生成后,自动部署开发自测环境和回归测试环境,自动运行全量的回归测试满足质量门禁要求后,初级制品自动晋级为α版本,系统测试部署的流水线,测试人员根据提测情况选择一个α版本部署到手工和自动化测试环境,分别进行手工测试和本迭代功能自动化测试,满足质量门禁要求后自动晋级为β版本。
用户测试的部署流水线,迭代结束的验收会议上会选择β版本部署用户验收环境,自动运行生死案例,并进行验收的测试,满足准入条件之后会晋级为RC版本,在投产前进行上线版本并版RC的版本会晋级为最终的一个定版的投产版本。
这里单独列示测试管理,将测试过程纳入持续交付流水线实现自动化,自动化测试包含单元测试、接口测试、界面测试等层级,依托 DevOps 集成平台需求测试用地、测试计划、缺陷的管理以及关联都在TFS当中实现。
自动化测试用地在 ATP 编写后与 TFS 进行同步,TFS 编排中流水线执行 TFS 要请自动化 ATP 自动实行,实现了测试数据和用地的统一管理,提高自动化测试案例质量和覆盖率,实现了开发和测试的联动,提高了测试自动化水平。在自动化测试方面做了很多重大的改进。
第一,本次参评了5个项目快速完成自动化能力提升,月均案例执行条数从不足1万条快速提升到90万条以上,积累发现缺陷48个,多数是人工测试不易发现的缺陷,比如说个人网银账户别名设置,含特殊字符时,接口返回错误信息,界面设置成功等等这种场景。
第二个重大改进就是推动了我行自动化测试平台ATP的服务,实现了手工测试案例和自动化测试案例在TFS上的统一管理,用户直接操作TFS操作即可实现自动化测试并查看结果。
第三个改进在 CI/CD 流水线上建立以生死核心全量按批次按测试计划调度方式,满足了每日构建测试准入应用发布等等各种场景下的自动化测试需求,使已有的自动化测试的资产到开发部门,并且最大限度发挥了他的价值。
第四项改进实现了自动化测试结果自动的推送,到TFS主要的内容细化到了每条界面案例,每个关键步骤的截图,接口案例每条字段的输出,测试人员建立缺陷时自动关联到执行结果,无需手工描述任何测试过程。
第五设计执行集群加多线并发两级加速体系,优化执行及任务调度策略,解决各种对侧系统不能并发的系统难题,将数千条的自动化测试用地的图形时间,从11个小时优化到3到5分钟。
第六设计公用消耗性数据等数据类别,保证了大病发下数据的独立性,大幅提升案例的成功率。
第七通过建立并查询知识库对接方式实现了测试结果的自动分析,大幅降低了自动化测试的误报率。
第八开发业务规则分析系统,大幅提升测试案例的编写效率,帮助项目快速建立了多路径、全覆盖的测试能力。
通过制品库分区,分布式配置中心灵活编排等等手段保障了部署过程在流水线中的全自动的图形,规范式多项目顺利落地DevOps的一个把控,建立融合协作的组织文化打造DevOps体制规范,助力DevOps落地实践。
DevOps 的规范体系建设最表DevOps分级评级要求,结合研发中心的实际情况对中心DevOps项目实施过程中相关工作流程、产出物、工具、使用进行统一的要求,作为研发中心DevOps项目实施的主要因素我们建立DevOps规范体系共涉及18项,规范体系框架如图所示,后续我们将合并相关的规范,落实在工具中两个方面技术不规范进行改进。
这张图展示是度量规范中的指标设计,完善度量体系和改进模型形成研发质量统一视图,实现持续反馈与改进。
一共是研制了43个DevOps的度量指标,指标覆盖研发过程、客观反应、研发现状,指标划分7个领域,需求、编码、构建、持续集成、测试、缺陷、发布、环境、管理,其中还有6个跨领域的指标,包括需求的吞吐量,完成的计划率,平均需求交付更新开发时间占比,代码、大概率、自动化测试投入分布。
这里是列示了度量驱动改进的例子,下面就是构建时长针对过长的情况,超过了30分钟,我们经过排查并发现数据单元测试的日志过大导致Jenkins单元结果值回长过慢造成的,项目组对于日志输出进行分析之后构建了有了大幅的下降。
右上角是单元测试覆盖率,包括左下角从原来51%迅速提升到91.29%,从68%到80%,还有两个图,一个是显示降低最大复杂度改进,还有合并通过率异常,发现合并通过率只有33%,通过查找原因进行解决,最后合并通过率提升到70%以上.
下面看一下落地DevOps所产生效果,此次通过农行三级评估5个项目,覆盖了Jira技术栈、Request技术栈、云上云下中台前台服务端、移动端,微服务架构的各个方面涉及镜像发票、移动营销、信贷、个人网银、分布式互联等业务领域。
通过对比列示的数据我们可以看到实施的效果,需求的交付周期从原来50多天缩减到8天,单元自动化测试覆盖率以前在组织级是没有统一要求,实施DevOps能够达到80%接口自动化覆盖率达到100%,还有流水线平均时长达到7到10分钟,投产时间由原来的一个月到两个月一次缩短到一周两次。
另外还有按天部署能力在一天内完成变更,这个要求带来的挑战更多是管理制度和流程上的,刚开始接触到这个指标的时候,我们认为这个是不可能完成的任务,最后所有项目都做的。
DevOps不仅仅是流程工具的贯通,也是管理流程的再造。
最后演示是一个事例,客户经理台这个产品也是科技成功引领的成功事例,科技人采用了敏捷的方式将我们想做的产品迅速做出原形,打通了需求与开发的壁垒,借助DevOps打通开发与运维壁垒,形成从需求到开发到投产到运营全领域闭环,充分发挥DevOps平台优势,实现全生命周期一体化全流程的支持。
这里也列出了一些数据, 12条流水线,1094条APP自动化接口测试案例,2万多条单元测试代码,代码覆盖超过80%,每天的15.2次的合并次数。
投产后的效果也很显著,以金融小店为例,客户经理开店32万多个,线上交易突破了200万,线上累计销售额近4800亿,活跃客户同比增长262.5%,基金同步增长168%。
我们总结这个产品做到了6个提升,提升了营销氛围,提升了活跃,提升营销效率,提升管理效率,提升了客户体验,提升营销业绩,从而真正做到了提升产品价值。