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

11月2日,普元云计算产品线总经理刘相受邀出席DevOps国际峰会(DOIS)2018·深圳站,在DevOps行业实践及解决方案专场分享《构建企业DevOps度量体系——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法则,表示模型,其次是四个很重要的维度在未来做度量。

来源:业界供稿

0赞

好文章,需要你的鼓励

2018

11/08

10:11

分享

点赞

邮件订阅
白皮书