DevOps 研究與 DORA 評估指標可幫助我們深入了解軟件開發和交付流程的性能和效率。這些指標包括部署頻率、變更交付時間、變更失敗率和平均恢復時間等方面。DORA 指標對于管理開發團隊（從團隊領導到 CTO）都很重要，因為這些指標提供了對團隊交付軟件情況的數據驅動的了解。這篇文章將帶您了解這些指標是如何計算出來的，以及它能告訴我們團隊的表現如何。

部署頻率

定義

部署頻率衡量團隊成功將代碼發布到生產環境的頻率。

重要性

高部署頻率通常是成熟的 CI/CD 流水線以及開發、QA 和運營之間有效協作的標志。它能加快反饋循環并更快地適應市場變化。

請注意，在 DORA 的四個指標中，這是唯一一個越高越好的指標，因此為了便于繪制圖表，您可能需要計算 1/頻率或類似的反向指標"平均部署間隔時間"，數值越高意味著發布速度越慢。

衡量部署頻率

本文中的度量指標按照難度從易到難的順序排列。部署頻率只要求我們知道部署發生在某個時間。在此基礎上，我們就可以計算出以日、周或月為單位的柱狀圖。在 DORA 指標項目 "四個關鍵"中，計算中的唯一復雜之處是為沒有部署的時間段創建行。

評估部署頻率

更頻繁的部署意味著更快、更敏捷的產品團隊。性能級別定義參考以下：

Source: 2019 Accelerate State of DevOps, Google

變更的交付時間

定義

變更的準備時間是指將提交部署到生產中所需的中位時間。計算提交和成功部署到生產之間的時間差。取特定時間段內這些值的中位數。

重要性

更短的交付周期通常表明開發和部署流程得到了簡化。這表明團隊可以快速交付功能、修復或更新。

測量變更的交付時間

在測量變更的交付時間時，時間跨度的起點應該很簡單：即拉取請求（PR）的創建或合并時間。要獲得提交部署到生產中的時間，我們需要部署頻率中的部署信息。同時還要求變更流程的開始包含一個 ID，該 ID 將貫穿部署步驟。這可能看起來像部署上的一個包含拉取請求 ID 的標簽。只要 ID 從拉動請求一直延續到部署即可。當我們有了一個 Lead_times 數組，我們就可以將這些交付時間相加，然后除以 {length of time window}. 。

評估變更交付時間

雖然改進審核流程等措施可能會增加這一價值，但一般來說，變更最好還是在提交后不久發生。性能級別定義參考以下：

Source: 2019 Accelerate State of DevOps, Google

恢復服務的時間

定義

恢復服務所需時間是指發生故障后恢復服務所需的中位時間。當相關錯誤或事件報告關閉時，即認為修復工作完成。

重要性

恢復服務的時間越短，說明事故管理越有效，系統越有彈性。它能最大限度地減少停機時間和對終端用戶的影響。

如何衡量恢復服務所需的時間

恢復服務的時間是最難衡量的指標。與其他三個完全可以通過源控制來衡量的指標不同，我們需要知道事件開始和結束的時間，因為每個人認定的時間點都會有所偏差。在一些企業中，事件發生時間最終會通過手動輸入來計算正常運行時間，但這樣的出的結果并不理想。一般來說，有三種方法可以確定事件的時間跨度：

• 綜合監測：有時也稱為 "pinger"。如果我們向一個設定的 URL 發送一致的請求，我們就能確定事件發生的確切時間范圍。這樣做的明顯弊端是出現假陰性，即綜合監控器認為服務沒有宕機，因為盡管出現了意外行為，但返回的結果卻是 200。在過去幾年中，綜合監控已經變得更加復雜，因此可以進行更像端到端的測試。
• 記錄錯誤、引發異常或直接監控代碼：如果出現內部錯誤，我們通常就可以認為發生了故障。這種系統既可能將真實的故障誤判為無故障（假陰性），也可能在沒有故障的時候誤報故障（假陽性）。有時函數可能會引發錯誤，但用戶仍能得到滿意的響應。這可能需要改變對錯誤的定義。例如，我們可能有一個用戶查詢服務，當沒有找到匹配記錄時就會引發錯誤。因此在通過日志記錄衡量事件時，我們需要改變非關鍵故障引發標志的級別。
• 通過統計閾值（如響應時間）進行測量：從統計性能推斷事件是可行。如果響應時間急劇延長，盡管容量有所降低、服務仍在運行，也可將其視為事件。這種方法的最大優點是能密切反映用戶的期望。一個網站的加載時間超過 15 秒，即使代碼從未出錯，或者系統最終總是發送 "良好 "的響應，用戶也會認為該網站 "宕機 "了。

