七牛云从最初发展到现在已经七年了，目前有 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。

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/