我們看到越來越多的組織重新關注采用和改進他們的 DevOps 實踐，以幫助優化他們的軟件開發生命周期并提高他們的交付速度以更快地到達市場和客戶。以下是您需要了解的四個關鍵 DevOps 指標，以及團隊如何使用這些指標來提高開發效率和性能，從而為他們的客戶構建更好更快的產品。

什么是 DevOps 指標？

DevOps 指標是用于衡量團隊 DevOps 軟件開發過程的性能和效率的數據點。由于 DevOps 集成了開發和運維的功能，因此指標應該能夠衡量和優化相關流程和人員的績效。

從 DevOps 指標中衡量和收集見解可以幫助管理人員收集對其團隊流程和瓶頸的可操作見解，并在出現障礙時迅速采取補救措施。因此，DevOps 指標使團隊能夠成功完成目標。

四個關鍵的 DevOps 指標

Google 的DevOps 研究與評估(DORA) 團隊確定了四個關鍵指標，可以指示和優化 DevOps 性能的健康狀況。DORA 四鍵項目旨在生成有價值的數據并收集見解，以提高圍繞 DevOps 實踐的工程生產力。以下是四個核心 DevOps 指標，通常稱為DORA 指標：

• 部署頻率： 衡量團隊成功將變更發布到生產環境的頻率，表明團隊交付軟件的速度。
• 變更提前期： 從開始處理變更請求到將其投入生產并最終提供給客戶的時間稱為變更提前期。團隊使用提前期來確定開發過程的效率。
• 更改失敗率： 衡量產品更改在發布后導致失敗的比率。它是團隊編寫的代碼質量的指標。
• 平均恢復時間： 衡量通過生產變更解決事件或故障所需的時間。

雖然部署頻率和變更提前期衡量的是團隊的速度，但變更失敗率和平均恢復時間指標側重于軟件的穩定性。

根據 2019 年加速 DevOps 狀態報告，這種格式的 DevOps 指標分析團隊并將其分為低、中、高和精英績效者，后者達到或超過其組織績效目標的可能性是后者的兩倍。通過使用這些指標，組織可以跟蹤和改進團隊的績效和流程的有效性。

部署頻率

團隊的部署頻率直接轉化為將代碼部署或發布到生產環境的速度。這個 DevOps 指標可能因團隊、功能和組織而異。它還取決于產品和內部部署標準。例如，一些應用程序可能每年只發布幾個大版本，而其他應用程序可以在一個季度內進行大量的小部署。

部署頻率如何影響業務

更高的部署頻率比率可能表明團隊正在更快地跟蹤或改進或向市場推出新功能。更高的部署頻率也為客戶和團隊之間的持續反饋循環鋪平了道路，這種反饋循環轉化為向最終用戶發布的產品的更好版本。谷歌對 DORA的研究還表明，積極主動的團隊具有更高的部署頻率，這意味著他們可以始終如一地按需部署。

如何測量

長時間跟蹤部署頻率有助于跟蹤速度變化、跟蹤瓶頸并更快地采取糾正措施。衡量部署頻率的一種有效方法是從 GitHub、Jira 和其他地方收集數據，以確定計劃的代碼是否已發布。這樣做不僅可以讓管理人員跟蹤部署頻率，還可以清除阻礙因素，因為對部署頻率的定期關注可以揭示錯過的部署，并了解其背后的模式和原因。

實現更高部署頻率的技巧

• 自動執行部署過程中的重復性任務，并設置和配置持續交付管道
• 對發布進行持續改進以優化最終結果
• 僅在必要時獲得有關改進的持續反饋
• 明確要求和期望，不給不必要的范圍蔓延留下余地
• 優化周期時間以提高效率，以確保定期進行部署

更改交貨時間

團隊使用變更提前期（不要與周期時間/提前期混淆）來確定他們的開發過程的效率。提前期過長可能是由于程序效率低下或開發或部署管道中的瓶頸造成的。團隊的目標通常是更短的交付周期，但更長的交付周期可能并不總是麻煩的跡象。某些版本可能很復雜，可能需要更多時間才能交付。

變更提前期如何影響業務

LTC 指標有助于跟蹤流程中的低效率。提前期優化的主要目標之一是通過自動化增加部署，主要是測試過程，以縮短部署的總體時間。與部署頻率一樣，交付周期也可能因團隊和產品而異。因此，組織應該隨著時間的推移跟蹤、設定基準并比較各個團隊的績效，而不是將他們與其他團隊進行比較。

如何測量

交付周期是通過測量初始提交和發布投入生產日期之間的時間來計算的。由于交付周期由開發周期中的多個階段組成，因此團隊應計算開發過程每個階段的時間以識別瓶頸。跟蹤周期時間有助于了解開發過程中的不同步驟、識別有問題的區域并對其執行 RCA。始終如一地這樣做有助于發現瓶頸并在未來的任何開發周期中更好地制定戰略。

