軟體工程的重要的指標

簡單整理一下今天看到的這篇文章, 未來可以用指標來改善團隊狀況。 ----- 軟體工程的重要的指標 DORA 指標 (DevOps Research Assessment) 1. 部署頻率: 產品多快發佈出去 2. 投入到交貨的時間 (Lead-Time For Change): 需求多快可以給客戶 3. 變更失敗率: 部署後造成線上異常的頻率, 也可以視為 Hotfix 次數 / 部署次數 4. 恢復服務時間: 從故障到恢復需要的時間 可觀察部署的摩擦系數及產品變更的可靠性。 SRE 指標 (Site Reliability Engineering Metrics) 1. 服務水平指標 (SLI): 決定服務水平的數據, 例如回應時間、失敗/請求比例 (error rates) 2. 服務水平目標 (SLO): 對每一項 SLI 定義目標, 例如一個月內, P99 的回應時間在 200 毫秒內。 3. 服務級別協議 (SLA): 對客戶宣告基於 SLO 的商業承諾, 若沒有達到則有罰則。 團隊應該要關注在 SLI & SLO 的關係, 什麼樣的指標代表服務水平, 例如電商可能會包括交易成功率跟每秒成單數量。 錯誤預算 (Error budgets) - 這可能是基於 SLO 的指標來決定; 例如站台一個月內的可用性是 99%, 代表有 1% 的錯誤率可以消耗。 如果在每個月的前2次部署錯誤率升到 0.7%, 那代表你接下來的部署只剩下 0.3% 錯誤率可以花。如此花光了或到了臨界值, 團隊應該停止部署, 直到找到錯誤率升高的原因為止。 這樣可以機械式的將把可靠性放在新功能交付的前面。 苦勞指數 (Percentage toil-work) - 例如維運人員的工作, 有 50% 在用工人智慧處理, 應該就將工作自動化。 流動時間 (Flow time) - 有點像價值流, 計劃中工作應該都要算在內, 以此可以看出有多少需求是提出後大半年才排進年度計劃或交到團隊手上。 流量分配 - 定義每個工程階段花費時間的比例, 例如把整體的價值流程圖拉出來, 可看出團隊花在測試及提高可靠性上的時間分配有多少。 PR lead-time & rework - PR lead-time: PR 開出後到被 merged 的時間 - PR rework: PR 審核後的修改次數 可以看出團隊基於 PR 的工作流程卡關的程度, 如果時間花在讓 PR 被 merged 的成本很高, 應該在發出 PR 前就提前進行討論。 錯誤日誌量 - 應該要觀察每個服務寫出來的 Log 數, 如果要靠寫 Log 才能幫助釐清似乎也不是個健康的做法, 錯誤日誌應該在真正異常的情況才做記錄。 團隊健康/心理安全 - 每季或每月進行匿名的心理安全調查, 有助於發現一些風險及警告信號。 結論 - 指標用於需要改善的地方 - 指標做為預警制 - 團隊自己跟自己比 不要用在 - 把指標落到個別開發人員身上 - 小心團隊之間的比較 - 根據指標對團隊或個人排名 來源: https://chaordic.io/blog/software-engineering-metrics-that-matter/?utm_source=techleaddigest&utm_medium&utm_campaign=1447