建站
咨詢
售后
建站咨詢
新聞中心
學(xué)習(xí)如何使用DevOps指標(biāo)來提高開發(fā)團隊的速度、一致性和效率。
成都創(chuàng)新互聯(lián)服務(wù)項目包括八宿網(wǎng)站建設(shè)、八宿網(wǎng)站制作、八宿網(wǎng)頁制作以及八宿網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，八宿網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到八宿省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
人們看到越來越多的組織重新關(guān)注于采用和改進他們的DevOps實踐，以幫助優(yōu)化他們的軟件開發(fā)生命周期，提高他們的交付速度，以更快地到達市場和客戶。以下是關(guān)于DevOps的四個關(guān)鍵指標(biāo)以及團隊如何使用這些指標(biāo)來提高開發(fā)效率和性能，為客戶構(gòu)建更好、更快的產(chǎn)品所需要知道的全部內(nèi)容。
什么是DevOps指標(biāo)?
DevOps指標(biāo)是用來衡量團隊DevOps軟件開發(fā)過程的性能和效率的數(shù)據(jù)點。因為DevOps集成了開發(fā)和運營的功能，所以指標(biāo)應(yīng)該能夠度量和優(yōu)化流程和相關(guān)人員的性能。
通過DevOps度量和收集見解，可以幫助管理人員對團隊的流程和瓶頸收集可操作的見解，并在遇到阻礙時迅速采取補救措施。因此，DevOps指標(biāo)使團隊能夠成功地完成目標(biāo)?！ ?/p>
DevOps的四個關(guān)鍵指標(biāo)
谷歌的DevOps研究和評估(DORA)團隊已經(jīng)確定了四個可以指示和優(yōu)化DevOps性能健康狀況的關(guān)鍵指標(biāo)。DORA四鍵項目旨在生成有價值的數(shù)據(jù)和收集見解，以提高圍繞DevOps實踐的工程生產(chǎn)率。以下是四個核心DevOps指標(biāo)，通常被稱為DORA指標(biāo):
?部署頻率:度量團隊成功向生產(chǎn)發(fā)布變更的頻率，表明團隊交付軟件的速度。
變更前置時間:從變更請求的工作開始到交付生產(chǎn)并最終交付給客戶的這段時間稱為變更前置時間。團隊使用前置時間來確定開發(fā)過程的效率?！ ?/p>
更改失敗率:度量產(chǎn)品更改在發(fā)布后導(dǎo)致失敗的比率。它是一個團隊所產(chǎn)生的代碼質(zhì)量的指標(biāo)?！ ?/p>
?平均恢復(fù)時間:衡量通過生產(chǎn)變更解決事故或故障所需的時間?！ ?/p>
部署頻率和變更前置時間的度量計算團隊的速度，而變更失敗率和恢復(fù)度量的平均時間則關(guān)注軟件的穩(wěn)定性?！ ?/p>
根據(jù)2019年DevOps加速狀態(tài)報告，這種形式的DevOps指標(biāo)分析并將團隊分為低、中、高和精英表現(xiàn)者，后者達到或超過其組織績效目標(biāo)的可能性是后者的兩倍。通過使用這些指標(biāo)，組織可以跟蹤并改進團隊的績效和過程的有效性。
部署頻率
團隊的部署頻率直接轉(zhuǎn)化為將代碼或版本部署到生產(chǎn)中的速度。這個DevOps指標(biāo)可能因團隊、特性和組織而異。它還取決于產(chǎn)品和內(nèi)部部署標(biāo)準(zhǔn)。例如，一些應(yīng)用程序可能每年只發(fā)布幾個大型版本，而另一些應(yīng)用程序可以在一個季度內(nèi)進行大量小型部署。
部署頻率如何影響業(yè)務(wù)
更高的部署頻率比可能表明團隊正在更快地跟蹤、改進或向市場推出新功能。更高的部署頻率還為客戶和團隊之間的持續(xù)反饋循環(huán)鋪平了道路，從而轉(zhuǎn)化為向最終用戶發(fā)布更好版本的產(chǎn)品。谷歌在DORA上的研究還表明，主動團隊有更高的部署頻率，這意味著他們可以按需部署?！ ?/p>
如何衡量
在一段較長的時間內(nèi)跟蹤部署頻率可以幫助跟蹤速度的變化、跟蹤瓶頸并更快地采取糾正措施。測量部署頻率的一種有效方法是從GitHub、Jira和其他地方收集數(shù)據(jù)，以確定計劃中的代碼是否已交付。這樣做不僅允許管理人員跟蹤部署頻率，而且還可以清除阻礙因素，因為對部署頻率的常規(guī)關(guān)注可以揭示遺漏的部署，并了解其背后的模式和原因?！ ?/p>
實現(xiàn)更高部署頻率的技巧
?自動化部署過程中的重復(fù)任務(wù)，建立和配置連續(xù)交付管道
?對發(fā)布進行持續(xù)改進，以優(yōu)化最終結(jié)果
?只在必要時獲得持續(xù)的改進反饋
?明確需求和期望，不要給不必要的范圍變動留下空間
?優(yōu)化周期時間，使其更有效，以確保部署在定期進行
改變交貨時間
團隊使用變更前置時間(不要與周期時間/前置時間混淆)來確定開發(fā)過程的效率。較長的前置時間可能是由低效的過程或開發(fā)或部署管道中的瓶頸造成的。團隊的目標(biāo)通常是縮短交貨時間，但較高的交貨時間并不總是麻煩的跡象。有些版本可能很復(fù)雜，可能需要更多的時間來交付?！ ?/p>
交貨時間的改變?nèi)绾斡绊憳I(yè)務(wù)
LTC指標(biāo)有助于跟蹤流程中的低效率。前置時間優(yōu)化的主要目標(biāo)之一是通過自動化(主要是測試過程)來增加部署，從而縮短部署的總體時間。與部署頻率一樣，前置時間也可能因團隊和產(chǎn)品而異。因此，組織應(yīng)該跟蹤、設(shè)置基準(zhǔn)，并隨著時間的推移比較單個團隊的表現(xiàn)，而不是將它們與其他團隊進行比較?！ ?/p>
如何衡量
前置時間是通過測量初始提交和發(fā)布版本投入生產(chǎn)之間的時間來計算的。由于交貨期由開發(fā)周期中的多個階段組成，團隊?wèi)?yīng)該計算開發(fā)過程的每個階段的時間，以確定瓶頸。跟蹤周期時間可以幫助理解開發(fā)過程中的不同步驟，確定有問題的區(qū)域，并執(zhí)行相同的RCA。堅持這樣做有助于發(fā)現(xiàn)瓶頸，并在未來的開發(fā)周期中更好地制定戰(zhàn)略?！ ?/p>
優(yōu)化交貨時間的建議
縮短交貨時間的一個關(guān)鍵因素是改進測試和開發(fā)團隊之間的協(xié)作，以改進質(zhì)量保證。這有助于經(jīng)理更好地理解DevOps的周期時間?！ ?/p>
?自動化測試可以消除重復(fù)的工作和消耗開發(fā)人員時間的瑣碎更改?！ ?/p>
?工作在小增量保持在當(dāng)前模塊的頂部，以確保沒有錯誤，可能需要在未來返工?！ ?/p>
?對重復(fù)版本進行更改，以確保主代碼不受影響?！ ?/p>
更改失敗率
更改失敗率度量生產(chǎn)中部署失敗的百分比，需要進行錯誤修復(fù)或回滾。這個DevOps指標(biāo)檢查部署次數(shù)與失敗次數(shù)，以解碼DevOps流程的效率。
變更失敗率如何影響開發(fā)過程
更改失敗率指標(biāo)跟蹤花費在糾正問題而不是開發(fā)新項目上的時間。這有助于管理人員了解他們的團隊在哪些方面投入了精力，并有助于使團隊和流程在編寫新代碼上花費更多的時間，而不是處理錯誤和返工。
如何衡量
用部署失敗的次數(shù)除以部署的總次數(shù)就得到了CFR。團隊?wèi)?yīng)該確保變更失敗率降到最低。但這也并不意味著要花費太多時間構(gòu)建和測試每個模塊，因為這可能會影響交付時間?！ ?/p>
優(yōu)化變更失敗的提示
更改失敗并不總是表明代碼執(zhí)行得很糟糕。有時，外部因素，如不明確的需求或小錯誤，可能導(dǎo)致程序失敗?！ ?/p>
?確保代碼按照sprint計劃編寫、評審和測試
?控制sprint速度和代碼變動指標(biāo)，可以幫助了解所做的更改及其背后的原因
平均恢復(fù)時間(MTTR)
MTTR是衡量部署后為解決問題而采取的對策所花費的時間。團隊快速從失敗中恢復(fù)的能力依賴于他們在失敗發(fā)生時立即識別失敗(MTTD)并發(fā)布補救措施或回滾導(dǎo)致失敗的任何更改的能力。這通常是通過持續(xù)監(jiān)視系統(tǒng)運行狀況并在發(fā)生故障時通知操作人員來實現(xiàn)的。
MTTR如何影響開發(fā)過程
MTTR測試團隊解決bug或事件的速度。高績效團隊從事故中快速恢復(fù)，而低績效團隊可能需要長達一周或更長時間才能恢復(fù)。測量MTTR是確保彈性和穩(wěn)定性的關(guān)鍵實踐。
如何衡量
MTTR可以通過計算事件發(fā)生和解決之間的時間來測量。為了解決事故，運營團隊?wèi)?yīng)該配備正確的工具、協(xié)議和權(quán)限?！ ?/p>
優(yōu)化MTTR的技巧
要實現(xiàn)快速的MTTR度量，可以以小增量部署軟件以降低風(fēng)險，并部署自動監(jiān)視解決方案以搶占故障。
?構(gòu)建更健壯的系統(tǒng)，在發(fā)布之前進行測試
?更好的日志記錄提供了數(shù)據(jù)，以便在故障發(fā)生時更快地診斷和發(fā)現(xiàn)問題
?這可以通過不斷檢查錯誤和阻礙來實現(xiàn)
改進DORA指標(biāo)的策略
關(guān)注框架
簡單地使用DORA指標(biāo)并不能改進開發(fā)過程。管理者還應(yīng)該制定如何利用和提高DORA指標(biāo)的策略。做到這一點的最佳方法是對團隊的當(dāng)前狀況進行基準(zhǔn)測試，并為項目的目標(biāo)和計劃繪制路線圖。在定義目標(biāo)和截止日期時，需要關(guān)注的兩個主要因素是項目分配和項目計劃準(zhǔn)確性?！ ?/p>
管理人員應(yīng)該根據(jù)業(yè)務(wù)優(yōu)先級確定團隊并分配項目。優(yōu)化的項目分配過程還有助于確保工程團隊在任何給定的時間都在正確的項目上工作，并在需要時進行修改?！ ?/p>
項目計劃使管理人員能夠保持在時間表的頂端，并確保一個sprint又一個sprint地實現(xiàn)目標(biāo)。持續(xù)地衡量這一點有助于識別和解決阻礙進展的障礙。在這里，諸如周期時間、代碼周轉(zhuǎn)和sprint速度等指標(biāo)提供了實現(xiàn)每個sprint目標(biāo)和滿足截止日期所需的支持。
促進合作
定義目標(biāo)并使團隊朝著實現(xiàn)目標(biāo)的方向調(diào)整可以幫助實現(xiàn)更好的結(jié)果。做到這一點的一個有效方法是每天召開站立會議，把團隊聚集在一起，明確目標(biāo)。站立會議還能讓每個人都知道誰在做什么，但更重要的是，它能幫助團隊識別阻礙因素并制定解決問題的路線圖。為了使站立會議更加高效和有效，管理者可以采用異步站立會議，這樣不僅可以達到目的，還可以保留工程師的注意力時間和文檔信息以供將來參考?！ ?/p>
建立更好的工作流程
管理者應(yīng)該專注于創(chuàng)建基于數(shù)據(jù)的工作流。他們應(yīng)該有辦法收集各種軟件工程度量，如拉請求度量、開發(fā)人員專注時間、團隊周期時間、代碼變動和其他度量，以設(shè)計一個數(shù)據(jù)豐富的過程，該過程具有高質(zhì)量和低失敗幾率?！ ?/p>
號召持續(xù)集成和持續(xù)交付
持續(xù)集成和持續(xù)交付結(jié)合了在共享存儲庫中持續(xù)集成所有編寫的代碼的實踐，觸發(fā)自動測試，并最終提供持續(xù)交付的方法。CI/CD自動化了將新代碼從提交到生產(chǎn)中所需的大部分或所有手動干預(yù)。這包括構(gòu)建、測試和部署階段。有了CI/CD管道，開發(fā)人員就可以對代碼進行返工和更改，這些代碼將被自動測試并推動部署。這促進了更高的開發(fā)頻率和變更的前置時間，同時也限制了變更失敗的空間。
文章名稱：如何提高效率和性能的關(guān)鍵DevOps指標(biāo)
網(wǎng)站網(wǎng)址：http://www.5511xx.com/article/cogcioe.html
