‍

阅读本文你将收获：

1、研发效能度量平台整体架构有哪几部分构成；

2、软件研发效能开源工具与平台推荐

作者简介

董海炜，百度 移动生态事业群组质量研发效能平台部 技术委员会负责人，2007年加入百度质量部，长期以来主要从事自动化测试、持续集成、devops、云原生质量保障相关技术领域。现在负责部门的质效中台方向，全面推动质效技术的云原生、产品化改造。

本文来源：董海炜老师的研发效能系列文章，本文全篇收录于QECon组委会发布的白皮书之《研发效能实践指南》

‍

研发效能度量平台整体架构

‍

平台的主要作用便是将各种需求、研发、测试过程的离散数据进行有机的组合计算，最终形成各种客观指标数据，再配合多种展现方式，形成直观的数据看板和数据分析能力。具体来说，研发效能度量平台主要包含以下内容：

‍

●离散数据的采集存储：需求、研发、测试涉及多个环节和工具，各方数据都是离散的数据，因此首先要解决如何方便的进行离散数据的采集和存储

‍

●数据计算：主要解决如何将离散的数据进行有机组合，最终形成质效评估的指标数据

‍

●数据展现和分析：指标数据需要通过多种展现和分析方法，才能便于用户发现和分析问题，因此如何展现和分析，也需要度量平台合理设计一个典型的研发效能度量平台的架构设计图如下所示

图1：典型的研发效能度量平台架构设计

‍

数据采集层

‍

数据采集层的主要作用，是通过多种方式，如API、Agent、队列等方式进行数据采集，将离散数据转为结构化数据，并建立各数据间的关联关系。从需求创建到最终上线，一般都会涉及多个环节和工具，因此数据的采集需要适配多种场景，一般来说，数据采集有如下几种方式：

‍

●Agent采集：主要针对实时数据或实时打点数据。通过Agent的方式，监听相关的文件、内存或第三方存储数据，进行数据实时的采集和回传。Agent采集方式优点在于可以实时采集，且可以按照使用需求进行采集字段定制，不足之处在于，需要部署Agent，且需要被采服务的授权。

‍

●API采集：被采集数据服务通过API方式将自身的数据按照约定格式对外输出，度量平台通过定时任务进行API请求获取增量或全量数据。API采集方式优点在于，度量平台可主动请求获取数据，同时进行数据的初始化处理；不足之处在于需要离线定时任务进行采集，实时性不足，且离线任务管理也需要额外的处理。

‍

●消息队列：被采集数据服务实时或定时将自身数据，按照约定格式推送到消息队列，度量平台或其他数据需求方进行数据消费。从数据角度来讲，不同的数据，也需要按照自身的特点采用不同的方式进行采集。如实时数据可以通过消息队列或Agent方式进行实时采集，时效性不高或需要进行初级处理的数据可通过API方式统计和处理。数据的来源方不同，但是最终的指标数据是需要将各方的数据进行关联、聚合等计算的，因此各来源的离散数据要具备关联关系，且这个关系是要在采集阶段就要确定的，否则采集之后形成的格式化数据很难做到各数据源的关联。 如下图是一种可行的方式，最终的指标数据是以需求卡片的方式来产出，根据研发过程规范，可以主要以需求卡片为核心，将主要数据进行关联；无法直接关联的，通过间接关联关系进行关联

图2：数据之间的关联关系

‍

数据计算层

‍

研发效能度量平台的数据计算层的主要作用，是通过多次计算，整体数据形成原始数据、中间数据、画像数据的分层结构并通过数据仓库存储起来。主要解决结构化数据关联计算、冷热数据拆分、规则/非规则数据拆分问题。研发效能度量的数据计算层按数据处理流程又分为几个步骤：

●离线任务编排：因为计算任务之间存在一定数据依赖关系，需要对离线任务进行合理编排，对于有数据依赖的上下游任务需要串行执行，非依赖数据可并行执行。考虑到数据会有更新和回溯的需求，所有的任务需要是幂等的，一旦某个中间数据修正后，即可明确从哪个任务开始重新执行，从而保证数据计算的效率以及可重入

‍

●数据处理：该过程目的是将研发效能度量相关的数据经过ETL（Extract-Transform-Load）加载到数据仓库的过程，为研发效能的决策提供分析依据。

‍

●画像生成：研发效能度量一般需要从产品、项目、团队、人员等不同维度进行刻画和分析，因此需要把每个画像主体看为一个对象，分析每个对象的相关属性及影响因素，从而确定每个画像相关的数据项。然后依据数据项，进行画像数据的生成。

‍

●数据入库：根据数据计算结果的特点，比如结构化/非结构化，冷热数据，规则型/非规则型等类型，选择合适的对象存储、关系型存储、KV存储或文件存储。业务线在计算分析研发效能数据的时候，往往会有一些自定义的需求，比如仅选取活跃模块进行度量，需要考虑增加一些黑白名单处理的机制，这样可以根据不同业务线的需求，灵活调整规则和度量结果。

‍

数据分析展现层

‍

在研发效能画像数据的基础上，便可以将各种画像数据进行相关的组合、关联，从而生成各种看板数据。看板的数据最终还是要依赖指标的设计，但是整体上可以分为两类：

●研发质量看板：主要呈现跟质量相关的数据，如线上问题、崩溃率等等。

●研发效能看板：主要呈现跟研发效能相关的数据，如团队吞吐、交付效率、人员效率等。看板数据要支持任意时间段、多种聚合纬度的交叉选择，因此在数据缓存方面，一般按照天级、最小聚合纬度进行缓存，从而保证整体数据的展现效率度量平台除了要具备整体数据看板的展示功能外，还要具备支持用户进行数据分析的能力。常见的数据分析机制有：

●趋势分析：通过按照周、月、季度等纬度的整体趋势展示，分析某项指标的走势、同环比情况，从而更清楚某项指标的变化情况

●下钻分析：主要按照聚合纬度逐步细化，最终细化到每个需求纬度，如部门->子业务->小组等。可以更快速明确问题原因

●关联分析：多种指标组合分析，从而更客观评估。如交付周期和吞吐的关联分析，可以更客观评估交付周期的增长或吞吐的提升是否合理。

●模型分析：根据历史数据进行模型训练，针对同类型需求，评估需求耗时是否合理或团队吞吐是否正常。

‍

开源工具与平台

‍

下面以开源研发大数据平台DevLake为例，介绍其实现方式。

‍

DevLake的Data Sources（数据源）即数据采集层，可通过插件（plugin）实现对特定DevOps工具的支持。

注意Schema（模式）层在系统中扮演的作用。同一个实践域中，通常有多个工具可供选择，比如Jira和TAPD都能完成需求管理。这些工具大同小异，其数据的定义不同但概念相近，需要完成一层抽象和映射，才能实现不同数据源之间的统一化。

‍

这就是模式层完成的功能。基于模式层，DevLake构建统一的、规范化的指标集及分析能力，对应上述数据分析层。指标集参照《软件研发效能度量规范》，归为交付价值、交付速率、交付质量、交付能力和交付成本五大认知域，参见度量框架。

‍

DevLake的数据展现层目前直接采用Grafana，有丰富的看板功能。