客户案例
价格
登录
注册
首页文章页

腾讯会议后台研发效能提升之路

avatar周桂明
2022-11-09

本文摘录于 《软件研发效能权威指南》
作者:周桂明
腾讯会议高级架构,腾讯云与智慧产业事业群 DevOps 与研发效能架构师

从字面上看,研发效能追求的是“效率”,但是脱离目标谈效率是没有意义的。从研发的角度看,软件的意义就是为用户和客户交付他们的所需,从而产生价值。因此,研发效能就是更快地为软件的用户或客户交付价值。这里的价值包括几个方面:

  • 有效性:让业务交付的服务和客户的需求及市场更加匹配,即对不对的问题。

  • 质量:提升业务的安全性和可靠性、用户体验等,即好不好的问题。

  • 效率:提升研发运维和变更的效率,即快不快的问题。

2021 年,腾讯 CSIG 技术委员会成立了研发效能提升组,基于腾讯云的技术标准化,以 CODING 为底座,建设了统一的 DevOps 平台,集成从需求、代码、制品到云原生部署研发运维全生命周期的工具能力,基于工作流帮助业务实现研发运维过程的自动化,提升软件研发效率和质量。

下面介绍腾讯会议在研效项目中的实践经验,希望对同样走在研发效能提升道路上的你有所借鉴与帮助。

腾讯会议研效建设前概况

腾讯会议作为行业领先的云视频会议产品,为企业混合式办公、会议室协作,以及各类垂直场景提供高清流畅、便捷易用、安全可靠的连接模式,虽然经常被大家调侃为“只有三个按钮的 APP”,但随时随地的便捷入会体验,极大地提升了协作效率。

腾讯会议于 2019 年底上线,面对疫情期间用户需求的爆发式增长,小步快跑,通过 AppStore 可以看到腾讯会议的迭代频率:在刚上线的 100 天内,快速迭代了 20 多个版本。

腾讯会议发展历程概览
预览

但随着产品的持续发展,腾讯会议在 2020 年下半年已经拥有了云会议、腾讯会议 Rooms、会议室连接器、开放平台等四个产品线,随着团队规模和业务规模的扩大,团队协作的复杂性不断增加,导致研发效率下降。

如图所示,2021 年初研效专项建设前的数据所示,腾讯会议的团队规模与业务规模迅速扩大,但随着业务与协作复杂性的增加,研发效率却出现明显的下降,而导致研发效率下降的主要原因,相信也存在于大多数研发团队中。

研效建设前的腾讯会议
预览

腾讯会议的研发流程主要分为开发、测试、部署、运营四个部分,它们分别存在以下问题。

  • 开发域:技术栈不统一、流程化程度低、公共组件积累少。
  • 测试域:环境单一、自动化程度低、测试工具不完善。
  • 部署域:平台多、入口多、发布慢、回滚慢、没有门禁权限控制。
  • 运营域:组件分散、定位时间长、自动化拨测覆盖低。

生于云、长于云的腾讯会议,从规范和组件的建设开始,开启了研效提升之路。

腾讯会议研效改进历程

从 2020 年下半年开始,腾讯会议启动了基础建设与调研。2021 年,腾讯 CSIG 技术委员会研发效能提升组成立,腾讯会议作为第一批试点业务团队,正式启动了研效专项,目标是通过半年的专项共建提升团队的整体研发效能。

研效建设规划
预览

腾讯会议研发效能体系建设分别从开发域、测试域、部署域、运营域四个方面输出解决方案,对存在的问题逐个击破。

开发

开发域的研效建设主要分为两个方向:标准化建设和工具建设。

腾讯高级管理顾问乔梁说:“一致性是效能提升的必经之路”。没有标准,散乱的微服务就如同一盘散沙,无法形成合力。这也是腾讯会议要从标准化建设入手建设研效体系的原因。

腾讯会议的标准化建设包括语言、框架和流水线。

统一语言和框架

