簡介：如今，研發(fā)效能越來越受到重視。那么效能的本質是什么？效能度量的終極目標是什么？如何讓“專家經(jīng)驗”產(chǎn)品化、標準化，從“事后復盤”發(fā)展為“風險管控”？本文從度量的分類、效能本質、模型的存儲等方面聊一聊效能度量，并分享一種研發(fā)度量領域模型。

沒有可靠的度量就無法有效的改進，高度數(shù)字化的軟件研發(fā)領域一直是進行各類效能度量嘗試的創(chuàng)新重地。

阿里云·云效服務的內部版本“Aone”承載著阿里集團數(shù)百個BU協(xié)同研發(fā)和持續(xù)交付的職責，筆者在數(shù)月前短暫的參與了該平臺的效能透視鏡板塊建設，因而得以從平臺的“上帝視角”重新審視效能度量這件事，隨著項目開展，略微摸索了些門道。此文中觀點源于這段時間里筆者在團隊內以及與周邊相關團隊的討論和個人思考，且作拋磚引玉之用。

度量的分類

度量的分類方式有很多，其中比較有意思的一種角度，是根據(jù)目標意圖將度量劃分為“針對人的度量”和“針對事的度量”。

任何協(xié)作系統(tǒng)都離不開人的參與，加之可與績效、考核等事情牽上關系，即使相關指標的分析往往伴隨著爭議，針對人的度量在企業(yè)里有時依然被視為一種“剛需”。譬如“代碼量”、“代碼質量”、“工作時長”等數(shù)據(jù)評判都是常見的依據(jù)指標。從產(chǎn)品實現(xiàn)而言，由于對結果可解釋性要求高，這類度量的單因素指標居多，計算方案通常不會太復雜，宜采用小范圍同維度橫向比較，防止過度泛化。

相比之下，針對事度量的范疇和方法更加靈活。既包括簡單的數(shù)值指標，譬如產(chǎn)研中的發(fā)布頻率、需求交付時長；也包括需要對比分析的多元指標，譬如需求在各階段的停留時長、缺陷在各環(huán)境的漏測率等。在就事論事的基礎上，為了更全面的理解事實的客觀規(guī)律，還經(jīng)常需要將一組數(shù)據(jù)向上聚合（譬如整個部門、整個項目的情況）或者跨領域關聯(lián)（譬如業(yè)務領域需求關聯(lián)到相關代碼提交情況），從而獲得更寬的觀察視角。由于涉及的度量主體更多，有時為了確定哪個主體是主要的影響因素，還需要進行額外的歸因判定。相較于以人為目標的度量，對事進行度量時，可以包含更多的經(jīng)驗和推理因素。

對人或對事主要是針對度量目的而言，在實際運用時，兩者采用的具體指標會有許多共同之處，并不能一概而論。根據(jù)管理學中的“平衡計分卡（The Balanced ScoreCard）”理論，度量活動要遵循“目標-度量-指標-行動”的規(guī)則，指標最終服務于目標的達成，好的度量產(chǎn)品不僅應當反映“發(fā)生了什么”，還應當能根據(jù)目標提供“該怎么做”的輔助建議。因此度量類產(chǎn)品的成敗，不僅是對指標設計者的領域理解、抽象能力的挑戰(zhàn)，而且對產(chǎn)品自身的業(yè)務目標清晰度也會提出很高的要求。

效能的本質

歸根究底而言，效能的本質是對價值流動速度和質量的評價。

“價值流”的概念伴隨著精益思想的傳播，被越來越多行業(yè)所接納。不過很少有其他哪個行業(yè)能夠像軟件研發(fā)行業(yè)這樣，能夠讓價值交付的各個環(huán)節(jié)幾乎完全在線數(shù)字化，從而提供大量可分析的過程數(shù)據(jù)樣本。

所謂價值流動過程可以表示為，“價值原料”在可被度量的價值加工活動之間有序傳遞，不斷疊加價值增量，最終形成可被消費的“價值產(chǎn)物”。下圖將這一過程的度量抽象為一種非常簡潔的表示結構，可稱為效能度量的“元模型”。

度量中所用的各類“領域特征”則是由在此元模型之上的領域對象，以及基于這些對象的“領域指標”來定義的。

譬如在研發(fā)領域，“價值原料”可以是一個業(yè)務方的需求，或是一個開發(fā)者突發(fā)奇想的創(chuàng)意。可被度量的活動包括需求拆解、任務指派、代碼編寫、測試、部署、驗證、發(fā)布等等。每個活動本身都具有可被觀測的屬性，實體之間也具有可被量化的關系。這些實體、屬性、關系就組成了特定領域的模型，下圖展示了一種簡化的研發(fā)度量領域模型（為了美觀省略掉很多實體關系連接，僅作示意）。

