太帅 发表于 2022-5-26 13:05:03

DevOps度量与改进

本帖最后由 FYIRH 于 2022-5-26 13:08 编辑


一、背景
说一点背景,快手在今年开始正式做一些度量和不同事业部技术团队改进的工作,在这个过程中,今天主要是跟大家分享这大半年时间所经历的事情和几点启发。
在开始之前,我说一下我们整体的结构,我是负责质量与研发效能的团队,但不是所有的DevOps都在我们团队,同时我还run了所有工具链的团队,做工具的同时也要考虑怎么支持业务改进,目前形成的模式是业务牵头,我们会有BP的同学到业务去,基本上就跟业务的同学差不多,业务的leader,来代表这个业务去规划整体的事情,工具团队来支持,大概是这样的状况。
二、动机决定改进的目标和抓手

第一个想跟大家分享的是:动机决定改进的目标和抓手。主要是因为中国互联网下半年发展的整体形势非常严峻,大家也都有非常大的成本压力,公司也会对研发效能部越来越重视,当时我就感觉有点不对头,研发效能工作的改进,是公司想节约更多成本,想去提升效率,这事有那么大的关系吗?其实我是有疑问的,所以我去聊了不同公司的同学,看他们在改进过程中的动机是什么。
腾讯PCG我比较熟悉,很多同学也都认识,了解了他们主要的动机是塑造行为,他的动机并不是要提升产能,所谓的产能是同样的人是不是可以做更多的事情。
百度这两年也在提口号做这个事情,大概是三年产能提升一倍,这个逻辑就会更偏产能一些。
我也翻了谷歌的Blog,也有很多同学跟我分享这个,提到了四个关键指标,我们可以感受他关注的点,他用四个关键指标去度量DevOps:
[*]Deployment Frequency 部署频率
[*]Lead Time for Changes 变更时间,就是从代码提交到上线,代码提交就是代表工作做完了,做完之后到上线的时间
[*]Change Failure Rate 变更失败的比例
[*]Time to Restore Service 出现错误后,花多长时间恢复你的服务

我不是想说这四个指标背后的逻辑,而是看到在硅谷的公司,当他们提DevOps的时候都在提什么,他们认为这四个指标就可以去度量DevOps,他关注的就是发布。在国内范围更大,需求、开发、测试什么都会包含在里面,强调的是我代码写完了,写完之后一跺脚就得线上跑起来,强调的是这个关系,所以他们的出发点跟大部分同学做的事情很不一样。
在我公司里不同的业务也不一样,有的业务是面临着很强的稳定性挑战,总出一些故障,他会特别关注故障发生的时间,定位的时间和止损的时间。阿里还有一个2510时间,2分钟发现,5分钟定位,10分钟止损,我们离这个还很远,所以需要提升这部分,所以提出的挑战决定了他要关注的东西。另外有其他的业务就不一样了,各种问题都有,但都不是那么突出,你就找不到一个top3中的top1是什么,那时候搞不清楚最优做哪些事情,更多提的是解决研发工程师的痛点。所以不同的业务,他的动机会不太一样,不同的公司做这些事情的动机不太一样,出于产能动机做这些事情,可能结果都不太好。
有了这样的思考,当我们了解一个团队要改进的时候,可能就要了解动机。前两天别人介绍了一个同学,他说了自己公司遇到的问题,来了一个新领导,他觉得团队人多,要度量一下自己的效率,那你一定要给出结果,我人就是多,你不给出这个结果,领导都没有信任了,动机就决定了你要做什么事情。
三、DevOps技术能力建设对北极星指标影响不大

另外一个是DevOps技术能力建设对北极星指标影响不大。北极星指标就是我们要给老板看的,就是产能,你是不是同样的人做更多的事,以及你这个事情是不是可以做得更快,这个需求是不是可以更快上去,这个是大家提的北极星的指标。
为什么提这个呢?是因为有些业务觉得,我们想一些指标,但是最好不要超过三个,超过三个太多了,我就感觉到这个结果可能不太好,因为三个指标,你一定会选择北极星指标,你一定会选择关于交付的时间、产能指标,而我们做了好多事情,跟这些指标的关系没那么大。结果也就是不了了之,包括年初的时候建立指标体系也是想少点,最后也都八九十个,但不是说这些指标都要用,后面我会说这些关系。
针对这一点,还有一些我们做依赖治理,不同的业务要打包,最后打出来一点几个G,但是业务代码没那么多,会带来编译时间,启动时间的问题,启动问题十分钟,一出故障之后要十分钟,而且集群还要分批次,影响就非常大。我们做这个事情,老板就会想我们投入这些人做这些事情,解释一下,想想能带来什么业务价值。我们这么做了之后,编译时间降低,降低时间加起来这么多,折合多少人。这个逻辑隐隐觉得哪里不对劲,基于这些点,还包括我们在整体控制成本的氛围下,更加重视研发效应的事,是不是也觉得不对劲?所以我跟业内很多同学聊,最后渐渐的认识更清晰化,就是我们做工具的,没什么影响,能起的作用很少。