除非您目前正在非常密切地測量事件，否則確定恢復服務的時間很可能需要使用可觀測性工具來測量新信息。對于剛剛探索測量開發人員速度的小型團隊來說，手動記錄事件發生時間作為事后分析流程的一部分也許是可行的。

恢復服務時間統計的最終計算結果為: sum([array of all incident lengths])/{number of incidents} .

評估恢復服務的時間

該指標可能已經成為運營團隊的核心能力。性能級別定義參考以下：

Source: 2019 Accelerate State of DevOps, Google

變更失敗率

定義

變更失敗率是指失敗的部署數量與部署總數的比率。

重要性

變更失敗率越低，說明系統越可靠，測試程序越有效。它表明新的變更不太可能帶來問題。

如何衡量變更失敗率

在默認情況下，變更失敗率（如恢復服務的時間）依賴于計算部署和事件，并計算兩者之間的比率。這有一些隱含的假設：它假定唯一重要的故障是那些影響用戶的故障，并且所有失敗的部署都持續了足夠長的時間，以至于引發事故。還有一個問題是，這里關鍵的衡量標準是事件的數量，而不是時間的長短。因此，如果一周內有多次部署，持續 24 小時的故障看起來沒什么問題，但 20 次 5 分鐘的中斷看起來就非常可怕了。如何獲得更可靠的變更故障率？有三種可能的途徑：

• 定義標準回滾流程。如果您決定事件響應團隊始終標記失敗的 PR 或始終使用 git rewind，則您可以直接測量更改何時失敗。
• 采用金絲雀流程，例如 Argo Rollouts，并將回滾計為失敗。
• 定義事件何時算作失敗的標準。例如，根據部署頻率設置算作故障的事件的最短長度。

在上述例子中，看起來變更失敗率是一個比其他三個 DORA 指標更模糊的統計數據。不過根據 DORA 小組，變更失敗率的最終計算方式是 {number of deployments in time window} / {number of failures in time window} 。

評估變更失敗率

有時，變更的失敗率可能包括較高的誤報率。如果您將部署的最后階段用作測試組件，比如進行最終集成測試，那么如果變更經常失敗，可能也沒什么好擔心的。DORA 小組的標準是：

Source: 2019 Accelerate State of DevOps, Google

特別情況

對于所有這四種指標，都有可能出現指標增量實際上情況并沒有那么糟糕的時候。例如，如果我們通過實驗提高代碼部署的速度和便利性，那么變更失敗率就有可能上升。有了更好、更可靠的審查流程，部署時間可能會增加。但是，在所有這些情況下，流程的改進應該會導致其他三個指標的顯著改善。這些非常高層次的指標可以幫助更多好的改變，即小的變更會帶來速度上的大改善。

DORA 指標能說明什么？

DORA 指標旨在提示開發團隊的整體生產力。這些指標衡量的是您的開發人員平臺提高開發人員速度的能力；換句話說，是開發人員環境、部署系統和測試在輕松可靠地發布代碼方面的效率。

開發團隊可能非常努力地工作并編寫出了優秀的代碼，但他們的 DORA 指標可能仍然很糟糕，因為測試和部署過程容易出錯、工作量大，而且需要大量的人工干預。這種困難的開發人員體驗會影響開發人員的整體開發速度，但解決辦法并不是讓產品工程師更加努力地工作。解決 DORA 指標不佳問題的辦法是認真審視內部平臺的開發人員體驗，并將平臺工程作為團隊的真正優先事項。

DORA 關系到開發人員的生產力

如果代碼易于測試和發布，并且您的開發環境與生產環境非常相似，那么開發團隊就可以減少回滾，更快地將代碼發布到生產環境。這種速度不僅僅是技術卓越性的指標，它意味著你的團隊在滿足用戶需求方面做得更好。

了解和實施 DORA 指標不僅是一項技術工作，也是平臺工程師和開發團隊領導者的一項戰略任務。這些指標提供了從代碼提交到部署和事件解決的開發流水線的整體視圖。它們是衡量團隊敏捷性、運營效率和整體開發速度的關鍵指標。

雖然只關注開發團隊的產出很有誘惑力，但 DORA 指標顯示，開發人員的體驗同樣至關重要。繁瑣、容易出錯的部署流程甚至會嚴重阻礙最有能力的開發團隊。投資平臺工程和改善開發人員體驗是優化這些指標的重要步驟。請記住，在快節奏的軟件開發領域，原地踏步是行不通的。將 DORA 指標作為優先考慮事項，企業將具備良好的適應能力、創新能力和卓越能力。

參考鏈接:

https://thenewstack.io/how-to-do-dora-metrics-right/