DevOps 实施效果度量的启发和思考

未分类

作者简介
茹炳晟，

我聊一下 DevOps 实施效果度量的启发与思考。之前准备的内容是想跟大家聊一聊 DevOps 相关具体实践（技术层面），后来考虑到对于 DevOps 实践包括整个 CI/CD、制品库管理等一系列的东西包括大会上面以及其他分享上面都能听到。

这次是闭门会议，我们会想去聊一些比较敏感的话题，可能在大范围分享当中并不能聊的，或者不会在公开场合大规模聊的话题，所以想聊一聊Devops实施效果度量，主要是围绕度量展开具体讨论。看一下在 DevOps 实施过程当中度量里面有哪些坑，这些坑在本质上在很多时候让我们走向歧途，我们把这些东西用一些比较具体的例子或者结合实际项目当中碰到的问题，给大家做一些分享。

我来自腾讯，我叫茹炳晟，主要在测试以及研发效能提升两个领域工作了很长时间。我个人同时参与Devops包括研发效能提升以及测试能力提升相关具体工作。早年待过外企，后来加入国内互联网，也待过国外互联网，包括以前假如腾讯之前给很多一些企业做 DevOps 落地包括研发效能提升相关咨询工作，所以对这个行业有了一些成长史，整个过程当中也有自己很多的想法和感悟。

今天想借助此机会跟大家聊一聊关于研发过程当中，整个 DevOps 过程体系当中度量相关话题。

第一、会聊度量失败案例。
第二、在 DevOps 领域或者研发效能领域度量失败案例，里面具体指标导致错误结果或者导致不好结果的具体案例，有了这些案例做铺垫会去引出“第一性原理”，度量背后逻辑是什么，度量到底以什么样的形式解释出这个问题，给大家一个思考。
第三、分享度量常见误区（度量十宗罪），在我们度量过程当中如何避坑。
第四、度量指导原则
第五、DevOps 度量案例与度量常用指标。

整个内容分享并不属于完整理论体系，而是在我以及我以前的团队在实施Devops过程当中遇到的经验与教训，尤其是当Devops实施进入深水区之后所遇到困惑的总结或者相关思考。这是整个分享一个整体定位。

历史上度量失败案例

其实我们都知道，一个不好度量行为或者不好度量指标，经常会引导出不好的行为。在历史上非常有名是这样一件事情，大家（PPT）从这张图片上可以看到很多窗户，那这些窗户都是用砖封起来的，大家知道这是怎么回事吗？这些其实是非常有名一个叫做英国曾经执行的税收所引发的，我们称之为“窗户税”。

1696年之前房屋税收是根据房子内壁炉数量统计的，但是税务员如果要收税必须要跑到房间去数，老百姓不希望税务人员进门的，所以整个收税过程很不顺利。税务部门突发奇想，既然进门不方便，能不能采用另外一种度量指标来度量指标，就是窗户数量，房子窗户的数量，因为他们默认理解，如果这个房子越大或者豪华程度越高跟采光的窗户数量以及采光窗户数成正比，所以根据这个东西进行税收收取。有了这样想法之后，大家知道执行的结果是怎么样？这件事情执行结果想通过似乎窗户数量这种度量来决定税收，这件事情的结果：大家都把窗子封起来，最终得到很多近视眼，同时照明工业发展的比较快，但是英国税收增长几乎寥寥无几。这是历史上非常著名的由错误度量指标所引发的不良行为，最终没有达到效果的具体案例。

我们身边也有很多这样的案例，大家都吃过海底捞，海底捞的CEO张勇，他当时说过一句话：“每个指标体系背后其实都有一个不为人知的阴暗面”为什么会有这样一种说法？海底捞的服务做的还是比较好的，为了提高一些用户满意度。如果你要去吃火锅，如果你戴眼镜一定会给你眼镜布，同时如果杯子里的饮料比较少了，会及时给你加满，如果带了手机会帮你套上等一系列的行动。如果你用这些行动指标去考核你的团队或者考核你的员工的时候，会必然发生一个问题，这些店员这些服务员会不停骚扰你的顾客，顾客不需要饮料了，但是必须帮你加满，哪怕后面是浪费掉的，顾客不喜欢手机被套上一个塑料袋，但不行，你必须套上，否则店长看上之后会扣分，甚至有些翻台率也是，顾客只要迟到一分钟，哪怕是一分钟，你的订单就被取消了，从而导致了很多一系列问题。你回过头去想一想，这些指标当时被提出目的是为了什么？目的是为了提高客户满意度，但是反而你会发现，这些指标跟最终用户满意度在一定程度上对着干，这个现象跟 DevOps 实施很像。