由于历史遗留等原因,腾讯会议存在技术栈不统一、缺乏统一规范的问题。

统一语言和框架可以大大减少开发的差异和学习成本,也有利于团队内部研发进行组间流动和需求支持。站在语言的角度看,没有任何一门语言能一统天下,但站在腾讯会议的角度看,肯定有一门最适合腾讯会议目前现状的语言。

研效建设专项成立后,腾讯会议对比了腾讯内部各业务的使用情况,分析了各门语言和框架在公共组件的适配程度,以及语言和社区的学习成本,最终选择公司内部主流的 Golang+tRPC 作为开发基础。

这时,又面临一个困难:统一语言,存量的业务模块怎么办?

对此,我们采用的策略主要有阻断新增、限时重构,减少支持的力度。最终,腾讯会议采用 Golang+tRPC 的覆盖率已超过 95% ,完美地实现了语言与框架统一的目标。

统一语言与框架
预览

统一流水线

在研效建设前,腾讯会议项目下有一百多种风格的持续集成(CI)流水线。在研发配置流水线时,由于对流水线的设计很大程度上靠“觉悟”,因此统一流水线的建设,其实是统一研发流程的起点,因为这是卡住代码质量的切入口。比如,如果某个第三方组件存在安全风险,则可以通过在流水线上增加 Hook 添加相关的校验规则。

腾讯会议通过标准化接入、统一基线流水线配置模板等方式,让流水线逐渐统一,达到控制提交代码质量、流程和规范的效果。

我们基于研发现状梳理了各个流水线的工作流,如图所示,按研发过程流水线被拆分为 5 条,开发流水线->提测流水线->合流流水线->主干流水线->预发布流水线。

开发流水线:通过提交代码触发,在个人开发环境下完成代码扫描、单元测试以及单组件冒烟自动化。

提测流水线:通过扭转 TAPD 状态触发,在集成测试环境中完成产品 P0 用例自动化回归、开发自测以及测试验证。

合流流水线:通过 MR 触发,在集成测试环境中实现产品 P0 用例的自动化回归、CodeReview、自动打包。

主干流水线:通过定时或提交代码触发,从而实现单组件 P0 用例回归、自动打包。

预发布流水线:通过手动或者打标签触发,完成发布测试区、多产品 P0 用例自动化回归。

流水线工作流
预览

以开发工作流为例,统一流水线改造的内容。

开发工作流
预览
  • 通过流水线模板创建开发流水线,确保执行的内容一致,也可以一个代码库对应一条流水线。
  • 监视分支代码变更,有推送时自动触发。
  • 必要的门禁保障,如单元测试、代码分析等。
  • 环境部署建议通过子流水线来维护。
开发流水线实例
预览

工具建设

在工具建设方面,腾讯会议分别从服务脚手架、性能分析、接口即文档等方面进行了研效建设。

服务脚手架

在进行研效建设前,团队研发人员经常反馈:项目从 0 开始搭建非常复杂,各个项目间的差异非常大,交接、维护成本高等。

在研效建设开展后,我们通过服务脚手架建设解决上述问题。

首先通过 CODING 平台的服务接口功能编写 PB 文件,然后根据基础项目模板一键生成项目代码。新生成的项目能直接部署、运行,并符合开源治理规范,便于进行后续的自动化流程,如代码质量检查、镜像构建等。

服务脚手架实例
预览

性能分析

在性能分析中,腾讯会议的自研工具——火焰图可以与 CODING 应用管理无缝集成,做到一站式闭环。火焰图集成是 Golang 官方的性能调优利器,通过可视化能直观呈现 CPU 和内存等消耗情况,同时支持多维度在线性能分析,10 秒即可完成性能分析,对服务的关键指标和热点消耗做到一目了然。

性能分析-火焰图实例
预览

接口即文档

随着业务规模的迅速扩大,文档问题一直为大家所诟病,特别是在接口对接、联调过程中,“口口相传”成为常态。

