度量平台落地实践
转载:https://mp.weixin.qq.com/s?__biz=MzkwNTI2NjAxMA==&mid=2247483751&idx=1&sn=463ee3061aa2ffab48bd45773974cecd&chksm=c0fb1752f78c9e44ece31fda12b9dabc57f7544123c5e35316a2ea411debe3eabce0f8cbffaa&cur_album_id=1979310371207184387&scene=189#wechat_redirect
度量的最终结果不是一个可视化的图表,而是一个问题改进的清单及改进方案,关注这些度量数据给我们带来的信息,获取当前团队的改进重点,持续优化,才是重中之重。同时,度量是动态变化的,在持持续改进的进程中,我们需要逐步提高标准
最近,研发效能平台在业内被不断的提起,总结。张乐大神还出来长篇连载,从不同的角度来解读研发效能,笔者也在持续的关注大佬的文章。恰巧笔者在去年也负责了公司度量平台的研发,有一些收获,通过本文分享给大家,也算是自己对这个平台总结。为后续在新团队开展度量活动理清思路。本文将从以下几个方面来做开展:
![](https://img2022.cnblogs.com/blog/733625/202210/733625-20221017142651954-1719208180.png)
NO.1 为什么要引入度量活动
管理大师德鲁克说:“你如果无法度量它,就无法管理它”(“It you can’t measure it, you can’t manage it”)”,这句话的大背景是处在工业发展时间,企业创造活动更趋向于劳力活动,所以很多东西都比较好度量。如果以计件的方式来管理软件研发过程,是否合适?这个每个人都有自己的体会。笔者从自己团队的现状出发,给出了自己的看法:NO.2 度量活动的目标是什么
笔者认为,主要是为了解决痛点4失中的2失:目标导向缺失及持续优化迷失。 解决标导向缺失:没有明确的、直观的、可量化的数据,我们就无法知道我们努力的目标在哪,在制定OKR的时候,我们经常说目标要数据化,是因为具体的数据才能引导我们往这个目标去努力。通过度量活动,建立团队的研发基线,有助于我们明确目标(例如阿里的“211” 交付愿景) 解决持续优化迷失:我们在为什么做优化?当下技术能力的提升是否能解决团队最紧急的痛点?技术团队比较容易陷入自嗨的情绪中,业务最终的目标是交付价值,不是技术SHOW。技术难点是团队的瓶颈点,还是测试活动是团队的瓶颈点?又或许是需求拆分?更有可能的是各种环境的准备搞的你焦头烂额?没有可靠的度量数据,只能凭借自己的感觉或者经验,无法弄成统一的大局观,看似解决了某一个痛点,但并未对团队的整体交付带来更高的价值NO.3 度量指标的选择
明确了目标后,我们就可以有选择性的选择度量指标,经过团队的充分讨论后(而不是拍脑袋或者依据所谓的成熟度指标),我们定义了以下几个维度的度量指标:需求交付维度,目标:拆分合理,快速交付
测试交付,目标:更早介入,更快回归
在度量前期,我们以这些指标作为指导,观察我们整体的研发活动,看看哪个节点上花费的时间最多,然后就想办法针对性的解决,然后再观察整体,发现节点瓶颈,以此往复,慢慢缩短整体的交付周期。在多轮迭和更新后,形成的最终度量体系如下:
NO.4 技术落地过程
度量平台经过几轮的技术重构和定义,最终的业务架构如下:
上面的业务架构图应该比较清晰了,就不过多的说明,使用的技术栈也相对简单,核心是Django+Pandas+Mysql+es+vue。当然还有一些其它的技术组件,就不一一说明了,都相对比较常见。在整个平台的研发过程中,也踩过很多坑,这里提两点比较重要的来说明下,希望大家可以少走点弯路。1. 不同的业务数据库间的数据如何同步到度量平台 虽然公司通过统一的DevOps平台管理研发过程,但是每个服务都有自己的数据库,度量平台如何从不同的业务库中收集数据,是第一个难点,经过调研,业内主要有两种方案: 方案一:同步双写:最为简单的方式,业务在将数据写到mysql时,同时将数据写到ES,实现数据的双写。
优点:业务逻辑简单。 缺点:硬编码;业务强耦合;存在双写失败丢数据风险;性能较差 方案二:利用Mysql的Binlog来进行同步,具体步骤如下:读取Mysql的Binlog日志,获取指定表的日志信息;将读取的信息转为MQ;编写一个MQ消费程序;不断消费MQ,每消费完一条消息,将消息写入到ES中。 优点:自主可控,性能也较好。 缺点:需要binlog权限,需要额外的研发工作量 我们采用的是第三种取巧的方案:因为业务的数据库采用了主从结构,所以我们直接从业务的从库中拿一台出来,给度量平台用,直接从业务数据库里读数据,虽然方法土了些,但省时省力,后续数据量上来了,再考虑其它的方案。2. ES从入门到放弃 当度量平台把业务数据从业务数据库抽取出来,经过清洗后,要放在哪里进行聚合计算,成为了第二个难点。当时团队有两种思路:用行业比较流行的ES来处理,或者用Pandas来处理。由于两种方式团队内成员都没有明显的实战经验,于是就两种方法都采用,需求和测试的报表用ES,研发类报表用Pandas。 经过几轮的迭代后,Pandas的优势明显。ES的缺陷有两个:第一个问题,Mysql的数据同步到ES需要用到logstat组件来处理,这需要我们单独部署一个服务来处理,由于经验不足,logstat的output配置写的很糟糕,用表结构直接映射。这就带来了第二个问题,由于output是根据表来做的,所以ES生成的Index和表是一一对应的,对于Mysql来说,多表关联查询是再正常不过了,但是对于ES来说,跨Index查询是非常糟糕的,官方的用法也不推荐(虽然用宽表模式可以解决,但会冗余很多数据,并不友好。有这方面经验的大神可以指教下)。 最终,我们还是逐渐放弃使用ES,Pandas还是很香的,不是么。放一些效果图给大家参考下:
NO.5 测试活动只是开始,不是结束
度量平台搭建完成后,并不意味着度量活动的终结,恰恰相反,有了度量平台,反而是我们做持续改进的开始,度量的最终结果不是一个可视化的图表,而是一个问题改进的清单及改进方案,关注这些度量数据给我们带来的信息,获取当前团队的改进重点,持续优化,才是重中之重。同时,度量是动态变化的,在持持续改进的进程中,我们需要逐步提高标准。 同时,不要把度量反馈的数值直接和个人的KPI关联,这样会很容易把度量引导到不正确的方向。细心的读者可能会发现,在第3小节中,我们选取的指标基本上都是基于团队导向的,很少会有个人的数据度量(业内常见的代码行数、个人缺陷数、千行BUG率之类),因为这类数据虽然很好统计,但缺乏指导性,团队成员容易提交大量重复、冗余的代码来“凑指标”,让数据变得很好看,但这对团队没有任何价值。