在刚开始实施 DevOps 的时候会用一些度量体系，比如说Lead Time、千行代码bug率等一系列度量指标，但是这些度量指标在 DevOps 实践早期可能会给我们带来一些正向作用，但是Devops实践在企业内部逐渐进入深水区之后，你会发现这些指标很多时候可能反而会引发出很多不好甚至意想不到的副作用，这个就是我们所面对的很大困境。

在我们工作、生活当中对这种选出不好度量指标而引发不良行为案例非常多。大家如果有兴趣的话，我们可以特别关心这本书，这本书是我最近看得一本书，因为我最近一直研究如何让整个Devops体系包括研发效能本身是如何度量，如何做数据驱动，所以我最近刚看了这本书，叫做《指标陷阱》。这本书英文原本叫做“指标暴政”，对度量指标进行了非常强有力的批判，作者是历史学家，非常有意思，如果大家感兴趣可以去看一下这本书，里面提到了很多度量失败案例。

这边跟大家举例，有一个小小感受，但不一一展开了，比如说像我印象比较深刻的几个案例，自媒体运营。自媒体运营是为了提高效率，那么一般怎么来度量自媒体运营的效率？一般通过阅读量或者点击打开量。如果用点击打开量度量指标去考核你的团队或者考核你的内容，那你就会发现你的打开率会显著提升，但是有可能你整个自媒体公众号关注人数随着时间推移出现不增返减的情况，因为你考虑是短期的指标或者是局部指标：点击量，那这个时候一定会触发小编用标题，用害人评论的标题，用标题党的方式让读者去打开，但是打开之后读者发现上当受骗，那么从此以往对这个公众号失去了信任，不再关注了，像这样的例子在这本书当中是非常多。用手术成功率考核或者评价一个医生，医生会怎么样？医生会刻意回避疑难杂症或者重症病人，所有医生手术成功率一定会提高，但是重症病人是得不到救治。如果用手术后30天的存活率评估这个医院的话，那么那些手术失败的患者可能强行去维持生命体征到31天，这样病患死亡就可能不算在医院头上了，这些都是引发了一系列不好行为。

我们回到整个 DevOps 或者整个效能提升领域看待这件事情，这样的案例更多。

第一是大家非常知名度量指标，在 DevOps 领域里面质量维度上经常作为考核指标的指标叫做千行代码缺陷率，我不知道有多少人听过这个指标或者说有多少企业在使用这个指标去作为你的质量考核？我不知道大家有没有深入思考这个指标背后含义以及指标对于最终目标结果驱动正向或者反向作用。这个指标我简单解释一下，这个指标计算非常简单，就是分母是开发完成代码行数，分子就是代码里面发现缺陷数量，每千行代码为单位里面bug数量，那么业界一般指标对于CMMI体系里面包括Devops体系当中，对于不同等级对于千行代码bug率都有一个比较理想的状态。大家可能对这个指标也习以为常，觉得这是一个比较好的指标，但是如果仔细去思考这个问题，这个指标真正起到正向牵引的作用，对真正效果落地是正向牵引还是负向牵引，我们简单分析一下这件事情。

不通过抽象方式，通过一个场景来分析这件事情。小明技术很挫，技术能力比较弱，写得代码非常臃肿，这个时候他可能完成一个功能，写了两万行代码，其中有162个版本，那么这种算出来千行代码bug是8.%的位置，业界一般会认为在10个以内千行代码bug还是属于勉强可以接受的范畴，所以小明至少不会得到批评，认为是得到正常的结果。

另外是小刚，小刚是技术大牛，水平很牛，他实现同样业务功能，代码行数比较低，只有4000行。同样他的代码发现bug很少，这样千行代码bug可能只有3个，这种情况下会出现什么结果？千行代码bug3个显著低于平均值，那这个情况下你有可能不是得到赞扬，而是被认为你的测试不充分，责令去加强整个测试。这个其实已经显示出指标的不公平性。更有一个人叫小美，小美是非常有技术追求，试图成为小刚技术大牛，所以在这种体系下面试图学习更好模式，去学更高质量更容易被融入的代码。

