從 2010 年團購的百團大戰開始，國內的眾多公司創始人、投資者就將里德 · 霍夫曼的《閃電式擴張》一書奉為圭臬，而《閃電式擴張》中的預言也在中國市場中得以驗證并升華。《閃電式擴張》所信奉的是“Prioritizing speed over efficiency in the face of uncertainty”，即“面對巨大的不確定性，速度遠優于效率”，明確表達了“將效率讓位于發展速度和規模”。因此，資本市場熱衷于押注藍海賽道而不僅僅是單一企業；企業內部奉行“賽馬機制”，在同一方向安排多個獨立團隊，以此提高整體的最終勝率。此外，企業在團隊建設上也會放寬 HC 預算，為未來潛在增長點提供人才儲備。

對于增量市場，或者說憑空創造一個市場的巨大誘惑，令各級資本市場為互聯網垂類市場競爭投入近乎無限的彈藥，同時也讓企業競爭變得格外殘酷。這種競爭壓力容易誘發企業在內部管理上的“墊腳效應”。

回顧近些年來互聯網行業的業務發展，社區團購之于團購、共享單車之于共享打車，它們雖仍有海量資金投入，但已無乾坤再造之功。

高頻次、低毛利只是社區團購和共享單車在業務上的共同點，更深層次的則是二者在各自大業務鏈路中處于相同的生態位。在生態位上，二者實際都無法成為獨立閉環的市場，而只能是對已有業務的延續。例如，共享單車的上游是出行業務，下游是 LBS 業務，上下游兩個行業的龍頭企業都希望通過這個高頻業務場景鏈接自身業務，甚至反向進入對方領域。

當閃電式擴張的戰役目標從再造一個市場到構建已有業務的拒馬時，我們可以認為，資本意義上的互聯網下半場已經來臨。對于互聯網下半場來說，存量市場競爭會有兩個顯著特征：第一，在業務形態上找尋高處的果實，例如 toB、XR etc；第二，企業戰略從擴大再生產、追求規模和占有率，轉向提高利潤率、增強自身造血能力。前者依靠戰略和洞見，具有很強的不確定性；后者則更明確且易用。因此，后者被當前的企業廣泛采用，具體做法都是指向提升效率、提高 ROI，具體到應用研發環節，則是對研發效能提升的強烈訴求。正如彼得德魯克所說，“If you can't measure it, you can't manage it ”，這令研發效能度量這一課題重新回到聚光燈下。

今天這篇文章將詳細介紹字節跳動研發效能核心技術，希望能以字節跳動度量平臺 DevMind 為例，為企業內部的數字化場景提供具有參考價值的分析思路和解決方案。

以下是字節跳動研發效能度量核心技術分享。

困境與破局

1.1 建設背景

字節跳動研發效能度量團隊成立于 2020 年 6 月。回望當時的時間節點，直到 2020 年年初仍然沒有一款面向全公司的、服務于研發全周期的數字化產品。研發鏈路的相關數據散落在各個研發工具內部，各條業務線都有一個或多個類似的定制化看板產品，只用于度量各自業務的研發效率和質量。因為缺乏公司級的數倉建設，不同業務線間的研發效能情況無法橫向比較，甚至在一個業務線內的不同部門，對同一個指標都有著不同的口徑定義。因此，在公司內部對研發效能度量有三大訴求：首先，完成整個軟件研發生命周期數據數倉的統一建設；其次，梳理指標口徑定義，確保業務線內部可以統一“北極星指標”，并在公司層面大業務線間實現橫向比較；最后，基于度量發現問題并提出解決方案，推動業務方優化。

1.2 軟件研發效能度量及其難點

軟件研發效能度量的第一大難點在于“軟件研發效能”這一研究課題本身。“軟件研發效能”涉及軟件研發鏈路中的每個環節，同時包含現代企業內部管理協作模式和業務收益評估等多個課題。在這一母題之下，每個環節都有其獨有的領域知識門檻，同時各個環節之間又有著千絲萬縷的聯系。在度量的過程中稍有不慎，就會令業務囿于局部優化的陷阱之中。