有了領域模型，就可以基于規(guī)則制定指標。指標通常被描述為各種量化特征和實體屬性的數(shù)值計算。有些指標是領域無關的，譬如端到端流通時長；有些指標是多個領域之間可以復用的，譬如許多行業(yè)都會有單位時間任務吞吐量、任務按時完成率這樣的指標；有些指標是領域特有的，譬如研發(fā)領域的千行代碼缺陷率等等。

在指標之上，還需要有與具體運用場景相匹配的工具或平臺來將度量結果轉換為便于觀察分析的表現(xiàn)形式。譬如各種圖表、報表，以及事件通知。

元模型和領域對象的分離，似乎能夠形成一種足夠抽象的通用度量產(chǎn)品，通過領域相關的指標規(guī)則、展示規(guī)則、通知告警規(guī)則，快速適配不同目標和場景，然而現(xiàn)實情況其實更復雜。一方面受制于計算能力，有些指標實際無法根據(jù)模型+規(guī)則實時計算出來，必須單獨預先算好，以空間換時間。另一方面受限于價值增值過程的可觀測性，并非所有行為的結果都能立即被簡單量化（否則說服人們堅持鍛煉身體就容易多了），即使在高度數(shù)字化的軟件研發(fā)領域，依然存在數(shù)據(jù)質量和時效性問題，在使用數(shù)據(jù)時需要加以考慮。因此各種效能的場景雖然具有十分相似的流動特征，實際產(chǎn)品依然會不可避免的根據(jù)業(yè)務定制化，萬能的度量工具或公式是不存在的。

模型的存儲

對于度量模型的存儲，圖數(shù)據(jù)庫可能是最好的選擇，沒有之一。

相比結構化的SQL數(shù)據(jù)庫和文檔型的NoSQL數(shù)據(jù)庫，圖數(shù)據(jù)庫屬于比較小眾的一種偏門奇術，主要用在知識圖譜和基于關系的信息搜索領域。從基本特征而言，圖數(shù)據(jù)庫通常具備NoSQL的非結構化KV存儲能力，允許同一類實體具有不同屬性項的實例，這對于處理來自多種數(shù)據(jù)源或多個子類型的實體信息帶來很大便利。同時，圖數(shù)據(jù)庫通常能像SQL數(shù)據(jù)庫那樣支持事務和多實體關聯(lián)查詢。不僅如此，圖數(shù)據(jù)庫對復雜關系的檢索性能遠高于SQL數(shù)據(jù)庫，對于判斷、循環(huán)查詢的支持也比SQL存儲過程更加優(yōu)雅。

然而這些基礎能力上的差異，并非我推薦將圖數(shù)據(jù)庫用于效能度量的主要原因。

好的技術選型應該能夠充分適應潛在的業(yè)務需求變動，避免過早將技術實現(xiàn)耦合到局部的應用場景。在基于SQL表的開發(fā)模式里，“表結構設計”是在軟件詳細設計階段里非常重要的一個環(huán)節(jié)，因為它不僅是對整體業(yè)務領域的建模，還關系著未來數(shù)據(jù)查詢的效率和便利性。熟悉SQL表設計的同學應該知道，1對1、1對N、N對N關系，數(shù)據(jù)表的處理方法是完全不同的：N對N關系需要額外設計關聯(lián)表，1對N關系通常是在后者的實體上設計外鍵，而1對1關系的外鍵設計就更有講究了，要根據(jù)實際場景來決定該在哪個實體上放另一者的外鍵，然后在使用的時候順著這個關聯(lián)方向來查詢。對于聚合的設計也是如此，需要事先在被聚合表上提前設計好用于聚合的外鍵，因此會有“事實表”、“維度表”的區(qū)分。數(shù)據(jù)的查詢規(guī)則，在數(shù)據(jù)庫表結構設定的時候就被確定下來了。

對業(yè)務模式比較固定的場景而言，提前考慮好數(shù)據(jù)的使用方法并做針對性優(yōu)化顯得合情合理，然而效能度量業(yè)務并不屬于此類。在度量領域里，關聯(lián)、級聯(lián)、聚合都是十分常見的指標計算操作，由于指標的作用在于發(fā)現(xiàn)潛藏于表面之下的問題，事先不應當提前規(guī)定只能從哪一類實體作為關聯(lián)查詢的起點，或者必須以哪些維度做聚合觀察。