研效建设开展后,腾讯会议通过自研接口即文档工具,无缝闭环嵌入 CODING 应用管理。通过规范接口定义和注释说明,使得定义 PB、定义接口自动生成对应的接口文档,从而实现一站式的统一管理,摆脱了“口口相传”的困境,也降低了沟通的信息差与成本。

接口文档前后对比
预览

测试

腾讯会议在测试域的研效建设主要从环境治理、快速更新、接口测试压测 3 方面入手。

环境治理

环境治理分为环境构建和环境编排两部分。

环境构建

在进行研效建设前,腾讯会议环境单一千人一面。

腾讯会议后台日常并行的需求有一百多个,但测试环境只有一套,这显然是不够的,并且环境冲突问题频繁出现,经常阻塞测试进度。如果直接采用横向扩展的方式,把一变成十,则维护十套测试环境的常态化人力投入非常大,也是治标不治本。因为各套环境的一致性无从保证,服务质量更无从说起。

在研效建设开展后,如何 “一键快速构建环境” 变成腾讯会议必须攻克的难题。环境治理就此诞生。

腾会议对测试环境的要求是同需求的生命线持平,由需求而生,也由需求而止。

CODING 平台提供的环境管理能力,支持快速构建一套全新的、独立的 All in one 环境,构建时间一般在分钟级,最长不超过 20 分钟,并且互相隔离,保证互不干扰。另外,新环境的质量也有对应的度量指标,如环境构建完成后,需要跑一遍全量的自动化用例,保证环境交付的质量。

环境构建前后对比
预览

环境编排

环境编排是腾讯会议特有的,也是研效建设中重点克服的难题之一。

由于腾讯会议的服务都是基于镜像的模式,因此一百多个服务就有一百多个镜像,而每个镜像都是单独部署,资源和成本的压力非常大,并且腾讯会议的私有化场景也是刚需。比如,某银行购买了一套腾讯会议产品,需要进行私有化部署,但是能提供的机器可能只有 2 台或 4 台。

如果没有动态编排环境的能力,则会频繁遇到资源严重不足的问题,故环境编排由此诞生。

腾讯会议的环境编排支持根据自身的需求动态编排模板,快速生成一套环境。在环境中,可以把全量的服务合并到一个镜像,也可以自由编排把某些服务合并到一个镜像。多个镜像和服务可以灵活组合编排,并支持自动化构建和部署。

环境编排解决方案
预览

快速更新

在腾讯会议的研效建设中,快速更新的诉求其实来源于开发层面:如果一个小变更的改动需要 5 秒钟,而发布需要 5 分钟,则显然是不能接受的,快速更新就此诞生。

在进行研效建设前,采用的是“编译+打包+冷更新”模式;在进行研效建设后,快速更新采用的是“编译+上传+热更新”模式。简单来说,使用了一键自动化的 RZ 工具。以前更新一次需要 5 分钟,现在只要 30 秒,开发人员的幸福感有了明显的提升。

快速更新解决方案
预览

接口测试与压测

在进行研效建设前,研发人员经常反馈:接口协议多,自测和 Mock 困难,并且测试工具不完善,测试左移也愈发成为讨论的话题之一。

在研效建设展开后,自研的接口测试与压测工具被无缝集成进入 CODING 平台,做到了测试与压测一站式闭环。同时,支持腾讯会议常用的多种传输协议,如 Oidb、tRPC、HTTP 等,支持自动关联服务接口,并自动保存测试用例。

接口测试与压测实例
预览

部署

腾讯会议的部署域研效建设主要从部署优化和部署编排两部分入手。

部署优化

容器化

腾讯会议作为自研业务上云的首批业务,在整体架构上采用了容器化的云原生方案,真正做到弹性伸缩、自动扩容、异地容灾备份、服务化治理。在研效建设的过程中,腾讯会议全面使用腾讯云的云原生组件和能力,比如 TDSQL、对象存储、CDN 加速器、文件存储、日志监控、消息队列等。基于云原生模式,会议的开发、测试、部署、运营等四个域的研发效能全面得到提升,也让腾讯会议在快速成长时得以保持敏捷的迭代节奏。

