本届DOIS峰会深圳站为期两天，云集全球顶级专家1600余人签到。嘉宾阵容汇集全球 DevOps 领军人物《DevOps Handbook》合著者 John Willis 、Google 资深技术专家刘靖、IBM 资深架构师邱见等明星人物，中国信通院多位领导与腾讯、招商银行、中国移动等经标准评估DevOps 持续交付能力处于国内领先水平的明星企业。通过硬到不行的技术干货分享，为企业 DevOps 落地提供具体的方向和实践标杆，让实施DevOps有据可查、有据可依。

在深刻理解本届峰会“DevOps落地需要体系化的能力框架、实践方法和工具平台”“有效保障DevOps落地”的基础上，普元刘相围绕度量如何让团队清晰认清自己强调企业DevOps度量体系构建的重要性，结合普元DevOps平台6年的沉淀与积累，分析怎样从关注滞后性指标到关注引领性指标的转变来实现DevOps驱动价值的交付，并通过普元在DevOps度量领域的多项落地实践解读企业如何实现DevOps驱动价值的交付，打造适合自己的企业级数字化生产线。

刘相演讲全文实录

普元云计算产品线总经理刘相：不论大家做DevOps全链条还是一部分，在整个DevOps里面，度量都是很重要的一块。这次我主要跟大家分享：第一，度量怎么做，怎么建立适合我们自己的度量体系？第二，标准其实很难通用，在不一样中怎样寻求通用指标？因为随着大家做的业务形态不一样，大家可能有做产品型、有做交付型，未来大家的度量体系肯定是不一样的。最后，给大家分享在普元这样一个产品型的公司里面，整个度量体系是怎么做的。我还会分享两个普元的案例，一个是面向金融行业的，另一个是面向制造业的，看看大型的航空公司是怎么做的。

说到度量，有几个问题可能要看一下，比如度量跟KPI考核放在一起。其实我们未来在做度量的时候，应该把度量和KPI考核丢开。我们度量不是为了KPI考核，是帮助大家找到瓶颈点，找到最薄弱的环节，去突破和改进。这才是我们的目标。

度量我写的是铜镜，经常照照镜子，我们个体瓶颈在哪，我们的团队、组织在哪儿？这样我们的价值和目标才能达到。我们做度量，什么才是我们做度量的准则，其中有一个很核心的准则。乔帮主在大场里面讲过，提到了引领性指标，其实是非常重要的，因为引领性指标，才决定了未来你的最终目标，很容易达到。但是我们其实在很多度量的时候，你每天写了多少代码，你的交付频率是多少，这个不是我们最关心的目标，这个是你目前个体或者团队目前水平的一个反映。

第三部分就是一些我的案例的实践。

首先分享两个小故事，都是真实的故事。第一个是我在一家银行，有一次在开他的整个部门的会议，正好我是作为一个顾问在那里参加他们的大会，领导比较关心，你看我们现在有几个系统在建，你汇报汇报吧，目前所有的系统都怎么样的？建设到什么程度了？现场肯定所有人都回答不上来，这个问题三天后上报了，三天后所有人因为他们最终可能是各个项目经理统一了一下上报了，这里面反映了一个很大的问题：第一，你很难时时把整个团队的里面项目时时做一个汇报，幸好他们汇报出来的，但是领导想要的时间早就过了。第二个问题很正常的，领导就问了，你这个项目做得比较好，或者不好，三天后能不能上线？大部分人怎么回答？应该差不多吧。是不是？其实，基本上我相信大家也都是这种感觉，咱们认为当领导的或者管几个项目，问你们项目经理能准时上线吗？差不多是什么概念，完全不知道，那就是不知道嘛。

