DevOps在你的組織中執行的如何？如果你需要幫忙衡量它執行的如何，我們準備了一些DevOps的關鍵指標來進行追蹤。這些指標可以幫助理解你的團隊過去做的如何。

定義DevOps對你的組織意味著什麼

DevOps這個詞，不同的人不同理解。有些人說他是一種文化並且行業中的每個供應商聲稱，他們的工具有助於DevOps。取決於你如何定義DevOps，這些指標會對你和你的團隊多多少少有些幫助。

我把DevOps定義為與部署和監視應用相關的所有內容。從許多方面來說，這都是現場可靠性工程的問題。在Stackify，我們都沒有一個操作團隊來合作。我們的開發人員直接部署到雲上，我們的操作方式更多的是“NoOps”風格。可以看我的部落格，瞭解我對DevOps的更多看法。

確定你的DevOps挑戰

在弄清楚DevOps衡量標準是什麼之前，需要確定組織所面臨的挑戰以及你要解決的問題。在Stackify，我們最大的問題不是頻繁部署，和降低的bug逃逸率。我們的執行團隊正把重點放在2018年的具體指標上。

DevOps衡量標準的型別

DevOps是關於持續交付和儘可能快的釋出程式碼。你想要的是行動迅速而不是打破常規。通過跟蹤這些DevOps指標，可以評估在事情開始變壞之前，你可以移動多快。

1. 部署頻率

2. 體積變化

3. 部署時間

4. 交付時間

5. 客戶反饋

6. 自動化測試通過百分比

7. bug逃逸率

8. 可用性

9. 服務水平協議

10. 失敗部署

11. 錯誤率

12. 應用的使用和流量

13. 應用效能

14. 平均檢測時間(MTTD)

15. 平均恢復時間(MTTR)

DevOps的目標：速度、質量、效能

DevOps的主要目標是速度、質量和應用效能。

你希望儘快地釋出程式碼。根據你的產品型別、團隊和風險承受能力，可以有多快地實現這一目標。

即使沒有在速度上跟蹤任何DevOps指標，至少應該在質量上評估下工作方式。也許在可能的情況下試著釋出，而且並不在意有多快，但是質量你總是關心的。你最不想要的就是總是在追著生產的災難。

方程式的第三個部分是效能。你可以說，這也與你的高速度和高質量的目標不一致。效能也與質量有關，但可能略有不同。

部署大小

跟蹤多少stories、特性請求和錯誤修復正在被部署，這是DevOps一個很好的衡量標準。根據你的專案有多大，它們的數量可能會有很大差異。還可以跟蹤部署了多少個story points或這幾天開發工作的價值。

部署頻率

跟蹤部署頻率是DevOps一個良好的衡量標準。最終，目標是儘可能多地做更多小型部署。減少部署的大小讓測試和釋出變得更加容易。

我建議單獨計算生產和非生產部署。部署到QA或預生產環境的頻率也很重要。需要在QA中儘早部署，以確保測試的時間。在QA中發現bug很重要，可以降低bug的轉化率。

部署時間

這看起來可能很奇怪，但是跟蹤實際部署需要多長時間是很好的指標。我們在Stackify的一個應用中部署了Azure工作者角色，部署大約需要一個小時。這是一個噩夢。跟蹤這些事情可以幫助識別潛在的問題。當實際執行比較快時，更容易頻繁部署。

交付時間

如果目標是快速釋出程式碼，這是一個非常關鍵的指標。我把交付時間定義為從工作項開始到它被部署之間的時間。這可以幫助你知道，如果你今天開始一項新的工作，它平均需要多長時間，直到它開始生產。這也是有助於BizDevOps的一個好方法。

客戶反饋

應用問題的最好與最差的指標是客戶的支援和反饋。你最不想要的就是讓的使用者發現bug或者發現你軟體有問題。因此，它們也能很好地反映應用的質量和效能問題。

自動化測試通過百分比

為了提高速度，建議團隊廣泛使用單元測試和功能測試。由於DevOps嚴重依賴於自動化，所以跟蹤自動化測試工作的好壞是一個DevOps指標。瞭解程式碼更改導致測試中斷的頻率是很好的。

