工程效率如何为研发赋能 博客分类： 奇文分享 工程效率如何为研发赋能

• 工程效率是什么？
• 工程效率如何为研发赋能

工程效率对大家来说并不是一个陈旧的概念，许多公司也成立了专门的工程效率部门，但如何更好地利用工程效率，提升研发效能呢？看七牛工程效率部负责人 & TGO 鲲鹏会上海分会会员李倩从“What、Why、How”三个角度为大家带来工程效率方面的经验及建议。

工程效率的 What , Why , How

对于大部分工程师而言，没办法把大量时间投入到写代码上。除了写代码，他们还要负责找 bug、上线等工作，尤其是事务性工作（比如调试环境，和各部门沟通等杂项）。这是一个很普遍的现象，尤其是在一些达到一定体量的公司里，这种情况很容易出现效率问题，我今天主要讲组织发展篇。

第一个“What”

什么是工程效率？

工程效率主要关注业务交付链条中研发交付环节的品控和效率，最核心的是缩短优质代码到客户 (用户) 交付间的距离。用一句话说就是：整个研发交付的事都要管。

工作效率到底要做什么？

我的理念是，工程效率不只是改善一个人力的投入，更重要的是为企业建立软件工程信息高速公路，让更多工程师可以专注于研发。

首先，要关注一些重要不紧急的事情。因为重要不紧急的事情，在公司发展到一定阶段的时候会暴露，而且很难解决，积重难返。这里涉及流程、工具、协作等一系列问题，它是为一个企业发展做长远的支撑。如果一个企业认为“咱们就是为了融一笔钱把这个产品做出来，过个半年就放弃掉，那根本不用做工程效率，堆人以最快的速度做出来就好。”工程效率是到一定规模或者为一定规模的增长做基础建设，比如发展多条产品线或者多个项目或者上百人。

第二，就是量化工程开发团队对业务的交付能力，并且识别薄弱环节。如果不量化我们就不知道到底哪里有问题。工程效率其实是很泛的东西，首先你的效率要可衡量，如果不可衡量哪都抓不住。我认为量化是非常重要的，量化以后你才知道哪里是薄弱环节，然后再针对薄弱环节做提升，这里建立业务反馈是必须的，可以帮助我们了解业务的缺陷、事故等健康状态。

第三，就是向工程建设卓越的企业学习，比如 Google、Facebook 以及 Netflix。通常我们建立非常多的流程，非常多的人、组织去做很多事情。有了这些人以后就要有流程，有流程就要去协作，有协作就是人的江湖，就会出很多短板。在协作上如果出现了一个薄弱环节，就会产生木桶效应，所以我认为流程要足够精简。不需要的部门都应该被统筹到另外一个部门，而不是出了问题就增加一个实体。很多公司有一个监管部门不行就再建设一个监管，使得组织非常庞大，向外包项目制发展，这样就会出现很多三权分立或者集权，牵扯到人非常复杂。所以我认为流程要足够精简，战略应该足够专注，职能部门不要太多，以业务交付为目标建立成长性的矩阵式管理组织。

第二个“Why”

举个例子，To C 的企业像 B 站这样成长非常快的公司，人员增长逐年成倍。七牛也是一样的，一年增长一倍之多，这个如果体系化建设不牢是很可怕的。加人以后业务复杂度提升了，产能并不一定可以成倍提升。要更稳定的业务增长务必要把工程这一层做厚，比如多套测试环境，提升自动化程度，CI / CD 建设等。

另外一个比较大趋势就是业务驱动的 IT，这其实是说，我们一直在做业务，以 IT 技术为中心，但是仅仅以技术为中心是不行的，要转化为业务驱动的 IT。而对于软件工程而言，如何以业务维度来量化各个职能的产出，也就是做企业内部的数字化转型？举个例子，QA 的产能怎么样评价？两条业务线到底哪个产能更高？对于工程师而言，他们的技术实力代表的是他们的真实实力，而不是企业卖了多少钱代表他的实力。所以，工程师这块需要告诉他们更多的反馈，比如覆盖率指标，返工率情况等等，数据驱动我们不断的提升和成长。

上图是七牛研发场景，我们这块已经发展七年，我们有海量的产品和代码。比如，我们产品线从前些年的存储 CDN、直播到近两年的 AI、大数据、容器云，涉及到不止 600 个组件和微服务，还有一些行业解决方案，整个产品平台实施的项目非常大。

