vivo 互联网研发效能关键技术与实践

作者：

vivo 互联网研发效能团队

Yang Peng、Huang Fengjin

本文为2024年 vivo 开发者大会互联网技术专场分享内容之一，在公众号对话框回复【2024VDC】获取 2024VDC 互联网技术会场议题相关资料。

本文介绍了vivo互联网研发效能平台建设与最佳实践的话题，将分为4个部分与大家分享，分别是研发效能提升的背景与挑战、关键场景技术，以及在项目案例中的实践与效果，最后也将和大家探讨未来在研发效能提升上的一些规划与思考。

一、互联网研发挑战与方案

随着互联网业务的快速发展，业务规模和用户体量在不断扩张，在如此大的规模和体量下，对研发交付效率及质量也提出了新的要求和挑战。

（图中数据统计截止时间为2024.07）

vivo互联网业务广泛，体量巨大。伴随而来的是互联网项目快速增长，最近5年增长超过了5倍。与此同时，项目的服务数量也出现大规模增长，最近6年从原先少于2500，到快速增长超过8000，服务数量增长超过3.7倍；服务器数量也同时期增长了2.8倍，研发交付和稳定性保障的复杂度成几何式增长。可以看到随着项目、服务、机器的大规模增长，研发团队规模也发生了较大的变化，前后增长超过2.7倍。随之而来研发协作难度逐步增加，甚至出现效能下滑的倾向。

（图中数据统计截止时间为2024.07）

随着研发复杂度增加，互联网研发流程也变得规范，与此同时，支撑的工具和平台能力也非常丰富。但是这也带来了交付复杂度的上升，项目成员往往需要在多个平台来回切换，非常麻烦！正如下图所示，从需求洞察到需求运营至少需要经历10个阶段、10多个角色的高效协作才能完成，显然相比以前复杂了许多，也逐步显示了需求交付效率下降的情况。

项目流程和平台复杂度增加的同时，在技术层面，研发基础设施也是几经变迁，线上线下环境的机器复杂度持续增长，变更与维护难度逐年上升，对变更质量的要求越来越高。

从上图可以看出，在2017年以前，研发整体线上交付的机器以物理机为主，所有的线上运维都是交由专门的业务运维及DBA角色来执行，开发人员主要参与编码和测试工作。

但随着研发规模增长，快速交付、低成本的资源也逐步开始引入像OpenStack这样虚拟化技术，此时用户的操作也逐步从原有运维逐步转向类似CICD这样自助化运维交付平台。

并且随着内外销业务的发展，越来越多弹性、快速、低成本的云主机也逐步引入，平台从简单流程逐步发展成体系化、场景化平台，用户的使用成本也逐步攀升。

回顾上面业务规模、研发体量和流程平台的现状，以及基础设施的变迁，vivo互联网业务面临相当大研发效能提升的挑战。

总结来看：

1. 研发规模攀升，研发交付复杂度持续上升。

2. 研发交付横跨多个阶段，在多个平台间操作，成本非常高。

3. 随着基础设施的变迁发展，平台需要不断兼容不同资源、不同云厂商、不同用户场景的诉求，为平台建设和项目实践带来了非常大的挑战。

回溯过去与当前的困境，结合公司文化行为准则，vivo研发效能团队坚持以用户导向深入业务侧，从顶层进行设计与规划，提出"1-2-3"建设框架：通过1个双环模型、2个标准化、3条研发管线助力研发效能持续提升。

**第1层结合"价值探索"与"价值交付" 的持续交付双环模型。**左环确定方向与目标，强调采用"提问"-"锚定"-"共创"-"精炼"的方式来循环验证；右环则偏重过程交付，快速实现左环目标，并保持业务结果与价值达成。

第2层定义了两个标准化：需求标准化、研发标准化。需求标准化更加强调需求从提出到需求实验全链路闭环管理，最终实现需求端到端交付；研发标准化更多强调从分支拉出到交付上线的标准化、自动化过程。

第3层为了重点支撑业务、数据、以及模型和算法需求的研发交付，规划了3条对应的研发管线，将原有烟囱式能力串联成体系化工具链，致力于打造丝滑流畅的开发者体验。

二、互联网研发效能关键场景技术

