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]