軟件研發效能度量的第二大難點在于開發流程的靈活性。現代工業化生產鏈路雖然復雜，但是在確認生產模式后并不會頻繁變更，因此 ERP 可以定制化構建生產過程的度量系統。軟件開發過程主要依賴團隊間不同角色的分工協作，在這種多方參與的腦力勞動中，很容易出現復雜的環節依賴，而這些流程依賴又極具多樣性和易變性。字節跳動研發團隊需求流程管理都是通過字節自研的項目管理工具進行的。字節項目管理工具的一大產品特色是能夠使管理員用戶低成本的完成需求節點流程模板的配置，因此各業務研發團隊都會基于自身特點配置不同的需求流程模板。

軟件研發效能度量的第三大難點是其交付結果投入高、收益計算復雜。軟件最終交付件是完全非標準化的，且通常不會重復完成的項目。即使有 A/B 實驗的加持，其數學原理也只能解釋單一需求的指標組變化，難以準確計算指定團隊整體的業務收益。在對團隊或者個體進行度量時，度量對象規模越小，則指標可靠性越會迅速劣化。

1.3 轉動效能提升的飛輪

研發效能提升是每一個研發團隊所追求的，但實際情況是，當某一效能問題成長為“屋里的灰犀牛”后，它才被人們真正重視。在常見的研發效能提升活動中，研發團隊通常會以某只“灰犀牛”為目標——團隊驅動自身進行流程和方案的改進，進而打贏這場有限的游戲。人們都知道，研發效能提升是一場持續精進的“修行”，卻只能用一場場有限的游戲去對抗熵增。就像拉姆斯菲爾德在“未知的未知”言論里提到的那樣，研發效能這一母題本身幽暗而深邃，限制效能的瓶頸、提升效能的方法都隱匿在未知的未知之中。字節跳動的研發團隊希望能夠通過轉動效能提升的飛輪，讓研發效能提升成為一場無限的游戲。在這個過程中，字節跳動轉動了兩個飛輪：協作的飛輪和價值的飛輪。

1.3.1 協作的飛輪

在這場游戲中，字節跳動構建一個令三位玩家高效協作的生態模式。首先是在業務方和效能專家之間，業務方對效能專家提出其具體效能提升的訴求，而效能專家基于經驗和分析給出專項解決方案，并在業務方改進過程中持續參與，以此幫助業務方落地并打磨自身方案；其次是效能專家和度量平臺，效能專家在平臺中進行業務全域數據的洞察分析，而平臺在效能改進方案落地后，將成功案例沉淀到平臺的專家系統中；最后是業務方和度量平臺，業務方將度量平臺作為管理運營監控的工具，以衡量改進效果，度量平臺通過業務方的使用不斷優化業務指標口徑精度。在協作的飛輪轉動的過程中，業務方可以獲得研發效能的提升，效能專家可以打磨其效能提升方法模型，度量平臺在對功能的迭代過程中使平臺能力更加完備。

圖 1-1

1.3.2 價值的飛輪

第二個飛輪是價值的飛輪。度量本身并不創造價值，只有洞察后的效能提升才真正為業務創造長期價值。“獵殺屋里的灰犀牛”的價值是不言而喻的，但更重要的是以長期業務價值為北極星，轉動研發效能提升價值的飛輪。在這個飛輪中，有兩大摩擦力：第一個是業務研發團隊的配合參與度，也就是論證長期業務價值和短期資源投入，以及研發習慣重塑之間的 ROI；第二個是如何高效搜尋更多的灰犀牛，最好是做到“除之于未有型”。字節跳動以研發效能度量團隊作為效能提升飛輪的發動機，由供給側驅動飛輪的高速運轉。

圖 1-2

挑戰與原則

研發效能母題的龐雜深邃，因而在 DevMind 的產品設計過程中，我們懷有足夠的敬畏之心。也正是因為這份克制，DevMind 本身并沒有做過多的業務假設和定制化開發。當我們拋開研發效能業務本身去關注 DevMind 內核時，可以發現它更接近于一個通用的數字解決方案。DevMind 平臺背后的產品理念和技術架構，完全可以低成本地轉換為任意一個垂類業務場景的數字化解決方案。

2.1 五大挑戰

為了保證研發效能提升的飛輪持續轉動，達到超越業務的技術目標，DevMind 在技術方面面臨著以下五大挑戰。

圖 2-1