所以说我们在度量指标的时候，我们更关注的不是个体，我们关注的是我们团体，我们的团队。你可以是一个开发团队，可以是测试团队，可以面对产品交付型的团队，都没有问题。我们未来度量的时候，更多考虑这样一个团队，一个组织能不能达成什么样的目标？我们看数据的时候，为什么我们要把一些所有的这种理性的东西，要表达出来，我们都是理科生用数据说明，在左边部分，其实是2009年的时候，当时是国外做了一个整体的报告，它就很典型给予了一个整个IT交付数据的报告。

大家看这个报告之后就很清晰，什么样是好的、什么样是坏的。右边部分一个数据大家可以关注的话，领导经常问你的系统可靠吗，大家怎么回答？我就回答说，我一年到底几次，我的平均可用时间是几个九。你这些说完，领导说没有问题，很清晰把数据度量出来。不止是这样的，还有很多，比如说应用型，你的产品怎么叫应用了。这里面当然举了一个例子，不一定全面。你应用说，我所有的用户不看文档都可以用，这个产品一定可以用。你这个产品，我查手册查了半天才找怎么应用，这个一定是非常难用的产品，我们连看都不看。我们在度量的时候，一定找哪些是我们的度量指标，哪些是我们要的。

其实通过度量的情况下，从三个维度来看，点线面。点是把我们个体、团队的现状找出来，在什么样的水平。线是什么？线是一段时间内，我的这样一个度量的指标变化趋势，我是上升了、是下降了，非常直观得出一个团队内一个能力在哪？一段时间内，工作状态和发展趋势可以看。面梳理标杆、帮扶落后，个体、团队、组织的横向比较。我们做度量最主要的一点，不是批评落后，是帮助他们提升，所有人都愿意配合你做事情。这也是说，度量里面一定不要把KPI和度量联合在一起。点线面是我们度量整个非常重要的体系指标。

说到度量大家很容易想，我们可能会有各种各样的度量体系，度量指标，这个成熟度模型是我们在DevOps领域自己做的，大家可以参考。

这里面有另外一部分列出来在度量这个领域。第一部分最初级第一级，原始的阶段，就是有人，我们以前都有很多的QA团队，人工帮你收集这样的数据，大部分都是在收集的，那这个时候，其实你是已经有了数据的收集。

第二个部分，对收集上来的数据有一定的分析、一定的加工，可以做一定的这种收取的事情，可以考验团队的能力，无论是交付的能力，还是面临业务价值的得可以做。

第三个部分，相当于是说，像DevOps的，我覆盖全生命周期一个整体的度量指标，这个时候可能范围就比较广，可以从交付速度，工程的质量、效率从业务价值多维度去衡量这样的指标。

第四个部分，有了这样一个全生命周期数据指标，结合业务目标，接下来分享怎么样通过设定这些指标去看我可以自定义很多，结合我业务的情况，去自定义我这样的业务目标，然后去度量大家的目标。

第五个部分，最高级了灵活应用了，其实有很多的这种，度量完了之后有一个改进，其实形成一个闭环的驱动力。

前面说了很多的“度量”收集数据，其实我们真正通过DevOps，能给我们带来很多的这种好处。普元信息做一个产品型的公司，DevOps的定义就是IT的交付生产线。汽车有汽车的生产流水线，IT的交付流水线就是DevOps，就是让所有IT团队的各个角色在上面做运行。

我们做DevOps最核心的是做三个维度的解决：第一个是DevOps把我们所有的数据做全链条的打通，很简单的一点就是说，你说你发布一个版本，上面做了多少需求，完成了多少目标，给哪些人提交的代码，介质在哪，能不能全部都抓一个点拎起来一根线。有一个客户打电话，问我版本找不到了，怎么办？我说你问我，也没有用，版本都不存，要么从源代码再编一份，我估计最可怕的，代码商连TIG都没有打，这个是最惨，这个客户弄了两个小时，基本上算是一个事故。

所以，我们通过DevOps第一个是数据打通，第二个上我们所有的数据可以随时获取。

