DevOps在你的組織內(nèi)部運(yùn)行的如何？如果你需要一些幫助來(lái)度量它的運(yùn)行情況，我們已經(jīng)準(zhǔn)備了一個(gè)用于跟蹤的關(guān)鍵DevOps指標(biāo)的列表，這些度量可以幫助了解你的團(tuán)隊(duì)是如何隨著時(shí)間的推移而運(yùn)行的。

在團(tuán)隊(duì)內(nèi)部明確DevOps的定義意義重大

DevOps這個(gè)詞不同的人有不同的理解，有人說(shuō)這是一種文化，業(yè)內(nèi)的每個(gè)廠商都聲稱他們的工具幫助了DevOps，根據(jù)你如何定義DevOps，其中的一些度量可能對(duì)你的團(tuán)隊(duì)有重要的影響。

我將DevOps定義為與部署和監(jiān)視應(yīng)用程序相關(guān)的所有內(nèi)容，從很多方面來(lái)說(shuō)，這都是現(xiàn)實(shí)的可靠的工程問(wèn)題。在Stackify，我們甚至沒(méi)有運(yùn)維團(tuán)隊(duì)，我們的開發(fā)人員直接部署到云上，我們的操作方式更多的是“NoOps”風(fēng)格。

確定你的DevOps的挑戰(zhàn)

在弄清楚DevOps度量標(biāo)準(zhǔn)是什么之前，你需要確定組織所面臨的挑戰(zhàn)以及要解決的問(wèn)題。在Stackify，我們最大的問(wèn)題不是經(jīng)常部署，并且降低了缺陷逃逸速度。我們的執(zhí)行團(tuán)隊(duì)正把重點(diǎn)放在2018年的具體指標(biāo)上。

DevOps指標(biāo)的類型

DevOps是盡可能快的持續(xù)交付和傳輸代碼，你想要行動(dòng)迅速而不是打破常規(guī)，通過(guò)跟蹤這些DevOps指標(biāo)，你可以評(píng)估在開始破壞之前，可以有多快。

Deployment frequency 部署頻率

Change volume 容量變化

Deployment time 部署時(shí)間

Lead time 交付時(shí)間

Customer tickets 客戶工單

Automated test pass % 自動(dòng)化測(cè)試通過(guò)百分比

Defect escape rate 缺陷逃逸率

Availability 可用性

Service level agreements 服務(wù)水平協(xié)議SLA

Failed deployments 失敗的部署

Error rates 錯(cuò)誤率

Application usage and traffic 應(yīng)用程序的使用和流量

Application performance 應(yīng)用程序的性能

Mean time to detection (MTTD) 平均檢測(cè)時(shí)間

Mean time to recovery (MTTR) 平均恢復(fù)時(shí)間

DevOps的目標(biāo)：速度、質(zhì)量、性能

DevOps的主要目標(biāo)是速度、質(zhì)量和應(yīng)用程序性能。

希望盡可能快地發(fā)送代碼，根據(jù)你的產(chǎn)品類型、團(tuán)隊(duì)和風(fēng)險(xiǎn)承受能力，你可以盡快的實(shí)現(xiàn)這一目標(biāo)。

即使你沒(méi)有在速度上跟蹤任何DevOps指標(biāo)，至少應(yīng)該衡量在質(zhì)量上的工作，也許你并不真的在乎到底有多快，但是，你總是關(guān)心質(zhì)量，你最不想要的就是一直在疲于生產(chǎn)。

關(guān)于性能，你可以爭(zhēng)辯說(shuō)，這也與你的高速度和高質(zhì)量的目標(biāo)不一致，性能也與質(zhì)量有關(guān)，但可能略有不同。

部署規(guī)模

跟蹤有多少功能、特性請(qǐng)求和錯(cuò)誤修復(fù)正在被部署，這是另一個(gè)良好的DevOps度量，取決于你的工作項(xiàng)目有多大，它們的數(shù)量可能會(huì)有很大差異，您還可以跟蹤部署了多少個(gè)功能點(diǎn)或幾天的開發(fā)工作。

部署頻率

跟蹤部署的頻率是一個(gè)良好的DevOps度量，最終目標(biāo)是盡可能多地部署更小的部署，減少部署的規(guī)模使測(cè)試和發(fā)布變得更加容易。

