ArchSummit深圳站7折本周截止,点击立减2640元>> 了解详情
写点什么

支付宝是怎么炼成的?专家手把手为你解答研发效能问题

  • 2020 年 3 月 11 日
  • 本文字数:7388 字

    阅读完需:约 24 分钟

支付宝是怎么炼成的?专家手把手为你解答研发效能问题

今天的整理来自 SOFA-LinkE 研发效能平台的吕中邦,为大家分享蚂蚁金融级研发效能实践解析,以下为演讲整理全文:


大家好,我是来自蚂蚁金服研发效能部的解决方案架构师吕中邦,很高兴今天和大家做交流分享。最近 SOFAStack 在阿里云商业化发布,借着这股东风今天给大家带来研发效能相关的内容,题目叫做《蚂蚁金融级研发效能实践解析》,介绍如何基于 SOFAStack 研发效能平台来开展持续交付和稳妥创新兼顾的持续交付、风险防控及质量保障的最佳实践,来赋能金融产品高可用和研发效能的持续提升。


今天的分享分四个部分,首先我们看看行业的当前背景和主要挑战,然后分享蚂蚁金服在研发效能领域的最佳实践,最后介绍支撑这些最佳实践落地的平台产品,以及我们提供的在研发效能领域的解决方案。


背景与挑战

进入第一部分,简单介绍一下蚂蚁现在的业务现状,首先看到的是大家熟知的业务,比如说花呗,借呗、芝麻分这些东西。下面是支撑这些业务的实践能力,比如说包括风控、反套现、精算这些。看到这个场景,大家很容易就知道蚂蚁是做金融的,不仅是做金融而且是互联网金融。提到互联网金融,具体到研发效能领域,我们把它归结到两个关键词:一方面需要保障资金、安全、高可用,我们把第一个关键词定义成 “稳”,稳妥的稳;另外一个方面互联网是一个 VUCA 的时代,最直接的要求就是速度,快速的交付产品价值,支持业务的快速创新,我们把第二个关键词定义成 “快”,快速的快。不仅要稳,而且要快,看似矛盾的两个方面缺一不可。


基于这样的业务形态,蚂蚁在研发效能领域做的怎么样,几个数据报告给大家。首先,我们有近万名研发工程师,应用系统的规模有数千个,每天提交的代码行有数百万级,每天有 200 多次的应用发布,代码从提交到发布的平均周期 6.2 天,线上服务的可用率达到了 99.99%,所有这一切都是基于 SOFAStack 研发效能平台 LinkE 来来支撑和实现的。



看完蚂蚁,我们再看看整个金融行业,金融行业做研发效能和 DevOps,有哪些共同的挑战?我们总结下来四个方面:



第一,管理者认知方面的挑战。很多中小机构的管理者,对研发效能的认知是严重不足的,不会把这些东西纳入到紧急重要的日程事项中去。所以说就需要在意识上给他们做破冰。


第二,团队协作,典型的重业务、轻 it,业务主导性特别强。需求就一句话,随意变更,这都是常态。然后研发运维各自为政,彼此之间的协作多基于文档,整体沟通和协作的效率是非常低下的。


第三,技术人员的能力参差不齐,导致交付质量千差万别。包括技术栈各种各样、外包难于管理,所有这些东西都影响交付的质量和效率。


第四,就是体系规范和工具方面,整个 IT 的基础管理规范和标准文件都比较老比较重,执行依赖于人肉,落地就比较困难,更不用提数据积累了,整体缺少自动化方面的全局的建设,整个 DevOps 工具链是比较初级的。


那么要解决这些我们刚才提到的内部和外部的挑战和问题,蚂蚁金服也给出了自己的一些解法和答案,赋能伙伴最终实现又快又稳的持续交付。微观上,我们希望我们的方案能够尽量自动化减少人肉,提升研发同学的幸福感,让研发过程丝般顺滑。宏观上可以提升团队的研发,持续交付的效能,进而赋能企业去升级组织效能。其中,最重要的还是把我们蚂蚁金服这么多年在这个领域积累下来的经验和最佳实践,对外提供赋能使其价值。