以前更多通过QA部门反馈数据，已经很晚了，在我们内部所有的IT研发的数据，每天早上大家都收到邮件肯定很多的更新的数据，后面会有一个展示。

第三个是基于大家未来的这样一个度量的维度，做各种各样的优化一个能力。这样的话，我们去把整个前面的度量是很重要的。未来无论个体还是团队，无论是未来是领导还是主管，在整个团队把这个事情重视起来。既然认为度量这么重要，如何建立度量体系，你问我度量有标准吗？我告诉你，我说出来不是你想要的，我说出来适合我自己的团队和我自己的企业。

所以说，我们在度量的时候，其实有很多的关键指标，这个大家经常关注DevOps的时候，这个是2017年DevOps现状调查报告的中文版我做了一个截图，这个里面给大家度量的指标，你构建的频率，交付的频率，其实这并不代表你的团队就好了，一天交付10次，你代表你能创造1亿的业务价值呢，没有用的，我们在做DevOps的时候，一定要以自己的业务为目标，来建立我们整个度量体系，以业务为目标是什么？其实很简单的，给大家分享简单的小例子，就是说，我现在其实我自己看两条产品线很简单，每年两个数字，一个是每年产生多少营收，第二产生多少成本，我做自己的度量指标很简单，是不是做的授权不够从去年的50场加到100场，提高授权的质量就是我们达成的指标。

我们未来在做度量体系的时候，一定要以业务来看。从度量维度来说的话：第一个是刚才强调的从个体团队到组织；第二个要从除了业务价值之外，还要从整个效率，我们的质量到速度；现在还有一个重要的点，就是用户体验，所有产品体现不好，你的业务、效率、产品质量做得再好，也代表整个业务的价值。这个是我们在内部做的很多度量性的指标体系，这个体系大家参考一下，有一些东西可以作为一个参考项，结合自己的实际，来选择。

我把我们做的方法给大家做一个方向，我们在这里面关注一个东西，就是引领性指标，是什么？帮我们把最终的目标达成的这样一个指标。就是说你可以定一个很大的目标，比如巨石就是你的目标，怎么样让你的目标达到，这样一些关键的数据是未来推动你很快去实现业务价值的指标，所以是一些引领性的指标。比较抽象，举一个例子，大家看了之后就很明白了。有一个小朋友，经常辅导做作业，考一个好成绩。父母都希望孩子考一百分，可是天天盯着考试成绩有用吗？其实我们应该关注怎么让他考一百分。很简单，每天让他学习半个小时，再狠一点的家长，每天刷五套试卷。这样的话，可以定这样的指标，这个指标是帮助我们真正达到目标的。我们再思考一下，真正关注之后我们让我们的团队关注的是什么？是引领性指标，是吧？你天天让他考一百分，其实考多少分都是要关注的。

总结一下，滞后性指标，也是我们的目标，这是要我们达到的。但是关注滞后性指标没有用，我们要关注引领性指标。很容易让我们的滞后性指标达到，而引领性指标是有预见的。如果每天读半个小时书，刷五套试卷，即使年底考不了100分，也可以考上95分。我们回到这里来看一些我们IT团队里面的指标。我们经常会说，我们要让我们的缺陷逃逸率在多少，5%，就是产品发布之后发现的缺陷的占比，发现这个时候已经没有用了。我们更关注是什么，怎么样让我们的缺陷率降低，有几个指标，可以让我的覆盖率提高，可以让我的数据集成的测试可以提前通过，甚至在自己内部已经做到在开发阶段，就能发现70%的产品缺陷，有很多手段可以做，测试提前介入。

所以说我们在看，做一些这种指标的时候，我们自己也总结了一些法则，就是GQM法则。你问一下你的目标是什么，达到这个目标有什么样的问题？有什么样的度量指标，只不过在度量的指标的时候，一般推荐从设计者的角度考虑比较多。举一个例子来讲，比如说要提升代码质量，有一个问题，如何将代码的缺陷率提高10%，这个时候建议大家从人事物几个维度考虑，人的维度我让每个人写测试，覆盖到95%，或者是覆盖到90%。我们也可以从事的角度考虑，是不是整个开发周期内的迭代。我要做的控制数要降低，本来团队没有这个能力，非要提高，就会带来很大的问题，最终可以归到物上去考虑。

