DevOps 最初是作為簡化軟件交付的一個選項而嶄露頭角的。今天，DevOps 被廣泛認(rèn)為是交付過程的重要組成部分。關(guān)鍵的 DevOps 流程涉及從保護到維護應(yīng)用程序的方方面面。DevOps 實踐和原則本身并不能確保質(zhì)量，如果沒有正確集成，甚至可能導(dǎo)致更多問題。為了盡快將軟件推向市場，公司冒著被最終用戶發(fā)現(xiàn)的更多缺陷的風(fēng)險。

端到端 DevOps 的現(xiàn)代時代要求仔細(xì)整合關(guān)鍵績效指標(biāo) (KPI)。正確的指標(biāo)可以確保應(yīng)用程序發(fā)揮其最大潛力。理想情況下，DevOps 指標(biāo)和 KPI 以清晰易懂的方式呈現(xiàn)相關(guān)信息。他們應(yīng)該一起提供部署和更改過程的概述 - 以及可以改進的地方。在您努力提高效率和用戶體驗時，以下指標(biāo)值得跟蹤。

DevOps 指標(biāo)和關(guān)鍵績效指標(biāo)

1. 部署頻率

部署頻率表示啟動新特性或功能的頻率。頻率可以每天或每周測量一次。許多組織更喜歡每天跟蹤部署，尤其是在它們提高效率時。理想情況下，頻率指標(biāo)要么隨著時間的推移保持穩(wěn)定，要么會出現(xiàn)輕微而穩(wěn)定的增長。部署頻率的任何突然降低都可能表明現(xiàn)有工作流程中的瓶頸。更多的部署通常會更好，但只是在一定程度上。如果高頻導(dǎo)致部署時間增加或故障率增加，則可能值得推遲部署增加，直到現(xiàn)有問題得到解決。

2. 改變音量

如果大多數(shù)部署沒有什么影響，那么部署頻率就沒有多大意義。部署的實際價值可能會更好地反映在變化量上。此DevOps KPI確定代碼更改與保持不變的程度。部署頻率的改進不應(yīng)對變更量產(chǎn)生重大影響。

3. 部署時間

一旦獲得批準(zhǔn)，部署部署需要多長時間？自然，如果部署速度快，部署的頻率會更高。部署時間的急劇增加值得進一步調(diào)查，尤其是在部署量減少的情況下。雖然縮短部署時間是必不可少的，但不應(yīng)以準(zhǔn)確性為代價。錯誤率增加可能表明部署發(fā)生得太快。

4. 部署失敗率

有時稱為平均故障時間，該指標(biāo)確定部署提示中斷或其他問題的頻率。這個數(shù)字應(yīng)該盡可能低。失敗的部署率通常與更改量一起引用。較低的更改量以及不斷增加的失敗部署率可能表明工作流程中的某個地方出現(xiàn)了功能障礙。

5. 改變失敗率

變更失敗率是指發(fā)布導(dǎo)致意外中斷或其他計劃外故障的程度。較低的更改失敗率表明部署快速且定期發(fā)生。相反，高更改失敗率表明應(yīng)用程序穩(wěn)定性差，這可能導(dǎo)致最終用戶產(chǎn)生負(fù)面結(jié)果。

6. 檢測時間

較低的更改失敗率并不總是表明您的應(yīng)用程序一切正常。雖然理想的解決方案是盡量減少甚至消除失敗的更改，但如果確實發(fā)生了故障，則必須快速捕獲它們。檢測 KPI 的時間可以確定當(dāng)前的響應(yīng)工作是否足夠。檢測時間過長可能會引發(fā)能夠中斷整個工作流程的瓶頸。

7. 平均恢復(fù)時間

一旦檢測到失敗的部署或更改，實際上需要多長時間才能解決問題并重回正軌？平均恢復(fù)時間 (MTTR) 是一項重要指標(biāo)，表明您對已識別問題做出適當(dāng)響應(yīng)的能力。如果不進行同樣快速的恢復(fù)工作，那么及時檢測就毫無意義。MTTR 是最著名和最常被引用的DevOps 關(guān)鍵性能指標(biāo)指標(biāo)之一。

8. 交貨時間