根据上述研发效能现状来看，我们规划了研发效能的需求标准化、研发标准化。根据2个标准化，我们梳理了3个关键场景：++需求自动化++ 、++标准流水线++ 、++测试自动化++。

**需求标准化：**需求自动化作为标准化实现的关键，它作为需求整个标准化驱动引擎，推动需求状态自动流转。从而实现分支创建和合并、测试环境交付、测试自动化验证等场景串联，达到全链路需求标准化交付目的。例如：需求拆分任务时按照分支策略自动拉分支，需求转测时能够自动合并分支，以及触发流水线执行测试环境发版，及时更新测试环境版本。

**标准流水线：**主要流水线内卡片类型有明确的规范，为了减少流水线配置，推进流水线"一人配置、多人共享"，实现流水线并行执行，不受运行时流水线的限制，使得满足所有目标项目符合持续集成的要求。

**测试自动化：**作为研发效能质量提升的重要措施，在需求状态发生流转时，则自动触发流水线实现测试环境更新，以及触发测试用例的执行，主要包含流程管控自动化和测试实施自动化两个方面。

上面需求自动化是为了解决需求端到端过程中自动化串联，那原先需求自动化是解决什么问题呢？我们接下来看下目前互联网需求流程端到端流程，不同阶段的场景之间自动化率较低，大部分靠手工操作。并且根据该页下半部分来看，支持研发效能实施操作的平台较多，图上所示的基本只是在平台层面有单一支持，并没有实现串联，用户多平台操作成本较高。

根据图上流程显示多平台操作成本高，自动化联动率较低，面对这样的用户痛点问题，我们需要根据上述流程示意图，3个大的阶段7个关键状态和3个核心平台之间动态自动化联动。

首先，在需求阶段，需求从纳入迭代时就根据分支策略自动化拉取分支，完成需求设计进入开发阶段，当需求状态从待开发状态变成已完成开发时，则自动化触发测试环境流水线运行。

其次，触发流水线运行后则首先将分支进行合并，并且将合并后的分支执行代码静态检查和代码评审，通过之后借助全链路能力快速拉取多版本测试环境，与此同时也同步触发测试平台的测试用例执行，涵盖功能、性能等接口测试用例。

再次，完成测试环境搭建以及测试用例的执行，生成对应的测试报告。此时流水线将结合测试结果动态生成上线工单，也同步反馈更新需求状态到待上线状态。

最后，待上线工单完成相关审批，此时将按照预设策略执行线上部署，完成线上交付，则自动反馈需求状态更新已上线状态。到目前为止，我们能够看到整体的状态流转绝大部分以上都自动化完成。

上述我们谈到需求自动化的流转流程，那要实现这样的自动化流程，我们要如何做到呢？如图所示我们能够看到完成整个自动化流转需要4个部分：++事件触发机++ 、++规则匹配引擎++ 、++规则执行器++ 、++日志记录器++。

首先，在触发执行之前，我们需要先配置触发执行规则，例如："当xx发生时，则执行xx事件"等，并且将规则的执行主体、触发时机、执行动作关联。此时，一旦规则的触发时机达到条件时，则产生触发事件，加入事件队列，采用先进先出模式执行。

其次，当事件队列出列某个触发事件之后，则将事件传播到规则匹配引擎，此时通过匹配规则进行模版匹配，一旦匹配通过，则将规则对应的执行主体任务取出，并且触发action动作，例如：传递xx参数并调用指定流水线运行等，最后将执行状态返回，记录到日志。

刚刚我们看到的是需求自动化的上下游触发，要是能够让研发交付效能进一步提升，我们此时就需要关注通过流水线实现标准化交付。从图上我们能够看到要想实现交付成熟度从1.0提升到2.0，需要提升持续交付的规范化，我们知道单纯依靠流程规范来实现流水线按照指定的规范配置和执行，只能通过平台标准化流水线配置与运行，才能以实现交付流程的标准化和一致性。

为了实现标准化流水线，需要3个部分。

首先，需要定制标准流程，约束所有业务研发团队统一标准化流程操作；

其次，要考虑多场景触发，则需要保证流水线可并行运行；

最后，要通过标准检查来保证流水线能够按照设定好的规则配置，从而实现标准化交付。

上述我们也提到要实现标准流水线，需要支持流水线在多场景下并行执行，提升流水线的使用和运行效率。谈到并行执行，我们类比类与实例的关系，目标是一套流水线配置，可以并行根据参数动态运行不同实例。

