DevOps 研究與 DORA 評(píng)估指標(biāo)可幫助我們深入了解軟件開(kāi)發(fā)和交付流程的性能和效率。這些指標(biāo)包括部署頻率、變更交付時(shí)間、變更失敗率和平均恢復(fù)時(shí)間等方面。DORA 指標(biāo)對(duì)于管理開(kāi)發(fā)團(tuán)隊(duì)（從團(tuán)隊(duì)領(lǐng)導(dǎo)到 CTO）都很重要，因?yàn)檫@些指標(biāo)提供了對(duì)團(tuán)隊(duì)交付軟件情況的數(shù)據(jù)驅(qū)動(dòng)的了解。這篇文章將帶您了解這些指標(biāo)是如何計(jì)算出來(lái)的，以及它能告訴我們團(tuán)隊(duì)的表現(xiàn)如何。
部署頻率
定義
部署頻率衡量團(tuán)隊(duì)成功將代碼發(fā)布到生產(chǎn)環(huán)境的頻率。
重要性
高部署頻率通常是成熟的 CI/CD 流水線以及開(kāi)發(fā)、QA 和運(yùn)營(yíng)之間有效協(xié)作的標(biāo)志。它能加快反饋循環(huán)并更快地適應(yīng)市場(chǎng)變化。
請(qǐng)注意，在 DORA 的四個(gè)指標(biāo)中，這是唯一一個(gè)越高越好的指標(biāo)，因此為了便于繪制圖表，您可能需要計(jì)算 1/頻率或類似的反向指標(biāo)"平均部署間隔時(shí)間"，數(shù)值越高意味著發(fā)布速度越慢。
衡量部署頻率
本文中的度量指標(biāo)按照難度從易到難的順序排列。部署頻率只要求我們知道部署發(fā)生在某個(gè)時(shí)間。在此基礎(chǔ)上，我們就可以計(jì)算出以日、周或月為單位的柱狀圖。在 DORA 指標(biāo)項(xiàng)目 "四個(gè)關(guān)鍵"中，計(jì)算中的唯一復(fù)雜之處是為沒(méi)有部署的時(shí)間段創(chuàng)建行。
評(píng)估部署頻率
更頻繁的部署意味著更快、更敏捷的產(chǎn)品團(tuán)隊(duì)。性能級(jí)別定義參考以下：
|
Elite | High | Medium | Low |
按需部署（每天多次部署） | 每周一次到每月一次部署 | 每周一次至每月一次部署 | 每月一次至每六個(gè)月一次部署 |
Source: 2019 Accelerate State of DevOps, Google
變更的交付時(shí)間
定義
變更的準(zhǔn)備時(shí)間是指將提交部署到生產(chǎn)中所需的中位時(shí)間。計(jì)算提交和成功部署到生產(chǎn)之間的時(shí)間差。取特定時(shí)間段內(nèi)這些值的中位數(shù)。
重要性
更短的交付周期通常表明開(kāi)發(fā)和部署流程得到了簡(jiǎn)化。這表明團(tuán)隊(duì)可以快速交付功能、修復(fù)或更新。
測(cè)量變更的交付時(shí)間
在測(cè)量變更的交付時(shí)間時(shí)，時(shí)間跨度的起點(diǎn)應(yīng)該很簡(jiǎn)單：即拉取請(qǐng)求（PR）的創(chuàng)建或合并時(shí)間。要獲得提交部署到生產(chǎn)中的時(shí)間，我們需要部署頻率中的部署信息。同時(shí)還要求變更流程的開(kāi)始包含一個(gè) ID，該 ID 將貫穿部署步驟。這可能看起來(lái)像部署上的一個(gè)包含拉取請(qǐng)求 ID 的標(biāo)簽。只要 ID 從拉動(dòng)請(qǐng)求一直延續(xù)到部署即可。當(dāng)我們有了一個(gè) Lead_times 數(shù)組，我們就可以將這些交付時(shí)間相加，然后除以 {length of time window}. 。
評(píng)估變更交付時(shí)間
雖然改進(jìn)審核流程等措施可能會(huì)增加這一價(jià)值，但一般來(lái)說(shuō)，變更最好還是在提交后不久發(fā)生。性能級(jí)別定義參考以下：
|
Elite | High | Medium | Low |
不足一天 | 一天至一周 | 一周至一個(gè)月 | 一個(gè)月至六個(gè)月 |
Source: 2019 Accelerate State of DevOps, Google
恢復(fù)服務(wù)的時(shí)間
定義
恢復(fù)服務(wù)所需時(shí)間是指發(fā)生故障后恢復(fù)服務(wù)所需的中位時(shí)間。當(dāng)相關(guān)錯(cuò)誤或事件報(bào)告關(guān)閉時(shí)，即認(rèn)為修復(fù)工作完成。
重要性
恢復(fù)服務(wù)的時(shí)間越短，說(shuō)明事故管理越有效，系統(tǒng)越有彈性。它能最大限度地減少停機(jī)時(shí)間和對(duì)終端用戶的影響。
如何衡量恢復(fù)服務(wù)所需的時(shí)間
恢復(fù)服務(wù)的時(shí)間是最難衡量的指標(biāo)。與其他三個(gè)完全可以通過(guò)源控制來(lái)衡量的指標(biāo)不同，我們需要知道事件開(kāi)始和結(jié)束的時(shí)間，因?yàn)槊總€(gè)人認(rèn)定的時(shí)間點(diǎn)都會(huì)有所偏差。在一些企業(yè)中，事件發(fā)生時(shí)間最終會(huì)通過(guò)手動(dòng)輸入來(lái)計(jì)算正常運(yùn)行時(shí)間，但這樣的出的結(jié)果并不理想。一般來(lái)說(shuō)，有三種方法可以確定事件的時(shí)間跨度：
- 綜合監(jiān)測(cè)：有時(shí)也稱為 "pinger"。如果我們向一個(gè)設(shè)定的 URL 發(fā)送一致的請(qǐng)求，我們就能確定事件發(fā)生的確切時(shí)間范圍。這樣做的明顯弊端是出現(xiàn)假陰性，即綜合監(jiān)控器認(rèn)為服務(wù)沒(méi)有宕機(jī)，因?yàn)楸M管出現(xiàn)了意外行為，但返回的結(jié)果卻是 200。在過(guò)去幾年中，綜合監(jiān)控已經(jīng)變得更加復(fù)雜，因此可以進(jìn)行更像端到端的測(cè)試。
- 記錄錯(cuò)誤、引發(fā)異常或直接監(jiān)控代碼：如果出現(xiàn)內(nèi)部錯(cuò)誤，我們通常就可以認(rèn)為發(fā)生了故障。這種系統(tǒng)既可能將真實(shí)的故障誤判為無(wú)故障（假陰性），也可能在沒(méi)有故障的時(shí)候誤報(bào)故障（假陽(yáng)性）。有時(shí)函數(shù)可能會(huì)引發(fā)錯(cuò)誤，但用戶仍能得到滿意的響應(yīng)。這可能需要改變對(duì)錯(cuò)誤的定義。例如，我們可能有一個(gè)用戶查詢服務(wù)，當(dāng)沒(méi)有找到匹配記錄時(shí)就會(huì)引發(fā)錯(cuò)誤。因此在通過(guò)日志記錄衡量事件時(shí)，我們需要改變非關(guān)鍵故障引發(fā)標(biāo)志的級(jí)別。
- 通過(guò)統(tǒng)計(jì)閾值（如響應(yīng)時(shí)間）進(jìn)行測(cè)量：從統(tǒng)計(jì)性能推斷事件是可行。如果響應(yīng)時(shí)間急劇延長(zhǎng)，盡管容量有所降低、服務(wù)仍在運(yùn)行，也可將其視為事件。這種方法的最大優(yōu)點(diǎn)是能密切反映用戶的期望。一個(gè)網(wǎng)站的加載時(shí)間超過(guò) 15 秒，即使代碼從未出錯(cuò)，或者系統(tǒng)最終總是發(fā)送 "良好 "的響應(yīng)，用戶也會(huì)認(rèn)為該網(wǎng)站 "宕機(jī) "了。
除非您目前正在非常密切地測(cè)量事件，否則確定恢復(fù)服務(wù)的時(shí)間很可能需要使用可觀測(cè)性工具來(lái)測(cè)量新信息。對(duì)于剛剛探索測(cè)量開(kāi)發(fā)人員速度的小型團(tuán)隊(duì)來(lái)說(shuō)，手動(dòng)記錄事件發(fā)生時(shí)間作為事后分析流程的一部分也許是可行的。
恢復(fù)服務(wù)時(shí)間統(tǒng)計(jì)的最終計(jì)算結(jié)果為: sum([array of all incident lengths])/{number of incidents} .
評(píng)估恢復(fù)服務(wù)的時(shí)間
該指標(biāo)可能已經(jīng)成為運(yùn)營(yíng)團(tuán)隊(duì)的核心能力。性能級(jí)別定義參考以下：
|
Elite | High | Medium | Low |
1小時(shí)以內(nèi) | 1天以內(nèi) | 1天以內(nèi) | 1周至1個(gè)月之間 |
Source: 2019 Accelerate State of DevOps, Google
變更失敗率
定義
變更失敗率是指失敗的部署數(shù)量與部署總數(shù)的比率。
重要性
變更失敗率越低，說(shuō)明系統(tǒng)越可靠，測(cè)試程序越有效。它表明新的變更不太可能帶來(lái)問(wèn)題。
如何衡量變更失敗率
在默認(rèn)情況下，變更失敗率（如恢復(fù)服務(wù)的時(shí)間）依賴于計(jì)算部署和事件，并計(jì)算兩者之間的比率。這有一些隱含的假設(shè)：它假定唯一重要的故障是那些影響用戶的故障，并且所有失敗的部署都持續(xù)了足夠長(zhǎng)的時(shí)間，以至于引發(fā)事故。還有一個(gè)問(wèn)題是，這里關(guān)鍵的衡量標(biāo)準(zhǔn)是事件的數(shù)量，而不是時(shí)間的長(zhǎng)短。因此，如果一周內(nèi)有多次部署，持續(xù) 24 小時(shí)的故障看起來(lái)沒(méi)什么問(wèn)題，但 20 次 5 分鐘的中斷看起來(lái)就非常可怕了。如何獲得更可靠的變更故障率？有三種可能的途徑：
- 定義標(biāo)準(zhǔn)回滾流程。如果您決定事件響應(yīng)團(tuán)隊(duì)始終標(biāo)記失敗的 PR 或始終使用 git rewind，則您可以直接測(cè)量更改何時(shí)失敗。
- 采用金絲雀流程，例如 Argo Rollouts，并將回滾計(jì)為失敗。
- 定義事件何時(shí)算作失敗的標(biāo)準(zhǔn)。例如，根據(jù)部署頻率設(shè)置算作故障的事件的最短長(zhǎng)度。
在上述例子中，看起來(lái)變更失敗率是一個(gè)比其他三個(gè) DORA 指標(biāo)更模糊的統(tǒng)計(jì)數(shù)據(jù)。不過(guò)根據(jù) DORA 小組，變更失敗率的最終計(jì)算方式是 {number of deployments in time window} / {number of failures in time window} 。
評(píng)估變更失敗率
有時(shí)，變更的失敗率可能包括較高的誤報(bào)率。如果您將部署的最后階段用作測(cè)試組件，比如進(jìn)行最終集成測(cè)試，那么如果變更經(jīng)常失敗，可能也沒(méi)什么好擔(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
特別情況
對(duì)于所有這四種指標(biāo)，都有可能出現(xiàn)指標(biāo)增量實(shí)際上情況并沒(méi)有那么糟糕的時(shí)候。例如，如果我們通過(guò)實(shí)驗(yàn)提高代碼部署的速度和便利性，那么變更失敗率就有可能上升。有了更好、更可靠的審查流程，部署時(shí)間可能會(huì)增加。但是，在所有這些情況下，流程的改進(jìn)應(yīng)該會(huì)導(dǎo)致其他三個(gè)指標(biāo)的顯著改善。這些非常高層次的指標(biāo)可以幫助更多好的改變，即小的變更會(huì)帶來(lái)速度上的大改善。
DORA 指標(biāo)能說(shuō)明什么？
DORA 指標(biāo)旨在提示開(kāi)發(fā)團(tuán)隊(duì)的整體生產(chǎn)力。這些指標(biāo)衡量的是您的開(kāi)發(fā)人員平臺(tái)提高開(kāi)發(fā)人員速度的能力；換句話說(shuō)，是開(kāi)發(fā)人員環(huán)境、部署系統(tǒng)和測(cè)試在輕松可靠地發(fā)布代碼方面的效率。
開(kāi)發(fā)團(tuán)隊(duì)可能非常努力地工作并編寫出了優(yōu)秀的代碼，但他們的 DORA 指標(biāo)可能仍然很糟糕，因?yàn)闇y(cè)試和部署過(guò)程容易出錯(cuò)、工作量大，而且需要大量的人工干預(yù)。這種困難的開(kāi)發(fā)人員體驗(yàn)會(huì)影響開(kāi)發(fā)人員的整體開(kāi)發(fā)速度，但解決辦法并不是讓產(chǎn)品工程師更加努力地工作。解決 DORA 指標(biāo)不佳問(wèn)題的辦法是認(rèn)真審視內(nèi)部平臺(tái)的開(kāi)發(fā)人員體驗(yàn)，并將平臺(tái)工程作為團(tuán)隊(duì)的真正優(yōu)先事項(xiàng)。
DORA 關(guān)系到開(kāi)發(fā)人員的生產(chǎn)力
如果代碼易于測(cè)試和發(fā)布，并且您的開(kāi)發(fā)環(huán)境與生產(chǎn)環(huán)境非常相似，那么開(kāi)發(fā)團(tuán)隊(duì)就可以減少回滾，更快地將代碼發(fā)布到生產(chǎn)環(huán)境。這種速度不僅僅是技術(shù)卓越性的指標(biāo)，它意味著你的團(tuán)隊(duì)在滿足用戶需求方面做得更好。
了解和實(shí)施 DORA 指標(biāo)不僅是一項(xiàng)技術(shù)工作，也是平臺(tái)工程師和開(kāi)發(fā)團(tuán)隊(duì)領(lǐng)導(dǎo)者的一項(xiàng)戰(zhàn)略任務(wù)。這些指標(biāo)提供了從代碼提交到部署和事件解決的開(kāi)發(fā)流水線的整體視圖。它們是衡量團(tuán)隊(duì)敏捷性、運(yùn)營(yíng)效率和整體開(kāi)發(fā)速度的關(guān)鍵指標(biāo)。
雖然只關(guān)注開(kāi)發(fā)團(tuán)隊(duì)的產(chǎn)出很有誘惑力，但 DORA 指標(biāo)顯示，開(kāi)發(fā)人員的體驗(yàn)同樣至關(guān)重要。繁瑣、容易出錯(cuò)的部署流程甚至?xí)?yán)重阻礙最有能力的開(kāi)發(fā)團(tuán)隊(duì)。投資平臺(tái)工程和改善開(kāi)發(fā)人員體驗(yàn)是優(yōu)化這些指標(biāo)的重要步驟。請(qǐng)記住，在快節(jié)奏的軟件開(kāi)發(fā)領(lǐng)域，原地踏步是行不通的。將 DORA 指標(biāo)作為優(yōu)先考慮事項(xiàng)，企業(yè)將具備良好的適應(yīng)能力、創(chuàng)新能力和卓越能力。
參考鏈接:
https://thenewstack.io/how-to-do-dora-metrics-right/
版權(quán)聲明：本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻(xiàn)，該文觀點(diǎn)僅代表作者本人。本站僅提供信息存儲(chǔ)空間服務(wù)，不擁有所有權(quán)，不承擔(dān)相關(guān)法律責(zé)任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容， 請(qǐng)發(fā)送郵件至 舉報(bào)，一經(jīng)查實(shí)，本站將立刻刪除。