就圖數(shù)據(jù)庫的存儲模型來說，所有業(yè)務實體都是平等的，任何類型的關系都由實體間的關聯(lián)來表示。這就像是在SQL表設計時，不論是1對1還是N對N關系，總是額外增加一張關聯(lián)表，卻無需顧慮多表JOIN帶來的性能影響。這樣一來，相當于將查詢和聚合方式的決策推遲到實際使用的時候再做，從而有效解耦建模和查詢時的相互制約，不再需要為優(yōu)化查詢而返工改表。

此外，由于關聯(lián)直接建立于實體之間，當刪除實體的時候，實體間的關聯(lián)也將自動斷開。這就像有垃圾回收機制的Java語言不用自己管理內存指針一樣。圖數(shù)據(jù)庫絕不會產(chǎn)生由于關系修改時的不對稱清除而導致的數(shù)據(jù)不一致情況。

那圖數(shù)據(jù)庫會不會有坑？肯定有。不過在我們目前有限的探索里，遇到比較大的麻煩主要來自它不夠完善的周邊工具配套、阿里云圖數(shù)據(jù)庫服務的某些配置限制，以及市場上稀缺具備相關技能的專業(yè)工程師。

專家經(jīng)驗

在研發(fā)效能領域，度量的終極目標是DevOps文化所提倡的識別和消除系統(tǒng)性瓶頸。

通過各式各樣的過程數(shù)據(jù)，經(jīng)驗豐富的項目經(jīng)理和管理教練往往能夠準確判斷出項目的潛在問題和交付風險。

在經(jīng)濟學領域有個十分有趣的“古德哈特定律”，即“當決策者試圖以一個事物的客觀測度指標作為指針來施行政策時，這一指標就再也不能有效測度事物了”。

然而效能度量并不是玄學，價值生產(chǎn)活動中的風險應當是有章可循的。古德哈特式的此消彼長現(xiàn)象其實來源于經(jīng)濟領域的范圍太過寬廣，任何實用指標往往只能是局部度量的結果。效能透視鏡產(chǎn)品的提出者嵩華老師曾經(jīng)分享過一種識別研發(fā)項目系統(tǒng)性風險的思路，即有的放矢的關注四種典型的全局現(xiàn)象：

• 流動阻滯
• 返工
• 落后的工程能力
• 技術債務

這幾種現(xiàn)象不太容易在局部進行遮掩，且在一定條件下能夠相互疊加，成為“爛項目”的標配。

透過整個研發(fā)過程中的種種現(xiàn)象，找到反映這些全局性問題的蛛絲馬跡，不僅能在一定程度上讓“專家經(jīng)驗”產(chǎn)品化、標準化，也有助于將效能數(shù)據(jù)的使用方法從當前普遍的“事后復盤”式向以全局流動速率和質量作為關注點的“風險管控”式發(fā)展，從而在可靠性和時效性兩個方面都得到提升。

總結

數(shù)據(jù)不會騙人，但數(shù)據(jù)的呈現(xiàn)和解讀依然有很大的空間值得探索。現(xiàn)實事物復雜而多面，度量正是為描述和對比這些具象事實而采取的抽象和量化措施，從某種意義上來說，度量的結果一定是片面的，反映部分事實。沒有銀彈，也沒有完美的效能度量。

對于企業(yè)研發(fā)效能的提升，開發(fā)者工具、效能方法理論、效能度量指標都是缺一不可、環(huán)環(huán)相扣的幾個重要板塊，相信隨著數(shù)據(jù)價值被越來越多的挖掘，我們終將實現(xiàn)更有效的反饋和更精確的賦能，讓研發(fā)協(xié)作真正變得透明、簡單、高效。

最后

分享十條前人總結的經(jīng)驗觀點。

• 任何指標一旦用于管控，就不再可靠（古德哈特定律）。
• 測量的對象與人越近，越不可靠。
• “凡可度量，皆可改造”是錯的。
• 變化趨勢的價值高于指標絕對值。
• 選擇適當?shù)亩恰皹藴实摹敝笜?#xff0c;若發(fā)現(xiàn)指標沒用，果斷舍棄。
• 務必了解指標的獲取成本，明確指標意圖和針對的企業(yè)目標。
• 設計“北極星指標”，指標數(shù)量越多，邊際收益遞減。
• 不要將指標對所有人透明。
• 讓一線人員參與指標制定。
• 如果可能，合理縮短度量周期。

原文鏈接：https://developer.aliyun.com/article/773021?

版權聲明：本文內容由阿里云實名注冊用戶自發(fā)貢獻，版權歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的如何度量研发效能？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。