沒有可靠的度量就無法有效的改進，高度數字化的軟體研發領域一直是進行各類效能度量嘗試的創新重地。
阿裡雲·雲效服務的内部版本“Aone”承載着阿裡集團數百個BU協同研發和持續傳遞的職責，筆者在數月前短暫的參與了該平台的效能透視鏡闆塊建設，因而得以從平台的“上帝視角”重新審視效能度量這件事，随着項目開展，略微摸索了些門道。此文中觀點源于這段時間裡筆者在團隊内以及與周邊相關團隊的讨論和個人思考，且作抛磚引玉之用。
度量的分類
度量的分類方式有很多，其中比較有意思的一種角度，是根據目标意圖将度量劃分為“針對人的度量”和“針對事的度量”。
任何協作系統都離不開人的參與，加之可與績效、考核等事情牽上關系，即使相關名額的分析往往伴随着争議，針對人的度量在企業裡有時依然被視為一種“剛需”。譬如“代碼量”、“代碼品質”、“工作時長”等資料評判都是常見的依據名額。從産品實作而言，由于對結果可解釋性要求高，這類度量的單因素名額居多，計算方案通常不會太複雜，宜采用小範圍同次元橫向比較，防止過度泛化。
相比之下，針對事度量的範疇和方法更加靈活。既包括簡單的數值名額，譬如産研中的釋出頻率、需求傳遞時長；也包括需要對比分析的多元名額，譬如需求在各階段的停留時長、缺陷在各環境的漏測率等。在就事論事的基礎上，為了更全面的了解事實的客觀規律，還經常需要将一組資料向上聚合（譬如整個部門、整個項目的情況）或者跨領域關聯（譬如業務領域需求關聯到相關代碼送出情況），進而獲得更寬的觀察視角。由于涉及的度量主體更多，有時為了确定哪個主體是主要的影響因素，還需要進行額外的歸因判定。相較于以人為目标的度量，對事進行度量時，可以包含更多的經驗和推理因素。
對人或對事主要是針對度量目的而言，在實際運用時，兩者采用的具體名額會有許多共同之處，并不能一概而論。根據管理學中的“平衡計分卡（The Balanced ScoreCard）”理論，度量活動要遵循“目标-度量-名額-行動”的規則，名額最終服務于目标的達成，好的度量産品不僅應當反映“發生了什麼”，還應當能根據目标提供“該怎麼做”的輔助建議。是以度量類産品的成敗，不僅是對名額設計者的領域了解、抽象能力的挑戰，而且對産品自身的業務目标清晰度也會提出很高的要求。
效能的本質
歸根究底而言，效能的本質是對價值流動速度和品質的評價。
“價值流”的概念伴随着精益思想的傳播，被越來越多行業所接納。不過很少有其他哪個行業能夠像軟體研發行業這樣，能夠讓價值傳遞的各個環節幾乎完全線上數字化，進而提供大量可分析的過程資料樣本。
所謂價值流動過程可以表示為，“價值原料”在可被度量的價值加工活動之間有序傳遞，不斷疊加價值增量，最終形成可被消費的“價值産物”。下圖将這一過程的度量抽象為一種非常簡潔的表示結構，可稱為效能度量的“元模型”。
度量中所用的各類“領域特征”則是由在此元模型之上的領域對象，以及基于這些對象的“領域名額”來定義的。
譬如在研發領域，“價值原料”可以是一個業務方的需求，或是一個開發者突發奇想的創意。可被度量的活動包括需求拆解、任務指派、代碼編寫、測試、部署、驗證、釋出等等。每個活動本身都具有可被觀測的屬性，實體之間也具有可被量化的關系。這些實體、屬性、關系就組成了特定領域的模型，下圖展示了一種簡化的研發度量領域模型（為了美觀省略掉很多實體關系連接配接，僅作示意）。
有了領域模型，就可以基于規則制定名額。名額通常被描述為各種量化特征和實體屬性的數值計算。有些名額是領域無關的，譬如端到端流通時長；有些名額是多個領域之間可以複用的，譬如許多行業都會有機關時間任務吞吐量、任務按時完成率這樣的名額；有些名額是領域特有的，譬如研發領域的千行代碼缺陷率等等。
在名額之上，還需要有與具體運用場景相比對的工具或平台來将度量結果轉換為便于觀察分析的表現形式。譬如各種圖表、報表，以及事件通知。
元模型和領域對象的分離，似乎能夠形成一種足夠抽象的通用度量産品，通過領域相關的名額規則、展示規則、通知告警規則，快速适配不同目标和場景，然而現實情況其實更複雜。一方面受制于計算能力，有些名額實際無法根據模型+規則實時計算出來，必須單獨預先算好，以空間換時間。另一方面受限于價值增值過程的可觀測性，并非所有行為的結果都能立即被簡單量化（否則說服人們堅持鍛煉身體就容易多了），即使在高度數字化的軟體研發領域，依然存在資料品質和時效性問題，在使用資料時需要加以考慮。是以各種效能的場景雖然具有十分相似的流動特征，實際産品依然會不可避免的根據業務定制化，萬能的度量工具或公式是不存在的。
模型的存儲
對于度量模型的存儲，圖資料庫可能是最好的選擇，沒有之一。
相比結構化的SQL資料庫和文檔型的NoSQL資料庫，圖資料庫屬于比較小衆的一種偏門奇術，主要用在知識圖譜和基于關系的資訊搜尋領域。從基本特征而言，圖資料庫通常具備NoSQL的非結構化KV存儲能力，允許同一類實體具有不同屬性項的執行個體，這對于處理來自多種資料源或多個子類型的實體資訊帶來很大便利。同時，圖資料庫通常能像SQL資料庫那樣支援事務和多實體關聯查詢。不僅如此，圖資料庫對複雜關系的檢索性能遠高于SQL資料庫，對于判斷、循環查詢的支援也比SQL存儲過程更加優雅。
然而這些基礎能力上的差異，并非我推薦将圖資料庫用于效能度量的主要原因。
好的技術選型應該能夠充分适應潛在的業務需求變動，避免過早将技術實作耦合到局部的應用場景。在基于SQL表的開發模式裡，“表結構設計”是在軟體詳細設計階段裡非常重要的一個環節，因為它不僅是對整體業務領域的模組化，還關系着未來資料查詢的效率和便利性。熟悉SQL表設計的同學應該知道，1對1、1對N、N對N關系，資料表的處理方法是完全不同的：N對N關系需要額外設計關聯表，1對N關系通常是在後者的實體上設計外鍵，而1對1關系的外鍵設計就更有講究了，要根據實際場景來決定該在哪個實體上放另一者的外鍵，然後在使用的時候順着這個關聯方向來查詢。對于聚合的設計也是如此，需要事先在被聚合表上提前設計好用于聚合的外鍵，是以會有“事實表”、“次元表”的區分。資料的查詢規則，在資料庫表結構設定的時候就被确定下來了。
對業務模式比較固定的場景而言，提前考慮好資料的使用方法并做針對性優化顯得合情合理，然而效能度量業務并不屬于此類。在度量領域裡，關聯、級聯、聚合都是十分常見的名額計算操作，由于名額的作用在于發現潛藏于表面之下的問題，事先不應當提前規定隻能從哪一類實體作為關聯查詢的起點，或者必須以哪些次元做聚合觀察。
就圖資料庫的存儲模型來說，所有業務實體都是平等的，任何類型的關系都由實體間的關聯來表示。這就像是在SQL表設計時，不論是1對1還是N對N關系，總是額外增加一張關聯表，卻無需顧慮多表JOIN帶來的性能影響。這樣一來，相當于将查詢和聚合方式的決策推遲到實際使用的時候再做，進而有效解耦模組化和查詢時的互相制約，不再需要為優化查詢而返工改表。
此外，由于關聯直接建立于實體之間，當删除實體的時候，實體間的關聯也将自動斷開。這就像有垃圾回收機制的Java語言不用自己管理記憶體指針一樣。圖資料庫絕不會産生由于關系修改時的不對稱清除而導緻的資料不一緻情況。
那圖資料庫會不會有坑？肯定有。不過在我們目前有限的探索裡，遇到比較大的麻煩主要來自它不夠完善的周邊工具配套、阿裡雲圖資料庫服務的某些配置限制，以及市場上稀缺具備相關技能的專業工程師。
專家經驗
在研發效能領域，度量的終極目标是DevOps文化所提倡的識别和消除系統性瓶頸。
通過各式各樣的過程資料，經驗豐富的項目經理和管理教練往往能夠準确判斷出項目的潛在問題和傳遞風險。
在經濟學領域有個十分有趣的“古德哈特定律”，即“當決策者試圖以一個事物的客觀測度名額作為指針來施行政策時，這一名額就再也不能有效測度事物了”。
然而效能度量并不是玄學，價值生産活動中的風險應當是有章可循的。古德哈特式的此消彼長現象其實來源于經濟領域的範圍太過寬廣，任何實用名額往往隻能是局部度量的結果。效能透視鏡産品的提出者嵩華老師曾經分享過一種識别研發項目系統性風險的思路，即有的放矢的關注四種典型的全局現象：
- 流動阻滞
- 返工
- 落後的工程能力
- 技術債務
這幾種現象不太容易在局部進行遮掩，且在一定條件下能夠互相疊加，成為“爛項目”的标配。
透過整個研發過程中的種種現象，找到反映這些全局性問題的蛛絲馬迹，不僅能在一定程度上讓“專家經驗”産品化、标準化，也有助于将效能資料的使用方法從目前普遍的“事後複盤”式向以全局流動速率和品質作為關注點的“風險管控”式發展，進而在可靠性和時效性兩個方面都得到提升。
總結
資料不會騙人，但資料的呈現和解讀依然有很大的空間值得探索。現實事物複雜而多面，度量正是為描述和對比這些具象事實而采取的抽象和量化措施，從某種意義上來說，度量的結果一定是片面的，反映部分事實。沒有銀彈，也沒有完美的效能度量。
對于企業研發效能的提升，開發者工具、效能方法理論、效能度量名額都是缺一不可、環環相扣的幾個重要闆塊，相信随着資料價值被越來越多的挖掘，我們終将實作更有效的回報和更精确的賦能，讓研發協作真正變得透明、簡單、高效。
最後
分享十條前人總結的經驗觀點。
- 任何名額一旦用于管控，就不再可靠（古德哈特定律）。
- 測量的對象與人越近，越不可靠。
- “凡可度量，皆可改造”是錯的。
- 變化趨勢的價值高于名額絕對值。
- 選擇适當的而非“标準的”名額，若發現名額沒用，果斷舍棄。
- 務必了解名額的擷取成本，明确名額意圖和針對的企業目标。
- 設計“北極星名額”，名額數量越多，邊際收益遞減。
- 不要将名額對所有人透明。
- 讓一線人員參與名額制定。
- 如果可能，合理縮短度量周期。