bug逃逸率

你知道在生產和QA中發現了多少軟體bug嗎？如果想要快速地釋出程式碼，需要有信心，可以在他們開始生產之前發現軟體bug。bug逃逸率是DevOps一個很大的指標，用來跟蹤這些bug在生產過程中經常發生的情況。

可用性

最不想發生的就是應用停機。根據應用型別以及如何部署它，可能會有一些停機時間作為計劃維護的一部分。建議跟蹤這一點，以及所有計劃外的停機。

服務水平協議

大多數公司都有一些服務水平協議(SLA)。同樣重要的是你要追蹤是否遵守SLA。即使沒有正式的SLA，也可能需要實現應用需求或預期。

失敗部署

我們都希望這種情況永遠不會發生，但是部署經常會給使用者造成中斷或重大問題嗎？反轉失敗的部署是我們永遠都不想做的事情，但這是應該一直計劃的事情。如果遇到了部署失敗的問題，請務必跟蹤這個指標。這也可以看作是對失敗的跟蹤平均時間(MTTF)。

錯誤率

在應用中跟蹤錯誤率非常重要。它們不僅是質量問題的指示器，而且是與持續效能和正常執行時間相關的問題。好的異常處理最佳實踐對於良好的軟體是至關重要的。

• bug——在部署後識別在程式碼中丟擲的新異常。

• 生產問題——通過資料庫連線捕獲問題，查詢超時和其他相關問題。

對於大多數應用程式來說，錯誤是無法更改事實。在Stackify，我們在幾百個伺服器和上千個SQL資料庫中處理數百萬條訊息。這裡有一些錯誤，只是一個繁忙系統的部分噪音。重要的是，你要對你的錯誤率保持一個脈衝，並尋找峰值。

應用使用和流量

在部署之後，想檢視訪問系統的事務或使用者數量是否正常。如果突然之間沒有流量或者流量有大幅上升，那麼有些東西可能是錯誤的。

最不想看到的就是根本沒有流量。如果使用的是微服務可以看到流量激增，而你某個應用突然導致了大量的流量。

應用效能

在進行部署之前，應該使用像Retrace這樣的工具來查詢效能問題、隱藏的bug和其他問題。在部署期間和部署之後，還應該尋找總體應用程式效能的任何變化。

在部署之後，可以看到特定SQL查詢、web服務呼叫和其他應用依賴項的使用的主要變化。Retrace這樣的工具可以提供有價值的視覺化效果，比如下面這個，可以幫助輕鬆地發現問題。

平均監測時間（MTTD）

當問題發生時，重要的是你要快速地識別它們。最不希望的是出現重大的部分或廣泛的系統中斷，而卻不知道為什麼。擁有強大的應用監控和良好的覆蓋將有助於快速發現問題。一旦發現它們，也必須快速修復問題。

平均恢復時間（MTTR）

這個指標可以幫助跟蹤從失敗中恢復需要多長時間。對企業來說，一個關鍵的衡量標準就是將失敗降到最低，並且能夠迅速地從失敗中恢復過來。它通常是按小時計算的，可能是指工作時間，而不是時鐘時間。

擁有良好的應用程式監視工具可以快速識別問題並快速部署修復程式，這對減少MTTR非常重要。

應用指標

除了上面列出的DevOps指標之外，還可以跟蹤許多其他的指標，這些指標都是特定於你的應用程式的。它們中的大多數與DevOps在部署應用方面不一定相關。但是，它們對於監視應用程式在生產中的使用和效能非常關鍵。

例如，在Stackify中，我們使用自定義指標來跟蹤每分鐘通過API接收的日誌訊息數量。這是一個重要的衡量指標，幫助我們理解流經系統的資料量。根據你應用程式的不同，可能有類似的自定義指標，對你的應用程式至關重要。

在部署之後，你將希望監視所有關鍵的應用程式指標，以確保一切仍然正常。

總結

如果你想要讓DevOps進行到下一個級別，我相信我們的DevOps指標列表將幫助你瞭解如何跟蹤和改進。DevOps的目標是協作，讓開發人員更多地參與部署過程和應用程式監控