那我们来一起看看并行流水线如何实现的，考虑到流水线在运行过程中根据具体配置，固化按照预设分支、环境运行。

为此，要想实现并行执行，关键如下：

1. 去除排队限制，让同一条流水线可以支持运行多个实例；

2. 执行过程中隔离资源（机器、环境、任务等），避免环境污染；

3. 动态生成不同执行任务，并自动触发运行；

4. 保证任务运行过程中资源隔离，避免运行环境污染；

5. 之后要注意运行结束后隔离资源回收是否全面。

上述谈到要实现流水线标准化，靠人工检查效率低下，此处基于标准规则和检查机制来保证。为此，我们来了解下我们是如何实现标准化规则检查的，此处核心是将所有配置位运算可解析的格式，通过&和^操作来实现。

正如上图所示，我们将规则检查分为两个关键步骤：

• 通过&识别是否一致，主要通过二进制位检查来识别是否有通过检查；

• 如果不一致，则通过^和&再次识别具体不一致的位置，从实现快速校验和识别，将得到的结果到数据库中比对出不一致的流水线及归属服务。

我们从需求自动化到流水线标准化，主要关注效率维度提升，接下来我们看下在质量维度的提升。在测试域我们关注的测试活动实施，主要分为两块：++流程管控自动化++ 、++测试实施自动化++。

**流程管控自动化，**通过打通了研发域、交付域、测试域，完成测试任务的自动流转，从而实现覆盖了80%项目的测试活动。

对于测试实施自动化而言，测试实施分为客户端和服务端两个维度。

• 对于服务端测试：接口和性能自动化、变更风险可视化是确保服务端高质量测试交付的关键，两者的自动化覆盖度超过70%的核心项目。

• 对于客户端测试：通过统一的插件化方案实现各类自动化能力（稳定性、功能、埋点等），并支持实时监控手工测试过程中相关数据，从而保障客户端测试的整体效果。目前覆盖超过90%的APK应用。

我们提到接口测试自动化，那我们来一起看下如何实现？接口自动化实现总体分为4个大的步骤，分别是：接口管理、用例转化、用例执行、输出报告，其中接口管理考虑场景，又分为接口自动化扫描和流量录制。

接口录制阶段：接口扫描采用agent组件在java工程测试环境启动过程中动态采集工程所有的java访问接口，并且实时将接口数据上报到接口服务平台。

接口管理阶段：除了支持工程扫描，也可以借助自研流量录制平台进行录制，并且将线上录制好的接口链接及参数登记到接口服务平台。

用例执行阶段：通过将接口参数进行解析，动态生成接口测试用例，并针对生成的接口测试用例进行验证是否有效。

报告输出阶段：通过接口测试用例动态生成，我们后续可以将单个测试用例进行批量组合成套件，可以根据代码变更动态识别出需要自动化测试的接口用例，通过手工、流水线、定时进行触发，并且将测试的接口生成测试报告通知给用户，便于用户实时关注测试结果。

我们了解了接口的自动化，通过自动化我们可以有效提升测试的质量。但是我们都知道，接口的稳定性除了功能的完整性测试之外，也需要考虑在目标用户体量下的稳定性和可靠性，我们接下来一起看下关于接口自动化压测的实现，谈到接口性能压测，那必然离不开接口、性能测试用例，以及压测需要的环境。我们从整体来看，压测过程分为两个部分：++线上环境接口录制++ 、++压测环境流量回放++。

1. 线上环境接口录制主要是采用我们公司自研的流量录制回放平台月光宝盒（MoonBox），通过moonbox-sdk将线上流量采集并推送到平台，之后将录制的流量接口数据存放在ES数据库中，待压测平台IPT需要的时候拉取。

2. 用户在IPT压测平台开启压测时，平台根据用户指定的配置动态形成压测策略推送到压测服务，并通过压测服务转化为一组组压测任务下发到压测集群，考虑到压测任务体量不同，压测集群借助容器可以动态伸缩，实现目标体量的完全模拟。通过压测集群批量、动态非线性实时压测，与此同时IPT压测平台会动态从监控平台获取压测环境监测数据，并且将性能压测结果进行整合，最终形成目标压测报告发送给用户。

三、研发效能项目实践与效果

