Devops之度量名額

為什麼要度量名額？

度量在很多企業裡落地的效果并不好。一是因為度量的前提是要有一套打通端到端的 DevOps 平台，否則再優秀的度量也隻是局部度量。目前國内很多企業還都處于建設 DevOps 平台的基礎階段，是以落實下來也并不容易。二是，度量本身投入産出比并不像 CICD 效果明顯。很多工程隻是為了“給上面看看”而完成的任務，并沒有從度量的本質上去考慮。

因為這兩點原因，度量名額在企業内的落地還存在問題。

我認為“有哪些度量名額”“名額如何擷取”這些問題是我們從一開始就要考慮的。原因有以下幾點：

• 精益思想的核心理念是持續改進，隻有清晰明确的度量名額作為指引，才能達到持續改進的目标。在持續改進這條路上，沒有終點，永遠在路上。
• 度量能夠提供資訊來幫助我們知道現在在哪裡，距離目标還有多遠，我們是在沿着目标前進，還是在倒退，程度如何。
• 度量名額是需要從 DevOps 平台擷取的，一開始要考慮有哪些度量名額，如何擷取，對 DevOps 平台的設計有指導意義。

這樣要強調的是，度量名額不是目的，而是手段；不是控制，而是改進。“目的”容易給人以到達終點的錯覺，“手段”是為了發現潛在的問題。“控制”容易給人以一種靜态目标的心理暗示，“改進”則是以動态目标植入人心。這有助于我們能夠不斷地發現問題，改正問題。

什麼樣的名額是好名額？

關于尋找度量名額這塊，在有些企業裡都有一個誤區，就是要“度量所有内容”。一些企業拍腦袋要度量幾百個名額，以期望能從這麼多的名額中找到一些重要資訊。這種方式是不正确的，有以下幾個問題：

• 更多的名額需要投入更多的資源來關注軟體研發的各個方面，最終會導緻每個名額的效果并不好；
• 以 KPI 的形式完成名額，最終完成的隻是數量，不是品質。

那麼，度量名額的品質是什麼？什麼樣的名額是好名額？下面這 5 個标準希望能夠幫到你。

1. 可度量的：名額必須是可衡量的，即是一個定量的名額，而不是“非常好”，“非常快”這種定性的名額。
2. 相關聯的：名額必須能夠度量對業務有重要影響的因素。
3. 不可更改的：團隊成員不能影響度量名額的結果。
4. 可實施的：名額是能夠通過技術的手段擷取并且數值是真實可靠的。
5. 可追溯的：名額必須是能夠直接反映軟體研發過程中存在的問題。

是以，我們不可能度量所有的名額，要選出哪些滿足這些要求的名額，名額不在多，而在精。在找出要跟蹤的 DevOps 名額之前，需要确定組織面臨的挑戰以及要解決的問題。好的名額是用來解決實際業務問題的。是以，應該避免那些不符合 DevOps 時代、對使用者沒有價值的名額，比如以下幾點。

• 傳統的工程名額：比如 MTBF（平均故障間隔時間）在 DevOps 時代意義就不大。系統的長期穩定性并不是首要目标，因為 DevOps 時代是通過快速部署來保證系統的穩定性的。基于虛拟化和基礎設施即代碼的工程實踐，可以通過頻繁的部署來進行線上測試，這些測試可能會經常失敗，但有利于制定更好的方案。這種情況下，MTBF 對業務需求來說并不是好名額。
• 基于競争的名額：切勿基于團隊成員或團隊之間的競争來建立名額。比如按團隊成員完成的需求數量進行排名、按開發人員出現的 Bug 數進行排名等。度量名額的目的是用來解決業務問題，不是用來晾曬團隊成員技術水準的手段。
• 虛榮性名額：比如每周代碼行的統計。不應該以代碼行數這樣無意義的名額評判開發人員工作量的名額。最終傳遞功能的及時性和品質才是最重要的。

在度量名額的時候，不要根據擷取名額的難易來取舍名額。在一項重要的名額上哪怕花費更多的成本都是值得的，在一項無用的名額上投入再少的時間也是在浪費。

如何選擇名額？