面对这样的问题，我们怎么支撑是一个很大的问题，包括复杂的编译环境，我们会用 Linux 、Mac、Windows。前后端、移动以及涉及语言的版本也不一样，比如，不同语言版本在不同产品线上用的也不一样，升级主版本也需要对比验证，谨慎升级。

另外就是协作难度大，我们有 400 多个研发人员同时写代码，分支也比较多，合并频度以及状态的跟踪等等都是挑战。对我们云计算公司而言，质量是我们的生命线，我们有 70 万客户，这 70 万客户都是 to B 的。比如，范冰冰正在做直播，如果我们直播服务挂掉，这是很可怕的一件事情，将影响上万的用户。这块怎么样快速迭代？怎么做才能又能保证质量保证效率？包括自动化 case 或者多场景的测试，都是要面对的一些实际场景。

第三个“How”

面对这些挑战我们是怎么做的，今天我分享两块务虚的东西，一个是组织发展，一个是文化建设。

组织发展这块中，三大块组成了我们整个工程效率的体系，这三大块对应我们的三个子 team。

质量管理是我们的测试开发 team，分很多线，效能运营是我们效能运营中心，是一个虚拟组织，但是包含多种服务。工程赋能是我们的平台工具组，来做整个的研发支撑。我们到底在做什么？质量管理这块我们 QA 的同学基本上是测试开发，还有技术专家这样一些职能。大部分情况下，他们做全流程质量的把控，核心工作在熟悉业务，写自动化，构建不同的场景。例如 chaos 工程来破坏云服务，验证其健壮性，然后也会去做客户验收的一些工作。

质量运营主要是关注 PMO 以及流程的产品化，还有我们整个内部系统的运维支持，还会做竞品分析等。以前做直播 SDK 我们会把竞品的几家 SDK 的自动化实现了以后去观察他们的一些性能指标。比如 ，CPU、Memory 以及丢帧或者一些实际的推流、播放的效果，会去做一些监控，这样就可以给内部提供更多的技术改进方向，或者是看得到其他人的技术成长。

然后现在他们的 scope 扩大了，就会去做一些质量分析。比如某团队，我们通过质效数据看到它是否有一些特性；比如通过事故统一分析下来，发现某个组件的性能非常容易出问题，技术专家会参与出专项改进方案，最终落地以及提供环境支撑等。

另外就是研发最佳实践的传播，比如单测或者是集成测试等做得比较好的，还有 codereview 做得比较好，都有这个组织来进行发起。近期准备组织内部的类似于效能运营活动。宗旨是主要来源于工程师，服务于工程师，让工程师自己把好的实践讲出来，我们只是一个组织者，配合一些运营。

然后是工程师，大概都包含哪些工程师？质量管理制度我们会分几条线，有技术线和管理线。比如，业务质量负责人类似于质量 owner，测试开发有两个方向，一个是技术专家方面，一个业务专家方向。质效运营中心包含三部分，一个是针对测试服务的 service，一个是 PMO 负责流程设计和产品化，另外是 sre 内部平台的运维支持

文化建设之“工匠精神、质量意识和工程文化”

文化建设篇其实写的务虚了一点，但七牛日常也确实是这么实践的。

第一、工匠精神

工程师对于质量应该有极致地追求，eat your own dog food。我们的理念是：代码是工程师写出来的，bug 也是他写出来的。举个例子，如果一段代码写的不好，给他多少个 QA 都解决不了问题，所以根上仍然是工程本身的质量怎么样。所以我们不会把质量往下游放，而是不断地向上游去思考，以及不会对 QA 追责，而是关注这个问题到底谁去解决成本更低。比如，一个问题如果是在 codereview 阶段就应该发现，那么就不应该到 QA 阶段。

第二、质量意识

我们这块会做大量的质量服务化工作，比如单测或者静态扫描等，我们会做成服务化。很多时候开发同学不是不愿意把代码写得好，而是自己不知道写出来到底能不能 work，我们就需要给他提供更多地支撑。比如，他不 work 的时候反馈给他原因。比如，一旦单测不过，或者说单测覆盖达不到要求，我们会让他看到，他会针对这个去做修改，而且是基于 Pr 级别的，秉承着“持续集成，小步快跑，快速反馈”的理念。

第三、工程文化

凡是超过两次都要考虑自动化或者服务化实现，Everything is Code。我们 CEO 许式伟先生曾经在群里说了一句话叫“系统性地解决一下”，这句话挺有意思也是我们日常的工程文化体现。

质效度量能力的建立与实践成果

