本文摘录于 《软件研发效能权威指南》 作者：周桂明 腾讯会议高级架构，腾讯云与智慧产业事业群 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 平台，因此组件之间的协调和磨合是不可避免的。比如，在组件的引进中，质量如何度量？有哪些验收标准？需要输出哪些报告？在此过程中，腾讯会议也踩过不少坑，最终总结出一些引用的规范与考量要点。比如：
- 引进的功能是否符合腾讯会议的业务现状？
- 组件性能是否满足或对齐业界的标准？
- 组件容灾情况是否满足要求？
- 使用后，成本是否能接受？
- 引进后，对业务的影响及是否符合预期？
质量保证核心标准
当然，目前腾讯会议只是完成了阶段性目标，我们对研效的追求是无止尽的，研效是随着项目的发展而持续迭代的。
我们针对接下来的研效建设也有一些新的设想，其中有一部分正在建设中，部分还在调研阶段，比如，测试左移、配置管理、秒级发布、变更体检、混沌工程等。随着腾讯会议规模的不断壮大，我们希望能在研效方面做得更好，为业务的快速迭代提供支撑，也为更多需要进行研效提升的团队带来借鉴与参考。