我还把这些关系简单梳理了一下。当你提到效能的时候,财务视角看到是研发费用比,你翻一下财报,高的20%,少的6%,这个东西我们影响不了。从HR视角看吞吐量,同样的人做更多的事。再从业务团队视角,除了考虑上面之外还要考虑需求能不能更快上,这是周期时间的视角。剩下是工程师,老板们别天天逼着我快马加鞭的,我看朋友圈分享,人类不适合去做追求效率的工作,那是给机器做的。但是我在写代码的时候,我用的东西要是不爽,我是要跳脚骂人的。这些就是工作中的痛点卡点,上线为什么那么慢,打包为什么那么慢,各种各样的问题,这都是DevOps工具链要解决的。解痛点,提升幸福感,后来我想作用就是这么点吗?我觉得还是提供一些长期的竞争优势,当你去公司发现,原来这个东西这么干,太low了,你觉得不牛,其实长期来看提供一些竞争优势,包括硅谷的公司跳来跳去的时候,我以前公司怎么怎么样。
所以是这四个视角,我们看一下平时关注的东西,交付方式是我们了解最多的,交付方式就是把代码怎么一步一步给送上线,我们为了更好交付,创造了各种各样的工具。两个特点,第一是跟线上的服务没有关系,服务跑起来之后,不依赖你这个工具,你没有监控,服务照样跑,但是出事就完蛋了,服务的运行只依赖于基础架构,这些服务跑起来,那是跑那部分代码。但是我们说跟交付相关的东西都不跑,这是一个特点。第二个特点,这里所做的工作都跟智力劳动无关,做编译的时候工程师不费脑子,一秒就编译出来,超过五分钟我就受不了了,各种环节都是。所以这是交付方式,它的特点就是工具团队可以负责这个事情,但这个事情也只能影响点卡点痛点。比如你编译慢了,你编译快了能节省多少时间,时间节省之后,即使你编译时间很长,工程师还想休息休息,再快也得休息,所以那个时间并没有完全浪费,且那个时间不动脑子,动脑子可以做别的事情,所以这就是他的命,命就影响不了其他。另外是生产方式,什么样的架构,什么样的框架,有没有中台,那些是能够大幅改变你交付的需求和智力复杂度的。生产方式就都影响,再就是协作方式,大家的分工流程主要是会影响周期时间,什么影响吞吐量呢?交付压力、个人能力,所以公司打一个仗,吞吐量一直往上涨,加班呗。个人能力也是,等20%的校招生产生生产力得半年,所以要招好人。想说的是业务团队能影响的是交付压力,业务技术能力影响的是个人能力,我去完善我的生产方式,对交付方式的影响不大,协作方式影响也是主要的。工具和Infra团队影响生产方式和主要的交付方式,而且交付方式不太影响周期时间。
我跟阿里的同学聊,跟圈子里主要的几个KOL都聊这个事情,大家都比较共识,腾讯PCG最开始做改进的时候,曾总也问到,经过了这么改进之后,能不能产能提升?你要是抱着这个目标,就不做了。认识得很清楚。所以当我在会上,大家提到依赖治理能节省时间,能提升产能的时候,就觉得没什么关系。听起来很大,但事实就这样。四、改进分类,指标分类
针对前面的认识,改进和指标都需要分类,这里的背景是什么呢?一个做工具的团队,我们也有这些领域的专家,也有BP派到各个业务去,都从业务的角度上思考,业务的技术的负责人自己或者指定的代理人做业务的改进。很多时候从老板的角度上,一旦想做这个事情,希望找一个团队就把这个事情负责了,往往会找做项目的团队,但是做项目的搞那点团队对老板的影响不大,主要是技术团队影响的,这里头怎么做?你是把自己摘出来?团队内部大家也会说,是这个道理,但是是不是努努力,试一试?最后自己也会感觉这个话圆不了,所以我们渐渐形成了业务员想搞,业务就得出一个基础负责人做,甚至技术负责人整理材料,逼技术负责人做这个事情,跟老板说,每个月针对这个专门做一次汇报,这次A业务,下次B业务,谁汇报呢?这个业务的某一个技术leader,技术leader就会去收集各种各样的数据,需求也就有了。每个人做事情的时候,都会自己想通模式和关系,尽管你看着很别扭,但是这是从他们自己的角度思考的,只有业务牵头去做这个事情,我们提供一些帮助,这事才能走完。
去年不是这样的,我们这边使劲,都是使一些特别通用基础的劲,比如说依赖自己,还有变更的规范,但是这些东西都不影响交付的北极星指标相关的内容,所以渐渐就形成了要业务去干这个事,最好的情况,比如我们有一个业务,这个业务的技术团队有上千人,这个业务的技术的老大需要去问团队效能情况,他需要去把看什么数据,怎么样证明自己,架构到底合不合理,协作到底合不合理,我的同学有很多关于工具抱怨,抱怨有没有解决等等。不同的leader阐述的逻辑和内容都不一样,这是OK的,横向拉齐的东西就收敛一些,所以是按照这么一种模式来的。
技术团队的管理者要对团队的效能负责,他是被问责的一方。腾讯PCG是塑造行为,但我说的不一定客观,但是确实有很强的味道,内部也会做一些调研,大家普遍认为不应该这么做,整个管理团队反思,也会觉得大致是类似的,真正带团队的那波人,那些基层中层的leader是改进的关键,他们不可能被指标驱动,他们得自己去回答这些问题,张三李四想的指标都不一样,这才是一个合理的生态,不可能被统一的指标塑造和驱动。如果有统一的指标,就无脑传递,骂两句,传递下来。所以管理者对团队效能负责,工具团队对技术优化负责,打包更快,工作流程更顺这类东西。
整个指标的置信度决定了用法,很多指标其实天然不太自信,特别是北极星指标,北极星指标就是个认知的建立,需求得花多长时间上,给你起到的作用就是你能够发现异常,这个团队怎么那么突出,但北极星指标可能没有太多的具体指导意义,因为置信不了,就天然这个命。对于特别置信的指标,往往是偏下面的,编译的时长等等这些指标,在DevOps里头还有流水线的时间、流水线的成功率等等都非常安全、统一,这些指标都非常置信,这些指标是可以去驱动的。大概是这个逻辑。整个指标体系还有很多指标,都是业务自取,业务自己有自己的月报,长得都千奇百怪,有的研发的leader说我要看一下团队每周每个同学代码提交的量,这显然不是一个特别普遍的指标。第一次看的时候发现这个团队有40%的人一周都没有提交一行,这说明什么?肯定不是没干活,是工作习惯不好,有什么影响?可能有ABCD的影响,然后他就去培养大家的工作习惯,也攒了一坨上去,把工作切成小的部分,持续的集成等等更好的工作习惯,这些指标也不给工程师看,他利用这些指标培养团队,所以是一个非常个性化的,同样的东西,这个团队这么用,另外一个团队可能得完全用招了,所以从这个角度上看,不同的技术的leader根据团队自己的禀性和认知,取用不同的指标,这些指标有的置信,有的不置信,不置信的就看异常,置信的就可以比一比,来去培养管理提升自己的团队和个人能力。
在这种情况下,很多指标就欢迎自取,不是说推指标,你推了别人不理,不同的业务推不同的指标,事情本来就应该是这样的,五彩纷呈的,因为整个改进的核心就在于真正带十个人,二十个人团队的leader。所以指标是分类的,改进也是分类的,靠一个项目团队去做全类的改进,老板就盯着他,这事不靠谱。

