01.引言
在之前的一系列文章中，我們已經深入地探討了研發效能洞察的重要性，并介紹了幾種常用的度量分析方法。然而在度量實踐的過程中，僅僅依靠理論框架是不夠的，我們還需要將這些理論與企業的實際情況相結合。在這個過程中，企業常常面臨著各種問題：比如，難以采集分散在多個系統中的關鍵數據；難以滿足業務發展中頻繁調整指標的需求以及難以對不同部門的數據權限進行隔離等。
因此，我們需要一個度量平臺，它能夠自動采集多個系統的數據，可以通過配置的方式快速修改指標，并且能夠實現精細化的權限控制等。在本章中，我們將詳細地描述效能洞察的建設過程，并進一步討論在實施效能度量中常見的問題，以幫助大家更好地了解一個良好的度量平臺所需具備的關鍵能力及其背后的原因，為企業提供一個全面了解和合理運用效能度量平臺的指南。
02.度量建設的常見步驟
首先，我們來詳細了解一下度量建設的常見步驟。
1）需求調研階段
在這一階段，我們需要了解用戶的原始度量訴求以及度量目標，并與客戶溝通是否已有所需度量的指標清單。若客戶對度量需求的概念較為模糊，暫不清楚如何開始度量體系的建設，我們可以按照指標拆解方法進行梳理和引導。最終，需要輸出一份詳細的指標清單文檔。該指標清單通常應包含以下關鍵內容：
- 主題（儀表板）：用于展示一組目標一致的指標。它通常旨在解決某一類角色面臨的一個或多個具體問題。
- 指標分類：幫助了解指標的度量類型，可以按域進行分類（如需求域、測試域、代碼度量域、集成域、跨領域），也可以按其他類型進行分類。
- 指標名稱：用于區分不同的指標。一個簡明扼要的標題能夠清晰地介紹指標內容，便于用戶一目了然了解指標的用途。
- 指標口徑：詳細介紹指標的統計邏輯，便于用戶能夠清晰了解指標結果的計算方式。指通常，指標口徑會通過指標備注進行展示。
- 數據來源：根據指標口徑，確定數據來源的系統、數據庫表、接口和字段。這些數據將被用于獲取、處理和關聯，最終構建出指標所需的數據模型。
- 圖表類型：根據指標的維度、度量和過濾條件來確定使用何種圖表類型進行展示，以便更有效地傳達數據信息。
- 查詢條件：幫助我們在大量數據中篩選出最關注的數。例如，我們可以按項目或優先級來查詢缺陷數據。
- 關聯指標：對于需要進行聯動、下鉆的指標，列出與之相關的指標，并按照指標清單的所需內容進行拆解和關聯。
- 指標意義：介紹指標所解決的問題，或在指標數據出現異常時，應如何查找問題原因及解決路徑。
- 閾值設置：用于定義指標結果的正常范圍，當數據超過這個范圍時，就需要引起我們的關注，以便及時采取措施。
2）數據處理階段
在需求調研階段輸出的指標清單中，已明確說明了每個指標的數據來源系統、取數邏輯以及必要字段等。我們將根據這些信息，對需要度量的相關數據進行清洗和加工，最終形成數據模型，并將這些模型統一存放在數據倉庫中。
3）數據展示階段
不同圖表類型有著不同的表達側重點，選擇合適的圖表類型能夠更為精確地傳達數據信息。我們需要確定每個指標的展示方式，并最終將這些指標分組展示在儀表盤中。
- 柱狀圖：適用于對比多個分類間的數據大小和數值。
- 折線圖：用于展示連續數值（如時間）或者有序分類的變化趨勢。
- 條形圖：與柱狀圖使用場景類似，但當數據類別名稱較長時，條形圖更為合適。
- 餅圖：用于展示分類之間的占比情況，適用于展示整體與各部分的相對比例。
- 散點圖：用于展示兩個連續變量之間的關系或相關性，便于觀察變量之間的分布和趨勢。
- 排行榜：通過數據高低排序，直觀體現數據排名情況。
- 雷達圖：能夠直觀呈現多個維度上的數據，便于一目了然地比較和分析數據的差異。
4）權限控制階段
數據是重要的資產，對其進行權限控制可以防止敏感數據泄露或濫用。此外，通過權限控制，可以對數據進行分組管理，讓不同用戶聚焦自己關注的數據。
03.企業度量建設可能會遇到的痛點和解決方案
下面介紹度量建設步驟中，企業可能會遇到的痛點以及解決辦法。
1）數據獲取階段的痛點
例子：某企業設有大數據部門，該部門主要負責存儲和處理數據，數據存放在Hive大數據倉庫中。隨后，該企業建立了DevOps平臺來支持研發過程。由于DevOps平臺產生的數據業務特性較強，因此由專門的業務部門自行存放，并將此部分研發過程數據存放在了Doris大數據倉庫中。同時，該企業還使用了多個自建的第三方系統，如測試管理平臺和代碼倉庫等，數據分散存儲在不同系統中。
該企業面臨的痛點：
- 擁有多個自建系統，業務數據分散存儲在這些不同的系統中，導致數據采集困難。
- 已經存在Hive數據倉庫，擔心重復建設，且不希望進行大規模的數據遷移。
- 不同業務系統使用的數據庫類型不統一，數據存儲格式也存在差異。
對度量系統提出的需求：
- 能夠方便接入多個系統的數據，自動采集這些系統的數據，并進行統一度量。
- 能夠直接利用現有數據倉庫的數據，無需做大批量數據遷移。
- 能夠統一數據格式，并使用相同語言對數據進行處理。
為解決企業在度量數據獲取方面的潛在痛點，度量系統需要具備以下能力：
- 具備快速接入第三方系統數據的能力，支持拓展外部數據源。
- 擁有直連不同數據源并直接取數的能力。
- 平臺具備一定的數據處理和建模的能力。
2）數據處理階段的痛點
例子：某企業基于原始業務數據庫數據（MySQL）進行取數和建模，由于缺乏建模思維，僅僅對原始庫表數據進行原樣存儲。這導致一旦新功能上線并改動庫表結構，就容易引發指標展示異常。同時，由于數據存儲在MySQL中，受限于其數據讀取性能，指標展示速度緩慢。當有多個用戶同時訪問指標時，頁面經常卡頓，導致無法正常打開。此外，使用原始庫表提供數據，受限于業務，模型的通用性很差，大部分指標都需要生成新的數據表再提供數據。
該企業面臨的痛點：
- 原始數據結構變更后，指標需要頻繁同步調整。
- 普通數據庫讀取數據的效率低下。
- 多表關聯關系復雜，數據處理難度大。
對度量系統提出的要求：
- 業務數據庫表字段發生變更時，不應影響現有指標的展示。
- 數據讀取與展示需要順暢，避免數據卡頓和計算慢的問題。
- 系統能夠在平臺上處理多表關聯關系，實現簡單的數據表關聯操作。
為解決企業在度量數據處理方面的潛在痛點，度量系統需要具備以下能力：
- 建模層次結構遵循一定的建模思維，需要具備通用性。頂層模型應能夠屏蔽底層數據表的字段差異，并具備不同層級的模型的管理能力。
- 系統需要自帶部署大數據倉庫，該倉庫需具備強大的數據讀取能力和處理能力。
- 系統需要具備對模型進行拓展的能力，包括連表能力、SQL處理能力等。
3）權限管控階段的痛點
例子：某大型擁有眾多企業部門和人員，其中包括部分外包人。集團希望對部分敏感數據進行權限管控，確保這些數據僅對關鍵崗位開放。然而，受限于當前系統的功能，權限只能控制到菜單級別。這導致不同部門間數據可以互通，A部門能夠看到B部門的關鍵數據。此外，由于部門人員眾多，每次發生人員部門變更，都需要重新調整權限設置，這不僅耗時費力，而且配置的權限還容易出錯。
該企業面臨的痛點：
- 無法實現不同部門人員僅能查看本部門的數據。
- 權限配置操作流程復雜繁瑣，授權過程耗時費力。
- 當用戶所屬組織發生變更后，需要重新更改權限配置，耗費人力。
對度量系統提出的要求：
- 鑒于該企業人員較多，數據被視為重要資產，因此需要實現權限的精細化控制。
- 簡化權限配置的操作流程，以提高工作效率。
- 用戶更換部門或職級時，系統應能自動調整或繼承相應的權限，從而避免重新配置權限。
為解決企業在度量數據處理方面的潛在痛點，度量系統需要具備以下能力：
- 提供多種權限配置能力，涵蓋但不限于菜單級別、功能級別、儀表板級別、數據級別的權限控制能力
- 權限配置操作簡潔明了，具備良好的交互體驗，便于用戶操作。
- 支持動態權限的讀取與自動配置功能，確保在用戶部門發生變化時，其數據權限能夠實時、自動地同步更新。
4）數據呈現階段的痛點
例子：某企業通過定開方式產出指標，需要耗費大量的研發資源做定開，大量度量需求堆積，業務數據得不到及時驗證，導致業務部門對長交付周期感到不滿，而研發則常感排期緊張，時間不夠用。此外，業務需求頻繁調整，每次調整后都需要重新處理數據處理并修改接口。代碼修改完成后，還需等待發布窗口進行部署，無法實現無感更新，導致上線出錯率高，且錯誤內容難以及時修正。
該企業面臨的痛點：
- 數據圖表依賴定期開發實現，導致開發周期長，研發產能難以滿足需求。
- 業務邏輯頻繁調整，數據統計口徑變化迅速，使得業務需求難以及時得到驗證。
- 圖表表現形式需求多樣，需要能夠靈活滿足各種數據的展示需求。
對度量系統提出的要求：
- 能夠解決資源卡點問題，減少投入研發資源。
- 指標能夠快速上線，幫助業務快速驗證度量需求。
- 圖表能力能夠滿足使用，樣式豐富。
為解決企業在度量數據處理方面的潛在痛點，度量系統需要具備以下能力：
- 具備可視化的在線指標配置能力，降低使用門檻，使得非開發人員也能輕松上手，降低使用難度。
- 能夠突破發布窗口的限制，實現即時保存與即時生效，實現無感上線。
- 支持多種常用且高級的圖表的配置，能夠配置指標間的聯動下鉆，并具備多種樣式的配置能力。
04.總結
通過上述說明，我們了解到優秀的度量平臺需要具備以下核心能力，這些能力也可作為企業在選擇度量平臺時的參考依據。
- 數據拓展性強，支持快速對接第三方數據源，實現跨領域的數據度量。
- 數據處理能力強，能夠高效處理大量數據的讀寫請求，確保查詢與展示數據時流暢無阻。
- 權限精細化管控，能夠實現數據行級別的權限控制，實現跨部門數據隔離。
- 指標可視化配置靈活便捷，配置操作簡單易懂，能夠迅速響應業務指標的快速迭代需求。