優化交貨時間的技巧

縮短交付周期的一個關鍵因素是改善測試和開發團隊之間的協作以提高質量保證。這有助于經理更好地了解 DevOps 周期時間。

• 自動化測試可以消除耗費開發人員時間的重復工作和瑣碎的更改。
• 以小增量工作以保持在當前模塊的頂部，以確保沒有將來可能需要返工的錯誤。
• 對復制版本進行更改，以免破壞主要代碼。

更改失敗率

更改失敗率衡量生產中部署失敗的百分比，需要錯誤修復或回滾。此 DevOps 指標檢查部署次數與失敗次數的對比，以解碼 DevOps 流程的效率。

變更失敗率如何影響開發過程

變更失敗率指標跟蹤花在補救問題上而不是開發新項目上的時間。這有助于管理人員了解他們的團隊將精力花在哪里，并有助于使團隊和流程保持一致，將更多時間花在編寫新代碼上，而不是處理錯誤和返工。

如何測量

將部署失敗的次數除以部署總數即可得出 CFR。團隊應確保將變更失敗率降至最低。但這也不意味著要花太多時間構建和測試每個模塊，因為這可能會影響交付時間。

優化變更失敗的技巧

更改失敗并不總是表示代碼執行不當。有時，諸如需求不明確或小錯誤等外部因素會導致程序失敗。

• 確保按照沖刺計劃編寫、審查和測試代碼
• 保持沖刺速度和代碼流失指標在檢查中可以深入了解所做的更改及其背后的原因

平均恢復時間 (MTTR)

MTTR 是衡量部署后采取反制措施解決問題所需時間的指標。團隊從故障中快速恢復的能力取決于他們在故障發生后立即識別故障 (MTTD) 并發布補救措施或回滾導致故障的任何更改的能力。這通常是通過持續監控系統健康狀況并在發生故障時通知操作人員來實現的。

MTTR 如何影響開發過程

MTTR 測試團隊解決錯誤或事件的速度。高績效團隊從事件中快速恢復，而低績效團隊可能需要長達一周或更長時間才能恢復。衡量 MTTR 是確保彈性和穩定性的重要實踐。

如何測量

MTTR 可以通過計算事件發生和解決之間的時間來衡量。為解決事件，運營團隊應配備正確的工具、協議和權限。

優化 MTTR 的技巧

要實現快速 MTTR 指標，請以小增量部署軟件以降低風險，并部署自動化監控解決方案以預防故障。

• 構建在發布前經過測試的更健壯的系統
• 更好的日志記錄提供數據以在出現故障時更快地診斷和發現問題
• 這可以通過不斷檢查錯誤和阻塞來實現

改進 DORA 指標的策略

關注框架

簡單地使用 DORA 指標并不能改進開發過程。管理人員還應制定有關如何利用和提升 DORA 指標的策略。做到這一點的最好方法是對團隊的當前地位進行基準測試，并繪制項目目標和計劃的路線圖。在定義目標和截止日期時要關注的兩個主要因素是項目分配和項目計劃的準確性。

管理人員應確定團隊并根據業務優先級分配項目。優化的項目分配流程還有助于確保工程團隊在任何給定時間都在正確的項目上工作，并在需要時進行修改。

項目規劃使管理人員能夠掌握時間線并確保在沖刺中實現目標。始終如一地衡量這一點有助于識別和解決阻礙進展的障礙。在這里，周期時間、代碼攪動和沖刺速度等指標提供了實現每個沖刺目標和按時完成所需的支持。

促進合作

定義目標并調整團隊以實現目標可以幫助取得更好的結果。一種有效的方法是召開每日站立會議，將團隊聚集在一起并明確目標。站立會議還可以讓每個人都了解誰在做什么，但更重要的是，它可以幫助團隊識別障礙并規劃路線圖來解決這些問題。為了使站立會議高效和有效，管理人員可以采用異步站立會議，這不僅可以達到目的，還可以保留工程師的專注時間和文檔信息以備將來參考。

建立更好的工作流程

管理人員應專注于創建基于數據的工作流程。他們應該有辦法收集各種軟件工程指標，例如拉取請求指標、開發人員專注時間、團隊周期時間、代碼流失和其他指標，以設計一個高質量且失敗幾率低的數據豐富過程。

呼吁 CI/CD

持續集成和持續交付結合了將所有編寫的代碼持續集成到共享存儲庫中，觸發自動化測試，并最終提供持續交付手段的實踐。CI/CD 使將新代碼從提交到生產所需的大部分或全部手動干預自動化。這包括構建、測試和部署階段。有了 CI/CD 管道，開發人員可以返工和更改代碼，這些代碼會自動測試并推送以進行部署。這促進了更高的開發頻率和更改的提前期，同時也限制了更改失敗的空間。