七牛云李倩：工程效率部如何为研发赋能
4 月 12 日，TGO 鲲鹏会上海分会会员，七牛云工程效率部负责人李倩作为 TGO 鲲鹏会线上分享第六季的嘉宾，以直播的形式分享了《工程效率部如何为研发赋能》。本文根据当天直播内容整理。
大家好，我是七牛云工程效率部负责人李倩，很高兴能和大家一起探讨工程效率的问题。今天我主要跟大家分享我的心路历程，以及我们团队从 0 到 1 的演进过程。
七牛从最初发展到现在已经七年了，目前有 300 多名研发同学。七牛主要有六大业务线：云存储、CDN 、云直播、容器云、大数据，以及人工智能实验室。
我认为组织的变革应该站在对业务和发展更有利的角度进行，并不是非要有测试组、质量保障部、工程部等，重要的是在公司现有条件下，能提供什么能力，同时这样的能力是否对业务有更好的发展。
在创业公司最大的感受就是拥抱变化。在这个过程中，你会发现很多事情并没有准备好，要不断地适应，不断地寻找最大价值，提升自我。下面我为大家介绍一下工程效率部的发展历程：
2014 年，工程效率部介入，主要负责跟进前、后端测试。这时我们要做的第一步就是搭建完备的测试环境；
2015 年 3 月成立测试组，对三大业务线（存储、数据处理、CDN 测试）进行日常质量保障。从一开始我们就倾向于用自动化的方式解决问题，所以招聘的都是测试开发工程师。也是从这个时候，我们引进了基本的 CI / CD 交付能力；
2016 年 2 月成立质量保证部，服务于整个研发，开始写测试服务，并完善 CI / CD 能力，将 pipeline 自动化。除此之外，我们还同时管理着公司内部平台及工具链，并写了一套质效分析平台；
2017 年 2 月成立平台服务组，并研发了效能平台，引入容器，把容器作为效能平台里最基础的技术使用。同时，部门正式改名为工程效率部（ V1.0 ）；
2017 - 2018 年，工程销量 V2.0 内部组织结构优化，以适应七牛业务飞速增长，为技术体系赋能。
作为一家做基础服务云计算的公司，我们要帮助客户更快、更好的提供技术能力。七牛云的愿景是缩短想法到成功产品间的距离，而部门内部分解愿景是缩短优质代码到生产上线 / 客户间的距离。这也是工程上非常重要的一段距离。
我们的体系主要分三大块：质量管理、工程赋能，以及过程改进。虽然这里有虚线、实线组织，但整体来说是有机的整体。我们不但要做质量，更重要的是在有效率的情况下，如何把质量做到最好。
质量管理：有专门的 QA 同学深入研发业务，识别质量风险，建立质量反馈闭环。同时围绕目标不断加深自动化程度，适配更多交互场景和大客户。这里主要的人员是测试开发工程师；
过程改进：PMO 流程管理，保障我们整个流程尽量简化，并适于公司发展，适当的时候我们会通过它来做最佳实践传播；
工程赋能：CI / CD 的主线，也是整个部门的轴心，让我们做的所有工作都能有很好的平台化追踪。同时不断完善优化质效度量体系，让大家更有目标感，知道我们应该从哪些角度去解决问题。
总结成一句话就是：工程效率主要是关注交付链条中研发交付环节的品控，以及效率的整体交付能力。
那么如何做到质量意识足、代码敢交付、服务敢升级，主要有三点：
工程师对质量有极致的追求。代码和 Bug都是人写出来的，所以我们会要求工程师对自己的代码负责 —— Eat your own dog food ；
内建质量的建立。内建质量决定外建质量，在交付之前的所有过程要尽量提前，并提升内部质量。比如：单测、静态扫描分析、集成测试等，每一步失败就要去修复。每走一步都要提供验证机制，让代码有办法校验，对整体的质量负责；
DevOps 工程文化引入：做一件事情如果超过两遍，我们就需要去思考这样做是否真的更有效率。所以我总结了一句话：Everything is Code 。
这方面我主要想跟大家讲一下质量小组的基本技术实践路径，这是每个 QA 同学都要做，每个开发同学都要理解的。
首先，我解释一下为什么会有上图这种看似 step by step 的效果。我们的产品很多是从 0 到 1 ，再到 10 ，所以一开始是有很多工作需要介入的，而不是自始至终做同一件事。我们每个技术人都要不断进化自己，把自己的工作重心从 A 转到 B ，再到 C 。
第一阶段，提升代码本身的质量、内建质量，我们会为开发人员提供反馈，让他知道哪里做的有问题；
第二阶段，针对产品业务，输出 API 级测试服务；
第三阶段，从代码分析去提高测试的覆盖率，基于测试覆盖率，辅助进行精准化测试；
第四阶段，针对服务间的依赖，做 mock 或回调的辅助测试；
第五阶段，考虑错误注入，模拟故障情况下的应对表现；
第六阶段，推出更多维度的检测手段，不仅是 e2e ，还需要有基于业务的调用链衡量，服务自身健康状况等，评估产品的每一次迭代；
第七阶段，将各个阶段的产出、总结、抽象，进行服务化，产品化输出，以服务模式提供质量保证。
平台演进比较重要，我们需要考虑是否有可能把更多的东西搬上服务。同时，平台化是服务化之后的阶段 —— 如何把服务融入到整个流程中，并且被完整的管理起来，提供一定的工程能力。我们的目标就是量化产品的质量和效率，提供质效分析能力，识别薄弱环节。
上图是以服务级别或模块级别列出来的主要功能：包括单测覆盖数据、静态扫描、代码检查、集成测试覆盖、缺陷和事故分析、发布跟踪、服务探测，竞品性能 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 小时以内。
最后，我想跟大家说一点自己的感悟：做正确的事情，不要给自己设限。尤其在创业公司，你会发现有很多事要做，也许你会认为有些事该做，有些不该做，但我认为没有应该与不应该，只要这件事是正确的，就一定要推动 get it down 。谢谢大家。
分析平台是一点点做起来的，把重要的东西先实现，慢慢累加；效能平台我们做了一年半左右，中间在架构上也遇到过一些问题，现在已经能稳定服务我们的三条产品线了。
坦白来讲，UI 要看业务属性是什么样的。因为 UI 的效率比较低下，我做过比较大的 UI 项目大概写了 3000 条 case ，跑 2 个多小时，之后也改用过 jquery ，但仍然效率提升不明显。
spock 是自研的，同时我们也在使用 Jenkins ，它作为 CI / CD 的工具还是比较广泛的。但当它达到一定程度时，会发现碎片化比较严重，所以我们研发 spock 也是因为对碎片化、对信息的把控程度不够高。
我们用自己的容器 —— Kirk ，底层技术用的是 k8s 。所以从整套驱动来讲，还是要了解 docker 。我们现在推各个产品使用，但仍然需要把容器的概念也深入进去，至少要先学会写 k8s 样本文件。
线上监控这块其实我们会去监控，也会借助内部的监控工具。因为不同的业务属性监控平台也不一样，所以会针对这些加入自己业务质量的指标监控。但监控对我们部门来说也只是为了更好的了解业务的实际状态。
是 GO 语言。GO 语言是一个插装方式，它的原理其实跟单元测试有点类似，但需要把本身编译的程序重写插装，之后再把它做一边运行。其实就是了解 Go ，就是最终的底层就是 GO Test 。
不是业务流程，是 GO 原生的语句插桩，针对的是目标代码包下的所有方法逻辑。但我们现实现的不够优雅，后面我们把它迁到了 Docker 里，去用异步的方式跑系统覆盖。系统覆盖是很重要的指标，它会让你知道业务是否真实的覆盖了代码，比较有分析的价值，所以我觉得以后应该是异步并且提供更方便的方式去做，而不是像现在这样复杂的流程。