在这种情况下，代码行数由于采用不同设计模式，代码行数还是比较少的，但是bug数量通常比较高，这种情况下算出来bug量高于平均千行代码缺陷率，这个时候小明得到责备与批评，要求他改进代码质量，这个已经看到指标不公平性。更糟糕的是，没有过多久需求会发生变更，需求发生变更的时候，小刚与小美这两个我们认为比较好的程序员，因为他写的代码用了设计模式，代码有很好可重塑性，面对变更的时候可以做优雅变更，只做少量变更，而且不太会引入新的问题。在这种情况下面会发现工作量看似很简单，而且千行代码bug率依然很低，所以他们可能继续受到中评或者差评，因为他们千行代码bug率依然很低，而且工作看起来是很简单的，反而小明因为他写得代码都是流水账似的，改起来难度很大，复杂程度很高，而且还引入新的bug。这样一来小明看起来很忙碌，由于小明bug代码行数基数够大，所以引入bug很多情况下也让他千行代码bug率不会太高，所以他可能并不一定受到批评。

这就引出一个很有意思的现象，忙碌代表了高效率，代表会被表扬，而优雅的设计反而会得到批评或者得不到正向的反馈，那这个是度量想达到的目的吗？这显然不是。程序员面对这种不公平，他一定会为了指标刻意优化。优化有两条思路，一种是增大分母，一种是减小分子。减小分子显然减小bug数量是很难的，那么必然会人选择增大分母，增大用更多代码行数让这个指标更得更好看，这违背整个度量原始目的，而且你会发现不仅违背原始目标，而且还隐隐传达了一些信息，比如说我们不欢迎程序写的好的程序员，像这里的小刚以及试图让自己变得更好的小美，同样我们也不鼓励技术提升阶段的镇痛，比如说小美，是在技术提升阶段经历的镇痛，我们都不鼓励，同样也不相信程序员能够写出高质量的代码，因为当你千行代码bug率很低的时候，可能遭到你没有充分测试的差评，所以千行代码缺陷率指标在真正实施过程当中有没有正向牵引或者负向牵引哪一头才是更大的？这个才是我们需要思考的问题。

这个问题本质是什么？这个问题最终本质是回到一件很重要的事情上。大家可以去思考一下，代码行数跟代码质量到底有没有关系？当你使用千行代码缺陷率的时候，你势必假定了你的代码一定是有缺陷的，而且你的缺陷数一定跟代码行数成正比，这个真的是这样吗？

大家可以想一下代码行数跟质量到底有没有关系？像森林火灾跟冰淇淋的销量到底有没有关系，虽然看起来当冰淇淋销量搞得时候森林火灾率也会上升，同样森林火灾率上升的同时，冰淇淋销量也在上升，但是它们是没有关系的，它们真正关系是因为天气热。代码质量与行数到底有没有关系是我们值得去深思的问题。

这是非常典型的失败度量。这样度量失败有没有办法去避免？既然我们谈了这个问题，我们稍微多讲几句，其实是有办法避免的。既然你可以通过稀释代码，那有没有办法让你不稀释代码或者让你稀释代码的手段无效，那么现在业界提出了另外一种千行代码缺陷率代码替代品，分母把千行代码换成抽象语法树的复杂度或者一个逻辑复杂度。

抽象语法树可能要简单做一个解释，其实是一个在编译过程当中经过词法分析、语法分析之后生成树状结构。树层次越多，叶子越多，代码逻辑就会越复杂。学过编译原理的同学应该都知道这个东西，由于抽象语法树AST获取之后已经去除代码当中人为干预，比如说空行、换行这些影响都去掉，这样让千行代码bug率分母变得更具有可信性，但是这个是正解吗？可能你仔细去想一下这种度量手段依然不是正确的解法，因为你继续可以用算法来对抗基于抽象语法树维度千行代码bug率，因为你可以把一个循环写成顺序执行来增加抽象语法树逻辑层次，依然可以通过算法对抗的。

我们更进一步想一下，我们正解或者最终解在哪里？当我们弄明白一件事情的时候，看清一件事情的本来目标之后，很多事情就有一个正确解法。很多时候我们的管理者尤其是我们目标管理的同学，通常会把一个目标拆解成指标，就像我们想把质量拆解千行代码bug率的指标，但是时间久了之后，你可能只知道这个指标，也就是只知道千行代码bug率了，而不知道原来的目标。如果你的目标是一个森林的话，指标其实就是当中的树木，这样时间久了你看得只有树木，看不见森林了，这个时候会非常盲目，如果我们能够跳出这种思维模式想一下，千行代码bug率最终解决的目的是什么？其实是要提供高质量软件。

