困境与破局
字节跳动研发效能度量团队成立于 2020 年 6 月。回望当时的时间节点，直到 2020 年年初仍然没有一款面向全公司的、服务于研发全周期的数字化产品。研发链路的相关数据散落在各个研发工具内部，各条业务线都有一个或多个类似的定制化看板产品，只用于度量各自业务的研发效率和质量。因为缺乏公司级的数仓建设，不同业务线间的研发效能情况无法横向比较，甚至在一个业务线内的不同部门，对同一个指标都有着不同的口径定义。因此，在公司内部对研发效能度量有三大诉求：首先，完成整个软件研发生命周期数据数仓的统一建设；其次，梳理指标口径定义，确保业务线内部可以统一“北极星指标”，并在公司层面大业务线间实现横向比较；最后，基于度量发现问题并提出解决方案，推动业务方优化。
软件研发效能度量的第一大难点在于“软件研发效能”这一研究课题本身。“软件研发效能”涉及软件研发链路中的每个环节，同时包含现代企业内部管理协作模式和业务收益评估等多个课题。在这一母题之下，每个环节都有其独有的领域知识门槛，同时各个环节之间又有着千丝万缕的联系。在度量的过程中稍有不慎，就会令业务囿于局部优化的陷阱之中。
软件研发效能度量的第二大难点在于开发流程的灵活性。现代工业化生产链路虽然复杂，但是在确认生产模式后并不会频繁变更，因此 ERP 可以定制化构建生产过程的度量系统。软件开发过程主要依赖团队间不同角色的分工协作，在这种多方参与的脑力劳动中，很容易出现复杂的环节依赖，而这些流程依赖又极具多样性和易变性。字节跳动研发团队需求流程管理都是通过字节自研的项目管理工具进行的。字节项目管理工具的一大产品特色是能够使管理员用户低成本的完成需求节点流程模板的配置，因此各业务研发团队都会基于自身特点配置不同的需求流程模板。
软件研发效能度量的第三大难点是其交付结果投入高、收益计算复杂。软件最终交付件是完全非标准化的，且通常不会重复完成的项目。即使有 A/B 实验的加持，其数学原理也只能解释单一需求的指标组变化，难以准确计算指定团队整体的业务收益。在对团队或者个体进行度量时，度量对象规模越小，则指标可靠性越会迅速劣化。
研发效能提升是每一个研发团队所追求的，但实际情况是，当某一效能问题成长为“屋里的灰犀牛”后，它才被人们真正重视。在常见的研发效能提升活动中，研发团队通常会以某只“灰犀牛”为目标——团队驱动自身进行流程和方案的改进，进而打赢这场有限的游戏。人们都知道，研发效能提升是一场持续精进的“修行”，却只能用一场场有限的游戏去对抗熵增。就像拉姆斯菲尔德在“未知的未知”言论里提到的那样，研发效能这一母题本身幽暗而深邃，限制效能的瓶颈、提升效能的方法都隐匿在未知的未知之中。字节跳动的研发团队希望能够通过转动效能提升的飞轮，让研发效能提升成为一场无限的游戏。在这个过程中，字节跳动转动了两个飞轮：协作的飞轮和价值的飞轮。
在这场游戏中，字节跳动构建一个令三位玩家高效协作的生态模式。首先是在业务方和效能专家之间，业务方对效能专家提出其具体效能提升的诉求，而效能专家基于经验和分析给出专项解决方案，并在业务方改进过程中持续参与，以此帮助业务方落地并打磨自身方案；其次是效能专家和度量平台，效能专家在平台中进行业务全域数据的洞察分析，而平台在效能改进方案落地后，将成功案例沉淀到平台的专家系统中；最后是业务方和度量平台，业务方将度量平台作为管理运营监控的工具，以衡量改进效果，度量平台通过业务方的使用不断优化业务指标口径精度。在协作的飞轮转动的过程中，业务方可以获得研发效能的提升，效能专家可以打磨其效能提升方法模型，度量平台在对功能的迭代过程中使平台能力更加完备。
图 1-1
第二个飞轮是价值的飞轮。度量本身并不创造价值，只有洞察后的效能提升才真正为业务创造长期价值。“猎杀屋里的灰犀牛”的价值是不言而喻的，但更重要的是以长期业务价值为北极星，转动研发效能提升价值的飞轮。在这个飞轮中，有两大摩擦力：第一个是业务研发团队的配合参与度，也就是论证长期业务价值和短期资源投入，以及研发习惯重塑之间的 ROI；第二个是如何高效搜寻更多的灰犀牛，最好是做到“除之于未有型”。字节跳动以研发效能度量团队作为效能提升飞轮的发动机，由供给侧驱动飞轮的高速运转。
图 1-2
研发效能母题的庞杂深邃，因而在 DevMind 的产品设计过程中，我们怀有足够的敬畏之心。也正是因为这份克制，DevMind 本身并没有做过多的业务假设和定制化开发。当我们抛开研发效能业务本身去关注 DevMind 内核时，可以发现它更接近于一个通用的数字解决方案。DevMind 平台背后的产品理念和技术架构，完全可以低成本地转换为任意一个垂类业务场景的数字化解决方案。
为了保证研发效能提升的飞轮持续转动，达到超越业务的技术目标，DevMind 在技术方面面临着以下五大挑战。
图 2-1
在 DevMind 平台建设之初，确立了产品建设的三大原则及相应的关键步骤。这三大原则分别是：以 ADLM 为业务目标，以数据中台为整体技术架构，以 ABI 为产品内核。对应的三个关键步骤分别是：构建在线的 ADLM 全域数仓，关注全局、关注结果，警惕局部优化的陷阱；通过指标中台和业务映射的方式实现对数据资产的沉淀；消除指标口径的歧义。
图 2-2
DevMind 整体技术架构按照业务目标可划分为“一横一竖”两大方向。
横向架构源自数据生命周期，用数据中台模式构建整个底层基座，其中包含数据采集、数据定义、数据消费。
纵向架构是 DevMind 产品本身的技术架构，可以分为两层，上层是直接面向终端用户的平台能力，下层是“乐高化”的基建模块。
图 3-1
从数据分析的视角来看，数据的一生会经历三个阶段：数据采集、数据定义和数据消费。
DevMind 需要逐个平台进行对接，这需要大量沟通协调的工作。例如，字节跳动内部有近十个 OnCall 反馈类平台，DevMind 需要耗费大量精力分别和各 OnCall 平台沟通数据接入，并实现数据维度对齐。此外各个源平台性质不同，采集方式也有较大差异。例如：对于客户端监控数据，其每日上报的原始数据可达 100+TB，因此需要基于 Flink 进行流式写入；而对于配置类平台，如果不提供相应的 Hive 数仓或 OpenAPI，就需要监听、捕获、更新数据。数据采集 ETL 的过程不仅仅是将原始数据写入 ODS 表，还需要深刻理解业务背景和数据源特性，完成从 ODS 表到 DW 表的转录。
指标定义基于指标中台体现，指标中台的核心在于元信息数据模型设计，对其最重要的要求是：强悍且可扩展的数据表达能力。为了实现这个要求，需要对数据模型进行分层解耦的模块化设计，并保证每层模型均是结构化的。
业务模型是对物质世界的一种抽象，指标中台的数据模型是对底层存储引擎的一种抽象。目前公司主流的存储引擎有：基于 SQL 查询的关系数据库 (如 MySQL、ClickHouse)、图数据库，以及通过 OpenAPI 开放的各类数据平台 (如 DataRocks、Metrics、VCloud)。
在基础信息层之上是元指标层 (Meta-Metric Module)。元指标在物理意义上是指可被存储引擎执行的业务单元，例如关系数据库中的 SQL 语言、图数据库中的 Gremlin 语言。元指标与存储引擎交互后获得代数结果。业界指标中台元信息的记录通常止步于基础信息层相关数据的元信息。但是，指标中台最终是为上层的数据分析服务的。而随着分析的深入，数据分析师们会引入愈发复杂的数据模型和算法。设计元指标层的目标就是有效地管理这些复杂模型和算法的元信息。
图 3-2
此处数据消费不仅指数据分析，还包括数据运营。在数据运营活动中，首先会明确目标，并以 SMART 原则构建目标的北极星指标。围绕北极星指标，再构建相应的数据指标体系，并以定量化的方式指导和推动业务落地。例如，DevMind-Insight 模块不仅是在线化分析报告，还涵盖了评论、任务录入、问题反馈等管理协作功能。
图 3-3
DevMind 在产品功能上分为 Insight、Measure、Platform、Nudge 四大模块。其中，Platform 承担数据生命周期中指标 / 数据定义的任务，Measure、Insight、Nudge 分别对应数据生命周期中数据消费的描述、分析、行动三个步骤。在技术上。四个模块的具体功能是平台能力层原子能力的封装展现，例如「指标」这一元信息会串联起所有模块。
洞察（Insight）：用于研发管理辅助，以报告为中心输出洞察内容。由专家基于指标完成主题的聚合，将内容“汇报”给业务方，并让用户基于报告管理团队、跟踪改进任务。
度量（Measure）：用于数据可视化分析和监控大盘的搭建，以丰富的数据可视化表达能力帮助专家对数据进行深入探查和分析。
指标中台（Platform）：用于数据资产的建设和沉淀，进而降低生产者用户和消费者用户管数、取数、用数的门槛。
助推（Nudge）：用于研发过程辅助，在研发过程中提示风险和问题，并辅助解决，消除研发过程中等待和浪费时间，帮助一线研发人员更好、更顺畅地完成工作。
在设计之初，DevMind 已经意识到，在对即席查询引擎的需求中，唯一不变的就是变化本身。设计过程中会遇到表达能力的挑战、性能的挑战、数据一致性的挑战，以及业务定制化需求腐蚀的挑战。因此在设计时，遵循高内聚、低耦合的中台化分层架构，同时通过 Middleware、UDF 等手段将定制化需求的熵增控制在有限的范围内。
即席查询引擎架构从下到上可以分为：可插拔的异构存储层、屏蔽方言差异的数据查询层、承载表达能力的内存计算层。
图 4-1
可插拔的异构存储设计，使数据选型得以在业务、数据、效率三者之间寻得平衡点。当前引擎支持 SQL 类、OpenAPI 类两大存储，未来还将支持 Graph、NoSQL 两大类。SQL 类因各数据库支持的 SQL 方言不同，进一步细分为 MySQL、ClickHouse、Slardar-Veno；OpenAPI 类支持 DataRocks、Tea、Metrics 等公司内部平台所开放的各类 OpenAPI。
SQL-Manager 的设计目标，是希望通过利用自建查询层获得更丰富的数据表达能力、更良好的查询性能，以及更精细化的业务控制。SQL-Manager 的执行过程可分为串行的五个模块，分别是解析器 Parser、分析器 Analyzer、重建器 Rebuilder、优化器 Optimizer 和重写器 Rewriter。解析器通过 Antlr4 实现，将内存计算层的查询语言重新构建成 AST 抽象语法树。分析器将识别语法树中的业务逻辑，并完成相关处理。例如，DevMind 的 Cube 算子查询和 VirtualTable 改写就是在分析器中完成的。重建器用于标准 SQL 的构造及相关业务逻辑的拼接。优化器用于实现查询加速，最典型的场景是在多重查询场景中，实现算子下推。最后是重写器，负责将标准 SQL 转换为存储物理表 DB 对应的 SQL 方言。
图 4-2
内存计算层是数据可视化表达的核心，并为上层提供统一的查询语言。该层采用代数计算模型来突破 SQL 表达能力的边界，并以模块化的方式对外提供多种能力，其中在表达能力拓展上主要包括代数计算、Middleware 和 UDF 框架这三个部分。
代数计算：数据层返回的查询结果可以被视为一个标量或 N 阶向量的代数矩阵。当参与计算的矩阵各阶向量单位和量纲相同时，就能保证逻辑上的自洽。在内存计算层中，元指标 / 复合元指标均是纯粹的内存代数计算。其表达能力上限只受到当前模块支持的算术运算符和逻辑运算符的限制，因此理论上拥有近乎无限的表达能力。此外，纯内存代数计算非常适合为后续基于并行计算的计算加速。
Middleware：查询层注定会承接大量的定制化需求，而定制化需求往往是一个系统“腐败”的诱因。因此，需要在计算层增加 Middleware 结构，分为 Pre、Sub 两个部分，分别用于处理 Request 和 Response。通过 Middleware 结构将定制化需求从系统的核心逻辑中释放出来，进而提升引擎整体扩展性和可维护性。
UDF 框架：UDF 框架的设计目标是在内存计算层中提供一个统一的开发框架，令开发者可以通过低成本的框架实现各自的业务需求。
图 4-3
和 AIOps 不同，在数据分析场景中，辅助分析算法除了关注准确率和召回率，还需关注算法本身的可解释性和可验证性，从而降低理解成本，并提高结论的权威性。因此，在算法设计过程中，DevMind 将重新回归到经典的数理统计方法。
潜力分析是指在指标分析场景中，找出某个确定维度的维度项，改变它能对指标大盘产生最大的影响。
维度分项潜力值 = 维度分项贡献度 × 均值回归系数 × 稀疏维度处理
维度分项贡献度是指目标指标各维度的维度分项对大盘影响的贡献度。此处引入潜力分析的第一个假设：高占比项提升，使指定维度的各维度项变化同一固定比率，则高占比维度项对大盘的影响更大。
均值回归系数源于潜力分析的第二个假设：均值回归，也就是假设维度分项数值都将围绕维度均值波动，波动趋近于均值的概率要高于背离均值的概率。同时，假设维度分项数值距离其均值越远，回归的概率越高。基于上述两点，算法设计了均值回归系数，且经过概率密度函数归一化处理。
对于稀疏维度处理，举例说明，在分析 DAU 贡献度时，容易发现“性别”这一维度的维度分项贡献度会显著高于“城市”维度的维度分项贡献度。这是一个完全正确但是没有太多价值的发现，稀疏维度处理就是为了减少这类情况对分析结果的影响。
在分析简单的数值型指标（如 DAU）时，常规的分析方式是首先进行维度分解，然后进行后续分析操作，例如贡献度计算、基尼系数计算。但是比率型指标具有不可加性的特点，不能直接进行维度分解。其不可加性的一个体现是除法对数值量纲的抵消，例如，大除大、小除小结果的量纲可能是相同的，而大除小、小除大的差异会被放大。此外，对于除法型复合指标还有另外一个问题——分子分母维度不对齐。
以每日客户端崩溃率 = 每日崩溃客户端数 ÷ 客户端 DAU 为例，每日崩溃客户端数包含特有维度崩溃类型，客户端 DAU 包含特有维度机型分档。贡献度的核心假设是不同分项对大盘整体的影响不同。该假设与目标指标算子无关，因此对比率型指标进行合适的换算仍然适用于贡献度分析。为便于理解，此处引入代数向量空间的概念做进一步解释。
在对研发效能领域进行数据分析时，不可避免地会涉及一些敏感数据。如果放任对敏感数据的滥用，那么极易造成潜在危机。就如同一个摆满瓷器的房间里，静静地站着一只灰犀牛，虽然此时此刻还没有一个瓷盘掉落在地，但整个房间被走动的灰犀牛摧毁是一个大概率会发生的事件。如何在确保在数据使用绝对安全合规的前提下，提高数据分析的效率呢？
图 4-4
元指标的定义：元指标是指拥有完备业务含义且可独立执行的结构化表达式，其运行结果是带有物理含义的代数矩阵。其中，通过维度的数量来划分元指标的阶次。没有维度的元指标称为标量元指标，带有维度信息指标称为向量元指标，根据维度数量分为一阶向量、二阶向量等，如图 5-1 所示。
元指标的意义：与传统的 SQL 类 BI 平台生产侧交互逻辑围绕数据源展开所不同，在 DevMind 产品设计中，转为以元指标为核心的声明式表达。元指标的引入可以将整个数据分析过程从单一的数据分析师拆分为两个角色——负责指标生产的领域专家和负责数据分析的业务方。角色职责的内聚将有效提高数据分析全流程的效率。
在 DevMind 中正式使用元指标的概念时，遵循约定优于配置的原则，制定了两条基本约定。
约定一：元指标必须带有时间范围修饰词，且位于特征第一位，且在后续注入维度的第一位。
约定二：在配置元指标时需要指定度量对象修饰词，并由 DevMind 在消费场景中动态注入。
图 5-1
(复合) 元指标的定义：因为元指标的运行结果是带有物理含义的代数矩阵，因此从数学上理解，维度数相同且各阶维度单位及量纲相同的元指标可以进行代数运算。在业务上的约束则更为宽松，只要参与计算的两个元指标之一是另一方的全集，即可进行运算。因此，DevMind 将 (复合) 元指标定义为，由一个或若干个 (复合) 元指标经算术运算符或逻辑运算符组合而成的元指标。
(复合) 元指标的意义：基于 (复合) 元指标，任何复杂的业务建模过程都可被视为纯粹的数学表达，因此其可以获得近乎无限的表达能力。
数据是对业务的客观记录，数据模型是对业务模型的高层抽象，数据仓库分层则是对数据架构的解耦，从而保持清晰的数据结构。
离线数仓的建设都围绕着 DW 层，尤其是以 DWD 层为核心展开。离线层弱化了 DM 层作用，且几乎没有 ADS，同时维护公共 DIM 层串联全局链路。离线层的“弱 DM、轻 ADS”并不代表 DevMind 团队不认可三层六类的数仓分层设计，而是 DevMind 着重建设在线查询层，通过应用层物化视图、VirtualTable 等方式代偿了离线数仓 ADS、DM 层的能力。此外，为了加快查询速度，DevMind 实现了多种查询加速方式。
条件下推和剪枝：业务发展的趋势表达能力→导致查询复杂→耗时增长。为了打破这个链条，在 SQL-Manager 优化器部分开发了算子下推、谓词下推能力。在自卷积及 VirtualTable 场景中，将查询条件下推，以此减少查询整体的 Scan 数据量。
Local/Short/Long Cache：缓存是查询引擎的必备组件之一。为了提高缓存命中率，根据下游数据源类型，为缓存时间设置了 Short/Long TTL 两种策略。
应用层物化视图：大数据消费的一个主要难点在于，无限灵活的大数据消费场景和有限而昂贵的存储计算资源之间的矛盾。为此，在引擎中增加了应用层物化视图功能，由上层业务方显式开启，以此满足为特定目标数据的长期趋势构建图表进行可视化观察的需求。
业务层预刷：针对诊断报告、管理驾驶舱等高价值、大计算量场景，需采用更精细化的预刷缓存策略，在性能上要求达到亚秒级响应、秒级呈现。
除了减少数仓人力开销、降低维护成本等收益之外，以在线化为主的数仓建设方式的最大优点是，成功实现了将数据资产沉淀在指标上而非固化到数据集中。传统的将北极星指标固化到数据集中的做法实际是不够直观的，整个维护链路冗长，并且容易脱离关键生产链路。任何数据资产如果只是作为旁路记录，而不能真正参与到生产环境中，就注定会过期腐化。
图 5-2
现代工业化生产涉及流水线设计、供应链管理、进销存管理等多个方面。ERP 系统设计是为了帮助组织自动度量和管理核心业务流程，从而实现最优表现。ERP 系统通过协调公司中各个业务流程之间的数据流，提供单一事实源，并简化整个企业运营流程。
大型软件研发流程有其复杂性，但并没有显著的证据证明其复杂度远高于其他工业领域。为什么互联网行业并没有诞生类似于 ERP 系统的系统性应用研发流程度量解决方案呢？一个可能的原因在于工业界的流程和环节的建设周期相对较长，针对一条产品线定制化建设一套 ERP 系统的边际成本较低。同时，通过一些 Low-Code 解决方案能够进一步降低构建成本。但是对于互联网应用软件研发流程来说，其软件开发的本质是人与人之间的协作，而非流水线节点之间的桥接。因此，应用软件研发生命周期各个环节所构建的 DAG 图，不可避免地具有易变性和多样性。
图 6-1
在字节跳动的实践中，DevMind 将应用软件研发流程的业务模型抽象到三个层次——需求、技术栈、成员。例如，一个“评论支持点赞功能”的需求涉及 iOS、Android 两个技术栈，其中，iOS 由张三、李四两位同学负责，Android 是由小 A、小 B、小 C 三位同学负责。上述是 DevMind 在流程度量模型中的最简表达形式，其中的里程碑节点、阶段耗时、工作量都可以在三个层次中分别表达。
图 6-2
DevMind 设计的目标是转动研发效能提升的飞轮，因此不仅要解决问题，还要降低解决方案的使用成本，直到普通生产者用户可以承受为止。针对 DAG 场景，DevMind 提出了一种超越范式的系统性解决方案。这个方案也很好地体现了 DevMind 通过对数据生产分析全链路的掌控，降低终端用户使用成本的实践思路。
图 6-3
除此之外，DevMind 在多个业务场景中运用了基于数据生产分析全链路掌控力，将整体成本左移的方案。例如，DevMind 基于 Cube 模型的超大规模数据在线分析方案。
图 6-4
DevMind 同样将全过程分为三步：模型设计、指标定义、数据消费。在模型设计过程中，设计者确定 Cube 粒度，以及涉及的维度组合。在数据生产过程中，完成所指定的 Cube 粒度聚合和剪枝优化；在指标定义时，定义者仅会基于已有的组合进行指标和维度设计；在数据消费阶段，用户自助分析时由即席查询引擎自动注入 CuboID，从而使用户（消费者）无须感知底层模型的复杂性。
图 6-5
在研发效能分析场景中，度量对象通常是树形结构，例如部门、组织架构、汇报关系等。同时，因为公司组织架构调整、人员离职 / 入职均会对树形结构产生影响，因此如果仅选择一个时间切面进行分析，无法反映真实情况。因此，算法不仅要考虑树形结构中父子节点的空间关系，还需兼顾父子节点的时效关系。
为便于理解，此处举一个情景化的例子。某研发团队负责人小 A 通知下属业务线负责人小 B 和小 C，需要统计这两个团队 7 月的 BUG 数。小 B 团队的小 D 在 7 月引入 5 个 BUG。小 B 团队的小 E 在 7 月共引入 4 个 BUG，其中 1 个 BUG 是在 7 月 1 日引入的，另外 3 个是 7 月 8 日转岗到小 C 团队后引入的。小 C 团队的小 F 和小 G 在 7 月分别引入 4 个 BUG。因此在 7 月，小 B 团队共引入 6 个 BUG，而小 C 团队引入 11 个 BUG。
图 6-6
在研发效能度量过程时，切忌基于数值型指标直接进行比较。在上述例子里，小 C 团队的 BUG 数看上去要远多于小 B 团队，但如果将度量视角从“团队 BUG 数”切换到“团队人均 BUG 数”，就会得出另一个结论。虽然软件研发是强创造性的脑力劳动，但基于均值回归假设，DevMind 假定百人以上的研发团队的产出与人数是强相关的。基于上述假设，DevMind 将团队成员理论可到岗天数之和作为团队人均类指标的分母。在例子中，7 月 1 日至 7 月 7 日共 5 个工作日，7 月 8 日至 7 月 31 日共 15 个工作日。因此，小 E 在小 B 团队是 0.25 人力，而在小 C 团队是 0.75 人力。最终，小 C 团队的人均 BUG 数是 4，而小 B 团队的人均 BUG 数则达到 4.8。
图 6-7
技术侧迭代发展规划首先不能脱离业务需求场景，没有业务落地场景和业务收益支撑的技术方案，只能是闭门造车、无法落地。其次，DevMind 实质上是一种通用的数字化解决方案，其底层的数据中台模式和 ABI 产品内核为后续技术演进提供了良好的基础。面对上层的 ADLM 研发效能度量业务域和下层的数据中台模式，DevMind 提出了“工型战略”。工型战略意为：在上横业务场景和下横架构底座之间，发展业务亟需的各类垂直技术能力，在多个不同领域的单点分别突破，取得收益后再持续演进，最后在演进过程中实现技术点的交叉，从而连点成面。
在可预见的未来，DevMind 技术驱动业务增长三驾马车分别是：即席查询引擎、数据科学、图分析。
图 7-1
本文虽着眼于字节跳动研发效能平台 DevMind 的技术发展历程，但希望借此能为广大读者朋友提供一份普适的数字化解决方案。
通过高内聚低耦合的设计来应对无限多变的业务场景，是度量团队立项之初的野望。也正因为此，我们选择了数据中台模式实现数据资产沉淀，数据生产消费全链路解决方案消解复杂业务分析场景。我们也因此洞见了降低普通用户数据分析门槛后所带来的巨大业务价值。此外，DevMind 其 SaaS 化的产品架构设计，也为其提供了第二增长曲线的可能。This would be another story。