我建議單獨(dú)計(jì)算生產(chǎn)和非生產(chǎn)部署，部署到QA或預(yù)生產(chǎn)環(huán)境的頻率也很重要。你需要在QA中盡早部署，以確保測(cè)試的時(shí)間，在QA中發(fā)現(xiàn)bug很重要，可以降低缺陷的轉(zhuǎn)化率。

部署時(shí)間

這看起來(lái)可能很奇怪，但是跟蹤實(shí)際部署需要多長(zhǎng)時(shí)間是另一個(gè)很好的度量。我們?cè)赟tackify的一個(gè)應(yīng)用程序部署在Azure上，部署大約需要一個(gè)小時(shí)。這是一個(gè)噩夢(mèng)，跟蹤這些事情可以幫助識(shí)別潛在的問(wèn)題，當(dāng)實(shí)際執(zhí)行任務(wù)的任務(wù)比較快時(shí)，更容易部署。

交付時(shí)間

如果目標(biāo)是快速發(fā)布代碼，這是一個(gè)非常關(guān)鍵的DevOps度量，我將把交付時(shí)間定義為從工作項(xiàng)開始到部署之間的時(shí)間。這可以幫助你知道，如果你今天開始一項(xiàng)新的工作項(xiàng)目，直到它開始生產(chǎn)，平均需要多長(zhǎng)時(shí)間。

客戶工單

應(yīng)用程序問(wèn)題的最好和最差的指示器是客戶工單和反饋，你最不想要的就是讓你的用戶發(fā)現(xiàn)bug或者對(duì)你的軟件有問(wèn)題，因此，它們也能很好地反映應(yīng)用程序的質(zhì)量和性能問(wèn)題。

通過(guò)自動(dòng)化測(cè)試通過(guò)率

為了提高速度，建議你的團(tuán)隊(duì)廣泛使用單元測(cè)試和功能測(cè)試，由于DevOps嚴(yán)重依賴于自動(dòng)化，所以跟蹤你的自動(dòng)化測(cè)試工作的好壞是一個(gè)良好的DevOps指標(biāo)，了解代碼更改導(dǎo)致測(cè)試中斷的頻率是很好的方法。

缺陷逃逸率

你知道在生產(chǎn)和QA中發(fā)現(xiàn)了多少軟件缺陷嗎？如果你想要快速地發(fā)布代碼，你需要有信心，你可以在他們開始生產(chǎn)之前發(fā)現(xiàn)軟件缺陷。缺陷逃逸率是一個(gè)很大的DevOps度量，用來(lái)跟蹤這些缺陷在生產(chǎn)過(guò)程中經(jīng)常發(fā)生的情況。

可用性

你最不想要的就是應(yīng)用程序被關(guān)閉，根據(jù)應(yīng)用程序類型以及如何部署它，可能會(huì)有一些停機(jī)時(shí)間作為計(jì)劃維護(hù)的一部分，我建議跟蹤這一點(diǎn)，以及所有計(jì)劃外的停機(jī)。

服務(wù)水平協(xié)議

大多數(shù)公司都有一些服務(wù)水平協(xié)議(SLA)，同樣重要的是你要追蹤你的SLA是否被遵守，即使沒(méi)有正式的SLA，也可能需要實(shí)現(xiàn)應(yīng)用程序達(dá)到期望。

失敗的部署

我們都希望這種情況永遠(yuǎn)不會(huì)發(fā)生，但是你的部署經(jīng)常會(huì)給用戶造成中斷或重大問(wèn)題嗎？反轉(zhuǎn)失敗的部署是我們永遠(yuǎn)都不想做的事情，但這是你應(yīng)該一直計(jì)劃的事情。如果你遇到了部署失敗的問(wèn)題，請(qǐng)務(wù)必跟蹤這個(gè)度量，這也可以看作是對(duì)失敗的跟蹤平均時(shí)間(MTTF)。

錯(cuò)誤率

應(yīng)用程序中跟蹤錯(cuò)誤率非常重要，它們不僅是質(zhì)量問(wèn)題的指示器，而且是持續(xù)的性能和與時(shí)間相關(guān)的問(wèn)題，好的異常處理最佳實(shí)踐對(duì)于良好的軟件是至關(guān)重要的。

bug，在部署后識(shí)別在代碼中拋出的新異常。

生產(chǎn)問(wèn)題，用數(shù)據(jù)庫(kù)連接捕獲問(wèn)題，查詢超時(shí)和其他相關(guān)問(wèn)題。