容器化历程
预览

发布提速

腾讯会议发布提速的诞生来源于一次次对故障的总结。

在研效建设前期,若要在生产环境里进行发布操作,需要十几分钟到一个多小时,回滚亦是如此,这就严重影响了研发效率和质量。

经过层层分析和总结容器发布时间的构成,腾讯会议在研效建设时把优雅终止时长、Pod 销毁时长、Pod 启动时长、就绪检测时长等每一环节进行了逐一击破,如,增加 StopSignal、优化轮询间隔、优化镜像大小等。针对一次发布操作,优化前一般需要 8 分钟,优化后 1.5 钟即可,效率足足提升了 5 倍。

发布提速解决方案
预览

镜像瘦身

镜像瘦身的目的也是提速。带宽不变,体积大小就是关键因素,镜像体积越大,发布时间就会越长。

在研效建设展开后,腾讯会议通过层层抽丝剥茧的努力达到瘦身等目标,如删除日常不需要的包、压缩镜像体积等,把原来近 4 G 的业务镜像缩小到 300M,发布效率有了显著的提升

镜像瘦身前后对比
预览

编排部署

在研效建设前,腾讯会议一次发布部署需要操作七八个平台,平台多且杂,自动化程度低,稍有疏忽可能就变成一次发布故障。

在研效建设展开后,腾讯会议的持续部署(CD)全部都闭环在 CODING 平台。从持续集成(CI )到持续部署(CD )无缝对接,彻底改变了之前“盯点式”的发布困境。CODING 持续部署(CD)除了支持自定义部署编排,还提供变更体检功能,可以及时发现由发布操作引起的故障。

编排部署实例
预览

运营

腾讯会议的运营域研效建设主要体现在可观测性上,如日志、监控、调用链-链路跟踪、自动拨测与压测。

统一日志

在研效建设前,腾讯会议后台使用的日志组件非常多,有 CLS、ULS、鹰眼等,缺乏统一的规范,研发人员根据各自的经验自由发挥,导致的问题非常多。比如,出现问题排查时,发现日志丢失;有的服务一天打 100TB 的日志,造成极大的成本压力;缺乏统一的管理机制,研发人员感知不到问题。

在研效建设展开后,腾讯会议进行了统一日志建设,使用 CODING 平台可观测模块的日志功能,并基于 CLS 平台主动采集,对业务代码做到零侵入;制定相应的度量指标,每天定时统计各个服务前一天的日志量,让每个研发都能掌握服务日志的量化数据,更好地评估日志的有效产出,进行成本优化。

统一运维

作为统一运维的重要环节,不管是发现故障及时预警,还是定位排查问题,监控平台的搭建都是至关重要的。在研效建设前,腾讯会议后台使用的监控组件也非常多,有传统的 Monitor、停止维护的秒监控、007 和云监控等,研发人员根据自己的熟悉程度自由发挥,没有统一的管理入口和继承机制,导致了一系列问题。例如,某个研发人员离职了,服务交接没有把监控的链接告知交接人,就永远找不到该监控;在使用的众多组件中,每新增一个指标都需要在平台上创建指标,缺乏维度功能,而且维度单一,只有单维度的上报,成本非常高。

在研效建设展开后,腾讯会议进行了统一监控建设,同时也对多个监控平台进行调研,最后选择了 CODING 应用管理上的监控功能。基于云监控平台,做到自定义指标、模调等多维上报,对业务细节一目了然;还有很多一站式的平台打通,如自动告警、变更体检等。

统一监控实例
预览

调用链-链路跟踪

在研效建设前,当腾讯会议出现问题时,因为调用链模糊、缺乏统一的平台和工具,问题解决所需要的时间比较长。

