目前，DevOps在國內正處于高速增長的階段。尤其在各大廠中它受到了熱烈歡迎，但是大家要注意結合實際，立足于業務。不能為了敏捷而敏捷，為了devops而devops!

[[361226]]

1. 部署頻率

開發后保持競爭優勢，高質量，準確地提供更新，新功能和技術增強都非常重要。增加交付強度的機會有利于提高靈活性并更滿足不斷變化的消費者需求。

定期測量部署頻率將提供更大的可見性，可以了解哪些改進成功，哪些部分要更改。頻率如果快速下降可能代表其他任務或手動操作在干擾工作流程。想要可持續的增長和發展，建議進行微小但持續變化的部署頻率指標。確定部署頻率，針對早期進行優化，使測試更易于管理。

2. 部署時間

此度量標準衡量執行部署需要多長時間看起來似乎無關緊要，但是衡量部署時間可以知道潛在問題。比如，如果你的部署需要一個小時，那一定有問題。所以最好集中在較小但更頻繁的部署上，用捕獲構建時間的方式。

3. 自動化測試通過率

非常建議你利用單元測試和集成測試以最大程度地提高速度。因為DevOps嚴重依賴于自動化，有用的DevOps指標用于衡量自動化測試的效果。知道多少代碼調整會導致測試崩潰，有效利用這一點就可以幫到你。

4. 代碼提交

計算團隊在將軟件實施到生產之前對軟件的提交次數，不僅能衡量開發速度，還能衡量代碼的準確性。團隊應提出每個人該遵循的標準代碼提交范圍。大量提交或許意味著代碼質量差、缺乏明確的開發目標之類的問題。團隊可能會因為人數低于標準值而缺乏生產力。找出減少或增加提交次數的原因是非常有必要的，用來保持效率和項目進度，也可以保持團隊成員之間的幸福感。

5. 計劃外工作

顧名思義，在標準項目中，計劃外工作率不應超過25%。太高的計劃外工作率可能會在工作中發生一些意外錯誤，如果在工作流的早期沒有發現就比較嚴重了。返工率也是試圖解決票證中存在的問題的嘗試。

平均故障時間(MTTF)是有缺陷的系統設法運行直到出現故障的平均時間。用來跟蹤不可修復的系統組件的狀態，并且評估它們在失效之前可以工作多長時間。它可以讓DevOps團隊在確定故障時維護關鍵任務系統的狀況。

6. 應用性能

執行部署之前，你一定要檢查性能故障，未知錯誤和其他問題。在整個部署過程中和部署之后監視整個程序輸出中的更改。以及發布后的SQL查詢，Web服務器調用和其他程序要求的使用。如果發生重大調整是正常的，可以使用監視工具，它可以更精確地顯示更改。

7. 平均檢測時間(MTTD)

當問題真正出現時，重點就是要立刻識別它們。不然出現嚴重的局部或大型機器故障時，還不了解它事態就會發展得很嚴重。記得設置強大的應用程序監視功能幫你輕松發現錯誤。

8. 平均恢復時間(MTTR)

平均恢復時間是衡量企業解決問題有效性的指標。分析業務和客戶體驗的效果的能力，提供了所需的視角。MTTR計算從故障到解決的總響應時間，并提供有關客戶端是否失去控制，遇到延遲或放棄系統的信息。改善它可以大大地減少影響。

總而言之，在人力成本高、市場競爭激烈、以及用戶需求變化十分頻繁的情況下，DevOps是必須選用的一條路。