我们介绍了在效能平台建设过程中面临的挑战和关键技术。当然所有能力的建设都会回归到助力业务效能提升上面去，在实际的业务中我们是如何实践这些能力提升研发效能。

在"应用商店"项目中，我们在"需求交付标准化"和"研发过程标准化"的框架下，重点实践了需求分层管理和自动化驱动，标准流水线和自动化测试，有效地解决了在需求管理和研发流程中的效率问题。

vivo应用商店是vivo官方团队倾力打造的应用下载及管理平台，为vivo手机用户提供海量的应用和游戏，是一款工具产品，也是一款商业化产品，既协助开发者获客的同时促进合规，也要在帮助用户获取应用时做好风险管控。对于上线的需求有着严格的评估流程，会经过需求、开发、测试、上线、实验等各个阶段的各类评审与评估。通过对应用商店研发效能成熟度的评估，发现在需求管理、质量保证和持续集成方面还有很大提升的空间，为此我们的实践重点也是从这里展开。

首先，通过需求的分层管理，将需求拆分成可以在线上进行独立商业验证的特性。在评审和设计环节，我们的过程涵盖了产品、需求、策划以及埋点，通过持续的评审来保证正在做正确的事情。

其次，在开发层面，将业务特性分端拆分成不同的用户故事，并进行开发和测试的闭环。整个需求流程的推进，更多的依赖工具来驱动，避免人工导致的错误和流程执行的不到位。

比如说：1）在需求的开始，项目管理工具会自动创建需求群，在策划评审通过后，流程引擎会通知数据产品和设计进行埋点和UI设计，在所有开发准备工作完成后，自动进行分端拆分用户故事，并通知项目管理人员组织进行排期。

2）在开发完成后，项目管理工具会协助开发创建验收单和测试单，并将必要的信息填充在工单中，开发人员所需要做的就是填写少量的信息，并提交执行。

最后 ，所有的项目活动，通过项目管理工具流程引擎来驱动，让开发专注于开发，测试专注于测试，流程的事情交给系统，力求一次性把事情做对。让项目团队持续、高效、高质量的进行价值交付，可以看到应用商店2024年上半年我们将需求研发平均交付时长优化至17天。

除了上面的需求流程自动化，我们在研发过程也进行了很多优化探索。我们在整个研发阶段打通各个系统之间的交互，详细如下：

**需求阶段：**我们在项目管理工具VAPD上对需求进行排期，确定好版本号后，通过"分支管理" 功能配合自定义的分支规范，一键创建并拉取各个服务的代码分支。并将各个服务的分支与流水线、工单、代码评审平台、发布等系统关联，后续所有代码分支相关的活动都可以自动化的处理。

**开发阶段：**我们设计了六条不同规格的流水线，涵盖了我们研发的各个阶段，比如"开发流水线"，会监听所有人的代码提交。在代码发生变动时会自动执行我们的预先定义好的各项任务，包括各类安全检查，静态代码分析及代码规范检查等等，将发现的问题实时通过V消息反馈给开发团队，将尽可能多的检查工作都放在开发阶段，尽早暴露编码过程中引入的各种风险和问题，实现验证左移。

**测试阶段：**当我们的开发结束，并通过 测试平台测试合格，制品晋级成功后，我们开发的产品就可以进行发布上线了，当然这个过程仍然伴随着各种自动化工具的配合，我们的流水线会推进整个发布过程，自动化点检平台会对所有的功能进行回归、点检、验证、灰度，确保发布功能的完善。

**上线阶段：**最后配合埋点、告警、监控、云诊断等手段，将我们的发布过程可视化。

纵观整个过程来看，参与的角色和平台非常的多，平台很多都是独立或者自动化能力不可达，需要人工传递或者手动编辑，我们将各平台能力打通，真正实现状态和数据的自动流转。下方也列出了我们统计到的一系列提效数据，从分支管理到工单自助，从需求建群到任务催办等等，最终我们在2023年实现开发人力节省超过270人天

我们介绍了更多的我们在开发编码阶段所实践的内容，接下来看看在测试阶段，我们做了哪些提升。