在研效建设展开后,腾讯会议进行了统一调用链建设,选择了 CODING 可观测模块的 Tracing 功能:基于云监控平台,对服务间的调用依赖关系和性能关键热点一目了然。腾讯会议整体的接入过程也非常简便,做到了代码低成本、零侵入。

拨测与压测

在研效建设前,研发人员经常反馈:自动化拨测覆盖率低,系统监控弱,故障发现不及时;缺乏系统压测,对当前的状况和瓶颈一无所知。

在研效建设展开后,腾讯会议进行了核心链路的统一梳理,做到分钟级自动化拨测,出现不符合预期的情况,会触发实时电话预警,拨测覆盖率提升至 95%;在系统压测方面积累了大量的测试用例,定期对系统进行压测与状况评估。同时,还在推进混沌工程的评估试点。

自动化测试实例
预览

腾讯会议研效建设总结与思考

研效成果概览
预览

总的来说,通过半年多的研效专项建设,腾讯会议达成了以下成果:

1. 完成了所有模块的一站式管理及语言和框架的统一。 腾讯会议所有的研发活动包括代码、发布、监控、文档等,且都集中在 CODING 平台上,框架和语言选用 Trpc-Go。 2. 标准化研发规范,统一流水线。 腾讯会议将开发流水线分为开发、合流、提测、预发、发布 5 类,让流水线逐渐统一。

3. 完成测试环境的自动化管理。 环境增加到 1940 多套,每个环境构建在 15 分钟以内,环境更新仅需 30 秒,环境管理效果对比。

环境管理效果对比
预览

4. 自动化拨测覆盖率提升到 95%。

5. 腾讯会议积极拥抱云原生,实现了所有模块容器化,并通过发布提速、镜像瘦身等措施,一次发布操作 1.5 分钟即可完成;业务镜像也大大缩小,效率得到提升。

6. 基础组件完成名字服务、配置、监控、日志系统的升级。

经验总结

从在对整个项目进行复盘的过程中,我们得到了以下经验。

流程建设

在流程建设方面,主要有内部推广和外部对接两个方面。

在内部推广时,CSIG 研效与腾讯会议形成接口人机制,并制定标准的对接流程:由架构组负责对外协调,组织内部接口人推广,接口人负责各小组实施落地。在外部对接时,制定了研效流程建设规范,每周组织例会沟通存在问题与研效建设需求落地的进展情况。在风险控制方面,增加了各种机器人和监控,做到实施可观测;在度量方面,有多维度、可视化的度量指标,如发布频率、发布时长、发布前置时间等。

项目过程整体概览
预览

质量保证

由于腾讯会议的研效建设需要引进 DevOps 平台,因此组件之间的协调和磨合是不可避免的。比如,在组件的引进中,质量如何度量?有哪些验收标准?需要输出哪些报告?在此过程中,腾讯会议也踩过不少坑,最终总结出一些引用的规范与考量要点。比如:

  • 引进的功能是否符合腾讯会议的业务现状?
  • 组件性能是否满足或对齐业界的标准?
  • 组件容灾情况是否满足要求?
  • 使用后,成本是否能接受?
  • 引进后,对业务的影响及是否符合预期?
质量保证核心标准
预览

当然,目前腾讯会议只是完成了阶段性目标,我们对研效的追求是无止尽的,研效是随着项目的发展而持续迭代的。

我们针对接下来的研效建设也有一些新的设想,其中有一部分正在建设中,部分还在调研阶段,比如,测试左移、配置管理、秒级发布、变更体检、混沌工程等。随着腾讯会议规模的不断壮大,我们希望能在研效方面做得更好,为业务的快速迭代提供支撑,也为更多需要进行研效提升的团队带来借鉴与参考。

订阅

CODING 官方公众号

随时获取 CODING 最新动态

code

现在开始,

在 CODING 体验高效的研发管理方式

免费使用