普元刘相DIOS深圳站分享企业DevOps度量体系构建

至顶网CIO与应用频道 11月08日 北京消息：11月2日，普元云计算产品线总经理刘相受邀出席DevOps国际峰会（DOIS）2018·深圳站，在DevOps行业实践及解决方案专场分享《构建企业DevOps度量体系——DevOps驱动价值的交付》。

本届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法则，表示模型，其次是四个很重要的维度在未来做度量。