阿里腾讯程序员写的代码就比别人好？你不知道大厂们操碎了多少心
1. 效能度量的难点和反模式
2. 效能度量的行业案例和关键原则
3. 效能度量的实践框架和指标体系设计
4. 效能度量的常用分析方法
5. 效能度量的落地实施建议
以上内容将以五篇连载文章的形式发布，共计超过 3 万字，本文是第二篇。
研发效能度量领域涉及到的范围很广，相关的方法和实践也非常多。我们在展开讲解具体的度量指标和细节的实践体系之前，先来看一下度量的一些关键原则。当然，如果只讲原则未免过于枯燥，所以本章我会结合阿里、腾讯、百度等多个“互联网大厂”及行业权威报告的案例，来总结和提炼出其中隐含的度量设计思路和关键原则。
DevOps 全球调查报告英文全称是《State of DevOps Report》，可以说是 DevOps 领域的实践者们每年必读的读物，我从 2017 年起连续几年主导了该报告的中文版翻译。但稍有点遗憾的是，随着 2019 年 DORA（DevOps Research & Assessment）被 Google 收购，该报告的创作灵魂人物 Nicole Forsgren 和 Jez Humble 就没有继续投入到该报告后续的调研、分析和创作中了。但在这份报告中提出并一直延续多年的四大 DevOps 关键结果指标，依然对行业提供了权威、极具价值的参考。
DevOps 全球调查报告的四大 DevOps 关键结果指标是：
部署频率： 所在组织部署代码的频率；
变更前置时间： 从代码提交到代码成功运行在生产环境的时间；
服务恢复时间： 发生服务故障后，通常多久能够恢复，即 MTTR；
变更失败率： 有百分之多少的变更会导致服务降级或需要事后补救；
在这四个指标中，前两个（部署频率、变更前置时间）用于衡量吞吐量，后两个（服务恢复时间、变更失败率）用于衡量稳定性。另外，基于每年上千份调查问卷收集上来的数据，这份报告把受访者所属组织分为精英效能、高效能、中等效能和低效能四个聚类，按照上图中每个指标的阈值范围，可以进行效能自评和行业对标。你可以根据自己所在产品线或团队的情况对号入座。在 2019 年，精英效能组织的占比大概是 20%，这比 2018 年的数据几乎翻了两倍，说明行业中的组织都在追求卓越的研发效能，而且这个目标的确是可以达成的。
根据精英效能组织的反馈，他们通常会按需部署，并且每天都会做多次部署。他们的变更前置时间，即从提交代码到代码成功部署到生产环境的时间，不到 1 天，服务恢复时间在 1 小时以内，变更失败率指标在 0%~15% 之间。这些数据与低效能企业相比，均有数十倍甚至上百倍的差异，说明 在研发效能领域，优胜者往往越做越好，而后进者会越来越跟不上时代的步伐。
在 DevOps 全球调查报告的四大关键指标中，我们可以识别出来一些效能度量的原则，即优先使用面向结果的指标，其次才是面向过程的指标；更多使用全局性指标，而不是局部性指标。这两个原则在下文中会详细展开讨论。
当然，从今天的角度来看，DevOps 全球调查报告中给出的这四大关键指标，我认为也有其局限性。比如变更前置时间，这个指标关注的是从（最后一次）代码提交到部署的时间。虽然这个指标对于衡量工程的卓越性也很重要，但只覆盖了研发过程中从生成构建到部署的一个小的阶段，而这种狭隘的局部改进的效果会随着时间收益递减。所以应该更进一步，考虑使用更加全局、更加面向结果的，衡量研发过程端到端的度量指标。
有效的度量体系应该围绕核心问题展开，我们这里讨论的问题就是团队的持续价值交付能力如何。阿里巴巴用五组指标来回答这一问题，它们分别是：
持续发布能力
具体包含两个细分指标，分别是：
（1）发布频率，也就是团队平均多长时间发布一次需求。它约束了团队对外响应的最大可能性 ;
（2）发布前置时间，也就是从代码提交，到功能上线所需要花费的时间。如果时间开销很大，团队就不太可能去增加发版的频率。
需求响应周期
包含两个细分的指标，分别是：
（1）交付周期时间，也就是从用户提出需求并被确认，到需求上线所要经历的时长。它反映团队 (包含业务、开发、运营等职能) 对客户问题或业务机会的整体响应速度 ;
（2）开发周期时间，即从开发团队理解并确认需求，到需求可以上线所经历的时长，它反映研发的响应能力。
交付吞吐率
也就是单位时间内交付的需求的个数。
内建质量的能力
也就是整个交付过程的质量。它包含两个细分的指标，分别是：
（1）开发过程中缺陷的创建和修复时间的分布，我们希望缺陷能够及时且持续的发现，并且在发现后尽快修复；
（2）缺陷库存，我们希望能在整个开发过程中控制缺陷库存量，让产品始终处于接近可发布状态，奠定持续交付的基础。
对外交付质量
包含两个细分的指标，分别是：
（1）单位时间（线上）问题数目；
（2）（线上）问题平均解决时长。
好的度量体系应该回答一个根本问题，并为此讲述完整的故事。为回答团队交付能力如何这一问题， 上面五组指标，分别从响应能力、效率和质量三个方面讲述了一个完整的故事。
其中，持续发布能力和需求响应周期这两组指标反映的是响应能力，也就是价值的流动效率 ; 交付吞吐率这一指标反映的是团队效率，也就是资源的产出效率 ; 内建质量的能力和对外交付质量这两组指标是质量指标。这些指标综合起来，让我们可以全面了解当前交付等能力，与目标的差距，以及改进的机会。
基于这样的度量体系，我们应该设定怎样的目标呢? 阿里巴巴内部做团队效能改进时，提出了称之为“2-1-1”的愿景，得到了不少部门的认可。
什么是 211 呢?“2”指的是交付周期 2 周——85% 以上的需求可以在 2 周内交付；第一个“1”指的是开发周期 1 周——85% 以上的需求可以在 1 周内开发完成；第二个“1”指的是发布前置时间 1 小时——提交代码后可以在 1 小时内完成发布。
到目前为止，阿里巴巴很多团队离“211”的愿景还是有距离的，特别是这个“2”，它涉及到整个组织各职能，和部门的协调一致，紧密协作。1 小时的发布前置时间，则需要持续交付流水线，产品架构体系和自动化测试、部署等有力保障。达成“211”并不容易，但它体现了组织提升持续交付和快速响应能力的目标，树立了持续改进的方向。
在阿里巴巴效能度量体系的案例中，我们可以看到更为落地一些实践经验，比如从响应能力、效率和质量三个方面讲述一个完整的故事，回答团队交付能力如何这一根本问题。在指标的选取上，仍然秉承了优先使用面向结果的指标，其次才是面向过程的指标；更多使用全局性指标，而不是局部性指标这样的原则。另外，这里面的指标都是可被量化的定量指标，并没有出现主观的定性指标。
蚂蚁集团已经有上万名研发工程师，如何更全面、更精准、更有效的提升整体研发效能成为组织面临的重要挑战。蚂蚁集团 CEO 在总裁会上提出“任何事情不能被衡量，就不能被改善，研发效能需持续建立指标体系，收集数据，识别问题，再通过自动化工具、服务体系等去解决研发问题，用赋能（Enable）的思想，最终让研发工程师高质量、高效工作”。围绕这个目标，基于多年积累的大数据技术，蚂蚁集团构建了“蚂蚁研发洞察体系”，包括：
研发效能指标体系
研发综合评价模型体系
研发度量基础设施（研发洞察平台）
其中，蚂蚁的研发效能指标体系设计，注重科学性、系统性、实用性，强调根据不同视角、不同目标、不同功用，精准提供指标。
在指标体系设计过程中，有两个关键点，分别是：分层度量、区分指标属性和类型。
关键点一：分层度量。蚂蚁把整个业产研（业务、产品、研发）过程分为三层，并分别提供指标：
（1）业务层：指从业务规划到价值验证的过程。这一层的目标是“做正确的事”——以业务目标为核心，创造更多有效、可验证、可闭环的价值，保障业务结果。使用的指标有盈利能力、市场份额等商业衡量指标，也有客户满意度、可用率、生产力等非商业衡量指标。这些指标的具体定义和业务特点、业务发展阶段强相关，并会随着市场变化进行调整。
（2）交付层：指从需求受理到需求发布。这一层的目标是“正确的做事”——以流动效率为核心，持续、快速、高质量交付价值。交付层像是一条管道，衡量这个“研发管道”的效能，主要看交付质量、交付效率，以及过程中的研发投入、产出。
（3）能力层（也可叫技术实现层）：指影响交付过程的所有研发活动。这一层的目标是“更好的研发能力”——研发过程中的每个环节（无论是人工还是自动化）能够顺畅、高效、低成本完成。使用的指标主要是每个研发活动中的工程任务的稳定性、时效性、有效性，以及关键研发活动的准出质量。
关键点二：区分指标属性和类型。根据观察角度不同，指标的属性分为质量、效率、投入、产出。根据使用场景不同，指标的类型分为结果指标、过程指标。结果指标用于评价或观察结果，具有滞后性。过程指标用于对过程中关键问题诊断，帮助持续优化，有效支撑结果性指标的达成。
根据以上设计思路，蚂蚁的指标体系实例如下：
其中，比较典型的结果性指标有：
[质量] 万行责任故障数：统计时间内发生的线上故障和变更代码行比例。相当于软件质量工程中最常用、最重要的质量指标之一 - “遗留缺陷密度”（Residual defect density），在蚂蚁使用“万行责任故障数”来衡量线上质量，牵引各团队交付可用的软件。
[质量] 责任故障监控发现率：责任故障中通过监控发现的线上故障占比，衡量研发团队风险防控能力。由于蚂蚁尤其重视提前发现故障的能力，因此也作为比较重要的结果指标。
[质量] 应用发布回滚率：团队所负责的应用的变更有多少比例导致问题，造成回滚。对应到 DORA 调研报告中指标 - “变更失败率”（Change failure rate）。
[质量] 活跃应用客观质量分：应用综合评价模型度量复杂问题，是蚂蚁研发度量的一个特色。质量分是应用发布上线前最后一次运行的各项质量检验结果的综合评价，它的构成包含了安全问题、测试通过率、接口注释率、代码重复度等多个工程维度的客观指标。用于衡量应用迭代过程的内建质量（Built-In Quality，确保每个增量在整个研发过程中都符合适当的质量标准）。
[效率] 需求平均交付周期：从需求受理到最终交付上线的时间。它反映团队对客户问题或业务机会的整体响应速度。
[效率] 研发迭代平均交付周期：研发迭代从迭代创建到迭代发布的时间周期。对应到业界指标称为“开发交付周期”，即一个需求从启动开发到发布上线的时间周期，由于蚂蚁这个过程是由“研发迭代”承载的标准工作流，因此指标命名与业界不同。研发团队的开发能力、研发模式、交付粒度、工程效率是影响迭代周期的关键要素。
[效率] 平均发布前置时间：每一次代码提交到发布上线的时间周期（Lead time for changes，how long does it take to go from code commit to code successfully running in production），它反应了团队的工程技术能力，依赖交付过程中工具的高度自动化和稳定性。
用这套方式，蚂蚁集团累计沉淀了 2200 多个指标。这些指标，经过研发洞察平台的处理，自动识别异常，转化为自动分析结论，并匹配相应的解决方案 & 实践建议，分层、分角色、分场景输出，让全组织使用数据持续优化和改进。
百度软件工程标准制定的目标是帮助研发团队持续提升工程能力。工程标准可以快速指导团队采用优秀的软件工程实践和研发工具，使其在研发效率或产品质量上获得提升。同时有了标准和规范，也能够更有效地衡量团队工程能力的水平，让各个团队能够更好地了解自身的工程能力现状，进而 设定工程能力提升目标，不懈追求工程卓越。
因为软件产品形态有多种，例如 App、Browser、PC Client、SDK 等。不同的产品类型其研发过程及优秀实践也不尽相同。百度把研发的工程类型大致分为四类:Server、App、SDK 和 AD (Autonomous Driving) 。每一类都制定了详细的工程类型的优秀实践集合——工程能力地图。通过工程能力地图，可以指导从开发到上线的流程，建立标准化研发工具链，统一度量团队软件工程的能力。例如下图就是 Server 类型的工程能力地图。
百度已经把内部的这些经验开放出来，形成一本被名为《百度工程能力白皮书》的小册子，如果感兴趣你可以自行在网络上搜索下载，对于全面理解百度这种体量的互联网公司的工程实践有一定借鉴意义。
采用工程实践的直观变化是工程实践完备程度和有效程度的提高，最直接的目的则是研发效率（速度）和研发质量的不断提升。在 《百度工程能力白皮书》的 V2.0 版本中，也加入了对效率（速度）和质量的指标定义和度量方式，以便每个团队在不断提升工程能力的同时，也能够直观看到他们研发速度和质量的同步提升。
在百度工程能力和效能度量体系的案例中，我们也可以识别出来一些度量的关键原则。比如除了面向过程活动的度量，还要增加面向效率和质量结果的度量指标。另外，度量的对象首先应该是产品和团队的工作，其次才是个人。产品的交付是需要组织跨越多种不同的角色进行通力协作，才能把需求最终交付给客户，那么度量也要遵从这一过程，而不要上来就专注于对个人的度量。最后，度量要有指导性，可牵引行动。比如在工程能力地图中通过分析识别到某个工程能力项最薄弱，那么就可以直接采取行动，针对性进行加强。
腾讯的高级管理顾问乔梁老师近期在分享中介绍了腾讯 PCG 的 EPC（ Engineering Productivity Compentence）模型，即工程效能胜任力模型。乔老师认为，“ 持续交付 2.0 双环模型”就是一种软件工程方法论，它包含重要的指导思想和一系列的工作基本原则。而 EPC 就是由它派生的要求与规范，其中包含一个结果维度和十一个过程维度。每个维度都有对应的规范，讲解了“是什么，做什么，怎么做”。工具建设和具体实践都应该理解和遵从这些“规范”。
彼得·德鲁克说：效率是“把事情做对”，效能是“做对的事情”。效率和效能不应偏废，我们当然希望同时提高效率和效能，但在效率与效能无法兼得时，我们也许可以首先应着眼于效能，然后再设法提高效率。
所以，改进效果应该更多聚焦于团队外部的结果性指标。常见的结果指标包括：速度（也称为响应力，包括发布频率、需求特性前置时间、平均故障恢复时间等）、质量（平均无故障时间、可用率、工单率等）、吞吐量（每周 / 月 / 年交付的需求特性数量，或者更近一步引申为价值，如收入、时长占有率等）、安全（如包的及时更新，安全问题数量等）。当然，除了度量结果指标，想要指导日常改进，应更多关注引领性过程指标，并且要有全局思维，关注这些过程指标之间的内在关联。
在外部改进条件不具备的情况下（特别是改进初期），不妨先以 CLCT（Change List Cycle Time）做为改进的北极星指标。Change List 就是一次代码变更，也是每个开发工程师的最小工作单位。CLCT 就是从代码提交到上线的这段时间长度。因为影响 CLCT 的因素最少，其确定性和可预期性最高，所以，可以用做在初期对效率改进的一个关键指标。这个指标度量的本质其实是从“开发完成”到“真正完成”之间的效率。它越小，说明团队中的琐事就越少。
腾讯的研发体系规模庞大，各个事业群也都非常积极的在研发效能度量和提升相关事宜，并且目前由各个事业群派遣专家组建了公司级的研效委员会，正在讨论和制定公司级的研效标准。由于目前对外公开分享的内容有限，本文只能管中窥豹介绍某些局部的信息。但是，我们依然能够识别出其中隐含的一些度量原则，比如通过结果指标进行改进效果的评估，通过引领性过程指标指导日常改进。另外，变更前置时间是一个常见的北极星指标，我们在下文中也会进行详细展开说明。
曾任职于 Facebook 的葛俊老师在极客时间上的专栏《研发效率破局之道》中，认为要真正发挥度量的作用，找到合适的度量指标，必须要先对指标进行分类。推荐从团队和个人这两个维度对度量指标进行分类，其中团队维度中又分为速度、准确度和质量三类。
速度：
天下武功，唯快不破，速度指标主要用来衡量团队研发产品的速率。比如，前置时间，从任务产生到交付的时长。
准确度：
关注产品是否跟计划吻合，跟用户需求吻合，能否提供较大的用户价值。一个例子是功能的采纳率，也就是有百分之多少的用户使用了功能 x。
质量：
如果质量有问题，产品的商业价值会被大打折扣。质量包括产品的性能、功能、可靠性、安全等方面。
个人效能：
个人开发过程中的效率指标，比如开发环境生成速度、本地构建速度等。
关于效率和质量，在上文的描述中已经多次出现了，这里我们重点谈下准确度和个人效能。首先是准确度。提供用户价值是公司存在的根本，因此与之相关的指标是最最重要的。比如净推荐值 (Net Promoter Score，NPS)，是通过调研了解用户满意度，实用性很强。其次是个人效能。个人效能相关的度量，直接反映开发人员的开发效率和满意度，对团队产出影响很大。所以，作为管理者或内部效能团队，应该关注开发人员的高频活动，并自动化和优化这些步骤，让开发人员能专注开发。
一般来说，“个人调测环境构建速度”是一个比较重要的指标。它描述的是开发人员在本地做好一个改动，到能够进行本地调测的时长。开发人员每次修改自行验证都要经历这个步骤，对它进行优化非常有用。在 Facebook，后端代码及网站的绝大部分修改都可以在一分钟之内在本地开发机器上使用线上数据进行验证，非常爽快，效率极高。
在 Facebook 效能度量的案例中，我们也可以识别出来一些度量的关键原则。比如，度量要具备全面性，指标之间可以相互制约。研发组织没法用单一指标来衡量，而需要用一组指标来互相制约以求得平衡。例如，单纯追求交付速度是危险的，必须用质量指标来平衡；同样，我们也不能在忽视工程师个人效能的情况下片面追求过程规范性的提升。
业界流传着一个关于代码质量度量的小段子：唯一一个可以衡量代码质量的指标，是代码评审时，评审者每分钟骂脏话的次数。
我们知道，国内外互联网行业的很多效能标杆公司都非常重视代码评审（Code Review），比如 Facebook、Google 等就要求每一个提交都必须通过评审。代码评审可以尽早发现 Bug 和设计中存在的问题，提高个人工程能力，增强团队知识共享，有助于统一编码风格。但大多数国内公司还是对代码评审理解得不够深入，对评审方法的认识也不够全面，只能简单地去追随一些所谓的最佳实践。结果就是，有些团队的代码评审推行不下去，半途而废；有的则流于形式，花了时间却看不到效果。
那么对于代码评审的度量，如何开展呢？下图就给出了一个在某互联网公司代码评审的不同的成熟度阶段所采用的度量指标：
在启动阶段，重点度量代码评审活跃度
千里之行，始于足下。我们面对的第一个问题是度量代码评审是否开展起来了，这个时候可以选择的指标包括代码评审活跃率、强制代码评审开启率、代码评审发起数、代码评审参与人数等。
在上一步基础上，度量代码评审有效性
这个时候代码评审已经有了较大规模的应用，我们重点要度量的是评审是否有效，是否发现了代码的问题。这个时候可以选择的指标包括代码评审覆盖率、千行有效评审评论数、评审平均交互次数等。
在前两步基础上，度量代码评审的效率
代码评审的活跃度和有效性都没有问题的时候，我们对团队提出了更高的要求，即评审效率要相对比较高。这个时候可以选择的指标包括评审响应时长和评审时长等。当然，这个指标的目标值设置也不能过于激进，我们希望在评审能够及时响应与尽量不破坏评审者的心流工作状态之间找到平衡。
在这个代码评审度量指标设计的案例中，我们也可以识别出来一个度量的关键原则，即 度量指标要具备动态性，根据上下文和所处阶段进行灵活调整。 我们可以随着组织的发展对指体系进行不断优化，定期增减或修订指标，保持指标体系本身的精简和有效性。
通过以上七个研发效能度量的行业案例，相信大家已经对行业中度量的普遍做法和原则有了一定认知，那么现在我就把这些案例中提炼出的度量原则总结一下，供大家参考。
原则一：结果指标 > 过程指标
我们要以终为始，通过结果指标评估效能水平，通过过程指标指导改进。比如：需求交付周期是结果指标，敏捷活动成熟度是过程指标。
原则二：全局指标 > 局部指标
过度的局部优化可能会导致全局的劣化，只聚焦在易于度量的局部指标上，会以牺牲组织更好地提升全局目标为代价。
原则三：定量指标 > 定性指标。
尽量使用量化指标客观评价，并通过系统自动采集，降低对团队的干扰。但也不排除部分综合评价的定性指标。
原则四：团队指标 > 个人指标。
指标设定需要促进团队协作，共同努力达到组织目标。不能因相互冲突的指标而破坏团队配合，制造出更多的部门墙。
原则五：指导性，可牵引行动。
指标设定为目标服务，指标的数值和趋势可以牵引团队改进。比如适当设定缺陷类指标可以促进质量内建能力的建设。
原则六：全面性，可相互制约。
比如需求交付周期 vs 线上缺陷数量、需求吞吐量 vs 需求规模、研发周期 vs 技术债务，这些都是可以成对出现进行相互制衡的指标。
原则七：动态性，按阶段调整。
随着团队能力的提升，指标也需要随之进行适当调整，从而促进团队的持续改进。
对于研发效能度量指标，可能有成百上千个，但度量的原则只有少数几条。我们分别分享了 DevOps 全球调查报告，以及阿里巴巴、腾讯、百度、Facebook 等公司研发效能度量体系和指标设计方面的思考，提取出了一些度量的关键原则。我相信，理解并把握原则的人，能够成功地选择适合自己的度量指标。
在下一篇文章中，我会介绍称为“研发效能度量的五项精进”的度量实践框架，对基于这几年经验总结出来的研发效能度量指标集设计、关键指标定义详细展开介绍，并对指标设计过程中的常见疑问进行解答。敬请期待！
作者介绍：
张乐，DevOps 与研发效能资深实践者，长期工作于拥有数万研发的互联网大厂（百度、京东等），主攻敏捷与 DevOps 实践、DevOps 平台建设、研发效能度量体系设计等方向，历任资深敏捷教练、DevOps 平台产品总监、研发效能度量标准化联盟负责人等岗位。长期活跃于技术社区，目前是 DevOps 起源国际组织 DevOpsDays 中国区核心组织者，同时也是国内多个技术峰会的联席主席、DevOps/ 研发效能专题出品人、特邀演讲嘉宾。EXIN DevOps 全系列国际认证授权讲师、凤凰项目 DevOps 沙盘国际授权教练。历任埃森哲、惠普等全球五百强企业资深咨询顾问、技术专家，多年敏捷与 DevOps 转型、工程效率提升和大型项目实践经验。畅销书《独角兽项目：数字化时代的开发传奇》译者。
在计算机图形学中，渲染是指用一系列算法将颜色填充进像素的过程，渲染技术对于表现力的增强有着至关重要的作用。图形从平面到 3D 趋向复杂化，比如现在的一些 App 里面甚至需要 3D 或者是更复杂的渲染效果，渲染技术面临的挑战也越来越大。
当前，端侧渲染技术最有代表性的当属游戏领域的渲染引擎，比如 Unity 和虚幻，对于非游戏行业，大多选择自研业务渲染器。另一边的 Web 侧，则主要在关注 WebGL、WebGPU 的发展。
GMTC 全球大前端技术大会（2021）深圳站「前沿渲染技术」专题将对以上方向进行探讨。目前门票 8 折特惠仅剩最后 6 天，购票立减 960 元，同时还有 InfoQ 技术大会中秋 + 国庆双节活动同享，购票请联系票务同学小倩：18514549229（微信同电话）