好的名額是用來解決問題的。當我們在選擇名額時的依據也是要解決的問題。在軟體開發過程中，需要解決的問題很多。代碼品質、團隊成員、釋出效率的等都有可能成為問題的來源。這些名額中，有些是給上層上司做決策用的，有些是為了提升團隊技能水準的，有些則是為了提升軟體品質。不管用途是什麼，衡量的标準就是解決或改善現有的問題。我舉了下面幾個例子。

• 縮短産品上市時間：用于衡量從使用者需求被提出到最終傳遞給使用者之間的時間，可以使用“前置時間”這個名額。因為更短的上市時間代表了企業在市場競争中的反應速度越快。
• 提高軟體開發的效率：可以使用“流動效率”這個名額，以檢視瓶頸點，并将工作重心放在如何改善流動瓶頸的地方。等待的時間越少，軟體開發的效率就越高。
• 解決團隊正在處理的事項和計劃外事項的沖突：可以使用“在制品數量”這個名額，以暴露工作内容過載的團隊或團隊成員，使得每個團隊成員的工作更加均衡。
• 解決未完成的重要工作不被遺忘的問題：可以使用“停留時間”或“過期時間”等名額，來度量未完成的工作在系統裡停留了多長時間，如果超過設定的門檻值則進行預警以暴露風險。
• 減少生産環境中使用者發現的問題數量：可以使用“缺陷逃逸率”這個名額，争取盡可能多的 Bug 是在測試環境或預生産環境中發現，以最大程度建設使用者發現的缺陷數量。

如何使用名額？

當根據上面的标準選擇好名額後，應該如何使用這些名額？回報循環是有效改進的基礎，通過度量名額的回報，有助于更加精準的調整團隊的行動，改善整個組織的溝通。下圖是度量名額的回報循環，需要有以下幾個步驟：

STEP 1：收集資料。

收集關于軟體研發過程中的資料，作為後續分析的原材料。在大多數企業，度量面對的問題不是資料準不準确，而是有沒有資料的問題。如果要有效地收集資料，需要從兩個方面入手。

• 平台方面：平台本身需要具備收集資料的能力。在設計平台時，要有針對度量名額方面的設計。比如每個任務都要有開始時間和結束時間，每個事件都應該有發生、處理、解決的時間記錄，事物之間的關聯（如代碼送出與任務或缺陷的關聯，代碼庫與産品線的關聯，流水線建構與代碼庫的關聯等）。平台具備收集這些資料的能力外，還可以提高統計報表，用更直覺的方式進行展示。
• 人的方面：團隊成員的有效參與能夠充分發揮平台的能力。DevOps 平台中，雖然将研發流程中的操作盡可能自動化了，但有些内容還是需要人工配合。比如：在送出代碼時按照規範送出，将需要關聯的需求 ID 和缺陷 ID 添加到 message 裡，進而建立送出的代碼與需求和缺陷的關聯。需求的拆解，任務的啟動、過程跟蹤以及完成後的關閉操作，都需要人工配合，才能使資料更加準确。

STEP 2 ：分析資料。

基于收集的資料進行分析，以便能發現目前存在的問題。舉個例子，通過資料收集系統發現：需求完成的數量在減少，代碼行數在增加，同時缺陷的數量在增長。下面通過這些資料進行分析：

• 需求完成的數量減少，說明團隊花在需求上的時間減少了，是什麼原因導緻的呢？繼續往下分析。
• 代碼行數在增加，說明團隊成員花費大量的時間在修改代碼上。既然完成的需求在減少，可以斷定代碼不是為開發需求而寫的。
• 缺陷的數量在增加，可以說明目前在測試階段，并且測試出了很多問題。

通過分析得出結論：說明軟體進入到測試階段後，問題很多，導緻團隊成員需要花費大量的時間修複缺陷，進而影響了正常的需求開發。

STEP 3：調整流程。

根據上面的分析判斷，開發人員在開發階段對軟體品質的控制效果并不好，可能的原因有：

• 開發人員沒有進行有效自測；
• 開發人員沒有編寫單元測試或者覆寫率較低。

是以，我們可以采取一些措施改善流程，盡早發現軟體中的問題。比如在持續內建流水線中內建單元測試，通過設定門限門檻值來控制單元測試的有效性和覆寫率；通過自動化的API接口測試，驗證服務以及服務之間調用的正确性等。

STEP 4：重複執行。

重複上面的步驟，再次收集名額，觀察名額的變化，并根據名額的值調整流程，直到滿足要求。