助力 DevOps 成功的十五個度量指標

　　本文轉載自 DevOps 時代高翻院（調整了部分翻譯問題）

　　英文原文：https://dzone.com/articles/15-metrics-for-devops-success

　　持續對特定指標的關注是衡量 DevOps 實踐是否成功的關鍵。通過本文，我們來看一下你需要關注的十五個度量指標。

　　你所在的組織里 DevOps 是如何踐行的？如果你需要一些幫助來了解這個過程進行的怎么樣，我們已經準備了一個關鍵的 DevOps 指標清單用來追蹤。這些指標可以幫助你了解到，在隨著時間的推移你的團隊是如何做的。

上海數據恢復

　　DevOps 這個詞對于不同的人有不同的含義。有人認為它是一種文化，這個行業中的每個廠商都聲稱他們的工具是有益于 DevOps 的。依據你對 DevOps 的定義不同，這些指標可能對你的或者你的團隊的意義或大或小。

　　我認為 DevOps 包括了你的應用程序在部署和監控中的整個過程。從很多方面來說，這都是站點可靠性工程的問題。

　　在 Stackify，我們甚至都沒有運維團隊來協作。我們的開發人員會直接部署到云服務器，并且更像是“No-Ops”的方式。

　　查看我的博客，可以找到更多我對于 DevOps 是什么的觀點。

　　在你弄明白有哪些 DevOps 指標需要追蹤之前，你需要識別出來你所在的組織中有哪些挑戰，有哪些問題是你們正在解決的。

　　在 Stackify，我們最大的問題是部署頻率低，并且降低了缺陷逃逸率。我們的執行團隊正在把重點放在2018年的具體指標上。

　　DevOps 是為了盡可能快的持續交付并交付代碼。你希望能盡快交付而不因此導致問題發生。

　　通過追蹤這些 DevOps 指標，可以評估出你們持續交付的速度有多快，而不會導致有問題。

　　1、部署頻率

　　2、部署規模

　　3、部署時間

　　4、投產周期

　　5、客戶工單數

　　6、自動化測試通過率

　　7、缺陷逃逸率

　　8、可用性

　　9、服務等級協議

　　10、部署失敗數

　　11、錯誤率

　　12、應用程序的使用和流量

　　13、應用程序性能

南通數據恢復

　　14、平均檢測時間（MTTD）

　　15、平均恢復時間（MTTR）

　　DevOps 的主要目標是快速，質量和性能。

　　你希望盡可能經常、快速地交付代碼。可以做到多快，很大程度上取決于你的產品類型、團隊以及風險承受能力。

　　你可以不跟蹤 DevOps 中速度的指標，但至少應該關于質量問題。你可能已經試著根據自己的能力來做這些，但并沒有真正地關心到底能有多快。

　　然而，你總是在關注質量。你最不希望的就是總是在救產品的“火“。

　　第三部分是性能。你可能對速度和質量的權衡有質疑。性能也和質量有關，只是有點區別。

　　跟蹤有多少故事、特性需求以及修復的 bug 正在被部署是 DevOps 的另外一個好的指標。你的項目的大小會影響部署規模的。你還可以追蹤有多少故事點或者開發任務量。

　　跟蹤部署頻率是另外一個不錯的 DevOps 指標。最終的目標是，降低部署規模并加快部署頻率。降低部署規模使得更加容易測試和發布。

　　我建議單獨統計生產和非生產的部署頻率。你多久部署一次 QA 或者預生產環境同樣是重要的。為了確保測試的時間，你需要盡早盡快地部署到 QA 環境中。

　　在 QA 環境中查找 bug，可以有效地保持較低的缺陷逃逸率。

　　這一點看起來有些奇怪，但跟蹤部署一次所需要花的時間同樣是一個好的指標。如果在 Stackify 中，你的一個程序需要花費一個小時才能部署到 Azure 上時。這將會是個噩夢。

　　跟蹤這些事情可以幫助你識別潛在的問題。如果部署的很快，也更加容易增加部署頻率。

　　如果目標是快速交付代碼的話，這也確實是一個關鍵的 DevOps 指標。我對投產周期的定義是，從開始工作到部署之間所需要的時間。

　　這可以幫你了解，如果今天開始一項新的工作時，多久將能夠投產。這也是有助于 BizDevOps 的一個好的指標。

