干货 | 金融级互联网产品持续交付的挑战与应对

小蚂蚁说：

在金融级互联网产品持续交付方面，蚂蚁金服积累了丰富的经验和最佳工程实践。在2018年ATEC技术探索大会上，蚂蚁金服解决方案架构师吕中邦（凤启）从行业背景出发，分析了金融级互联网产品持续交付的核心挑战，从“更快更早地交付价值”和“守住技术风险底线保障交付质量”两个维度分享了蚂蚁应对这些挑战的最佳工程实践做法，最后还介绍了蚂蚁研发效能平台支撑持续交付的实践经验。跟着小蚂蚁一起来学习吧~

数字化转型的大背景下，企业需要打造多方面的核心能力，这些能力客观上要求企业升级或者采用新一代的技术架构。其中非常重要的一个环节就是基于云端的基础设施、分布式架构下的持续交付。谈到持续交付，很容易想到一些具体的挑战：比如如何缩短新业务产品的研发与投产时间，快速响应细分客户需求；如何应对分布式微服务架构带来的业务场景复杂和高并发挑战；如何通过技术手段推动自动化减少研发过程中的人工投入等等。

此外，我们还需要认真审视所处的行业，到底有怎样的特点。金融互联网产品最核心的两个关键词，第一个就是“金融”。金融属性最重要的是保障资金、安全、高可用，归结成一个字——“稳”；另外一个关键词“互联网”，最显著的特征就是快速交付价值，支持业务的快速创新，我们把这归结成另外一个字——“快”。不仅要快而且要稳，这就是金融互联网行业的基本特质，看似矛盾的两个方面，缺一不可。

谈到“稳”和“快”，蚂蚁金服做得怎么样呢？分享上财年的几个实际数据：线上服务可用率——100%；每天应用发布超过150次；迭代平均研发周期5.8天；测试自动化率超过了80%；运维自动化率超过98%。

基于数字化转型背景和行业的基本特征，我们认为金融互联网产品在持续交付领域最核心的挑战是：如何兼顾快和稳？既能够敏捷快速地交付价值，又可以稳妥创新、守住技术风险底线、持续满足监管合规的要求。

本章节分四个部分展开，首先是精益研发流程定制和多样化分支与发布策略，主要解决我们的体系或流程如何适配不同业务场景，正确的路径和姿势是研发交付提效的基本前提。

其次是职能服务化、高效联调和问题诊断，这两个部分主要是阐述如何通过技术或自动化手段解放人肉、提高效率。

1. 精益研发流程定制

说到流程定制，很多人会问：我们依据什么来定制研发流程？在蚂蚁我们有一个比较有效的做法，那就是依据应用分级。应用分级主要考虑三方面的因素：依赖服务的调用量，日交易资金量，以及每日的PV和UV。根据这三个方面我们定义了从A1-C4十二个不同的应用级别，然后为每个级别的应用设置基线的研发规则，在基线规则之上我们还支持各业务去自定义附加的风险管控措施。

举两个例子，一是按需配置流程。蚂蚁金服的业务非常复杂和多样，有些比较核心的业务系统稳定性要求非常高，相应配套的技术风险防控措施、测试验证环节就会比较完善；反之，一些新业务或内部服务系统会倾向于更快、更早地上线，流程相对来说会更轻量、更敏捷。二是可编排、可扩展的流水线，效能平台的组件中心定义了很多质量检测组件，其中包括第三方或业务自建的组件，通过平台的编排能力为不同的业务编排个性化的流水线模板。有些应用强制做代码评审，有些应用需要通过CI的自动化测试或某专项测试之后才能向下推进，类似的场景都可以通过流水线编排来实现。

2. 多样化分支和发布策略

关于分支模式和发布策略，蚂蚁主要有四种玩法。

首先是日常发布，我们把它比作一辆定期发车的火车，适用于全站的核心业务系统、应用之间关联性比较强的场景。

第二种是独立发布，我们把它比作一辆小汽车，想什么时候发车就什么时候发车，适用于独立业务域、应用间有一定耦合和关联的场景。

第三种是单应用发布，我们把它比作是一辆摩托车，适用于业务独立性更强、与其他业务在架构层面完全解耦的场景。前三种模式通常采用分支开发主干发布的模式。

最后一种紧急发布，我们把它比作救护车，适用于紧急业务需求或线上故障的解决，通常采用分支开发分支发布的模式。

通过这四种模式，蚂蚁所有的业务场景基本得到覆盖，各业务可以根据自己的需要找到匹配的玩法。

3. 职能服务化

介绍完了敏捷交付的姿势和路径，接下来看看自动化提效方面。

通常在一个研发迭代中，会涉及到很多职能部门，传统的做法是各职能团队基于经验复核进行人肉的风险管控。比如，当开发人员完成了编码、自测，就会有安全、风控等职能团队层层把关，基于经验进行审核，“部门墙”会严重影响协作和交付的效率。在蚂蚁，各职能团队的协作方式完全不同，他们不再直接参与到项目迭代中，承担迭代验证和审核这种重复机械的活动，而是转型为能力输出和自动化工具建设，实现职能服务化，从而对业务的开发测试团队进行赋能，这种模式大大提高了研发协作的效率。

4. 高效联调和问题诊断