有了度量数据以后，也有一套比较完整的度量表述模型。有健康的，有容忍，有不健康的，中间的话其实有整个状态的趋势，有上升稳定和下降的，可以通过数值的度量有百分比，业务目标和具体的绝对值，最终加上我的时效，每天，每半周，每月，我们最终做度量指标，用右边总体的数据来做整个的展现，这样的话，就会把前面所有的类型是什么，你的趋势上升下降的，你的绝对值和相对值都可以体现出来。

接下来快速看一下我们典型的一些数据，这个是我们自己收集的一些案例。

因为我们是产品型的公司，所有的度量数据多少以团队为主。大家可能会考虑，我们的团队不稳定怎么办？其实在团队不稳定的时候，我们这个数据会有很大的偏差。我建议大家对团队做度量的时候，一定是一个相对稳定的团队。这里面我们有很多这样的一些生产率，我们会统计团队的生产率是什么，未来做项目评估的时候，基于代码源的评估，很准确知道这个团队能不能按期交付，包括每天所有的团队的成员早上起来的时候，都能收到当前版本所修改的故事或者是BUG能够看到所有缺陷的趋势图，还有一些更细，每个人的趋势图都会有。然后能看到所有单元测试的一些情况，能够看到所有集成测试，这个是对外结合的一个变化。这个是所有自动化的测试，这个是包括所有这些数据，每一个团队全部能够看完，所以在这个时候，我们大家就会看到这些数据怎么收敛，我们现在做成在DevOps平台统一把所有的数据收集。这里面举一个例子来讲，我们把用户的故事到我的任务，代码、介质、环境以及我所有的基础设施完成融合在一起，怎么做到？非常简单。

我们会在需求和任务的时候，可以关联编号，在所有的TAS和代码的有一个代码提交方法，进行关联，到构建的时候，能够知道当前版本号和数据联结在一起，最终发布到部署环境之后，所有的数据做了这样一个落地和搜集。这样的话，其实很容易做到整合能力的打通。

所以说，在建立引领性指标的时候可以根据这几个维度去看，在用户做了几个尝试，第一个用户体验、交付速度和运维保障，工程质量。

我们在金融客户做了这种所有的度量数据的看法，是严格按照四个维度来了，甚至包括每周的用户数都可以看到。这样的话，其实团队就非常容易知道，它的这样的一些当前的进度在哪里。所有的数据，我们都会在全部团队里面做公示，但是永远不排名，其实效果很明显的，最后那几名大家绝对有改进的。

下面一个案例是我们在某一个航空公司帮他们去做的，这个上升到他们总经理层面，非常重视，他们汇报所有的数据，每天做展示。

最后再做一个小的总结，我们今天其实给大家分享了，首先我们是从点线面，看到整个度量的数据模型，给大家分析一下未来的规范做引领性指标，告诉这些指标的JQM法则，表示模型，其次是四个很重要的维度在未来做度量。

一定要做自动化收集，无论你的业务还是团队，其实都是像坐火箭一样有大幅度的提升，谢谢大家。

普元DevOps产品资料

普元DevOps曾荣获多项“明星产品方案奖”，是支持企业级敏捷、打造交付流水线助企业IT走向精益运营的DevOps平台。在刚刚过去的10月，普元已发布了更适应企业级产线要求的DevOps最新版本，具有全生命周期、拥抱开源、安全可靠、企业级编译、动态编排、看板跟踪、丰富指标七大特性，为企业提供从咨询规划、落地定制再到运营推广的一站式交付，帮助企业制胜数字化未来。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。