提前期衡量更改發(fā)生所需的時間。可以從構(gòu)思開始并繼續(xù)通過部署和生產(chǎn)來跟蹤該度量。交付周期為整個開發(fā)過程的效率提供了寶貴的洞察力。它還表明了當(dāng)前滿足用戶群不斷變化的需求的能力。較長的交付周期表明存在有害的瓶頸，而較短的交付周期表明反饋得到及時解決。

9. 缺陷逃逸率

每個軟件部署都有引發(fā)新缺陷的風(fēng)險。在完成驗收測試之前，這些可能不會被發(fā)現(xiàn)。更糟糕的是，最終用戶可以找到它們。錯誤是開發(fā)過程的自然組成部分，應(yīng)相應(yīng)地進行計劃。缺陷逃逸率反映了這一現(xiàn)實，承認(rèn)問題會出現(xiàn)并且應(yīng)該盡早發(fā)現(xiàn)。缺陷逃逸率跟蹤在生產(chǎn)前與生產(chǎn)過程中發(fā)現(xiàn)缺陷的頻率。這個數(shù)字可以提供一個有價值的衡量軟件版本總體質(zhì)量的標(biāo)準(zhǔn)。

10. 缺陷體積

該指標(biāo)與上面突出顯示的逃逸率有關(guān)，而是側(cè)重于實際的缺陷量。雖然有些缺陷是意料之中的，但突然增加應(yīng)該引起關(guān)注。特定應(yīng)用程序的大量缺陷可能表明開發(fā)或測試數(shù)據(jù)管理存在問題。

11. 可用性

可用性突出了給定應(yīng)用程序的停機時間。這可以衡量為完全（讀/寫）或部分（只讀）可用性。更少的停機時間幾乎總是更好。話雖如此，定期維護可能需要一些可用性失效。密切跟蹤計劃內(nèi)停機和計劃外停機，記住 100% 的可用性可能并不現(xiàn)實。

12. 服務(wù)水平協(xié)議合規(guī)性

為了提高透明度，大多數(shù)公司根據(jù)服務(wù)水平協(xié)議運營。這些突出了供應(yīng)商和客戶之間的承諾。SLA 合規(guī) KPI 提供了必要的責(zé)任，以確保滿足 SLA 或其他期望。

13. 計劃外工作

有多少時間花在意料之外的努力上？計劃外工作率 (UWR)根據(jù)計劃工作所花費的時間來跟蹤這一點。理想情況下，計劃外工作率 (UWR) 不會超過 25%。較高的 UWR 可能表明在工作流程早期可能未檢測到的意外錯誤上浪費了精力。UWR 有時與返工率 (RWR) 一起檢查，這與解決工單中提出的問題的努力有關(guān)。

14. 客票量

正如缺陷逃逸率 KPI 所表明的那樣，并非所有缺陷都是災(zāi)難性的。然而，理想情況下，他們會盡早被發(fā)現(xiàn)。這個概念最能反映在客戶票數(shù)上，它表明最終用戶生成了多少警報。穩(wěn)定的用戶量以及增加的票證量表明生產(chǎn)或測試中存在問題。

15. 周期時間

周期時間指標(biāo)提供了應(yīng)用程序部署的廣泛概述。此 KPI 跟蹤整個過程，從構(gòu)思開始到用戶反饋結(jié)束。較短的周期通常是可取的，但不會以發(fā)現(xiàn)缺陷或遵守 SLA 為代價。

開始衡量 Devops 的成功

在跟蹤關(guān)鍵 DevOps 指標(biāo)時，不要關(guān)注根據(jù)任何一個指標(biāo)感知到的成功或失敗，而是關(guān)注這些指標(biāo)在一起檢查時所講述的故事。當(dāng)與其他數(shù)據(jù)一起分析時，一個本身似乎有問題的結(jié)果可能看起來完全不同。仔細(xì)跟蹤上面強調(diào)的 KPI 不僅可以確保更高的開發(fā)和生產(chǎn)效率，更重要的是，可以確保最佳的最終用戶體驗。擁抱 DevOps 指標(biāo)，您會看到應(yīng)用程序部署和反饋方面的巨大改進。