2.2 三項原則

在 DevMind 平臺建設之初，確立了產品建設的三大原則及相應的關鍵步驟。這三大原則分別是：以 ADLM 為業務目標，以數據中臺為整體技術架構，以 ABI 為產品內核。對應的三個關鍵步驟分別是：構建在線的 ADLM 全域數倉，關注全局、關注結果，警惕局部優化的陷阱；通過指標中臺和業務映射的方式實現對數據資產的沉淀；消除指標口徑的歧義。

圖 2-2

架構設計

DevMind 整體技術架構按照業務目標可劃分為“一橫一豎”兩大方向。

橫向架構源自數據生命周期，用數據中臺模式構建整個底層基座，其中包含數據采集、數據定義、數據消費。

縱向架構是 DevMind 產品本身的技術架構，可以分為兩層，上層是直接面向終端用戶的平臺能力，下層是“樂高化”的基建模塊。

圖 3-1

3.1 橫向數據生命周期

從數據分析的視角來看，數據的一生會經歷三個階段：數據采集、數據定義和數據消費。

3.1.1 數據采集 ETL

DevMind 需要逐個平臺進行對接，這需要大量溝通協調的工作。例如，字節跳動內部有近十個 OnCall 反饋類平臺，DevMind 需要耗費大量精力分別和各 OnCall 平臺溝通數據接入，并實現數據維度對齊。此外各個源平臺性質不同，采集方式也有較大差異。例如：對于客戶端監控數據，其每日上報的原始數據可達 100 TB，因此需要基于 Flink 進行流式寫入；而對于配置類平臺，如果不提供相應的 Hive 數倉或 OpenAPI，就需要監聽、捕獲、更新數據。數據采集 ETL 的過程不僅僅是將原始數據寫入 ODS 表，還需要深刻理解業務背景和數據源特性，完成從 ODS 表到 DW 表的轉錄。

3.1.2 數據定義

指標定義基于指標中臺體現，指標中臺的核心在于元信息數據模型設計，對其最重要的要求是：強悍且可擴展的數據表達能力。為了實現這個要求，需要對數據模型進行分層解耦的模塊化設計，并保證每層模型均是結構化的。

業務模型是對物質世界的一種抽象，指標中臺的數據模型是對底層存儲引擎的一種抽象。目前公司主流的存儲引擎有：基于 SQL 查詢的關系數據庫 (如 MySQL、ClickHouse)、圖數據庫，以及通過 OpenAPI 開放的各類數據平臺 (如 DataRocks、Metrics、VCloud)。

在基礎信息層之上是元指標層 (Meta-Metric Module)。元指標在物理意義上是指可被存儲引擎執行的業務單元，例如關系數據庫中的 SQL 語言、圖數據庫中的 Gremlin 語言。元指標與存儲引擎交互后獲得代數結果。業界指標中臺元信息的記錄通常止步于基礎信息層相關數據的元信息。但是，指標中臺最終是為上層的數據分析服務的。而隨著分析的深入，數據分析師們會引入愈發復雜的數據模型和算法。設計元指標層的目標就是有效地管理這些復雜模型和算法的元信息。

圖 3-2

3.1.3 數據消費

此處數據消費不僅指數據分析，還包括數據運營。在數據運營活動中，首先會明確目標，并以 SMART 原則構建目標的北極星指標。圍繞北極星指標，再構建相應的數據指標體系，并以定量化的方式指導和推動業務落地。例如，DevMind-Insight 模塊不僅是在線化分析報告，還涵蓋了評論、任務錄入、問題反饋等管理協作功能。

3.2 縱向產品功能分層

圖 3-3

DevMind 在產品功能上分為 Insight、Measure、Platform、Nudge 四大模塊。其中，Platform 承擔數據生命周期中指標 / 數據定義的任務，Measure、Insight、Nudge 分別對應數據生命周期中數據消費的描述、分析、行動三個步驟。在技術上。四個模塊的具體功能是平臺能力層原子能力的封裝展現，例如「指標」這一元信息會串聯起所有模塊。

