DevOps在你的組織內部運行的如何？如果你需要一些幫助來度量它的運行情況，我們已經准備了一個用於跟蹤的關鍵DevOps指標的列表，這些度量可以幫助了解你的團隊是如何隨着時間的推移而運行的。
在團隊內部明確DevOps的定義意義重大
DevOps這個詞不同的人有不同的理解，有人說這是一種文化，業內的每個廠商都聲稱他們的工具幫助了DevOps，根據你如何定義DevOps，其中的一些度量可能對你的團隊有重要的影響。
我將DevOps定義為與部署和監視應用程序相關的所有內容，從很多方面來說，這都是現實的可靠的工程問題。在Stackify，我們甚至沒有運維團隊，我們的開發人員直接部署到雲上，我們的操作方式更多的是“NoOps”風格。
確定你的DevOps的挑戰
在弄清楚DevOps度量標准是什么之前，你需要確定組織所面臨的挑戰以及要解決的問題。在Stackify，我們最大的問題不是經常部署，並且降低了缺陷逃逸速度。我們的執行團隊正把重點放在2018年的具體指標上。
DevOps指標的類型
DevOps是盡可能快的持續交付和傳輸代碼，你想要行動迅速而不是打破常規，通過跟蹤這些DevOps指標，你可以評估在開始破壞之前，可以有多快。
-
Deployment frequency 部署頻率
-
Change volume 容量變化
-
Deployment time 部署時間
-
Lead time 交付時間
-
Customer tickets 客戶工單
-
Automated test pass % 自動化測試通過百分比
-
Defect escape rate 缺陷逃逸率
-
Availability 可用性
-
Service level agreements 服務水平協議SLA
-
Failed deployments 失敗的部署
-
Error rates 錯誤率
-
Application usage and traffic 應用程序的使用和流量
-
Application performance 應用程序的性能
-
Mean time to detection (MTTD) 平均檢測時間
-
Mean time to recovery (MTTR) 平均恢復時間
DevOps的目標：速度、質量、性能
DevOps的主要目標是速度、質量和應用程序性能。
希望盡可能快地發送代碼，根據你的產品類型、團隊和風險承受能力，你可以盡快的實現這一目標。
即使你沒有在速度上跟蹤任何DevOps指標，至少應該衡量在質量上的工作，也許你並不真的在乎到底有多快，但是，你總是關心質量，你最不想要的就是一直在疲於生產。
關於性能，你可以爭辯說，這也與你的高速度和高質量的目標不一致，性能也與質量有關，但可能略有不同。
部署規模
跟蹤有多少功能、特性請求和錯誤修復正在被部署，這是另一個良好的DevOps度量，取決於你的工作項目有多大，它們的數量可能會有很大差異，您還可以跟蹤部署了多少個功能點或幾天的開發工作。
部署頻率
跟蹤部署的頻率是一個良好的DevOps度量，最終目標是盡可能多地部署更小的部署，減少部署的規模使測試和發布變得更加容易。
我建議單獨計算生產和非生產部署，部署到QA或預生產環境的頻率也很重要。你需要在QA中盡早部署，以確保測試的時間，在QA中發現bug很重要，可以降低缺陷的轉化率。
部署時間
這看起來可能很奇怪，但是跟蹤實際部署需要多長時間是另一個很好的度量。我們在Stackify的一個應用程序部署在Azure上，部署大約需要一個小時。這是一個噩夢，跟蹤這些事情可以幫助識別潛在的問題，當實際執行任務的任務比較快時，更容易部署。
交付時間
如果目標是快速發布代碼，這是一個非常關鍵的DevOps度量，我將把交付時間定義為從工作項開始到部署之間的時間。這可以幫助你知道，如果你今天開始一項新的工作項目，直到它開始生產，平均需要多長時間。
客戶工單
應用程序問題的最好和最差的指示器是客戶工單和反饋，你最不想要的就是讓你的用戶發現bug或者對你的軟件有問題，因此，它們也能很好地反映應用程序的質量和性能問題。
通過自動化測試通過率
為了提高速度，建議你的團隊廣泛使用單元測試和功能測試，由於DevOps嚴重依賴於自動化，所以跟蹤你的自動化測試工作的好壞是一個良好的DevOps指標，了解代碼更改導致測試中斷的頻率是很好的方法。
缺陷逃逸率
你知道在生產和QA中發現了多少軟件缺陷嗎？如果你想要快速地發布代碼，你需要有信心，你可以在他們開始生產之前發現軟件缺陷。缺陷逃逸率是一個很大的DevOps度量，用來跟蹤這些缺陷在生產過程中經常發生的情況。
可用性
你最不想要的就是應用程序被關閉，根據應用程序類型以及如何部署它，可能會有一些停機時間作為計划維護的一部分，我建議跟蹤這一點，以及所有計划外的停機。
服務水平協議
大多數公司都有一些服務水平協議(SLA)，同樣重要的是你要追蹤你的SLA是否被遵守，即使沒有正式的SLA，也可能需要實現應用程序達到期望。
失敗的部署
我們都希望這種情況永遠不會發生，但是你的部署經常會給用戶造成中斷或重大問題嗎？反轉失敗的部署是我們永遠都不想做的事情，但這是你應該一直計划的事情。如果你遇到了部署失敗的問題，請務必跟蹤這個度量，這也可以看作是對失敗的跟蹤平均時間(MTTF)。
錯誤率
應用程序中跟蹤錯誤率非常重要，它們不僅是質量問題的指示器，而且是持續的性能和與時間相關的問題，好的異常處理最佳實踐對於良好的軟件是至關重要的。
-
bug，在部署后識別在代碼中拋出的新異常。
-
生產問題，用數據庫連接捕獲問題，查詢超時和其他相關問題。
對於大多數應用程序來說，錯誤是生命周期的一部分，在Stackify，我們在幾百個服務器和上千個SQL數據庫中處理數百萬條消息。這里有一些錯誤，只是一個繁忙系統的部分噪音，重要的是，你要對你的錯誤率保持監控，並尋找峰值。
應用程序的使用和流量
在部署之后，你希望查看訪問你的系統的事務或用戶數量是否正常，如果你突然之間沒有流量，那么有些事情可能是錯誤的。
你最不想看到的就是根本沒有交通，如果使用的是微服務，你還可以看到流量激增，而應用程序之一突然導致了大量的流量。
應用程序的性能
在進行部署之前，你應該使用像Retrace這樣的工具來查找性能問題、隱藏的錯誤和其他問題。在部署期間和部署之后，你還應該尋找總體應用程序性能的任何變化。
在部署之后，可以看到特定SQL查詢、web服務調用和其他應用程序依賴項的使用的主要變化。像Retrace這樣的工具可以提供有價值的可視化效果，比如下面這個，可以幫助你輕松地發現問題。
平均檢測時間(MTTD)
當問題發生時，重要的是你要快速地識別它們。最不希望的是出現重大的部分或廣泛的系統中斷，而不知道它。擁有健壯的應用程序監控和良好的覆蓋將有助於快速發現問題。一旦發現它們，你也必須快速修復它們！
平均恢復時間(MTTR)
這個度量可以幫助你跟蹤從失敗中恢復需要多長時間。對企業來說，一個關鍵的衡量標准就是將失敗降到最低，並且能夠迅速地從失敗中恢復過來。它通常是按小時計算的，可能是指業務時間，而不是時鍾時間。
擁有良好的應用程序監視工具可以快速識別問題並快速部署修復程序，這對減少MTTR非常重要。
應用程序指標
除了上面列出的DevOps指標之外，你還可以跟蹤許多其他的指標，這些指標都是特定於你的應用程序的。它們中的大多數與DevOps在部署應用程序方面不一定相關。但是，它們對於監視應用程序在生產中的使用和性能非常關鍵。
例如，在Stackify中，我們使用自定義度量來跟蹤每分鍾通過API接收的日志消息數量。這是一個重要的度量指標，幫助我們理解流經系統的數據量。根據你的應用程序的不同，你可能有類似的自定義指標，對你的應用程序至關重要。
在部署之后，你將希望監視所有關鍵的應用程序指標，以確保一切仍然正常。
總結
如果你想要將DevOps帶到下一個級別，我相信我們的DevOps度量列表將幫助你了解如何跟蹤和改進。DevOps的目標是協作，讓開發人員更多地參與部署過程和應用程序監控。