点击直达原文：【DevOps系列】企业度量难题破解：全面解析度量平台的核心能力

01

引言

在之前的一系列文章中，我们已经深入地探讨了研发效能洞察的重要性，并介绍了几种常用的度量分析方法。然而在度量实践的过程中，仅仅依靠理论框架是不够的，我们还需要将这些理论与企业的实际情况相结合。在这个过程中，企业常常面临着各种问题：比如，难以采集分散在多个系统中的关键数据；难以满足业务发展中频繁调整指标的需求以及难以对不同部门的数据权限进行隔离等。

因此，我们需要一个度量平台，它能够自动采集多个系统的数据，可以通过配置的方式快速修改指标，并且能够实现精细化的权限控制等。在本章中，我们将详细地描述效能洞察的建设过程，并进一步讨论在实施效能度量中常见的问题，以帮助大家更好地了解一个良好的度量平台所需具备的关键能力及其背后的原因，为企业提供一个全面了解和合理运用效能度量平台的指南。

02

度量建设的常见步骤

首先，我们来详细了解一下度量建设的常见步骤。

1

需求调研阶段

在这一阶段，我们需要了解用户的原始度量诉求以及度量目标，并与客户沟通是否已有所需度量的指标清单。若客户对度量需求的概念较为模糊，暂不清楚如何开始度量体系的建设，我们可以按照指标拆解方法进行梳理和引导。最终，需要输出一份详细的指标清单文档。该指标清单通常应包含以下关键内容：

主题（仪表板）：用于展示一组目标一致的指标。它通常旨在解决某一类角色面临的一个或多个具体问题。

指标分类：帮助了解指标的度量类型，可以按域进行分类（如需求域、测试域、代码度量域、集成域、跨领域），也可以按其他类型进行分类。

指标名称：用于区分不同的指标。一个简明扼要的标题能够清晰地介绍指标内容，便于用户一目了然了解指标的用途。

指标口径：详细介绍指标的统计逻辑，便于用户能够清晰了解指标结果的计算方式。指通常，指标口径会通过指标备注进行展示。

数据来源：根据指标口径，确定数据来源的系统、数据库表、接口和字段。这些数据将被用于获取、处理和关联，最终构建出指标所需的数据模型。

图表类型：根据指标的维度、度量和过滤条件来确定使用何种图表类型进行展示，以便更有效地传达数据信息。

查询条件：帮助我们在大量数据中筛选出最关注的数。例如，我们可以按项目或优先级来查询缺陷数据。

关联指标：对于需要进行联动、下钻的指标，列出与之相关的指标，并按照指标清单的所需内容进行拆解和关联。

指标意义：介绍指标所解决的问题，或在指标数据出现异常时，应如何查找问题原因及解决路径。

阈值设置：用于定义指标结果的正常范围，当数据超过这个范围时，就需要引起我们的关注，以便及时采取措施。

2

数据处理阶段

在需求调研阶段输出的指标清单中，已明确说明了每个指标的数据来源系统、取数逻辑以及必要字段等。我们将根据这些信息，对需要度量的相关数据进行清洗和加工，最终形成数据模型，并将这些模型统一存放在数据仓库中。

3

数据展示阶段

不同图表类型有着不同的表达侧重点，选择合适的图表类型能够更为精确地传达数据信息。我们需要确定每个指标的展示方式，并最终将这些指标分组展示在仪表盘中。

柱状图：适用于对比多个分类间的数据大小和数值。

折线图：用于展示连续数值（如时间）或者有序分类的变化趋势。

条形图：与柱状图使用场景类似，但当数据类别名称较长时，条形图更为合适。

饼图：用于展示分类之间的占比情况，适用于展示整体与各部分的相对比例。

散点图：用于展示两个连续变量之间的关系或相关性，便于观察变量之间的分布和趋势。

排行榜：通过数据高低排序，直观体现数据排名情况。

雷达图：能够直观呈现多个维度上的数据，便于一目了然地比较和分析数据的差异。

4

权限控制阶段

数据是重要的资产，对其进行权限控制可以防止敏感数据泄露或滥用。此外，通过权限控制，可以对数据进行分组管理，让不同用户聚焦自己关注的数据。

03

企业度量建设可能会遇到的

痛点和解决方案

下面介绍度量建设步骤中，企业可能会遇到的痛点以及解决办法。

1

数据获取阶段的痛点

例子：某企业设有大数据部门，该部门主要负责存储和处理数据，数据存放在 Hive 大数据仓库中。随后，该企业建立了 DevOps 平台来支持研发过程。由于 DevOps 平台产生的数据业务特性较强，因此由专门的业务部门自行存放，并将此部分研发过程数据存放在了 Doris 大数据仓库中。同时，该企业还使用了多个自建的第三方系统，如测试管理平台和代码仓库等，数据分散存储在不同系统中。

该企业面临的痛点：

对度量系统提出的需求：

为解决企业在度量数据获取方面的潜在痛点，

度量系统需要具备以下能力：

2

数据处理阶段的痛点

例子：某企业基于原始业务数据库数据（MySQL）进行取数和建模，由于缺乏建模思维，仅仅对原始库表数据进行原样存储。这导致一旦新功能上线并改动库表结构，就容易引发指标展示异常。同时，由于数据存储在 MySQL 中，受限于其数据读取性能，指标展示速度缓慢。当有多个用户同时访问指标时，页面经常卡顿，导致无法正常打开。此外，使用原始库表提供数据，受限于业务，模型的通用性很差，大部分指标都需要生成新的数据表再提供数据。

该企业面临的痛点：

对度量系统提出的要求：

为解决企业在度量数据处理方面的潜在痛点，度量系统需要具备以下能力：

3

权限管控阶段的痛点

例子：某大型拥有众多企业部门和人员，其中包括部分外包人。集团希望对部分敏感数据进行权限管控，确保这些数据仅对关键岗位开放。然而，受限于当前系统的功能，权限只能控制到菜单级别。这导致不同部门间数据可以互通，A 部门能够看到 B 部门的关键数据。此外，由于部门人员众多，每次发生人员部门变更，都需要重新调整权限设置，这不仅耗时费力，而且配置的权限还容易出错。

该企业面临的痛点：

对度量系统提出的要求：

为解决企业在度量数据处理方面的潜在痛点，度量系统需要具备以下能力：

4

数据呈现阶段的痛点

例子：某企业通过定开方式产出指标，需要耗费大量的研发资源做定开，大量度量需求堆积，业务数据得不到及时验证，导致业务部门对长交付周期感到不满，而研发则常感排期紧张，时间不够用。此外，业务需求频繁调整，每次调整后都需要重新处理数据处理并修改接口。代码修改完成后，还需等待发布窗口进行部署，无法实现无感更新，导致上线出错率高，且错误内容难以及时修正。

该企业面临的痛点：

对度量系统提出的要求：

为解决企业在度量数据处理方面的潜在痛点，度量系统需要具备以下能力：

04

总结

通过上述说明，我们了解到优秀的度量平台需要具备以下核心能力，这些能力也可作为企业在选择度量平台时的参考依据：

1

数据拓展性强，支持快速对接第三方数据源，实现跨领域的数据度量。

2

数据处理能力强，能够高效处理大量数据的读写请求，确保查询与展示数据时流畅无阻。

3

权限精细化管控，能够实现数据行级别的权限控制，实现跨部门数据隔离。

4

指标可视化配置灵活便捷，配置操作简单易懂，能够迅速响应业务指标的快速迭代需求。