• 洞察（Insight）：用于研發管理輔助，以報告為中心輸出洞察內容。由專家基于指標完成主題的聚合，將內容“匯報”給業務方，并讓用戶基于報告管理團隊、跟蹤改進任務。
• 度量（Measure）：用于數據可視化分析和監控大盤的搭建，以豐富的數據可視化表達能力幫助專家對數據進行深入探查和分析。
• 指標中臺（Platform）：用于數據資產的建設和沉淀，進而降低生產者用戶和消費者用戶管數、取數、用數的門檻。
• 助推（Nudge）：用于研發過程輔助，在研發過程中提示風險和問題，并輔助解決，消除研發過程中等待和浪費時間，幫助一線研發人員更好、更順暢地完成工作。

平臺層技術要點

4.1 即席查詢引擎

在設計之初，DevMind 已經意識到，在對即席查詢引擎的需求中，唯一不變的就是變化本身。設計過程中會遇到表達能力的挑戰、性能的挑戰、數據一致性的挑戰，以及業務定制化需求腐蝕的挑戰。因此在設計時，遵循高內聚、低耦合的中臺化分層架構，同時通過 Middleware、UDF 等手段將定制化需求的熵增控制在有限的范圍內。

即席查詢引擎架構從下到上可以分為：可插拔的異構存儲層、屏蔽方言差異的數據查詢層、承載表達能力的內存計算層。

圖 4-1

4.1.1 異構存儲層

可插拔的異構存儲設計，使數據選型得以在業務、數據、效率三者之間尋得平衡點。當前引擎支持 SQL 類、OpenAPI 類兩大存儲，未來還將支持 Graph、NoSQL 兩大類。SQL 類因各數據庫支持的 SQL 方言不同，進一步細分為 MySQL、ClickHouse、Slardar-Veno；OpenAPI 類支持 DataRocks、Tea、Metrics 等公司內部平臺所開放的各類 OpenAPI。

4.1.2 數據查詢層

SQL-Manager 的設計目標，是希望通過利用自建查詢層獲得更豐富的數據表達能力、更良好的查詢性能，以及更精細化的業務控制。SQL-Manager 的執行過程可分為串行的五個模塊，分別是解析器 Parser、分析器 Analyzer、重建器 Rebuilder、優化器 Optimizer 和重寫器 Rewriter。解析器通過 Antlr4 實現，將內存計算層的查詢語言重新構建成 AST 抽象語法樹。分析器將識別語法樹中的業務邏輯，并完成相關處理。例如，DevMind 的 Cube 算子查詢和 VirtualTable 改寫就是在分析器中完成的。重建器用于標準 SQL 的構造及相關業務邏輯的拼接。優化器用于實現查詢加速，最典型的場景是在多重查詢場景中，實現算子下推。最后是重寫器，負責將標準 SQL 轉換為存儲物理表 DB 對應的 SQL 方言。

圖 4-2

4.1.3 內存計算層

內存計算層是數據可視化表達的核心，并為上層提供統一的查詢語言。該層采用代數計算模型來突破 SQL 表達能力的邊界，并以模塊化的方式對外提供多種能力，其中在表達能力拓展上主要包括代數計算、Middleware 和 UDF 框架這三個部分。

• 代數計算：數據層返回的查詢結果可以被視為一個標量或 N 階向量的代數矩陣。當參與計算的矩陣各階向量單位和量綱相同時，就能保證邏輯上的自洽。在內存計算層中，元指標 / 復合元指標均是純粹的內存代數計算。其表達能力上限只受到當前模塊支持的算術運算符和邏輯運算符的限制，因此理論上擁有近乎無限的表達能力。此外，純內存代數計算非常適合為后續基于并行計算的計算加速。
• Middleware：查詢層注定會承接大量的定制化需求，而定制化需求往往是一個系統“腐敗”的誘因。因此，需要在計算層增加 Middleware 結構，分為 Pre、Sub 兩個部分，分別用于處理 Request 和 Response。通過 Middleware 結構將定制化需求從系統的核心邏輯中釋放出來，進而提升引擎整體擴展性和可維護性。
• UDF 框架：UDF 框架的設計目標是在內存計算層中提供一個統一的開發框架，令開發者可以通過低成本的框架實現各自的業務需求。

圖 4-3

4.2 輔助分析算法

