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