掃二維碼與項目經(jīng)理溝通
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
我們看到越來越多的組織重新關(guān)注采用和改進他們的 DevOps 實踐,以幫助優(yōu)化他們的軟件開發(fā)生命周期并提高他們的交付速度以更快地到達市場和客戶。以下是您需要了解的四個關(guān)鍵 DevOps 指標,以及團隊如何使用這些指標來提高開發(fā)效率和性能,從而為他們的客戶構(gòu)建更好更快的產(chǎn)品。

創(chuàng)新互聯(lián)公司公司2013年成立,是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司,擁有項目網(wǎng)站設(shè)計、網(wǎng)站建設(shè)網(wǎng)站策劃,項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命,1280元惠州做網(wǎng)站,已為上家服務(wù),為惠州各地企業(yè)和個人服務(wù),聯(lián)系電話:18980820575
DevOps 指標是用于衡量團隊 DevOps 軟件開發(fā)過程的性能和效率的數(shù)據(jù)點。由于 DevOps 集成了開發(fā)和運維的功能,因此指標應(yīng)該能夠衡量和優(yōu)化相關(guān)流程和人員的績效。
從 DevOps 指標中衡量和收集見解可以幫助管理人員收集對其團隊流程和瓶頸的可操作見解,并在出現(xiàn)障礙時迅速采取補救措施。因此,DevOps 指標使團隊能夠成功完成目標。
Google 的DevOps 研究與評估(DORA) 團隊確定了四個關(guān)鍵指標,可以指示和優(yōu)化 DevOps 性能的健康狀況。DORA 四鍵項目旨在生成有價值的數(shù)據(jù)并收集見解,以提高圍繞 DevOps 實踐的工程生產(chǎn)力。以下是四個核心 DevOps 指標,通常稱為DORA 指標:
雖然部署頻率和變更提前期衡量的是團隊的速度,但變更失敗率和平均恢復(fù)時間指標側(cè)重于軟件的穩(wěn)定性。
根據(jù) 2019 年加速 DevOps 狀態(tài)報告,這種格式的 DevOps 指標分析團隊并將其分為低、中、高和精英績效者,后者達到或超過其組織績效目標的可能性是后者的兩倍。通過使用這些指標,組織可以跟蹤和改進團隊的績效和流程的有效性。
團隊的部署頻率直接轉(zhuǎn)化為將代碼部署或發(fā)布到生產(chǎn)環(huán)境的速度。這個 DevOps 指標可能因團隊、功能和組織而異。它還取決于產(chǎn)品和內(nèi)部部署標準。例如,一些應(yīng)用程序可能每年只發(fā)布幾個大版本,而其他應(yīng)用程序可以在一個季度內(nèi)進行大量的小部署。
更高的部署頻率比率可能表明團隊正在更快地跟蹤或改進或向市場推出新功能。更高的部署頻率也為客戶和團隊之間的持續(xù)反饋循環(huán)鋪平了道路,這種反饋循環(huán)轉(zhuǎn)化為向最終用戶發(fā)布的產(chǎn)品的更好版本。谷歌對 DORA的研究還表明,積極主動的團隊具有更高的部署頻率,這意味著他們可以始終如一地按需部署。
長時間跟蹤部署頻率有助于跟蹤速度變化、跟蹤瓶頸并更快地采取糾正措施。衡量部署頻率的一種有效方法是從 GitHub、Jira 和其他地方收集數(shù)據(jù),以確定計劃的代碼是否已發(fā)布。這樣做不僅可以讓管理人員跟蹤部署頻率,還可以清除阻礙因素,因為對部署頻率的定期關(guān)注可以揭示錯過的部署,并了解其背后的模式和原因。
團隊使用變更提前期(不要與周期時間/提前期混淆)來確定他們的開發(fā)過程的效率。提前期過長可能是由于程序效率低下或開發(fā)或部署管道中的瓶頸造成的。團隊的目標通常是更短的交付周期,但更長的交付周期可能并不總是麻煩的跡象。某些版本可能很復(fù)雜,可能需要更多時間才能交付。
LTC 指標有助于跟蹤流程中的低效率。提前期優(yōu)化的主要目標之一是通過自動化增加部署,主要是測試過程,以縮短部署的總體時間。與部署頻率一樣,交付周期也可能因團隊和產(chǎn)品而異。因此,組織應(yīng)該隨著時間的推移跟蹤、設(shè)定基準并比較各個團隊的績效,而不是將他們與其他團隊進行比較。
交付周期是通過測量初始提交和發(fā)布投入生產(chǎn)日期之間的時間來計算的。由于交付周期由開發(fā)周期中的多個階段組成,因此團隊應(yīng)計算開發(fā)過程每個階段的時間以識別瓶頸。跟蹤周期時間有助于了解開發(fā)過程中的不同步驟、識別有問題的區(qū)域并對其執(zhí)行 RCA。始終如一地這樣做有助于發(fā)現(xiàn)瓶頸并在未來的任何開發(fā)周期中更好地制定戰(zhàn)略。
縮短交付周期的一個關(guān)鍵因素是改善測試和開發(fā)團隊之間的協(xié)作以提高質(zhì)量保證。這有助于經(jīng)理更好地了解 DevOps 周期時間。
更改失敗率衡量生產(chǎn)中部署失敗的百分比,需要錯誤修復(fù)或回滾。此 DevOps 指標檢查部署次數(shù)與失敗次數(shù)的對比,以解碼 DevOps 流程的效率。
變更失敗率指標跟蹤花在補救問題上而不是開發(fā)新項目上的時間。這有助于管理人員了解他們的團隊將精力花在哪里,并有助于使團隊和流程保持一致,將更多時間花在編寫新代碼上,而不是處理錯誤和返工。
將部署失敗的次數(shù)除以部署總數(shù)即可得出 CFR。團隊應(yīng)確保將變更失敗率降至最低。但這也不意味著要花太多時間構(gòu)建和測試每個模塊,因為這可能會影響交付時間。
更改失敗并不總是表示代碼執(zhí)行不當。有時,諸如需求不明確或小錯誤等外部因素會導(dǎo)致程序失敗。
MTTR 是衡量部署后采取反制措施解決問題所需時間的指標。團隊從故障中快速恢復(fù)的能力取決于他們在故障發(fā)生后立即識別故障 (MTTD) 并發(fā)布補救措施或回滾導(dǎo)致故障的任何更改的能力。這通常是通過持續(xù)監(jiān)控系統(tǒng)健康狀況并在發(fā)生故障時通知操作人員來實現(xiàn)的。
MTTR 測試團隊解決錯誤或事件的速度。高績效團隊從事件中快速恢復(fù),而低績效團隊可能需要長達一周或更長時間才能恢復(fù)。衡量 MTTR 是確保彈性和穩(wěn)定性的重要實踐。
MTTR 可以通過計算事件發(fā)生和解決之間的時間來衡量。為解決事件,運營團隊應(yīng)配備正確的工具、協(xié)議和權(quán)限。
要實現(xiàn)快速 MTTR 指標,請以小增量部署軟件以降低風險,并部署自動化監(jiān)控解決方案以預(yù)防故障。
簡單地使用 DORA 指標并不能改進開發(fā)過程。管理人員還應(yīng)制定有關(guān)如何利用和提升 DORA 指標的策略。做到這一點的最好方法是對團隊的當前地位進行基準測試,并繪制項目目標和計劃的路線圖。在定義目標和截止日期時要關(guān)注的兩個主要因素是項目分配和項目計劃的準確性。
管理人員應(yīng)確定團隊并根據(jù)業(yè)務(wù)優(yōu)先級分配項目。優(yōu)化的項目分配流程還有助于確保工程團隊在任何給定時間都在正確的項目上工作,并在需要時進行修改。
項目規(guī)劃使管理人員能夠掌握時間線并確保在沖刺中實現(xiàn)目標。始終如一地衡量這一點有助于識別和解決阻礙進展的障礙。在這里,周期時間、代碼攪動和沖刺速度等指標提供了實現(xiàn)每個沖刺目標和按時完成所需的支持。
定義目標并調(diào)整團隊以實現(xiàn)目標可以幫助取得更好的結(jié)果。一種有效的方法是召開每日站立會議,將團隊聚集在一起并明確目標。站立會議還可以讓每個人都了解誰在做什么,但更重要的是,它可以幫助團隊識別障礙并規(guī)劃路線圖來解決這些問題。為了使站立會議高效和有效,管理人員可以采用異步站立會議,這不僅可以達到目的,還可以保留工程師的專注時間和文檔信息以備將來參考。
管理人員應(yīng)專注于創(chuàng)建基于數(shù)據(jù)的工作流程。他們應(yīng)該有辦法收集各種軟件工程指標,例如拉取請求指標、開發(fā)人員專注時間、團隊周期時間、代碼流失和其他指標,以設(shè)計一個高質(zhì)量且失敗幾率低的數(shù)據(jù)豐富過程。
持續(xù)集成和持續(xù)交付結(jié)合了將所有編寫的代碼持續(xù)集成到共享存儲庫中,觸發(fā)自動化測試,并最終提供持續(xù)交付手段的實踐。CI/CD 使將新代碼從提交到生產(chǎn)所需的大部分或全部手動干預(yù)自動化。這包括構(gòu)建、測試和部署階段。有了 CI/CD 管道,開發(fā)人員可以返工和更改代碼,這些代碼會自動測試并推送以進行部署。這促進了更高的開發(fā)頻率和更改的提前期,同時也限制了更改失敗的空間。

我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流