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