规模 300+ 的研发团队，怎样保持工程高质高效？

七牛云从最初发展到现在已经七年了，目前有 300 多名研发同学、六大业务线：云存储、CDN、直播云、容器云、大数据、以及人工智能实验室。而在七牛云优秀的产品研发团队身边，还存在着一个负责质量管理、工程赋能、以及过程改进的重要部门——七牛云工程效率部。

本期由七牛云工程效率部负责人李倩和大家一起探讨工程效率的问题。分享她一路以来的心路历程，以及整个团队从 0 到 1 的演进过程。

01 工程效率部发展历程

我认为组织的变革应该基于对业务和发展更有利的角度进行，并不是非要有测试组、质量保障部、工程部等等。更重要的是在公司现有条件下，你能提供什么能力，以及这样的能力是否能让业务更好地发展。

同时，在创业公司最大的感受就是拥抱变化。在这个过程中，你会发现很多事情并没有为你准备好，你要做的就是去不断适应，不断地寻找最大价值，提升自我。下面我为大家简单介绍一下工程效率部的发展历程：

• 2014 年，工程效率部介入，当时主要负责跟进前、后端测试。这时我们要做的第一步就是搭建完备的测试环境；

• 2015 年 3 月成立测试组，对三大业务线（存储、数据处理、CDN 测试）进行日常质量保障。从一开始我们就倾向于用自动化的方式解决问题，所以招聘的也都是测试开发工程师。也是从这个时候，我们引进了基本的 CI / CD 交付能力；

• 2016 年 2 月成立质量保证部，服务于整个研发，开始写测试服务，并完善 CI / CD 的能力，将 pipeline 自动化。除此之外，我们还同时管理着公司内部平台及工具链，并写了一套质效分析平台；

• 2017 年 2 月成立平台服务组，并研发了效能平台，引入容器，把容器作为效能平台里最基础的技术使用。同时，部门正式改名为工程效率部（V1.0）；

• 2017-2018 年，工程效率部（ V2.0） 内部组织结构优化，以适应七牛业务飞速增长，为技术体系赋能。

02 工程效率部的团队架构

作为一家做基础服务云计算的公司，我们要帮助客户更快、更好的提供技术能力。我们的内部愿景是：缩短优质代码到生产上线 / 客户间的距离。这也是工程上非常重要的一段距离。

我们的体系主要分三大块：质量管理、工程赋能、以及过程改进。虽然这里有虚线、实线组织，但整体来说是有机的整体。我们不但要做质量，更重要的是在有效率的情况下，如何把质量做到最好。

• 质量管理：有专门的 QA 同学深入研发业务，识别质量风险，建立质量反馈闭环。同时围绕目标不断加深自动化程度，适配更多交互场景，大客户。这里主要的人员是测试开发工程师；

• 过程改进：PMO 流程管理，保障我们整个流程尽量简化，并适于公司发展，适当的时候我们会通过它来做最佳实践传播；

• 工程赋能：是 CI/CD 的主线，也是我们的轴心，它让我们做的所有工作都能有很好的平台化追踪。完善优化质效度量体系，让大家更有目标感，知道我们应该从哪些角度去解决问题。

总结成一句话就是：工程效率主要是关注交付链条中研发交付环节的品控，以及效率的整体的交付能力。

03 质量意识的传承与升级

那么如何做到质量意识足、代码敢交付、服务敢升级，主要有三点：

1.工程师对质量有极致的追求。代码和 Bug 都是人写出来的，所以我们会要求工程师对自己的代码负责 —— Eat your own dog food 。

2.内建质量的建立。内建质量决定外建质量，在交付之前的所有过程要尽量提前，并提升内部质量。比如：单测、静态扫描分析、集成测试等等，每一步失败就要去修复。每走一步都要提供验证机制，让代码有办法校验，对整体的质量负责；

3.DevOps 工程文化引入：做一件事情如果超过两遍的，我们就需要去思考这样做是否真的更有效率。所以我总结了一句话：Everything is Code。

04 技术演进

这方面我主要想跟大家讲一下质量小组的基本的技术实践路径，这是每个 QA 同学都要去做的，以及每个开发同学都要理解的。

首先，我想解释一下为什么会有上图这种看似 step by step 的效果。我们的产品很多是从 0 到 1、再到 10，所以一开始我们需要介入很多工作，而不是自始至终做同一件事。每个技术人都要不断进化自己，把自己的工作重心从 A 转到 B，再到 C。

• 第一阶段，提升代码本身的质量、内建质量，我们为开发人员提供反馈，让他知道哪里做得有问题；

• 第二阶段，针对产品业务，输出 API 级测试服务；

• 第三阶段，从代码分析去提高测试的覆盖率，基于测试覆盖率，辅助进行精准化测试；

• 第四阶段，针对服务间的依赖，做 mock 或回调的辅助测试；

• 第五阶段，考虑错误注入，模拟故障情况下的应对表现；

• 第六阶段，推出更多维度的检测手段，不仅是 e2e，还需要有基于业务的调用链衡量，服务自身健康状况等等，评估产品的每一次迭代；

• 第七阶段，将各个阶段的产出、总结、抽象，进行服务化，产品化输出，以服务模式提供质量保证。

05 平台演进

平台演进比较重要，我们需要考虑是否有可能把更多的东西搬上服务。同时，平台化是服务化之后的阶段 —— 如何把服务融入到整个流程中，并且被完整的管理，提供一定的工程能力。我们的目标就是量化产品的质量和效率，提供质效分析能力，识别薄弱环节。

上图是以服务级别或模块级别列出来的主要功能：包括单测覆盖数据、静态扫描和代码检查、集成测试覆盖、缺陷和事故分析、发布跟踪、服务探测，竞品性能 benchmark 检测和工具箱。

这是我们质效平台的后台，这是其中的几个指标，里面有冠、亚军之分，是一种激励和评比。我认为，没有对比就没有伤害，没有对比也就没有进步。我们会把一些关键指标量化，也会相应推出奖励措施。但并不是奖励冠军，我们会按照各团队的成长速度进行奖励。

工程效率平台狭义上是 Devops 或 CI/CD 平台，广义上是软件工程的信息化平台。

• 编译：通过 Jira HOOK 定时触发任务，同时在 GitHub 上 声明要讨论的任务，触发系统编译。再将构建结果 push 到容器里，把结果 Archive 到存储里做备份；

• 部署：对服务进行分组，提供一定的组装能力，让多个服务构成服务组，同时支持实时日志检索，把生成的日志打到 Pandora 大数据平台；

• 测试：因为测试服务和生产服务比较类似的，所以部署方式也类似的。我们会生成 test report ，同时让 Log 打到质效平台。在测试方面比较重要的一点是：和质效平台交互产生大量的数据，每一个数据都记录下来；

• 分发：我们针对对象存储做分发。容器化部署会用容器平台做发布；物理级部署会用相应统一的位置发布。

下面我和大家分享一下七牛在实践上的结果。指向会从上图的两方面考虑：质量和效率。

质量方面：核心服务单测覆盖包括上传、下载、删除、直播推流播放等，这些核心服务覆盖率在 60% 以上、合规 80% 左右、pipeline 通过率 80% 以上、集成测试覆盖率 35%；

效率方面：pipeline 构建 2 - 10 分钟、缺陷解决率 82%+、发布频度每周 40+、核心服务 MTTR 在 2 小时以内。

效率方面：pipeline 构建 2 - 10 分钟、缺陷解决率 82%+、发布频度每周 40+、核心服务 MTTR 在 2 小时以内。

最后，说一点自己的感悟：做正确的事情，不要给自己设限。尤其在创业公司，你会发现有很多事要做，也许你会认为有些事该做，有些不该做，但我认为没有应该与不应该，只要这件事是正确的，就一定要推动 get it down。

本文转载自公众号七牛云（ID：qiniutek）。

原文链接：

https://mp.weixin.qq.com/s/ZO7vDUKBh-DXucev9iSXWA