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

原创
2018/05/08 10:41
阅读数 1.8K
AI总结

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

关注公众号「七牛云」 了解更多信息哦~

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
0 评论
0 收藏
0
分享
AI总结
返回顶部
顶部