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

部署頻率

定義

部署頻率衡量團(tuán)隊成功將代碼發(fā)布到生產(chǎn)環(huán)境的頻率。
?

重要性

高部署頻率通常是成熟的 CI/CD 流水線以及開發(fā)、QA 和運營之間有效協(xié)作的標(biāo)志。它能加快反饋循環(huán)并更快地適應(yīng)市場變化。
?

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

衡量部署頻率

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

評估部署頻率

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

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

Source: 2019 Accelerate State of DevOps, Google
?

變更的交付時間

定義

變更的準(zhǔn)備時間是指將提交部署到生產(chǎn)中所需的中位時間。計算提交和成功部署到生產(chǎn)之間的時間差。取特定時間段內(nèi)這些值的中位數(shù)。
?

重要性

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

測量變更的交付時間

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

評估變更交付時間

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

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

Source: 2019 Accelerate State of DevOps, Google
?

恢復(fù)服務(wù)的時間

定義

恢復(fù)服務(wù)所需時間是指發(fā)生故障后恢復(fù)服務(wù)所需的中位時間。當(dāng)相關(guān)錯誤或事件報告關(guān)閉時，即認(rèn)為修復(fù)工作完成。
?

重要性

恢復(fù)服務(wù)的時間越短，說明事故管理越有效，系統(tǒng)越有彈性。它能最大限度地減少停機(jī)時間和對終端用戶的影響。
?

如何衡量恢復(fù)服務(wù)所需的時間

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

• 綜合監(jiān)測：有時也稱為 "pinger"。如果我們向一個設(shè)定的 URL 發(fā)送一致的請求，我們就能確定事件發(fā)生的確切時間范圍。這樣做的明顯弊端是出現(xiàn)假陰性，即綜合監(jiān)控器認(rèn)為服務(wù)沒有宕機(jī)，因為盡管出現(xiàn)了意外行為，但返回的結(jié)果卻是 200。在過去幾年中，綜合監(jiān)控已經(jīng)變得更加復(fù)雜，因此可以進(jìn)行更像端到端的測試。

• 記錄錯誤、引發(fā)異常或直接監(jiān)控代碼：如果出現(xiàn)內(nèi)部錯誤，我們通常就可以認(rèn)為發(fā)生了故障。這種系統(tǒng)既可能將真實的故障誤判為無故障（假陰性），也可能在沒有故障的時候誤報故障（假陽性）。有時函數(shù)可能會引發(fā)錯誤，但用戶仍能得到滿意的響應(yīng)。這可能需要改變對錯誤的定義。例如，我們可能有一個用戶查詢服務(wù)，當(dāng)沒有找到匹配記錄時就會引發(fā)錯誤。因此在通過日志記錄衡量事件時，我們需要改變非關(guān)鍵故障引發(fā)標(biāo)志的級別。

• 通過統(tǒng)計閾值（如響應(yīng)時間）進(jìn)行測量：從統(tǒng)計性能推斷事件是可行。如果響應(yīng)時間急劇延長，盡管容量有所降低、服務(wù)仍在運行，也可將其視為事件。這種方法的最大優(yōu)點是能密切反映用戶的期望。一個網(wǎng)站的加載時間超過 15 秒，即使代碼從未出錯，或者系統(tǒng)最終總是發(fā)送 "良好 "的響應(yīng)，用戶也會認(rèn)為該網(wǎng)站 "宕機(jī) "了。
  ?

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

恢復(fù)服務(wù)時間統(tǒng)計的最終計算結(jié)果為: sum([array of all incident lengths])/{number of incidents} .
?

評估恢復(fù)服務(wù)的時間

該指標(biāo)可能已經(jīng)成為運營團(tuán)隊的核心能力。性能級別定義參考以下：
?

Elite	High	Medium	Low
1小時以內(nèi)	1天以內(nèi)	1天以內(nèi)	1周至1個月之間

Source: 2019 Accelerate State of DevOps, Google
?

變更失敗率

定義

變更失敗率是指失敗的部署數(shù)量與部署總數(shù)的比率。
?

重要性

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

如何衡量變更失敗率

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

• 定義標(biāo)準(zhǔn)回滾流程。如果您決定事件響應(yīng)團(tuán)隊始終標(biāo)記失敗的 PR 或始終使用 git rewind，則您可以直接測量更改何時失敗。

• 采用金絲雀流程，例如 Argo Rollouts，并將回滾計為失敗。

• 定義事件何時算作失敗的標(biāo)準(zhǔn)。例如，根據(jù)部署頻率設(shè)置算作故障的事件的最短長度。
  ?

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

評估變更失敗率

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

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

Source: 2019 Accelerate State of DevOps, Google
?

特別情況

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

DORA 指標(biāo)能說明什么？

DORA 指標(biāo)旨在提示開發(fā)團(tuán)隊的整體生產(chǎn)力。這些指標(biāo)衡量的是您的開發(fā)人員平臺提高開發(fā)人員速度的能力；換句話說，是開發(fā)人員環(huán)境、部署系統(tǒng)和測試在輕松可靠地發(fā)布代碼方面的效率。
?

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

DORA 關(guān)系到開發(fā)人員的生產(chǎn)力

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

了解和實施 DORA 指標(biāo)不僅是一項技術(shù)工作，也是平臺工程師和開發(fā)團(tuán)隊領(lǐng)導(dǎo)者的一項戰(zhàn)略任務(wù)。這些指標(biāo)提供了從代碼提交到部署和事件解決的開發(fā)流水線的整體視圖。它們是衡量團(tuán)隊敏捷性、運營效率和整體開發(fā)速度的關(guān)鍵指標(biāo)。
?

雖然只關(guān)注開發(fā)團(tuán)隊的產(chǎn)出很有誘惑力，但 DORA 指標(biāo)顯示，開發(fā)人員的體驗同樣至關(guān)重要。繁瑣、容易出錯的部署流程甚至?xí)?yán)重阻礙最有能力的開發(fā)團(tuán)隊。投資平臺工程和改善開發(fā)人員體驗是優(yōu)化這些指標(biāo)的重要步驟。請記住，在快節(jié)奏的軟件開發(fā)領(lǐng)域，原地踏步是行不通的。將 DORA 指標(biāo)作為優(yōu)先考慮事項，企業(yè)將具備良好的適應(yīng)能力、創(chuàng)新能力和卓越能力。
?

參考鏈接:

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

?

總結(jié)

以上是生活随笔為你收集整理的如何正确执行 DORA 指标的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。