研发效能实践

接下来我们就分享蚂蚁在研发效能领域里具体的实践,我们将按照软件生命周期的逻辑来进行讲解。


需求项管

经过不断的实践,蚂蚁金服自己也沉淀出了一套敏捷研发实践的框架。第一个就是文化引领,面向一线的研发团队进行敏捷文化的培训,让团队成员能够理解敏捷的基本理念和指导思想。第二个是实践落地方面,是一个逐步演化的过程,团队范畴到项目范畴,以价值交付为最终目标,然后通过不断的迭代,实现持续集成、持续交付。在整个过程里边又不断的去收集数据,做统计分析,建立数据模型,从而形成适合团队及项目的可视化的度量指标,持续的反馈到这个项目的迭代中去, 从而形成统一的节奏、统一的心跳,缩短和消除项目组内不同团队间的等待和浪费。在不断的实践过程中,蚂蚁也沉淀了大量的最佳案例、最佳实践,可以逐步的对外输出,来帮助到伙伴和客户。


刚刚谈的是偏方法论的,具体到敏捷项目管理的实践。首先看看在蚂蚁项目是如何组织的,在我们内部按照项目的规模我们有不同的叫法,比如说战役、战场这些概念,但无论是怎么样的规模,都涉及到三个核心的角色:PD 产品经理、PM 项目经理、技术架构师,我们叫做项目的三驾马车,所有工作都围绕这三个关键角色来展开。在项目的执行过程中,我们引入了 SCRUM 一些管理实践,需求和迭代的进展通过电子看板能够清晰的展示出来,使得敏捷所倡导的原则和理念能够得到比较好的落地。



这里边我们分享三点:


第一,敏捷是贯穿软件研发全生命周期的。敏捷不是说越重越好,适合的才是好的,我们称之为轻量级的敏捷实践。


第二,平台覆盖项目协作的全部领域,项目集、工作项、冲刺、里程碑、风险这些领域都能实现很好的管理。


第三,利用高效灵活的可视化看板,来提高整个项目的透明度,从而激发整个团队及组织的热情和文化。


我们通过平台也固化了一套比较有特色的迭代研发的模型。它通过发布、迭代、应用、流水线四层模型对研发过程进行有效的管控:


流水线维度,我们具备 PUSH、MR、手动等多种触发模式;流水线的所有的组件和节点,可编排、可扩展。然后 应用层面,我们的所有研发活动都是按应用去组织和推进的,包括质量的门禁和阶段的卡点,都是应用维度进行管控。在一个研发迭代中我们可以管理多个应用,一个发布窗口又可以管理和发布多个迭代,从而实现从微观到宏观,多个维度的、立体的项目协作和管控。



持续集成

那么接下来是持续集成环节,首先给大家介绍的是统一的 应用元数据管理。在蚂蚁我们有 5000 多应用,规模非常之大,而且支撑的业务也各不相同。我们给应用做了分级定义,主要是从服务依赖、交易/资金量以及每天的 PV UV 这些维度对应用进行分级,并在平台中进行统一管理。第一个好处,所有的应用以及架构一盘棋,组织层面可看到全貌,为整个架构的规划以及架构的治理,提供比较好的输入以及基础;第二个好处,每个架构域每个应用的技术负责人、质量负责人、运维负责人等角色一清二楚,有利于在项目中进行协作;第三个好处 是应用的属性,通过应用分级和应用属性,为精益研发流程定制提供依据,做到研发流程的千人千面,每个应用都可以定制自己的个性化的研发流程。



除了应用原数据的统一管理,我们还提到 配置统一管理,这里边配置就包括环境的配置、中间件的配置、CI 配置、技术栈软件配置等。蚂蚁研发效能平台可以按照不同的环境,对所有的配置项进行集中管理,在研发迭代推进的过程里边,还可以实现配置项在不同环境间的自动转化和生效,这样就避免了研发同学频繁访问配置项控制台进行人肉配置,提效的同时避免人肉错误。



接下来介绍 代码质量内建,其实代码质量在整个研发过程里边是非常关键的一环,我们鼓励第一时间就把代码写好写正确,或者在第一时间就发现和修复错误。



首先我们看代码的质量标准。事实上在蚂蚁的研发效能平台上边做开发,质量标准是可以按照这种应用维度去做配置的。每个应用都可以根据应用的分级、业务需要去配置不同质量标准。在质量标准里边,我们沉淀的一套成熟的质量分模型,将代码扫描、单元/接口自动化的通过率覆盖率,还有一些其他的质量指标,纳入质量分统一管控,进而可以比较直观地评价一个应用当前的质量情况。


其次是代码扫描,阿里的 Java 开发规约大家都耳熟能详,在这个基础之上,蚂蚁也沉淀了一些自己的开发规约,强强互补,通过 IDE 以及 Pipeline 两个端去执行,确保第一时间能快速的发现问题和解决问题。


然后是代码评审,代码评审是整个开发过程里边非常有价值的工作,他不仅能够帮助我们提高代码质量,而且对整个团队人员的学习培养,团队建设都非常有帮助。在蚂蚁的研发效能平台里边,我们的功能也是非常有特色,实现了与 Pipeline 流水线有效集成的可多人协作的高效代码评审。


接下来是自动化白盒测试。这边指的就是单元自动化和接口自动化。外部客户交流中发现,很多中小企业由于研发或者测试团队的能力限制,不能够高效的去准备自动化测试脚本,所以我们也提供了一个测试脚本的辅助生成工具。测试脚本可以通过效能平台的流水线自动触发执行和收集测试结果。每次执行完流水线之后,都会实时更新应用的质量数据。质量如果不达标的情况下推进迭代,我们还有配套的质量加签的审批流程,上述全是围绕着代码质量所进行的实践。


接下来我们给大家介绍我们的 Pipeline 流水线,以下是平台运营的实际截图。截图上边开发阶段、集成阶段、预发阶段、发布阶段,我们叫它迭代模板,这些迭代模板都是可以按需进行定制的。在蚂蚁我们鼓励基于 GitFlow 的最佳实践,通过 MR 而不是 PUSH 的方式,向项目分支和主干提交代码,这样的话给代码门禁和流水线检测提供一个机会。事实上我们流水线的 Pipeline 的所有节点和组件都是可编排的、可扩展的。可扩展的意思是说,业务可以根据自己的需要,把自己自建的一些测试工具、质量工具,封装成标准组件,接入到整个 Pipeline 流水线中来。这样的话每执行完一个组件平台都会实时的反馈结果,并更新迭代的应用的质量看板,帮助开发测试同学来管理质量风险。



在流水线的执行过程中和研发推进过程里边会产生大量的日志,为了帮助同学们快速的通过日志来定位到问题,节约同学们在定位解决问题上的时间成本,我们针对性的开发了日志诊断服务系统,为用户提供一个统一的日志查看界面,减少不必要的信息的干扰。同时我们通过这些异常问题的知识库,对常见的一些问题提供精准的定位和解决方案的推荐,提高开发同学的研发效率。


当每个流水线组建执行之后,那么应用的质量看板会实时的更新,这里边我们也做了一个截图,比如说质量分, PMD 安全问题,还包括测试的通过率、覆盖率,除此之外,我们还提供一些代码行接口、注释率、重复度等基本的统计信息。每次代码变更,我们都能够看到整个质量分,包括质量数据的更新变化情况,做一个很好的追溯。



此外我们还提供流程审批的能力,在实际的项目研发过程里边,我们鼓励自动化,但很多时候必要的人肉介入又不可避免。比如说技术风险评估、发布、评审这些场景,就需要专家介入去评估一些风险。所以灵活可配置的这种流程审批就非常有用了。



持续部署

接下来我们介绍持续部署,其实部署这边主要分两块,首先是线下环境的自动部署,我们平台通过和 SOFAStack 的运维管理相关模块的无缝集成,提供了自动部署的能力。它也是以流水线组件的方式执行,需要查看详情就直接跳转都能够看到整个部署的日志以及结果。



然后是一键提交生产发布。对于金融机构来讲的话,监管对线上和线下隔离这一块有明确的要求,所以线下我们支持自动部署,线上的话我们提供这种一键提交生产发布的能力,自动推送发布单并同步查询发布单的状态,这样有发布权限的同学就可以登录到生产环境去执行发布了。在这个过程里边,我们通过网络白名单、open API 接口级别的权限控制这些技术手段,来确保线上和线下是真正有效隔离的。



接下来分享一下发布策略,这里边提到一个概念变更三板斧,这个也是我们蚂蚁内部技术风险条例的核心思想,所有的应用研发的底线要求。变更三板斧大概三个方面,一个叫可灰度,要求应用发布过程确保变更的影响程度,影响面是可控的,又可以快速地应急,具体策略包括灰度,分组,Beta,蓝绿这些。第二个叫做可监控。在应用上线之前要进行日志的埋点,监控的配置不仅要有,而且需要确保监控的准确性,直观性,进而保证整个变更的过程都是可监控的。第三个叫可应急,随时暂停回滚,任何变更都有据可查。其实针对变更三板斧,容器应用服务上面有很好的实践,比如说包括分组的灰度发布、无损升级,可适配多种设计工作负载,这些能够很好的贯彻变更三板斧的思想。


测试验证

接下来进入测试验证部分,首先是分层测试的能力,我们主要谈两个方面。首先就是测试环境、环境策略,从开发到集成、预发、灰度,我们的环境一步步的去接近和模拟生产环境,确保生产发布最后是没有问题的。其次就是分层自动化测试验证能力,我们将单元自动化、接口自动化,结合研发效能平台,灵活的通过 Pipeline 流水线的组件去执行,统一赋能给全蚂蚁的研发团队。



针对外部很多机构在自动化测试脚本的编码方面有很大的能力和效率上的痛点,我们提供了测试脚本辅助生成的 ACTS 测试框架。基于数据模型驱动测试引擎执行,适配 TestNG+Spring 的测试上下文环境,以 yaml 为数据载体,实现了这种一站式的编辑、精细化的校验和高效的用例管理,能够有效的提升这种测试脚本的效率。


前面提的,无论是单元自动化还是接口自动化,都是应用及系统级别的测试。那么端到端的话一般都更带有业务属性,全链路的测试。蚂蚁经过这么多年在分布式架构工程测试领域的积累,沉淀了这种根据业务场景自适应加载测试流程,动态编排,精细化校验的金融级的端到端的测试能力,它又轻量又标准,帮助研发测试团队提升业务测试效率和质量保障能力。



产品支撑

在蚂蚁金服开展这么多的研发效能的工程实践,那么我们的平台是如何来支撑的?首先是 SOFAStack-LinkE 的公共云的产品大图,上面是支撑的业务以及交付的价值,我们重点介绍中间产品层,目前我们提供了两个组件,一个是项目协作,主要就是包括需求、项目、冲刺和工作项的管理。然后第二个组件就是持续交付,从编码到测试、到部署、到发布,整个端到端的支撑,下边有配套的代码服务,持续集成、持续部署、测试服务的这些组件。



那么,我们把 SOFA-LinkE 的产品能力做一个总结,大体七个方面:项目协作、代码服务、持续交付、代码分析、测试服务、流程审批、环境管理。