**首先，**测试过程中最重要的一环是我们要测试什么内容？如何圈定测试的范围？传统的方式是我们的测试人员根据需求，配合开发人员的意见来分析可能的业务影响范围、编写测试用例，整个过程其实相对主观，靠的是我们常说的经验主义，依赖于测试、开发人员的经验，对业务的理解深度，以及对上下游关联关系的掌握程度。

**其次，**这个能力是因人而异的，过程也是偏主观的，容易造成判断错误或者遗漏。所以我们要做的第一个提升就是通过工具来更客观地分析业务的影响范围，依据的就是代码的差异性分析和上下游调用链图谱，即通过编码前后代码的变化来确定哪些服务、接口受到了影响，同时结合调用链图谱检索可能被这些服务或接口影响到的上下游。这样在一定程度是弥补了不同测试水平人员在主观经验上的差距，以及各个业务上下文带来的影响。

**再次，**通过不同规格的流水线驱动，执行绑定的各类不同任务实现持续测试以及验证左移，这些任务包括了各类自动化的检查与验证，功能的、性能的以及人工介入的。

**最后，**通过我们的测试准出门禁，确保制品的输出质量，并将测试过程中产生的数据资产沉淀到后续的准出报告中。最终，在这些流水线和自动化工具的支撑下，我们整个研发阶段的测试活动渗透率提升了 156%，测试执行效率提升了 35%，版本发布的成功率也提升到了 97.27%。

四、研发效能未来规划

从上述的近几年在研发效能关键场景和项目上落地情况有了一定了解，那未来计划如何继续推进研发效能呢？接下来我们就一起聊聊研发效能未来的规划。

谈到研发效能每个公司都面临不一样的情况，vivo互联网研发效能也经历前前后后4个大的阶段，从早期的开源工具化时代到场景化业务赋能时代。

**工具化时代：**早2018年及以前，vivo互联网还是主要以解决当时研发管理过程中遇到的问题和痛点展开，不断提升研发过程白屏化、自动化，尽可能借助开源和商业化工具JIRA、SVN、Gitlab、Jenkins、SaltStack等来提升研发运维效率。

**平台化时代：**随着平台种类规模增加，用户需要基于自己的诉求去"找"平台和工具，然而平台也面临着"找不到"用户的两难境遇。

**体系化时代：**我们也考虑建立体系化平台，消除用户与平台的"隔离"，让用户能够在平台解决自己的诉求。

**场景化时代：**与大多数公司的发展一致，平台经历多年的发展以后，随着用户体量、业务复杂度增加，平台个性化、定制化诉求逐步导致平台维护和使用成本进一步增加，让平台研发团队维护成本非常高，也让用户的诉求受到了影响。为此，如何从用户场景出发规划和实现成为关键。

谈到这里vivo互联网研发效能的未来到底是什么？vivo互联网研发效能团队结合自身经历来看，还是要回归本源。结合行业的先进理论体系，进一步走进业务研发团队，找到真正的痛点与诉求，帮助业务团队"做正确的事，把事情做正确"。

我们前面聊到对研发效能新的认知和理解，未来我们将进一步走进业务来提效。我们为此也定义三个北极星指标来牵引我们的目标达成，分别为：代码前置变更时间1小时内，需求研发交付时长在2周内，需求实现到结果闭环3周内。

根据研发效能新的理解和目标，我们也多次回滚本源，思考我们的最佳路径，总结来看就5个阶段，分别为：

第1阶段实现工具全面自动化，消除绝大部分黑屏和手工操作。

第2阶段工具实现串联，能够结合项目研发流程初步具备自动化流转。

第3阶段实现研发效能信息全面拉通，平台之间的研效信息能够在多个平台间自由的共享，实现多维度、多角度度量识别效能低洼，并且结合研发流程不断提升项目的研发效能。

第4阶段之后，平台能够基于平台度量的能力逐步识别项目内个性化研发场景的短板，并且结合研发效能实践专家，深入项目内部，真正结合场景自助化、自动化进一步项目研发效能。

第5阶段就不仅仅关注项目本身的研效，而是需要回归需求本身去关注整体价值达成效果。

我们期望通过目标来牵引业务，将OKR、项目、需求等不同层级的要素进行连接。通过可视化看到任务分解、进展、数据效果，以及资源投入和风险，真正意义上做到"一层支撑一层"，层层看得清、管得明。从而实现始终在做正确的事情。除了上面的需求流程自动化，我们在研发过程也进行了很多优化探索。