特別說明：本文是在原文基礎上的改寫和添加，但總體不影響原文表達，特此說明。
1 - 自我認知
通過跟蹤關鍵的DevOps指標，隨着時間推移，可以有效瞭解DevOps在團隊內部實施和落地的情況，衡量DevOps的運行狀態。
通常都會根據自身定義一些常見的指標來評估DevOps的效果，期望產生積極的影響。
- 平均交付時間
- 缺陷逃逸率
- 新增代碼單元測試覆蓋
- 日均自動化部署次數
- 功能和性能測試周期
- 每輪迴歸測試周期
- 。。。
但定義DevOps指標指標之前，應該弄清兩個基本問題：
- “定義DevOps的指標，對團隊真正意味着什麼？”
- “從DevOps角度來看，組織所面臨的核心挑戰和要解決的主要問題是什麼？”
這兩個基本問題的實質，其實是在要求對自身真實情況和需求，能夠有一個正確的認知。
2 - DevOps的指標類型
DevOps是儘可能快的持續交付和傳送代碼。想要行動迅速而不是打破常規。
通過跟蹤這些DevOps指標，可以評估在開始破壞之前，可以移動多快。
部署頻率
質量大小
部署時間
交付時間
客戶反饋
自動化測試通過率
缺陷逃逸率
可用性
服務水平協議
失敗部署率
錯誤率
應用程序的使用和通道
應用程序的性能
平均檢測時間
平均修復時間
3 - DevOps的目標：速度、質量、性能
DevOps的主要目標是速度、質量和應用程序性能。
開發希望儘可能快地發送代碼。
根據產品類型、團隊和風險承受能力，可以有多快地實現這一目標。
即使沒有在速度上跟蹤任何DevOps指標，至少應該度量在質量上的工作方式。
也許試着在能的時候去只想，並不真的在乎到底有多快。
但是，總要關心質量。最不想要的就是一直在追逐生產。
4 - 十五項指標
# 部署規模
跟蹤有多少故事、特性請求和錯誤修復正在被部署，這是另外一個良好的DevOps度量。
取決於工作項目有多大，它們的數量可能會有很大差異。
還可以跟蹤部署了多少個故事點或幾天的開發工作。
# 部署頻率
跟蹤部署的頻率是一個良好的DevOps度量。
最終的目標是儘可能多且小的部署。
減少部署的規模使測試和發佈變得更加容易。
建議單獨計算生產和非生產部署。
部署到QA或預生產環境的頻率也很重要。
需要在QA中儘早部署，以確保測試的時間。
在QA中發現Bug很重要，可以降低缺陷的轉化率。
# 部署時間
跟蹤實際部署需要多長時間是另一個很好的度量
可以幫助識別潛在的問題。當實際執行任務的任務比較快時，更容易部署。
# 交付時間
如果目標是快速發送代碼，這是一個非常關鍵的DevOps度量。
交付時間定義爲從工作項開始到部署之間的時間。
可以幫助自身知道，如果今天開始一項新的工作項目，它平均需要多長時間，直到它開始生產。
# 客戶反饋
應用程序問題的最好和最差的指示器是客戶的支持和反饋。
最不想要的就是讓用戶發現bug或者對軟件有問題。
因此，它們也能很好地反映應用程序的質量和性能問題。
# 自動化測試通過率
爲了提高速度，建議團隊廣泛使用單元測試和功能測試。
由於DevOps嚴重依賴於自動化，所以跟蹤自動化測試工作的好壞是一個良好的DevOps指標。
瞭解代碼更改導致測試中斷的頻率是很好的。
# 缺陷逃逸率
知道在生產和QA中發現了多少軟件缺陷嗎?
如果想要快速地發送代碼，需要有信心，可以在他們開始生產之前發現軟件缺陷。
缺陷逃逸率是一個很大的DevOps度量，用來跟蹤這些缺陷在生產過程中經常發生的情況。
# 可用性
最不想要的就是應用程序被關閉。
根據應用程序類型以及如何部署它，可能會有一些停機時間作爲計劃維護的一部分。
建議跟蹤這一點，以及所有計劃外的停機。
# 服務水平協議
大多數公司都有一些服務水平協議(SLA)。
同樣重要的是要追蹤sla是否遵守。
即使沒有正式的SLA，也可能需要實現應用程序要求或期望。
# 失敗部署率
我們都希望這種情況永遠不會發生，但是部署經常會給用戶造成中斷或重大問題嗎？
回滾失敗的部署是大家永遠都不想做的事情，但這是應該一直計劃的事情。
如果遇到了部署失敗的問題，請務必跟蹤這個度量。這也可以看作是對失敗的跟蹤平均時間(MTTF)。
# 錯誤率
在應用程序中跟蹤錯誤率非常重要。
它們不僅是質量問題的指示器，而且是持續的性能和與時間相關的問題。
好的異常處理最佳實踐對於良好的軟件是至關重要的。
# 應用程序的使用和通道
在部署之後，希望查看訪問系統的事務或用戶數量是否正常。
如果突然之間沒有“交通堵塞“，那麼有些事情可能是錯誤的。
最不想看到的就是根本沒有交通。
如果使用的是微服務，還可以看到流量激增，而應用程序之一突然導致了大量的流量。
# 應用程序的性能
在進行部署之前，應該使用工具來查找性能問題、隱藏的錯誤和其他問題。
在部署期間和部署之後，還應該尋找總體應用程序性能的任何變化。
在部署之後，可以看到特定SQL查詢、web服務調用和其他應用程序依賴項的使用的主要變化。
性能工具可以提供有價值的可視化效果，可以幫助發現問題。
# 平均檢測時間(MTTD)
當問題發生時，重要的是要快速地識別它們。
最不希望的是出現重大的部分或廣泛的系統中斷，而不知道它出現在哪裏。
擁有健壯的應用程序監控和良好的覆蓋將有助於快速發現問題。一旦發現也必須快速修復它們！
# 平均恢復時間(MTTR)
這個度量可以幫助您跟蹤從失敗中恢復需要多長時間。
對企業來說，一個關鍵的衡量標準就是將失敗降到最低，並且能夠迅速地從失敗中恢復過來。
它通常是按小時計算的，可能是指工作時間，而不是時鐘時間。
擁有良好的應用程序監視工具可以快速識別問題並快速部署修復程序，這對減少MTTR非常重要。
# 應用程序指標
除了上面列出的DevOps指標之外，還可以跟蹤許多其他的指標，這些指標都是特定於應用程序的。
它們中的大多數與DevOps在部署應用程序方面不一定相關。
但是，它們對於監視應用程序在生產中的使用和性能非常關鍵。
根據應用程序的不同，可能有類似的自定義指標，對應用程序至關重要。
在部署之後，將希望監視所有關鍵的應用程序指標，以確保一切仍然正常。
5 - 摘要
如果想要將DevOps帶到下一個級別，相信DevOps度量列表將幫助瞭解如何跟蹤和改進。
DevOps的目標是協作，讓開發人員更多地參與部署過程和應用程序監控。