如何正確執行 DORA 指標

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

部署頻率

定義

部署頻率衡量 團隊成功將程式碼釋出到生產環境的頻率。
 

重要性

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

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

衡量部署頻率

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

評估部署頻率

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

Elite	High	Medium	Low
按需部署（每天多次部署）	每週一次到每月一次部署	每週一次至每月一次部署	每月一次至每六個月一次部署

Source: 2019 Accelerate State of DevOps, Google
 

變更的交付時間

定義

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

重要性

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

測量變更的交付時間

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

評估變更交付時間

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

Elite	High	Medium	Low
不足一天	一天至一週	一週至一個月	一個月至六個月

Source: 2019 Accelerate State of DevOps, Google
 

恢復服務的時間

定義

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

重要性

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

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

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

• 綜合監測：有時也稱為 "pinger"。如果我們向一個設定的 URL 傳送一致的請求，我們就能確定事件發生的確切時間範圍。這樣做的明顯弊端是出現假陰性，即綜合監控器認為服務沒有當機，因為儘管出現了意外行為，但返回的結果卻是 200。在過去幾年中，綜合監控已經變得更加複雜，因此可以進行更像端到端的測試。

• 記錄錯誤、引發異常或直接監控程式碼：如果出現內部錯誤，我們通常就可以認為發生了故障。這種系統既可能將真實的故障誤判為無故障（假陰性），也可能在沒有故障的時候誤報故障（假陽性）。有時函式可能會引發錯誤，但使用者仍能得到滿意的響應。這可能需要改變對錯誤的定義。例如，我們可能有一個使用者查詢服務，當沒有找到匹配記錄時就會引發錯誤。因此在透過日誌記錄衡量事件時，我們需要改變非關鍵故障引發標誌的級別。

• 透過統計閾值（如響應時間）進行測量：從統計效能推斷事件是可行。如果響應時間急劇延長，儘管容量有所降低、服務仍在執行，也可將其視為事件。這種方法的最大優點是能密切反映使用者的期望。一個網站的載入時間超過 15 秒，即使程式碼從未出錯，或者系統最終總是傳送 "良好 "的響應，使用者也會認為該網站 "當機 "了。
   

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

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

評估恢復服務的時間

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

Elite	High	Medium	Low
1小時以內	1天以內	1天以內	1周至1個月之間

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 小組的標準是：

Elite	High	Medium	Low
0-15%	0-15%	0-15%	46-60%

Source: 2019 Accelerate State of DevOps, Google
 

特別情況

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

DORA 指標能說明什麼？

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

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

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

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

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

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

參考連結: