[[360359]]

 DevOps通過一系列追求敏捷心態的實踐來提高軟件交付速度和質量。當您提到DevOps時，首先想到的術語是持續集成，持續交付和部署，協作，自動化和監視。DevOps對不同的團隊意味著不同的事情。一些團隊全都致力于自動化，而其他團隊則手動做事，仍然認為他們在做DevOps。有些人認為它是一種文化和一種思維定型者。

由于DevOps圍繞持續交付和快速代碼交付而展開，因此快速行動而沒有任何重大錯誤至關重要。跟蹤可幫助您實現此目標的DevOps指標至關重要。為了在DevOps中取得成功，團隊需要使用許多不同的工具。這就是為什么不同的DevOps指標對于不同的開發團隊至關重要。

因此，在開始使用DevOps之前，您的團隊就應該確定DevOps對他們意味著什么。而且，團隊還應該發現最大的DevOps挑戰。然后，他們可以更輕松地確定他們需要更積極地監視以改進和創建質量更高的軟件交付流程所需的DevOps指標。

以下是大多數團隊認為重要的重要DevOps指標：

部署頻率

開發并保持競爭優勢，以更高的質量和準確性提供更新，新功能和技術增強非常重要。增加交付強度的機會有助于提高靈活性并更好地遵守不斷變化的消費者需求。目的應該是盡可能頻繁地進行較小的部署。當部署規模較小時，軟件測試和部署會更加舒適。

定期測量部署頻率將提供更大的可見性，以了解哪些改進比較成功，哪些部分需要更改。頻率的快速下降可能表明其他任務或手動操作正在干擾工作流程。為了實現可持續的增長和發展，建議進行微小但持續變化的部署頻率指標是最佳的。

更進一步，使測試更易于管理，可以衡量生產和非生產部署。這樣，您將能夠確定部署進行質量檢查的頻率，并針對早期和較小的部署進行優化。

部署時間

此度量標準衡量執行部署需要多長時間。盡管起初看起來似乎無關緊要，但是衡量部署時間是可以指示潛在問題的DevOps指標之一。例如，如果您的部署需要一個小時，則一定有問題。這就是為什么最好集中在較小但更頻繁的部署上。實現方式：捕獲構建時間。

自動化測試通過率

強烈建議團隊有效利用單元測試和集成測試以最大程度地提高速度。由于DevOps嚴重依賴于自動化，因此有用的DevOps指標用于衡量自動化測試的效果。知道多少代碼調整會導致測試崩潰，這很有用。

代碼提交

此度量標準計算團隊在將軟件實施到生產之前對軟件的提交次數。這既可以衡量開發速度，也可以衡量代碼的準確性。團隊應提出每個團隊成員應遵循的標準代碼提交范圍。

大量提交可能意味著代碼質量差或缺乏明確的開發目標。另一方面，當人數低于標準范圍時，團隊可能會缺乏生產力或組織良好。有必要找出減少或增加提交次數的原因，以保持效率和項目進度，同時仍保持團隊成員之間的最大幸福感。

缺陷逃逸率

無論您在DevOps中的經驗如何，都會發生錯誤-尤其是當您經常進行調整時。軟件開發涉及試驗，并且作為過程的一部分，您應始終預見到錯誤。

缺陷逃逸率度量標準顯示了您在將軟件缺陷投入生產之前就可以捕獲它們的能力如果要快速交付代碼，這尤其重要。為了成功實現此目標，您需要有效地檢測缺陷。

費用

盡管云是降低基礎架構成本的絕佳解決方案，但某些計劃外的錯誤和事件可能會導致很高的成本。這就是為什么您應該專注于捕獲不必要的成本并嘗試降低成本，可視化您的支出來源可以在理解您最昂貴的操作方面發揮重要作用。理想的情況是使用一種工具，該工具可以自動執行您的睡眠周期并僅在實際使用它們來降低成本時才喚醒環境。

失敗的部署和環境運行狀況

部署通常會給您的用戶帶來問題，有時，我們必須撤消失敗的部署。即使這不是我們活動中想要的東西，我們也應始終意識到它有可能發生。頻繁失敗的部署是我們環境健康的指標，這使我們有了下一個指標。

檢測時間

盡管減少甚至消除失敗的更改是最佳方法，但重要的是要迅速捕獲故障(如果發生)。確定關鍵績效指標的時間將決定當前的響應工作是否適當。該高的檢測時間可以觸發限制可能破壞整個工作流程。

計劃外工作

這是您花在最初計劃中沒有的任務上的時間。在標準項目中，UWR(計劃外工作率)不應超過25%。較高的UWR可能會暴露浪費在意外錯誤上的工作，這些錯誤顯然在工作流的早期并未發現。與返工率(RWR)一起，這是試圖解決票證中存在的問題的嘗試，UWR也是一個重要指標。

平均故障時間(MTTF)平均故障時間(MTTF)是有缺陷的系統設法運行直到出現故障的平均時間。持續時間從系統中發生重大缺陷時開始，到機制最終崩潰時結束。

MTTF用于跟蹤不可修復的系統組件的狀態，并評估它們在失效之前可以工作多長時間。該指標還可以讓DevOps團隊在確定故障時維護關鍵任務系統中使用的組件的狀況。

應用性能

在執行部署之前，您應該檢查性能故障，未知錯誤和其他問題。您還可以在整個部署過程中和部署之后監視整個程序輸出中的更改。

發布后，看到某些SQL查詢，Web服務器調用和其他程序要求的使用發生重大調整是正常的。要檢測它們，您可以使用監視工具，這些監視工具將為您精確顯示更改。

平均檢測時間(MTTD)

當問題確實出現時，重要的是您容易識別它們。您不希望出現嚴重的局部或大型機器故障，并且不了解它。設置強大的應用程序監視功能可以幫助您輕松發現錯誤。

平均恢復時間(MTTR)

MTTR是衡量企業解決問題的有效性的成功指標**。**分析業務和客戶體驗的效果的能力為全面理解和確定優先級提供了所需的視角。MTTR計算從故障到解決的總響應時間，并提供有關客戶端是否失去控制，遇到延遲或放棄系統的信息。改善MTTR可以減少這些問題的影響，從而保持用戶的幸福感。

通過安裝實用的應用程序管理工具來快速檢測問題并輕松執行補丁程序，對于降低MTTR至關重要。

交貨時間

衡量工作流程和效率的一項重要指標是估計項目從概念到實施所需的平均時間。較低的交貨時間表明該團隊非常靈活，響應能力強，可以迅速回答反饋。

與DevOps相關的敏捷方法可以為框架改進提供快速的處理時間，從而使企業能夠滿足消費者的需求并專注于變化的趨勢。您可以使用Jira和Trello之類的工具來有效地捕獲交貨時間。

質量改變

由于DevOps涉及頻繁更改，因此您必須測量部署之間的變化率以支持部署頻率編號。最終目的應該是集中精力進行有意義的改進，以減少不便并帶來更流暢的體驗。對于每個部署，監視變更量可以更精確地描述開發。您可以從GitHub，Bitbucket和Jira等工具獲取此信息。

客戶反饋

積極的客戶體驗對于產品的生存至關重要。滿意的客戶和良好的客戶服務導致銷量增加。這就是為什么客戶票證表明客戶滿意度的水平，反映了您的DevOps流程的質量。數字越小，服務越好。

總結一下

DevOps的目的是促進開發團隊與運營團隊之間的協調與協作，以支持應用程序的快速執行，同時最大程度地減少對最終用戶的體驗產生負面影響的中斷，延遲和問題。

這取決于您市場的特定問題，并且需要選擇要跟蹤的特定DevOps指標。選擇合適的成功指標進行監控將有助于指導與開發和技術相關的戰略決策，同時支持當前DevOps活動的執行。