我拿这个图是其中一个leader,他们是一千人的团队,这一千人团队的技术负责人,让其中一个团队的leader负责整个大团队的工作,各种研究,各种采集,各种访谈,很长的文档,我想说明的是,研发负责人得去想这个事,尽管这图看着不一定顺心,各个团队也都不一样,他就只能这样。这里面包括他觉得需要提供扎实的基建,由一个BP负责,各个工具团队,各种抱怨和不足列出项目去改进,这不是这个leader该主要负责的事情,他主要负责的事情是上面,还包括中间,上面也需要很多指标,你需要什么,你提出来,大家帮你一起建。所以也会去分层看这些事情,大家各司其职。

简单说一下整个指标体系的样子,一开始的时候,我觉得也别太多了,小几十个?差不多就行了。最后也接近了上百,但不是说这些指标各个业务都有,而是这个池子当中有些指标是全公司拉齐的,就是人畜无害的指标,需求的周期时间这些不靠谱,这些业务自取,依赖于规范,团队规范不够,指标也不准,但整体的设想逻辑就是指标的池大家可以取用,提出新的指标之后,可以被另外的指标替换,不太靠谱就拒绝了,维持这样的状态。
除了交付性能的指标,多不多,快不快,好不好,省不省,好不好比较客观,上去了就听天由命,下面是工程能力的指标,整个工具链分成很多域,配置管理等等,分别都会有自己的指标,其中还有综合指标,就是跨度比较长的,比如说监控排障,就是多长时间定位问题,多长时间能够止损。变更就是变更的规范度,变更时长这类,持续集成就比较多了。研发框架,包大小,依赖的情况,代码质量等等。配置管理,依赖影响属于配置管理。其实我个人喜欢的是综合指标,但是我们没用,有条件的大家可以看一看,综合指标,一个是变更前置时间,是变更从拉分支到全量部署的耗时,这个条件挺好的,如果各个环节在整个时间段分配都比较均匀,它是比较综合的指标。还有一个前置时间(Ⅱ),变更从最后一次代码提交到全量部署的耗时。中间差的就是拉分支做需求的时间,都是比较综合的,会把后面各种打包到上线乱七八糟的时间都包含进去。
举几个例子,也有很丰富的看板,整个工具链和团队,放几个过程的数据全部落实舱,就在公司统一的BI平台上配各种各样的报表,中间如果涉及到了一些规范相关的东西,再去推规范。(转自路宁)
页: [1]
查看完整版本: DevOps度量与改进