体系化实践主要包括：自动化体系建立、量化驱动开发、平台赋能交付，这里主要看下我们的一些实践成果。

上图是我们实践的一些结果，左边是不同的产品线，右边是我们量化出来的指标，总共有 20 多个，上图显示了 8 个。我们会在不同阶段用不同的指标，每一个指标至少都涉及两方，而不是特定哪个角色。比如缺陷遗失率，其实开发和 QA 都会影响，还有返工率也是两个角色协作。

每条产品线差异很大，比如服务端和 web 应用，量化出来只是告诉你当前处于什么水平，自己与自己以往进行比较，看得到的自我成长。当然也有的同学看到数字就很敏感，不甘低于别的产品线，就会自发找原因提升或者去请教做的好的小组，这也是比对带来的侧面效果。

上图是一个系统测试覆盖趋势示意。系统测试覆盖非常重要，它声明了自动化程度和回归验证的具体效果，以及进一步决策需不需要把 QA 同学更合理地安排或调整工作重心。我们曾经有一条产品线，最初有三个 QA，自动化测试达到一定程度的时候迁移了两个同学到新产品线，随着不断积累，自动化程度进一步提高，剩下的一个同学还能空出一半时间做小工具开发或者效率提升的事情。通过这样持续的自动化能力打造和充分验证，我们更有信心发布甚至自助验证上线。

返工率，一定程度反应沟通成本，其实人与人协作成本很高，一段代码连验证都不验证就交到下游，下游如果发现有问题，再打回重写再验证，效能是很低下的，七牛在这方面控制在 15% 以下。

缺陷遗失率，即外部遗失缺陷占整体缺陷的比率。这是传统方法论里一个指标，我认为也比较有价值，能证明整体的缺陷遗失情况，与返工率联合分析可以看出 QA 的压力和能力。

上图是我们的质量和效率成果。在质量方面，我们现在核心服务的单测覆盖在 60% 以上，代码合规率 80%，pipeline 通过率 80%。其中 pipeline 通过率就是 CI/CD 中 CD 的通过率，即从编译部署到发布的通过率。这里面大部分不通过的原因，一方面是环境因素，另外一方面是自动化测试用例不稳定，还有就是本身框架支撑上的一些问题。这就相当于一个信息高速公路，如果不通畅，就没有信心用 pipeline。集成测试覆盖就是 E2E+API 的集成测试，现在我们已经达到 35% 以上。

在效率方面，构建效率为 2 到 10 分钟，这是我们 pipeline 的整个构建效率。构建效率高也一定程度因为我们采用高效的测试框架基于 golang 语言的 TDD 框架，它能实现严格意义的并发执行效率极高。除此之外，我们的环境可以提供多元化的平台支撑和全套的 CD Pipeline 实现。缺陷解决率其实是一种反馈机制，就是对客户的快速响应客户的服务能力评估。发布频度每周现在已经有 60+ 了。平均故障恢复时间现在小于 1.5 个小时，重点服务小于 20 分钟，事故率逐个季度呈现下降趋势，已经基本上属于高效能组织的标准中的中高级水平。Dev：QA 我们现在是 15 左右仍然在减少，当然前期会多加一些 QA 人员，目的是让他充分了解业务转化为可验证的质量环节，如果 QA 不懂业务，就失去了核心竞争力。

我们知道有一门课程叫软件工程，现在研发其实都是在做软件工程，Devops、CI / CD 本质上还是在做软件工程，是整体信息化的过程。我对未来软件工程趋势大胆的做三个方向预测：

1、软件工程信息化一定会被全面完整实现，现在有很多人在做的 CI/CD 或者 devops 只是其中一部分。

2、事务型的职位将会被技术取代或者优化。比如 Ops 和 QA 会越来越少，因为技术上可以更优雅地解决和优化职能效率。

3、未来组织极有可能变成研发团队 + 工程团队，没有项目经理，也没有特别多的产品经理，很少工程师加极少量的 QA，还有一部分 SRE，包括 SRE、QA 等只要跟业务交付无关的都属于工程团队，做强大的技术支撑。

每个团队都应该把自己当微服务、产品来运营。你着重需要关注彼此之间的接口 和产品界面，以及接口的质量和效率。我们把它们量化出来以后，就可以知道自己当前的水准。关于个人成长也是一种量化思维，考虑自己的评估体系，建立量化的能力，了解自己的优劣，去借鉴别人的成功做法和优秀经验。

 

 

from https://www.infoq.cn/article/N92M18s6Qdsm56JJj-De