发生缺陷并不可怕，可怕是修复缺陷时间过长。假设每个缺陷修一下只要20分钟，那么几十个甚至上百个缺陷，整体修复时间不会太长，而如果只有少量缺陷，而每个缺陷都要以几天为单位去修复甚至连查明根因都需要很长的时间，那这个时候就要反思一下你的代码是不是需要重构或者代码本身耦合性是不是存在严重问题。很多时候如果能够想明白这点，我们就能想清楚千行代码bug率替代指标更好度量维度替代指标反而是叫做平均缺陷修复时间的指标。这个指标往往能够更好反映代码本身质量状态以及团队对于修复bug的成熟度，往往平均修复时间较长的代码复杂度都很高，而且耦合性很高的代码，平均修复时间短的代码结构都是很清晰，命名都是很规范，也是容易理解，这种指标作为度量指标（网络卡顿[01:02:38]），而不会让整个指标流于形式。

这是第一个在研发效能或者Devops领域当中经常用的指标当中比较典型问题例子，叫做千行代码bug率。

需求按时完成率

需求按时完成率在 DevOps 度量体系中经常被使用，尤其 DevOps 进入深水区之后，你会发现我怎么证明我的价值？DevOps 必须进行度量，度量过程当中引入需求按时完成率指标。我其实看到有一些团队，当没有需求按时完成率这个指标的时候，整体团队需求完成情况，随着团队技术成熟，能力不断提升，其实是在不断增长的，一旦引用需求需求按时完成率指标之后，你会发现这个指标越来越好，但是能够交付业务价值是越来越差。当你用需求按时完成率作为考核指标的时候，作为工程师团队、Scrum、敏捷团队必然会在任务估算时候尽可能多留一些量，尽可能少接一些这样需求，因为这样才能保证需求按时完成率能够正常完成。

这件事情更糟糕的是，能力越强的人越是能够把自己累死，在这种情况下大家越能看清这个问题，所以最终得到就是我承诺能做的就是尽可能少，才能保证按时完成率，包括需求 Lead Time 指标在 DevOps 体系度量广泛使用，Lead Time 导致把需求过度拆的非常小，所以在用这些指标的时候，我们要非常慎重。

单元测试覆盖率

千行代码 bug 率分析了，单元测试覆盖率也是在Devops体系当中质量控制环节当中非常关键的指标。如果过度追求指标必然会引发很多副作用。我们曾经看到过很多企业，单人测试覆盖率很高的，但是仔细去看了这些单元测试里面要么是一个段言都没有，只是执行代码，没有任何段言，要么那些段言，那些测试代码只是在测get、set方法，而对真正核心代码逻辑根本没有进行覆盖，只是为了覆盖率而覆盖率，只是为了糊弄整个质量红线，这个是很悲催的一件事情。

通过失败案例引出整个度量对于正向牵引的作用。

接下来看一下DevOps也好，效能提升也好，业界对于这两个维度度量到底能不能做，这个业界有两派非常明显不同观点，但是这两派不同观点分别有两个流派人物分别为代表。

左手边是彼得•德鲁克，是管理学大师，他提出一句话：“如果你不能度量它，你就不能改进它，但是我们的软件”，但是我们软件大师马丁•福勒曾经发表过一篇文章，这个文章链接放在这里，你不能度量你的效率，也提出了效率不可度量的观点。这个到底谁对谁错，这个不想在这里花时间展开，因为你发现如果展开会变成一场辩论会，但是到底谁对谁错，你问我是什么观点，其实我认为两者说的都有一定的道理，看你面对具体的适用场景，但是有一点我可能偏向研发效能还是可以度量包括Devops能力，一定是可以度量的。

很多东西最终一定是有一个落到数字，像你个人能力好度量吗？很难度量，但是最终可以用工资、收入水平来度量你的最终能力，这就是很好指标。同样爱情能够度量吗？也不可度量，但是爱情可以感知到，同样我们技术当中谁是技术大牛，有度量标准吗？其实也没有，但是我们可以明确知道我们这个团队里面谁技术最牛，所以这种情况下一般认为我的观点还是偏向是能够度量，但是很难做到个人精准度量，但是我们一定是有度量可以有线索可循的。