和 AIOps 不同，在數據分析場景中，輔助分析算法除了關注準確率和召回率，還需關注算法本身的可解釋性和可驗證性，從而降低理解成本，并提高結論的權威性。因此，在算法設計過程中，DevMind 將重新回歸到經典的數理統計方法。

4.2.1 潛力分析

潛力分析是指在指標分析場景中，找出某個確定維度的維度項，改變它能對指標大盤產生最大的影響。

維度分項潛力值 = 維度分項貢獻度 × 均值回歸系數 × 稀疏維度處理

• 維度分項貢獻度是指目標指標各維度的維度分項對大盤影響的貢獻度。此處引入潛力分析的第一個假設：高占比項提升，使指定維度的各維度項變化同一固定比率，則高占比維度項對大盤的影響更大。
• 均值回歸系數源于潛力分析的第二個假設：均值回歸，也就是假設維度分項數值都將圍繞維度均值波動，波動趨近于均值的概率要高于背離均值的概率。同時，假設維度分項數值距離其均值越遠，回歸的概率越高。基于上述兩點，算法設計了均值回歸系數，且經過概率密度函數歸一化處理。
• 對于稀疏維度處理，舉例說明，在分析 DAU 貢獻度時，容易發現“性別”這一維度的維度分項貢獻度會顯著高于“城市”維度的維度分項貢獻度。這是一個完全正確但是沒有太多價值的發現，稀疏維度處理就是為了減少這類情況對分析結果的影響。

4.2.2 比率型指標歸因

在分析簡單的數值型指標（如 DAU）時，常規的分析方式是首先進行維度分解，然后進行后續分析操作，例如貢獻度計算、基尼系數計算。但是比率型指標具有不可加性的特點，不能直接進行維度分解。其不可加性的一個體現是除法對數值量綱的抵消，例如，大除大、小除小結果的量綱可能是相同的，而大除小、小除大的差異會被放大。此外，對于除法型復合指標還有另外一個問題——分子分母維度不對齊。

以每日客戶端崩潰率 = 每日崩潰客戶端數 ÷ 客戶端 DAU 為例，每日崩潰客戶端數包含特有維度崩潰類型，客戶端 DAU 包含特有維度機型分檔。貢獻度的核心假設是不同分項對大盤整體的影響不同。該假設與目標指標算子無關，因此對比率型指標進行合適的換算仍然適用于貢獻度分析。為便于理解，此處引入代數向量空間的概念做進一步解釋。

4.3 房間里的灰犀牛——數據安全合規

在對研發效能領域進行數據分析時，不可避免地會涉及一些敏感數據。如果放任對敏感數據的濫用，那么極易造成潛在危機。就如同一個擺滿瓷器的房間里，靜靜地站著一只灰犀牛，雖然此時此刻還沒有一個瓷盤掉落在地，但整個房間被走動的灰犀牛摧毀是一個大概率會發生的事件。如何在確保在數據使用絕對安全合規的前提下，提高數據分析的效率呢？

圖 4-4

數據模型層技術要點

5.1 元指標

元指標的定義：元指標是指擁有完備業務含義且可獨立執行的結構化表達式，其運行結果是帶有物理含義的代數矩陣。其中，通過維度的數量來劃分元指標的階次。沒有維度的元指標稱為標量元指標，帶有維度信息指標稱為向量元指標，根據維度數量分為一階向量、二階向量等，如圖 5-1 所示。

元指標的意義：與傳統的 SQL 類 BI 平臺生產側交互邏輯圍繞數據源展開所不同，在 DevMind 產品設計中，轉為以元指標為核心的聲明式表達。元指標的引入可以將整個數據分析過程從單一的數據分析師拆分為兩個角色——負責指標生產的領域專家和負責數據分析的業務方。角色職責的內聚將有效提高數據分析全流程的效率。

在 DevMind 中正式使用元指標的概念時，遵循約定優于配置的原則，制定了兩條基本約定。

• 約定一：元指標必須帶有時間范圍修飾詞，且位于特征第一位，且在后續注入維度的第一位。
• 約定二：在配置元指標時需要指定度量對象修飾詞，并由 DevMind 在消費場景中動態注入。

圖 5-1