SOFA-LinkE 研发效能平台,主要输出这四块的产品价值:



就平台产品特色而言,主要体现在三个方面:可扩展、可编排、多样化。可扩展 主要指的是 Pipline 流水线的组件是支持自定义的;可编排 体现在研发迭代流程及流水线,可根据业务需要对其进行配置;多样化 支撑多种分支策略,多种技术栈,经典与云原生架构的双模支持。



在多样化的分支发布策略方面,我们内部大概有是这四种玩法,一种叫日常发布,其实就是全站的窗口发布,主要适用于全站的这种核心链路上的业务应用,之间有一定的关联和耦合,每周发布一次。事实上现在我们日常发布已经消除了。第二个叫独立发布,主要场景在独立业务域里应用之间有一定的耦合度,但是更多的是为了管控的需要,把一些应用集中放在一个窗口去发。第三个叫单应用发布,相关应用业务独立性强、架构层面完全解耦,单应用想怎么走就怎么走,想什么时候发就什么时候发。前三种都是我们标准的分支策略叫分支开发主干。第四种是紧急发布,主要是为了响应紧急业务需求或者是修复线上的故障,通常是分支开发分支发布的模式。那么通过这四种模式,蚂蚁所有的业务场景基本上都能满足,你想怎么玩都能够覆盖到。


接下来我们谈到云原生,随着蚂蚁金服对云原生理念的理解越来越深,我们相信未来的金融级应用场景都会往这种极致的弹性和混合云方向去发展。所以我们的架构也一直在不断的演进,去拥抱云原生。向云原生新型技术转变的过程里边,不同场景的应用很难一步到位,所以为了满足这种业务的需要,我们同步的去支持经典的研发模式以及云原生的研发模式。在云原生的改造中,老业务、新老业务并存过渡,通过统一的研发平台,同时支持基于虚拟机和容器的双模持续交付,助力于整个架构的稳妥的演进和迁移。



金融行业本身受到严格的监管,蚂蚁在满足监管以及行业规范的领域里也积累了一套做法,并在我们的研发效能平台上将这些经验进行了沉淀。通过有效的技术手段去满足监管合规的要求,形成了金融级的技术风险的防控手段,把它内化到研发项目平台里面去了,能够帮助咱们企业在数字化转型的背景下边实现这种稳妥的创新。


解决方案

接下来是最后的解决方案部分,做研发效能其实还是要想实现整个 DevOps 跨职能的全流程协同,不同的职能团队能够高效地协同在一起,特别是开发、测试和运维。



介绍一下蚂蚁一站式研发效能解决方案。下图中间部分属于蚂蚁研发效能平台的范围,提供从需求到发布的整个持续交付的引擎,将整个 DevOps 的工程能力集成串接在一起,具体能力前面都有提到。大图 底部是应用 PaaS 平台,就是咱们 SOFAStack 运维管理相关的组件,效能平台通过 open API 和它交互,打通整个环境管理和环境部署这些功能,也实现了经典发布部署和容器应用服务的双模支持。大图 右侧是对蚂蚁智能科技其他产品的集成和支持,通过研发容器统一管理多环境的中间件配置,实现环境的隔离,迭代推进过程中不同环境之间的自动同步和生效。另外我们支持技术风险防控平台以及端到端测试等产品的集成和联动。蚂蚁研发的平台本身具备开放集成能力,所以可以通过自定义组件的方式来对接其他平台的能力以及业务自建的一些资产,比如说质量测试等工具,最终实现一站式的智能研发平台的方案。



那么我们可以提供哪些软性的服务,下图展示了咨询及其具体领域,然后我们可以和客户一起来针对痛点建立研发规范,我们还提供沙盘帮助用户快速的在实际项目里边去演练整套的规范以及平台工具。