接下来看一下关于度量“第一性原理”，讲了这么多终究是为了引出一个度量第一性原理，度量到底想解决一个什么样问题？其实一个号的度量，回答一个本质问题，并且要能够引导出正确行为。能够让专家经验产品化、标准化下来，从事后复盘模式转变风险管控。如果你对Devops整个过程环节有一定度量体系，那么你不是到了这件事情变得不可收拾的时候再去做反馈，而是能够在过程当中可以控制住整个过程的分享，这个是整个研发效能度量第一性原理。讲起来简单，但是实际理解第一性原理还是有一些难度的，我们举几个例子来看一下。

刚才讲的那些话当中有两个关键词，一个叫做要回答本质问题，第二我们要能够引导出正确行为，分别对这两句话进行解释，首先回答本质问题。

这个要回答本质问题，60%、80%是数据，但是数据所传导信息是什么？传递是单位测试代码行覆盖率从原本65%提升到80%，由数据所传达的数据。从度量视角来讲，单元测试代码行覆盖率能够达到95%以上，同时代码能够完全覆盖绿色功能，这是度量想达到标准，这些其实都是表面的东西，还是度量本身。最后要回答一个本质问题是什么？其实要一个更高的代码质量或者是能够让代码质量风险在整个开发过程当中被前置，这就是需要回答的本质问题。

其实如果往深的探讨这还不是本质问题，如果你更深一步往下去挖，你会发现更本质的问题是以更低成本完成整个软件价值交付，因为你越早发现风险前置之后软件成本以及研发成本可控性才会变得更好，这个才是本质问题。一个好的度量指标一定是能够回答本质问题的，与此同时还能够引出正确行为。

关于千行代码bug率就是典型的。千行代码bug率不够好，那么能够引导出更好行为就是平均缺陷修复时间。还有一些指标在Devops体系当中经常使用的，但是我们可能认为并不一定是贼好的，比如说接入Sonar的项目数量。因为我们做Devops接入过程当中通常会有这样的要求，要求每个项目在介入CI过程当中必须引入静态代码扫描，那么引入静态代码扫描业界比较典型是用Sonar去做代码静态质量分析。我们怎样度量Devops实施效果呢？看一下多少项目开始接Sonar？假定我公司有100个项目，这100个项目有多少用Sonar做静态代码分析了，并且把Sonar静态代码扫描环节加入到CI流水线当中了，我们会看这种指标。这种指标是不会引导出正确结果，为什么？我们做的事情把没接的全部接上，因为接上指标就完成了。其实我们想说你接了Sonar你想解决什么问题？你想回答的本质问题或者你想解决根本目标是什么，其实接Sonar只是一个手段，真正的目标是提高代码静态质量，所以说如果你用接入Sonar项目数量度量整个Devops落地效率的话，必然造成大量项目都接入Sonar，然后就没有然后了，然后不会引导出正确行为。我们应该变化思路，应该把接入Sonar数量指标转变成Sonar问题增长趋势或者Sonar严重问题平均修复时长。当这些指标去做度量的时候，做Devops实施效果落地度量的时候，这些指标将直接影响你的行为，如果你用严重问题平均修复时长来度量，你可以接入项目过少，但是凡是你接入项目里面被暴露出来严重问题会尽可能快速修复，这就达到引入这类工具本身背后目的。要正确引导正确行为，我们很多时候度量指标要有一些变化的。

看我们系统用户有多少，如果用系统用户数来衡量其实比较虚荣性的指标了，不能引导出正确行为，而如果你用系统用户数，那我用非常低的促销手段，以半买半送的方式把用户拉上来，然后用户用过一次之后，买过你这最便宜的商品之后用户再也不来了，那系统用户数增长了，但是最终目的没有达到，因为我们要的是日活用户数，我们关注是持续使用产品。所以这种情况下如果用日活活跃用户数度量整个行为发布，你的CI、持续集成都在我这个平台上完成，而不只是接进来就不使用了，这些指标设计好能够引发出好的行为，并且能够让你最终度量指标背后目的才能够更好达成，这是我们非常关键的观点。但是很多时候要看到一个事物本质问题并不是这么容易的。

