建站
咨詢
售后
建站咨詢
新聞中心
DevOps通過一系列追求敏捷心態(tài)的實(shí)踐來提高軟件交付速度和質(zhì)量。當(dāng)您提到DevOps時(shí)，首先想到的術(shù)語是持續(xù)集成，持續(xù)交付和部署，協(xié)作，自動(dòng)化和監(jiān)視。DevOps對(duì)不同的團(tuán)隊(duì)意味著不同的事情。一些團(tuán)隊(duì)全都致力于自動(dòng)化，而其他團(tuán)隊(duì)則手動(dòng)做事，仍然認(rèn)為他們?cè)谧鯠evOps。有些人認(rèn)為它是一種文化和一種思維定型者。
創(chuàng)新互聯(lián)主營團(tuán)風(fēng)網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,APP應(yīng)用開發(fā),團(tuán)風(fēng)h5小程序開發(fā)搭建,團(tuán)風(fēng)網(wǎng)站營銷推廣歡迎團(tuán)風(fēng)等地區(qū)企業(yè)咨詢
由于DevOps圍繞持續(xù)交付和快速代碼交付而展開，因此快速行動(dòng)而沒有任何重大錯(cuò)誤至關(guān)重要。跟蹤可幫助您實(shí)現(xiàn)此目標(biāo)的DevOps指標(biāo)至關(guān)重要。為了在DevOps中取得成功，團(tuán)隊(duì)需要使用許多不同的工具。這就是為什么不同的DevOps指標(biāo)對(duì)于不同的開發(fā)團(tuán)隊(duì)至關(guān)重要。
因此，在開始使用DevOps之前，您的團(tuán)隊(duì)就應(yīng)該確定DevOps對(duì)他們意味著什么。而且，團(tuán)隊(duì)還應(yīng)該發(fā)現(xiàn)最大的DevOps挑戰(zhàn)。然后，他們可以更輕松地確定他們需要更積極地監(jiān)視以改進(jìn)和創(chuàng)建質(zhì)量更高的軟件交付流程所需的DevOps指標(biāo)。
以下是大多數(shù)團(tuán)隊(duì)認(rèn)為重要的重要DevOps指標(biāo)：
部署頻率
開發(fā)并保持競爭優(yōu)勢，以更高的質(zhì)量和準(zhǔn)確性提供更新，新功能和技術(shù)增強(qiáng)非常重要。增加交付強(qiáng)度的機(jī)會(huì)有助于提高靈活性并更好地遵守不斷變化的消費(fèi)者需求。目的應(yīng)該是盡可能頻繁地進(jìn)行較小的部署。當(dāng)部署規(guī)模較小時(shí)，軟件測試和部署會(huì)更加舒適。
定期測量部署頻率將提供更大的可見性，以了解哪些改進(jìn)比較成功，哪些部分需要更改。頻率的快速下降可能表明其他任務(wù)或手動(dòng)操作正在干擾工作流程。為了實(shí)現(xiàn)可持續(xù)的增長和發(fā)展，建議進(jìn)行微小但持續(xù)變化的部署頻率指標(biāo)是最佳的。
更進(jìn)一步，使測試更易于管理，可以衡量生產(chǎn)和非生產(chǎn)部署。這樣，您將能夠確定部署進(jìn)行質(zhì)量檢查的頻率，并針對(duì)早期和較小的部署進(jìn)行優(yōu)化。
部署時(shí)間
此度量標(biāo)準(zhǔn)衡量執(zhí)行部署需要多長時(shí)間。盡管起初看起來似乎無關(guān)緊要，但是衡量部署時(shí)間是可以指示潛在問題的DevOps指標(biāo)之一。例如，如果您的部署需要一個(gè)小時(shí)，則一定有問題。這就是為什么最好集中在較小但更頻繁的部署上。實(shí)現(xiàn)方式：捕獲構(gòu)建時(shí)間。
自動(dòng)化測試通過率
強(qiáng)烈建議團(tuán)隊(duì)有效利用單元測試和集成測試以最大程度地提高速度。由于DevOps嚴(yán)重依賴于自動(dòng)化，因此有用的DevOps指標(biāo)用于衡量自動(dòng)化測試的效果。知道多少代碼調(diào)整會(huì)導(dǎo)致測試崩潰，這很有用。
代碼提交
此度量標(biāo)準(zhǔn)計(jì)算團(tuán)隊(duì)在將軟件實(shí)施到生產(chǎn)之前對(duì)軟件的提交次數(shù)。這既可以衡量開發(fā)速度，也可以衡量代碼的準(zhǔn)確性。團(tuán)隊(duì)?wèi)?yīng)提出每個(gè)團(tuán)隊(duì)成員應(yīng)遵循的標(biāo)準(zhǔn)代碼提交范圍。
大量提交可能意味著代碼質(zhì)量差或缺乏明確的開發(fā)目標(biāo)。另一方面，當(dāng)人數(shù)低于標(biāo)準(zhǔn)范圍時(shí)，團(tuán)隊(duì)可能會(huì)缺乏生產(chǎn)力或組織良好。有必要找出減少或增加提交次數(shù)的原因，以保持效率和項(xiàng)目進(jìn)度，同時(shí)仍保持團(tuán)隊(duì)成員之間的最大幸福感。
缺陷逃逸率
無論您在DevOps中的經(jīng)驗(yàn)如何，都會(huì)發(fā)生錯(cuò)誤-尤其是當(dāng)您經(jīng)常進(jìn)行調(diào)整時(shí)。軟件開發(fā)涉及試驗(yàn)，并且作為過程的一部分，您應(yīng)始終預(yù)見到錯(cuò)誤。
缺陷逃逸率度量標(biāo)準(zhǔn)顯示了您在將軟件缺陷投入生產(chǎn)之前就可以捕獲它們的能力如果要快速交付代碼，這尤其重要。為了成功實(shí)現(xiàn)此目標(biāo)，您需要有效地檢測缺陷。
費(fèi)用
盡管云是降低基礎(chǔ)架構(gòu)成本的絕佳解決方案，但某些計(jì)劃外的錯(cuò)誤和事件可能會(huì)導(dǎo)致很高的成本。這就是為什么您應(yīng)該專注于捕獲不必要的成本并嘗試降低成本，可視化您的支出來源可以在理解您最昂貴的操作方面發(fā)揮重要作用。理想的情況是使用一種工具，該工具可以自動(dòng)執(zhí)行您的睡眠周期并僅在實(shí)際使用它們來降低成本時(shí)才喚醒環(huán)境。
失敗的部署和環(huán)境運(yùn)行狀況
部署通常會(huì)給您的用戶帶來問題，有時(shí)，我們必須撤消失敗的部署。即使這不是我們活動(dòng)中想要的東西，我們也應(yīng)始終意識(shí)到它有可能發(fā)生。頻繁失敗的部署是我們環(huán)境健康的指標(biāo)，這使我們有了下一個(gè)指標(biāo)。
檢測時(shí)間
盡管減少甚至消除失敗的更改是最佳方法，但重要的是要迅速捕獲故障(如果發(fā)生)。確定關(guān)鍵績效指標(biāo)的時(shí)間將決定當(dāng)前的響應(yīng)工作是否適當(dāng)。該高的檢測時(shí)間可以觸發(fā)限制可能破壞整個(gè)工作流程。
計(jì)劃外工作
這是您花在最初計(jì)劃中沒有的任務(wù)上的時(shí)間。在標(biāo)準(zhǔn)項(xiàng)目中，UWR(計(jì)劃外工作率)不應(yīng)超過25%。較高的UWR可能會(huì)暴露浪費(fèi)在意外錯(cuò)誤上的工作，這些錯(cuò)誤顯然在工作流的早期并未發(fā)現(xiàn)。與返工率(RWR)一起，這是試圖解決票證中存在的問題的嘗試，UWR也是一個(gè)重要指標(biāo)。
平均故障時(shí)間(MTTF)平均故障時(shí)間(MTTF)是有缺陷的系統(tǒng)設(shè)法運(yùn)行直到出現(xiàn)故障的平均時(shí)間。持續(xù)時(shí)間從系統(tǒng)中發(fā)生重大缺陷時(shí)開始，到機(jī)制最終崩潰時(shí)結(jié)束。
MTTF用于跟蹤不可修復(fù)的系統(tǒng)組件的狀態(tài)，并評(píng)估它們?cè)谑е翱梢怨ぷ鞫嚅L時(shí)間。該指標(biāo)還可以讓DevOps團(tuán)隊(duì)在確定故障時(shí)維護(hù)關(guān)鍵任務(wù)系統(tǒng)中使用的組件的狀況。
應(yīng)用性能
在執(zhí)行部署之前，您應(yīng)該檢查性能故障，未知錯(cuò)誤和其他問題。您還可以在整個(gè)部署過程中和部署之后監(jiān)視整個(gè)程序輸出中的更改。
發(fā)布后，看到某些SQL查詢，Web服務(wù)器調(diào)用和其他程序要求的使用發(fā)生重大調(diào)整是正常的。要檢測它們，您可以使用監(jiān)視工具，這些監(jiān)視工具將為您精確顯示更改。
平均檢測時(shí)間(MTTD)
當(dāng)問題確實(shí)出現(xiàn)時(shí)，重要的是您容易識(shí)別它們。您不希望出現(xiàn)嚴(yán)重的局部或大型機(jī)器故障，并且不了解它。設(shè)置強(qiáng)大的應(yīng)用程序監(jiān)視功能可以幫助您輕松發(fā)現(xiàn)錯(cuò)誤。
平均恢復(fù)時(shí)間(MTTR)
MTTR是衡量企業(yè)解決問題的有效性的成功指標(biāo)**。**分析業(yè)務(wù)和客戶體驗(yàn)的效果的能力為全面理解和確定優(yōu)先級(jí)提供了所需的視角。MTTR計(jì)算從故障到解決的總響應(yīng)時(shí)間，并提供有關(guān)客戶端是否失去控制，遇到延遲或放棄系統(tǒng)的信息。改善MTTR可以減少這些問題的影響，從而保持用戶的幸福感。
通過安裝實(shí)用的應(yīng)用程序管理工具來快速檢測問題并輕松執(zhí)行補(bǔ)丁程序，對(duì)于降低MTTR至關(guān)重要。
交貨時(shí)間
衡量工作流程和效率的一項(xiàng)重要指標(biāo)是估計(jì)項(xiàng)目從概念到實(shí)施所需的平均時(shí)間。較低的交貨時(shí)間表明該團(tuán)隊(duì)非常靈活，響應(yīng)能力強(qiáng)，可以迅速回答反饋。
與DevOps相關(guān)的敏捷方法可以為框架改進(jìn)提供快速的處理時(shí)間，從而使企業(yè)能夠滿足消費(fèi)者的需求并專注于變化的趨勢。您可以使用Jira和Trello之類的工具來有效地捕獲交貨時(shí)間。
質(zhì)量改變
由于DevOps涉及頻繁更改，因此您必須測量部署之間的變化率以支持部署頻率編號(hào)。最終目的應(yīng)該是集中精力進(jìn)行有意義的改進(jìn)，以減少不便并帶來更流暢的體驗(yàn)。對(duì)于每個(gè)部署，監(jiān)視變更量可以更精確地描述開發(fā)。您可以從GitHub，Bitbucket和Jira等工具獲取此信息。
客戶反饋
積極的客戶體驗(yàn)對(duì)于產(chǎn)品的生存至關(guān)重要。滿意的客戶和良好的客戶服務(wù)導(dǎo)致銷量增加。這就是為什么客戶票證表明客戶滿意度的水平，反映了您的DevOps流程的質(zhì)量。數(shù)字越小，服務(wù)越好。
總結(jié)一下
DevOps的目的是促進(jìn)開發(fā)團(tuán)隊(duì)與運(yùn)營團(tuán)隊(duì)之間的協(xié)調(diào)與協(xié)作，以支持應(yīng)用程序的快速執(zhí)行，同時(shí)最大程度地減少對(duì)最終用戶的體驗(yàn)產(chǎn)生負(fù)面影響的中斷，延遲和問題。
這取決于您市場的特定問題，并且需要選擇要跟蹤的特定DevOps指標(biāo)。選擇合適的成功指標(biāo)進(jìn)行監(jiān)控將有助于指導(dǎo)與開發(fā)和技術(shù)相關(guān)的戰(zhàn)略決策，同時(shí)支持當(dāng)前DevOps活動(dòng)的執(zhí)行。
網(wǎng)站名稱：13個(gè)提高生產(chǎn)率的DevOps指標(biāo)
網(wǎng)址分享：http://www.dlmjj.cn/article/cceoscc.html