對(duì)于大多數(shù)應(yīng)用程序來(lái)說(shuō)，錯(cuò)誤是生命周期的一部分，在Stackify，我們?cè)趲装賯€(gè)服務(wù)器和上千個(gè)SQL數(shù)據(jù)庫(kù)中處理數(shù)百萬(wàn)條消息。這里有一些錯(cuò)誤，只是一個(gè)繁忙系統(tǒng)的部分噪音，重要的是，你要對(duì)你的錯(cuò)誤率保持監(jiān)控，并尋找峰值。

應(yīng)用程序的使用和流量

在部署之后，你希望查看訪問(wèn)你的系統(tǒng)的事務(wù)或用戶數(shù)量是否正常，如果你突然之間沒(méi)有流量，那么有些事情可能是錯(cuò)誤的。

你最不想看到的就是根本沒(méi)有交通，如果使用的是微服務(wù)，你還可以看到流量激增，而應(yīng)用程序之一突然導(dǎo)致了大量的流量。

應(yīng)用程序的性能

在進(jìn)行部署之前，你應(yīng)該使用像Retrace這樣的工具來(lái)查找性能問(wèn)題、隱藏的錯(cuò)誤和其他問(wèn)題。在部署期間和部署之后，你還應(yīng)該尋找總體應(yīng)用程序性能的任何變化。

在部署之后，可以看到特定SQL查詢、web服務(wù)調(diào)用和其他應(yīng)用程序依賴項(xiàng)的使用的主要變化。像Retrace這樣的工具可以提供有價(jià)值的可視化效果，比如下面這個(gè)，可以幫助你輕松地發(fā)現(xiàn)問(wèn)題。

平均檢測(cè)時(shí)間(MTTD)

當(dāng)問(wèn)題發(fā)生時(shí)，重要的是你要快速地識(shí)別它們。最不希望的是出現(xiàn)重大的部分或廣泛的系統(tǒng)中斷，而不知道它。擁有健壯的應(yīng)用程序監(jiān)控和良好的覆蓋將有助于快速發(fā)現(xiàn)問(wèn)題。一旦發(fā)現(xiàn)它們，你也必須快速修復(fù)它們！

平均恢復(fù)時(shí)間(MTTR)

這個(gè)度量可以幫助你跟蹤從失敗中恢復(fù)需要多長(zhǎng)時(shí)間。對(duì)企業(yè)來(lái)說(shuō)，一個(gè)關(guān)鍵的衡量標(biāo)準(zhǔn)就是將失敗降到最低，并且能夠迅速地從失敗中恢復(fù)過(guò)來(lái)。它通常是按小時(shí)計(jì)算的，可能是指業(yè)務(wù)時(shí)間，而不是時(shí)鐘時(shí)間。

擁有良好的應(yīng)用程序監(jiān)視工具可以快速識(shí)別問(wèn)題并快速部署修復(fù)程序，這對(duì)減少M(fèi)TTR非常重要。

應(yīng)用程序指標(biāo)

除了上面列出的DevOps指標(biāo)之外，你還可以跟蹤許多其他的指標(biāo)，這些指標(biāo)都是特定于你的應(yīng)用程序的。它們中的大多數(shù)與DevOps在部署應(yīng)用程序方面不一定相關(guān)。但是，它們對(duì)于監(jiān)視應(yīng)用程序在生產(chǎn)中的使用和性能非常關(guān)鍵。

例如，在Stackify中，我們使用自定義度量來(lái)跟蹤每分鐘通過(guò)API接收的日志消息數(shù)量。這是一個(gè)重要的度量指標(biāo)，幫助我們理解流經(jīng)系統(tǒng)的數(shù)據(jù)量。根據(jù)你的應(yīng)用程序的不同，你可能有類似的自定義指標(biāo)，對(duì)你的應(yīng)用程序至關(guān)重要。

在部署之后，你將希望監(jiān)視所有關(guān)鍵的應(yīng)用程序指標(biāo)，以確保一切仍然正常。

總結(jié)

如果你想要將DevOps帶到下一個(gè)級(jí)別，我相信我們的DevOps度量列表將幫助你了解如何跟蹤和改進(jìn)。DevOps的目標(biāo)是協(xié)作，讓開發(fā)人員更多地參與部署過(guò)程和應(yīng)用程序監(jiān)控。

申明：本文非原創(chuàng)，來(lái)自網(wǎng)絡(luò)轉(zhuǎn)載。