我相信很多人都去西贝吃过饭，西贝吃饭的时候看到它内部有度量，你点完菜之后会把沙漏放在那里，如果超过时间没有上菜的话，会怎么样。这是一个度量，背后解决本质问题是什么？很多人会想到是解决客户满意度，让用户更容易能够满意，让用户对上菜时间有合理时间预期，真的是这样吗？其实不是，它想回答的本质问题或者它想解决核心问题是什么？是单位评效。西贝菜馆忙的时候很忙，空的时候很空，在忙的时候能够提高效率最佳办法就是提高翻台率。翻台率提高有两个维度，一个是上菜速度，第二用户吃饭时间，吃饭时间是用户控制的，你控制不了，但是上菜速度是可以控制的。这个东西像一个沙漏保证上菜时间，在保证客户满意度维度上面只是一个副作用，只是带来一个效果，最主要背后本质问题是要提高单位面积评效，提高翻台率。

我们举这个例子就是想告诉大家，很多度量背后本质目标其实还是不太容易获得，你要对这件事物要有一些根深蒂固的理解。

接下来看一下十宗罪，这是我们想分享最主要的内容。这个是在大量企业包括腾讯内部包括大量外部企业落地Devops过程当中，尤其在深水区的时候，在初期阶段这些问题不会被暴露，尤其进入深水区之后在能力成熟度3级之后，你想往上走或者你已经过了3级甚至已经过了4级之后，你如何让这些过了级之后的实践，能够让整个企业Devops能力真正得到提升过程当中可能遇到的坑。

在讲十宗罪之前，我先告诉大家几个观点，这几个观点是非常重要的。因为现实事物本身是复杂，而且是多面的，而度量正是为了描述对比这些具体抽象事物而采取一种抽象以及一种量化手段，虽然是抽象，所以从某种意义上来讲度量结果一定是片面的，只能反映部分的事实甚至局部事实笔试并没有完美度量方式，这是我们要讲清楚第一个观点。

第二个观点数据是不会骗人，但是数据所呈现以及对这些数据解读其实是有很大空间的，同样我们要知道有些不懂数据的人是很糟糕，但是只看那些数据，只为指标去开展工作的也很糟糕。基于这样大前提看一看度量过程当中，Devops落地过程当中由度量引入十宗罪行。

第一、罪行是经常使用容易获得的指标来作为度量指标，前面像代码行的人天数，分别每天递交多少代码，这种指标容易获得。千行代码缺陷率容易获得，个人工作时长容易获得，各种Lead Time，各种需求前置时间，开发需求时间容易获得，但是这种指标有用吗？度量指标有一个特点越容易搜集指标用户往往比较小，而对于那些比较难搜集的指标，用处更大，而总有一种天然倾向，就是会把一些焦点放在最容易量化的目标上面，然后作为解决复杂问题的抓手，时间长了大家只重视简单，对量化之后可视化简单目标，而忽略不可量化背后真正要解决的问题。
第二、我们经常使用容易量化指标会排斥掉难以量化重要指标，比如说开发人员代码行人天，就会被排斥掉代码影响力，虽然有些开发改的代码很少，但是改的代码被别人调用很频繁，影响范围很广，所以这种指标反而会被短期局部目标掩盖掉。

试图想通过一种单一维度进行度量，这张图很有意思。一个圆柱体，当你光线来得方向不同的时候，你看到的东西其实是不一样的，那么有很多时候我们度量Devops效率的时候，如果我们光通过Lead Time或者是光通过某一个单一维度指标，这个时候是非常明显，如果你只追求单一维度指标的话，那这个指标一定会被优化，但是其他指标一定会被牺牲掉甚至你最终的目标，最终目的甚至受损。我们对于度量过程当中指标通常会采用这种手段，会定一组指标，这一组指标是相互牵引相互制约的，当人为去优化其中一个指标的时候，那么另外一些指标必然会出卖你这个行为，组成指标矩阵。指标矩阵放在一起之后就能够让你整个度量变得客观跟公正，这个也是相对客观与公正，你很难做到全面客观与公正。关于这个有兴趣可以线下讨论，因为根据你想要解决的不同问题，我们会有不同度量矩阵，不同度量矩阵之间相互制约关系，你改了那头，那头就会出卖你，让你整个行为变得不可受人为干预。

第三、在Devops过程当中最容易犯的错误，也是由Devops初级阶段进入深水区的时候经常会遇到的问题。既然要衡量Devops实施效率，敏捷实施效率、Devops效率、研发效率，通常会把过程数据进行采集，研发过程当中过程性数据进行采集，但是这种采集很大程度上不依赖于工具，而是依赖于人做这些填充。