　　應用程序問題的最好和最壞的表現是客戶支持工單和反饋。你最不希望看到的就是你的用戶發現 bug 或者軟件的問題。因此，這也就成為了程序質量和性能問題的指示器。

　　為了加快速度，強烈建議你的團隊廣泛使用單元測試和功能測試。由于 DevOps 嚴重依賴自動化，跟蹤你的自動化測試工作質量是一個好的 DevOps 指標。

　　知道代碼的變更多久會導致你的測試會失敗是件好事情。

　　你知道有多少軟件的缺陷在聲稱和 QA 中被發現？如果想要快速交付代碼，你需要有信心能上在生產之前發現軟件的缺陷。

　　你的缺陷逃逸率是非常大的一個指標，用來跟蹤這些缺陷在生產中經常發生的情況。

　　你最不想要的就是程序停止。根據你的程序類型以及部署方式，可能會需要在維護計劃中讓程序下線。我建議跟蹤這一點，以及所有計劃外的停機。

　　大多數有一些服務等級協議（SLA）。跟蹤你的 SLA 是否合規同樣重要。即使沒有正式的 SLA，也可能需要有對程序的期望。

　　我們都不希望發生，但是對于你們的用戶部署過程多久會發生一次中斷或者較大的問題？挽救一次失敗的部署是我們都不想要做的事情，但總是應該對此有應對措施。如果你們的部署過程有缺陷，一定要對這個指標做追蹤。這也應當在平均錯誤時間（MTTF）中被看到。

　　跟蹤程序的錯誤率是特別重要的。它不僅僅是質量問題的指示器，也與持續的性能和時間相關的問題有關聯。對于好的軟件來說良好的異常處理機制是很重要的。

　　Bugs – 識別代碼部署后產生的新異常。

　　線上問題 – 捕獲數據庫連接問題，查詢超時，以及其他相關問題。

　　對于大多數程序來說，錯誤總是存在的。在 Stackify，我們在幾百臺服務器和上千個 SQL 數據庫中處理百萬條消息。這里有些錯誤只是繁忙系統的意外。重要的是你要把錯誤率保持在一個頻率并且查找一個峰值。

　　部署之后，你想要看到會話的數量或者用戶訪問系統是否正常。如果突然沒有了流量或者出現峰值，就可能是出問題了。

　　你最不希望看到的就是沒有任何流量。當你采用服務時，也可能看到有流量的峰值，而一個程序突然有了大量的流量。

　　在你部署之前，應該使用類似 Retrace 這樣的工具查找性能問題、隱藏的問題或者其他問題。在部署期間和之后，你也應該查找是否有性能上的變化。

　　在部署之后，可以看到特定的 SQL 查詢、web 服務調用和其他程序依賴的主要變化。像 Retrace 這樣的工具可以提供下面可視化的價值評估，以幫助你發現問題。

　　當問題發生后，重要的是能夠快速識別出來。你最不想看到是主要功能或者大部分系統宕機并不知道原因。健壯的應用程序監控并且能覆蓋到位將有助于你快速定位問題。一旦你定位了問題，就必須快速地修復！

　　這個指標幫你記錄從失敗到恢復需要花費多長時間。一個關鍵的商業指標就是保持錯誤最小化并能夠快速地恢復。通常按小時來計算，但對應的是業務上的小時而不是時鐘小時數。

　　擁有一個健壯的應用程序監控工具從而快速識別問題并修復和部署對于減少你的平均恢復時間（MTTR）是很重要的。

　　除了上面列出來的 DevOps 指標外，你還可以記錄很多其他指標，這些指標都是針對特定程序的。它們中的大多數都在 DevOps 部署你的應用程序時不是必需的。然而，它們對于應用程序在生產中的使用和性能的監控是非常重要的。

　　例如，在 Stackify 中，我們利用自定義指標來跟蹤每分鐘通過 API 收到的日志消息數量。這是一個重要的指標，它可以幫助我們了解通過我們系統的數據量。根據你的應用程序實際情況，你可以定義類似對于你們來說非常重要的指標。

　　當部署以后，你就想要關注所有重要的程序指標，以確保是沒問題的。

　　如果你想要把 DevOps 實踐到更高層次，我相信上面列出的 DevOps 指標將會有助于你追蹤和改進。DevOps 的目標是共同協作并讓更多的開發者參與到部署和應用程序監控中來。

常州數據恢復

　　更多內容請關注DevOpsClub公眾號

　　點擊閱讀原文鏈接，查看英文原文。