最后给大家介绍的是整个 DevOps 转型的一个路径,大概分这几个阶段: 第一个阶段就是咨询诊断阶段,出具 DevOps 的实施方案以及落地规划,包括平台的搭建。第二个阶段就是培训赋能,这里边就包括理念的培训,产品的培训,要建立统一的体系和流程规范。第三个我们提供沙盘演练,让项目组的同学真正的了解敏捷、流水线和自动化,通过在项目里试运行,为企业内部研发效能团队赋能,培养带头人。第四制定落地的目标和规划,配合企业按照业务或者按照产品线去落地实施,通过日常监控以及数据的分析,能够持续的去解决痛点,去推动效能的持续提升。



以上就是我今天分享的全部内容了,希望对大家有所帮助,也希望大家去关注我们已经商业化的 SOFAStack 产品,特别是 LinkE 研发效能相关的组件。


谢谢大家。如果有问题我们可以线下持续去探讨。


本文转载自公众号蚂蚁金服科技(ID:Ant-Techfin)。


原文链接


https://mp.weixin.qq.com/s?__biz=MzI0Nzc3MTQyMw==&mid=2247490762&idx=1&sn=0170b4cd69ba5058faf2284fc1d16944&chksm=e9aba4badedc2dac6f26b3bed7bc746452137ac5779cfb1668829480c6687436e0ef8e19900f&scene=27#wechat_redirect


2020 年 3 月 11 日 10:152191

评论

发布
暂无评论
发现更多内容

CPU 执行程序的秘密,藏在了这 15 张图里

小林coding

操作系统 计算机基础 计算机 编译器、程序语言、CPU 指令

架构师训练营 - 第四周总结

一个节点

极客大学架构师训练营

LeetCode题解:144. 二叉树的前序遍历,使用栈,JavaScript,详细注释

Lee Chen

大前端 LeetCode

区块链思维是赋能未来经济的关键思维

CECBC

区块链 经济 技术创新

配置Ubuntu工作环境

Rayjun

第四周课后练习

大大猫

极客大学架构师训练营

大型网站架构总结

黄立

Week 4 总结

黄立

第四周课后练习

饭桶

区块链数字钱包技术开发,数字货币钱包源码搭建

135深圳3055源中瑞8032

week04_系统架构

……

架构师训练营 -week04-作业

大刘

极客大学架构师训练营

架构师训练营 - 第四周作业

一个节点

极客大学架构师训练营

数字人民币真的来了 六年历程全回顾

CECBC

数字货币 DCEP

MySQL-技术专题-MySQL索引面试题

浩宇天尚

随记-- 一件事要不要做,值不值得做?

wyzwlj

区块链挖矿系统开发,云算力矿机平台

135深圳3055源中瑞8032

架构师训练营第4周作业

悠哉

spring-boot-route(十二)整合redis做为缓存

Java旅途

Java redis Spring Boot

数字货币交易所定制开发,区块链交易系统搭建

135深圳3055源中瑞8032

架构师训练营第 4 周作业

netspecial

极客大学架构师训练营

架构师训练营第 4 周学习总结

netspecial

极客大学架构师训练营

第三周课后练习

大大猫

极客大学架构师训练营

浅析 Java 内存模型 二

朱华

Java JMM

承兑商USDT支付系统平台,区块链支付软件开发

135深圳3055源中瑞8032

架構師訓練營第 1 期 - 第 04 周作業

Panda

架構師訓練營第 1 期

技术创新+产业升级,区块链为白酒行业带来更多机遇

CECBC

区块链技术 防伪溯源

架構師訓練營第 1 期 - 第 04 周總結

Panda

架構師訓練營第 1 期

第四周总结

饭桶

第四周作业

alpha

极客大学架构师训练营

ARTS 打卡 (20.09.21-20.09.27)

小王同学

头号云话题:进击的开源操作系统

头号云话题:进击的开源操作系统

支付宝是怎么炼成的?专家手把手为你解答研发效能问题_架构_吕中邦_InfoQ精选文章