如何度量研发效能？
沒有可靠的度量就無法有效的改進，高度數字化的軟件研發領域一直是進行各類效能度量嘗試的創新重地。
阿里云·云效服務的內部版本“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文化所提倡的識別和消除系統性瓶頸。
通過各式各樣的過程數據，經驗豐富的項目經理和管理教練往往能夠準確判斷出項目的潛在問題和交付風險。
在經濟學領域有個十分有趣的“古德哈特定律”，即“當決策者試圖以一個事物的客觀測度指標作為指針來施行政策時，這一指標就再也不能有效測度事物了”。
然而效能度量并不是玄學，價值生產活動中的風險應當是有章可循的。古德哈特式的此消彼長現象其實來源于經濟領域的范圍太過寬廣，任何實用指標往往只能是局部度量的結果。效能透視鏡產品的提出者嵩華老師曾經分享過一種識別研發項目系統性風險的思路，即有的放矢的關注四種典型的全局現象：
- 流動阻滯
- 返工
- 落后的工程能力
- 技術債務
這幾種現象不太容易在局部進行遮掩，且在一定條件下能夠相互疊加，成為“爛項目”的標配。
透過整個研發過程中的種種現象，找到反映這些全局性問題的蛛絲馬跡，不僅能在一定程度上讓“專家經驗”產品化、標準化，也有助于將效能數據的使用方法從當前普遍的“事后復盤”式向以全局流動速率和質量作為關注點的“風險管控”式發展，從而在可靠性和時效性兩個方面都得到提升。
總結
數據不會騙人，但數據的呈現和解讀依然有很大的空間值得探索?，F實事物復雜而多面，度量正是為描述和對比這些具象事實而采取的抽象和量化措施，從某種意義上來說，度量的結果一定是片面的，反映部分事實。沒有銀彈，也沒有完美的效能度量。
對于企業研發效能的提升，開發者工具、效能方法理論、效能度量指標都是缺一不可、環環相扣的幾個重要板塊，相信隨著數據價值被越來越多的挖掘，我們終將實現更有效的反饋和更精確的賦能，讓研發協作真正變得透明、簡單、高效。
最后
分享十條前人總結的經驗觀點。
- 任何指標一旦用于管控，就不再可靠（古德哈特定律）。
- 測量的對象與人越近，越不可靠。
- “凡可度量，皆可改造”是錯的。
- 變化趨勢的價值高于指標絕對值。
- 選擇適當的而非“標準的”指標，若發現指標沒用，果斷舍棄。
- 務必了解指標的獲取成本，明確指標意圖和針對的企業目標。
- 設計“北極星指標”，指標數量越多，邊際收益遞減。
- 不要將指標對所有人透明。
- 讓一線人員參與指標制定。
- 如果可能，合理縮短度量周期。
原文鏈接：https://developer.aliyun.com/article/773021?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
- 上一篇： 深耕边缘计算 揭秘阿里云边缘云网一体化
- 下一篇： 作为数据库核心成员，如何让淘宝不卡顿？