(復合) 元指標的定義：因為元指標的運行結果是帶有物理含義的代數矩陣，因此從數學上理解，維度數相同且各階維度單位及量綱相同的元指標可以進行代數運算。在業務上的約束則更為寬松，只要參與計算的兩個元指標之一是另一方的全集，即可進行運算。因此，DevMind 將 (復合) 元指標定義為，由一個或若干個 (復合) 元指標經算術運算符或邏輯運算符組合而成的元指標。

(復合) 元指標的意義：基于 (復合) 元指標，任何復雜的業務建模過程都可被視為純粹的數學表達，因此其可以獲得近乎無限的表達能力。

公式 5-1

5.2 數據倉庫建設

數據是對業務的客觀記錄，數據模型是對業務模型的高層抽象，數據倉庫分層則是對數據架構的解耦，從而保持清晰的數據結構。

離線數倉的建設都圍繞著 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

應用層技術要點

6.1 全鏈路解決方案

現代工業化生產涉及流水線設計、供應鏈管理、進銷存管理等多個方面。ERP 系統設計是為了幫助組織自動度量和管理核心業務流程，從而實現最優表現。ERP 系統通過協調公司中各個業務流程之間的數據流，提供單一事實源，并簡化整個企業運營流程。

6.1.1 應用研發流程度量場景拆解

大型軟件研發流程有其復雜性，但并沒有顯著的證據證明其復雜度遠高于其他工業領域。為什么互聯網行業并沒有誕生類似于 ERP 系統的系統性應用研發流程度量解決方案呢？一個可能的原因在于工業界的流程和環節的建設周期相對較長，針對一條產品線定制化建設一套 ERP 系統的邊際成本較低。同時，通過一些 Low-Code 解決方案能夠進一步降低構建成本。但是對于互聯網應用軟件研發流程來說，其軟件開發的本質是人與人之間的協作，而非流水線節點之間的橋接。因此，應用軟件研發生命周期各個環節所構建的 DAG 圖，不可避免地具有易變性和多樣性。

圖 6-1

在字節跳動的實踐中，DevMind 將應用軟件研發流程的業務模型抽象到三個層次——需求、技術棧、成員。例如，一個“評論支持點贊功能”的需求涉及 iOS、Android 兩個技術棧，其中，iOS 由張三、李四兩位同學負責，Android 是由小 A、小 B、小 C 三位同學負責。上述是 DevMind 在流程度量模型中的最簡表達形式，其中的里程碑節點、階段耗時、工作量都可以在三個層次中分別表達。

圖 6-2

6.1.2 DAG 場景全鏈路解決方案

DevMind 設計的目標是轉動研發效能提升的飛輪，因此不僅要解決問題，還要降低解決方案的使用成本，直到普通生產者用戶可以承受為止。針對 DAG 場景，DevMind 提出了一種超越范式的系統性解決方案。這個方案也很好地體現了 DevMind 通過對數據生產分析全鏈路的掌控，降低終端用戶使用成本的實踐思路。

圖 6-3

6.1.3 基于 Cube 模型全鏈路解決方案

除此之外，DevMind 在多個業務場景中運用了基于數據生產分析全鏈路掌控力，將整體成本左移的方案。例如，DevMind 基于 Cube 模型的超大規模數據在線分析方案。

圖 6-4

DevMind 同樣將全過程分為三步：模型設計、指標定義、數據消費。在模型設計過程中，設計者確定 Cube 粒度，以及涉及的維度組合。在數據生產過程中，完成所指定的 Cube 粒度聚合和剪枝優化；在指標定義時，定義者僅會基于已有的組合進行指標和維度設計；在數據消費階段，用戶自助分析時由即席查詢引擎自動注入 CuboID，從而使用戶（消費者）無須感知底層模型的復雜性。

圖 6-5

6.2 樹形結構查詢

在研發效能分析場景中，度量對象通常是樹形結構，例如部門、組織架構、匯報關系等。同時，因為公司組織架構調整、人員離職 / 入職均會對樹形結構產生影響，因此如果僅選擇一個時間切面進行分析，無法反映真實情況。因此，算法不僅要考慮樹形結構中父子節點的空間關系，還需兼顧父子節點的時效關系。

6.2.1 場景案例

為便于理解，此處舉一個情景化的例子。某研發團隊負責人小 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。

作者 | 姜磊，字節跳動效能度量平臺（DevMind）技術負責人