金融互联网产品的业务场景非常复杂，搭建项目环境是是一个非常耗时耗力的事情。比如一个交易链路涉及20个应用，一般的做法是在研发迭代过程中给每个应用部署一遍，最后形成联调环境。蚂蚁的做法又会不同，首先我们搭建了一个共享的STABLE环境，在研发迭代中只需要针对有变更和修改的应用进行部署，然后通过sofarouter分组能力把所有20个应用关联在一起就形成了联调环境。这样做不仅大大提升了效率，还最大化利用了测试资源。此外，当代码发布上线之后，平台会自动更新STABLE环境保证其为最新代码。

如果在联调过程中发现问题，如何在如此复杂的链路中定位和诊断问题也非常重要。开发同学可通过TraceID或交易号查询链路图、时序图，直观全面地了解应用间的调用交互信息，再结合业务日志就可以非常容易地找到错误应用并定位问题根源。

本章节同样分四个部分来探讨，其中技术风险评估、质量内建、测试验证是按照开发的事前、事中、事后的逻辑来展开，最后向大家分享我们是如何守住安全底线、保障信息安全的。

1. 数据赋能技术风险评估

毫无疑问，开发事前的技术风险评估是非常重要的。蚂蚁的技术风险评估主要基于两大输入来做：第一是需求输入，第二是治理分析相关数据输入和赋能，后者对我们来说更为重要。开发同学可以非常便捷地获取应用依赖、服务调用、消息巡检、组件管控、代码检索等数据，全面准确地评估变更带来的技术风险，基于这些数据和分析，就轻而易举地确定风险应对策略，做到有效的闭环的反馈。

2. 内建质量实时闭环

开发的事中——内建质量与实时闭环反馈，帮助开发人员在第一时间把事情做对。在蚂蚁内部，我们鼓励基于gitflow的最佳实践，通过MergeRequest方式而不是Push方式向项目分支或主干提交代码, 给代码门禁、CI检测一个机会。事实上Pipeline流水线的所有节点和组件都是可编排、可扩展的。在提交代码之后，每执行完一个组件，平台都会实时反馈结果，并自动更新迭代的质量数据，协助开发测试同学管控质量风险。

3. 全环境和业务分层验证

开发的事后，也就是测试验证部分，我们分享两个点：第一是全环境验证，从开发》集成》预发》灰度一步步接近和模拟生产环境，确保生产发布没有问题。第二是业务分层验证，在每个环境，都有对应的测试手段。比如压测，很多公司都在做，但多基于线下环境进行，而蚂蚁会直接在生产环境里做压力测试，真正做到系统的高可用。

4. 信息安全保证

稳妥交付的最后部分，在保障信息安全方面，蚂蚁有一套完整的体系：在需求设计评审阶段，架构师会评估业务风险；在开发阶段，首先SOFA框架自身的安全是有保障的，其次每次代码提交我们都有安全的自动扫描，此外还会有专项的安全测试；最后在系统上线之后，我们有专门针对安全的监控和应急机制。

前面我们不仅介绍了如何敏捷交付，还介绍了如何稳妥创新，接下来分享工具平台层面是如何支撑整个持续交付过程的。

1. 平台简介

蚂蚁研发效能平台所做的事情，主要归结为三个方面：

• DevOps—一站式开发集成持续交付

• DevMind—实时多维的数据分析赋能研发过程

• DevServices—为研发者提供高效技术支持和咨询服务

2. 产品大图

下面是我们的产品大图，顶部是平台支撑的业务和交付的价值，底部DevOps、DevMind、DevServices三方面的主要能力，今天我们重点来介绍一下中间的产品层。

首先是持续交付，从创建迭代开始，到发布上线结束，为整个研发生命周期提供支撑。下面是配套的子产品：研发协作管理项目、迭代和需求；代码服务提供代码托管、代码搜索、CR等能力；IDE是蚂蚁比较有特色的产品，可以帮助开发人员第一时间做代码扫描，还与效能平台的Web端做了整合和集成打通，开发人员不用频繁切换工作台来开展开发工作；测试服务支持测试管理、自动化测试；问题诊断依赖分布式链路和业务日志快速定位和解决问题。最下面是研发洞察，在研发过程中，无论是IDE端还是研发效能平台的Web端，都会沉淀大量数据，这些数据是非常宝贵有价值的资产，我们通过对这些数据进行采集、统计、分析来驱动整个研发体系和组织的持续优化和升级。

3. 一站式持续交付解决方案

一站式持续交付解决方案如图所示。中间部分是研发效能平台，提供了从需求到发布的持续交付引擎，将所有相关的能力和工具串接在一起;底部是应用PAAS平台，效能平台通过openAPI与之交互，打通环境管理和环境部署等功能；右侧是分布式中间件，研发效能平台通过研发容器，统一管理多环境的中间件配置，既实现环境间的隔离，又实现了环境间的自动转换和同步；此外研发效能平台与技术风险防控平台打通，把技术风险防控的措施落实在研发过程中；此外，蚂蚁研发效能平台先天具备开放集成能力，可以通过组件的方式对接企业自有的工具平台，最大化发挥既有资产的价值。

无论对内部还是外部，蚂蚁研发效能平台一直秉承并将继续追求这样一个初心——提升研发者幸福感，提高企业创新效率，让我们一起重新定义研发！