最典型的例子，如果大家熟悉敏捷实践的话，就会看到这两张图，上面那张是理想当中的蓝鲸图，随着时间推移，待完成任务逐渐变少，随着时间推移当一个迭代结束的时候，我们任务须向为零，这个是很健康的。现实当中蓝鲸图度量是下面这张图，前面几乎不减，到了快结束最后一天或者两天瞬间一下子减下来了，这是什么原因？当你任务完成之后，工程师不会手动完成这些数据，不会到系统里面手工填状态变更，如果有项目经理可能帮你填，但是工程师通常会觉得自己已经很忙了，搞这些文档性的工作别来烦我，所以会造成经常出现这种现象。当出现这种现象是很危险的信号，因为最终一些决策是基于过程数据做参考，而你现在过程数据本身是通过手工填的，换句话说这些过程数据本身具有完全失真，根本不能反映出你整个研发过程Devops整个环节数据流动，这些数据都是后期补出来的，这些数据对于后期度量判定依据有非常大的影响。在这种情况下面对于数据度量获取一定基于自动化获取能力，一定跟工具体系相完备，让过程性的度量数据获取由工具自动化来完成，而不是人工采集。

举个例子，比如说我需求完成了，什么叫做需求完成开发？如果你靠开发工程师把需求ID状态从开发中改成开发已完成，没有几个工程师愿意干这件事情，你在落地过程当中一定会遇到阻力。应该通过工具，当你这个功能完成之后开发人员把功能分支和合并主干的时候，当合并操作发生的时候就会发起一个调入API，然后把需求ID对应这条需求从开发中自动转变成开发已完成。一旦开发代码做代码合并了，那么我的分支需求ID状态会随着代码合并而做自动变更是同步完成的，只有这样研发过程数据采集才可以做到自动获取，后期收支之后才有度量意义。

第四、度量与个人KPI绑定，这个是很多企业经常遇到的问题，要度量一定要绑定个人。有一句话说得非常经典，这句话也不是我讲的，你度量什么就会得到什么，而且一定不是以你所期望的方式来得到。你凭运气赚来的钱，一定会凭实力亏光道理是一样的。

如果你要度量生产钉子的能力，如果用钉子数量来衡量得到就是一堆小钉子，如果你用重量来衡量得到就是几颗大顶子，你度量什么一定得到什么。如果去绑定KPI会得到度量值全部满足，但是最终目标一定不满足。我们比较建议的做法，不绑定度量尤其是效率Devops效果度量不绑定个人KPI，而是绑定项目KPI或者用现在流行的话讲，绑定项目的OKI，而不是个人绑定，因为对于个人绑定，利跟弊比起来，远远弊大于利的。

第五、Devops进入深水区之后经常犯的大作物，叫盲目建立度量数据中台。当Devops体系已经跑得非常成熟了，像腾讯已经跑得非常成熟了，我们整套流水线跑得非常大的时候，我们希望这些过程数据已经能够自动获取情况下，在想有没有机会把这些数据全部搜集起来。

前段时间腾讯发布了腾讯研发数据大数据，在微信大家都能够找到发布数据，这些都是度量数据中台最终给出的数据。大家不要忘记这件事情，大厂能够干出这些事情是因为它比较有钱，你不要忘记度量本身是有成本，如果试图建立一个度量大的平台，你必然碰到很尴尬的状态，因为你什么过程数据都想搜集，都想存储，试图以后通过大数据分析来发现效率上的提升或者Devops改进点。有着没着先打一竿子，把数据先搜集起来，以后在做分析，但是这种做法对于大厂来讲可以玩，对于小厂来讲是非常致命的，因为度量是有成本的，度量获取数据是有很高成本包括分析。

我们比较建议不要一开始盲目建立大而一统的东西，而是在一开始的时候我们应该有一些问题的痛点，然后基于这些问题痛点找到度量指标，跟这个痛点相关度量指标然后去做改进，改进之后然后在去分析这些指标，而不是搞一个大一统所有东西都要去。当你什么东西都要的时候，其实你什么都得不到，我们要有针对性，根据你业务场景发现这段时间可能流水线失败率很高，那么可以定一些指标改进，然后看这些指标有没有改进，就是要有针对性去做一些系统性的优化，而不是盲目一统去看一些事情。有时候大厂可以干，但是小厂不一定能够干的事情。

第六、度量会有显著滞后效应。树懒动作很慢，度量东西通常采取的效果、采取的行动不可能立竿见影，不可能，度量通常会有非常显著的滞后效应，你要能够耐得住寂寞，不要前一次行动度量结果还没有反映出来之后，你就已经改变你的行为。

第七、业务还没有搞起来就开始搞度量，这个也是经常看到的。有一些大公司人才可能空降到一些初创团队或者互联网大厂的人降到金融企业，降到数字化转型传统企业，这个时候他们会把大厂那套东西搬过来。一开始业务还没有真正搞起来就开始搞度量体制了，因为他觉得有度量、有标准化、有流水线，这种情况下会发现度量对整个业务产生伤害。现在社区团购业务要搞度量根本没有必要，让它野蛮生长，让子弹飞一会，然后等市场起来之后已经规模化之后了，在去考虑规模化的事情。

第八、很多时候度量忽略工程师主观感受，在Devops当中尤其出现这种情况。在Devops编译环节，编译时间很长，试图去降低编译时间，通过分布式编译分时、通过编译缓存方式、通过依赖关系缓存能力降低编译跟打包实践，这种方法能够提高效率，能够让度量指变得更好看，但是有时候会忽略工程师主观感受。举个例子，编译时间假定从30分钟降低到15分钟，虽然从数字上看提高了50%，一倍提升，但是工程师面对15分钟编译时间，依然会有任务切换，依然会切到其他任务上线做其他的事情，这种情况下原来工作模式并没有变化，虽然提高一倍的效率，但是反过来如果对于一个即时反馈操作，从原来0.5秒提到0.1秒，哪怕提高了0.1秒，但是对于用户工程师来讲满足感更强，他会觉得快了，立马反馈，立马反馈周期变得更快了，操作系统流畅度高了零点几毫秒你就感觉舒畅很多，这个是工程师主管感受或者叫做微观体感。我们要做的事情不要在原来很花时间基础上做，但是不改变原来的行为模式。这个我们稍微聊了一下，这个可能很多人会忽略。

第九、高层不应过多关注下层目标，因为当你高层过多关注下层目标，如果业务老板关心研发指标，研发关心项目指标，项目经理关注研发指标，说明你公司业务走下滑路，上层老板不知道要干什么，只能看下面，这个是非常危险的信号。一线研发要关注项目经理的指标，项目经理同样要关心高层管理者的指标，从下往上看是不对的，但是从下往上看是必要的，这个是非常敏感的话题。

第十、很多时候做工作量估算的时候，到底用工作量还是用人天来做正确的度量，大家有不同的观点。很多人说两者都可以，但是我想告诉大家人天去做绝对是错误，时间关系没有办法给大家分享这个例子了。

整体来讲总结一下效能度量过程当中主要原则。

（1）用结果指标衡量整个好坏，而用过程好坏发现问题。

（2）度量时候尽可能让度量东西离事近，而离人越远。度量对象离人越接近其实是越不可靠的。

（3）度量变化趋势高于变化指标绝对值。关注是改进而不是指标本身绝对值。在度量体系下面尤其是Devops下面，不太去鼓励跨团队横向去比，而是鼓励纵向去比，跟我以前做的怎么样去比，而不是横向去比，横向去比就变成竞赛或者变成一些数字游戏。做指标的时候不是指标越多越好，而是需要设计一些经典的指标，像质量指标搞了很多过程指标其实都没有用，最终一个结果指标最终漏测率，当你北极星指标设的比较明切，过程指标设置的尽可能少得时候，你才能获得更大编译收益，当指标数量越多的时候编译收益是减的。

（4）尽可能让一线人员来参与指标制定，至少让他们参与指标评审，而不是管理层来决定整个完整指标。管理层应该给出结果性指标，但是一线人员应该给过程性指标，如果这个东西反过来就会形成一系列的很不好的事情。

（5）如果可能尽可能让度量周期短一点
时间关系不再展开了，后面可能还想给大家分享一些在Devops体系当中用的度量工具，比如说周期时间控制图、缺陷趋势图、累积流图，具体工具不去讲了，可能更多把一些理念以及背后理念跟大家讲清楚。

最后可能还会有一些度量指标体系参考，到时候这个PPT会给到大家，大家可以去看一下，如果有问题，到时候可以提问。