DevOps 最初是作為簡(jiǎn)化軟件交付的一個(gè)選項(xiàng)而嶄露頭角的。今天，DevOps 被廣泛認(rèn)為是交付過程的重要組成部分。關(guān)鍵的 DevOps 流程涉及從保護(hù)到維護(hù)應(yīng)用程序的方方面面。DevOps 實(shí)踐和原則本身并不能確保質(zhì)量，如果沒有正確集成，甚至可能導(dǎo)致更多問題。為了盡快將軟件推向市場(chǎng)，公司冒著被最終用戶發(fā)現(xiàn)的更多缺陷的風(fēng)險(xiǎn)。
端到端 DevOps 的現(xiàn)代時(shí)代要求仔細(xì)整合關(guān)鍵績(jī)效指標(biāo) (KPI)。正確的指標(biāo)可以確保應(yīng)用程序發(fā)揮其最大潛力。理想情況下，DevOps 指標(biāo)和 KPI 以清晰易懂的方式呈現(xiàn)相關(guān)信息。他們應(yīng)該一起提供部署和更改過程的概述 - 以及可以改進(jìn)的地方。在您努力提高效率和用戶體驗(yàn)時(shí)，以下指標(biāo)值得跟蹤。
DevOps 指標(biāo)和關(guān)鍵績(jī)效指標(biāo)
1. 部署頻率
部署頻率表示啟動(dòng)新特性或功能的頻率。頻率可以每天或每周測(cè)量一次。許多組織更喜歡每天跟蹤部署，尤其是在它們提高效率時(shí)。理想情況下，頻率指標(biāo)要么隨著時(shí)間的推移保持穩(wěn)定，要么會(huì)出現(xiàn)輕微而穩(wěn)定的增長。部署頻率的任何突然降低都可能表明現(xiàn)有工作流程中的瓶頸。更多的部署通常會(huì)更好，但只是在一定程度上。如果高頻導(dǎo)致部署時(shí)間增加或故障率增加，則可能值得推遲部署增加，直到現(xiàn)有問題得到解決。
2. 改變音量
如果大多數(shù)部署沒有什么影響，那么部署頻率就沒有多大意義。部署的實(shí)際價(jià)值可能會(huì)更好地反映在變化量上。此DevOps KPI確定代碼更改與保持不變的程度。部署頻率的改進(jìn)不應(yīng)對(duì)變更量產(chǎn)生重大影響。
3. 部署時(shí)間
一旦獲得批準(zhǔn)，部署部署需要多長時(shí)間？自然，如果部署速度快，部署的頻率會(huì)更高。部署時(shí)間的急劇增加值得進(jìn)一步調(diào)查，尤其是在部署量減少的情況下。雖然縮短部署時(shí)間是必不可少的，但不應(yīng)以準(zhǔn)確性為代價(jià)。錯(cuò)誤率增加可能表明部署發(fā)生得太快。
4. 部署失敗率
有時(shí)稱為平均故障時(shí)間，該指標(biāo)確定部署提示中斷或其他問題的頻率。這個(gè)數(shù)字應(yīng)該盡可能低。失敗的部署率通常與更改量一起引用。較低的更改量以及不斷增加的失敗部署率可能表明工作流程中的某個(gè)地方出現(xiàn)了功能障礙。
5. 改變失敗率
變更失敗率是指發(fā)布導(dǎo)致意外中斷或其他計(jì)劃外故障的程度。較低的更改失敗率表明部署快速且定期發(fā)生。相反，高更改失敗率表明應(yīng)用程序穩(wěn)定性差，這可能導(dǎo)致最終用戶產(chǎn)生負(fù)面結(jié)果。
6. 檢測(cè)時(shí)間
較低的更改失敗率并不總是表明您的應(yīng)用程序一切正常。雖然理想的解決方案是盡量減少甚至消除失敗的更改，但如果確實(shí)發(fā)生了故障，則必須快速捕獲它們。檢測(cè) KPI 的時(shí)間可以確定當(dāng)前的響應(yīng)工作是否足夠。檢測(cè)時(shí)間過長可能會(huì)引發(fā)能夠中斷整個(gè)工作流程的瓶頸。
7. 平均恢復(fù)時(shí)間
一旦檢測(cè)到失敗的部署或更改，實(shí)際上需要多長時(shí)間才能解決問題并重回正軌？平均恢復(fù)時(shí)間 (MTTR) 是一項(xiàng)重要指標(biāo)，表明您對(duì)已識(shí)別問題做出適當(dāng)響應(yīng)的能力。如果不進(jìn)行同樣快速的恢復(fù)工作，那么及時(shí)檢測(cè)就毫無意義。MTTR 是最著名和最常被引用的DevOps 關(guān)鍵性能指標(biāo)指標(biāo)之一。
8. 交貨時(shí)間
提前期衡量更改發(fā)生所需的時(shí)間。可以從構(gòu)思開始并繼續(xù)通過部署和生產(chǎn)來跟蹤該度量。交付周期為整個(gè)開發(fā)過程的效率提供了寶貴的洞察力。它還表明了當(dāng)前滿足用戶群不斷變化的需求的能力。較長的交付周期表明存在有害的瓶頸，而較短的交付周期表明反饋得到及時(shí)解決。
9. 缺陷逃逸率
每個(gè)軟件部署都有引發(fā)新缺陷的風(fēng)險(xiǎn)。在完成驗(yàn)收測(cè)試之前，這些可能不會(huì)被發(fā)現(xiàn)。更糟糕的是，最終用戶可以找到它們。錯(cuò)誤是開發(fā)過程的自然組成部分，應(yīng)相應(yīng)地進(jìn)行計(jì)劃。缺陷逃逸率反映了這一現(xiàn)實(shí)，承認(rèn)問題會(huì)出現(xiàn)并且應(yīng)該盡早發(fā)現(xiàn)。缺陷逃逸率跟蹤在生產(chǎn)前與生產(chǎn)過程中發(fā)現(xiàn)缺陷的頻率。這個(gè)數(shù)字可以提供一個(gè)有價(jià)值的衡量軟件版本總體質(zhì)量的標(biāo)準(zhǔn)。
10. 缺陷體積
該指標(biāo)與上面突出顯示的逃逸率有關(guān)，而是側(cè)重于實(shí)際的缺陷量。雖然有些缺陷是意料之中的，但突然增加應(yīng)該引起關(guān)注。特定應(yīng)用程序的大量缺陷可能表明開發(fā)或測(cè)試數(shù)據(jù)管理存在問題。
11. 可用性
可用性突出了給定應(yīng)用程序的停機(jī)時(shí)間。這可以衡量為完全（讀/寫）或部分（只讀）可用性。更少的停機(jī)時(shí)間幾乎總是更好。話雖如此，定期維護(hù)可能需要一些可用性失效。密切跟蹤計(jì)劃內(nèi)停機(jī)和計(jì)劃外停機(jī)，記住 100% 的可用性可能并不現(xiàn)實(shí)。
12. 服務(wù)水平協(xié)議合規(guī)性
為了提高透明度，大多數(shù)公司根據(jù)服務(wù)水平協(xié)議運(yùn)營。這些突出了供應(yīng)商和客戶之間的承諾。SLA 合規(guī) KPI 提供了必要的責(zé)任，以確保滿足 SLA 或其他期望。
13. 計(jì)劃外工作
有多少時(shí)間花在意料之外的努力上？計(jì)劃外工作率 (UWR)根據(jù)計(jì)劃工作所花費(fèi)的時(shí)間來跟蹤這一點(diǎn)。理想情況下，計(jì)劃外工作率 (UWR) 不會(huì)超過 25%。較高的 UWR 可能表明在工作流程早期可能未檢測(cè)到的意外錯(cuò)誤上浪費(fèi)了精力。UWR 有時(shí)與返工率 (RWR) 一起檢查，這與解決工單中提出的問題的努力有關(guān)。
14. 客票量
正如缺陷逃逸率 KPI 所表明的那樣，并非所有缺陷都是災(zāi)難性的。然而，理想情況下，他們會(huì)盡早被發(fā)現(xiàn)。這個(gè)概念最能反映在客戶票數(shù)上，它表明最終用戶生成了多少警報(bào)。穩(wěn)定的用戶量以及增加的票證量表明生產(chǎn)或測(cè)試中存在問題。
15. 周期時(shí)間
周期時(shí)間指標(biāo)提供了應(yīng)用程序部署的廣泛概述。此 KPI 跟蹤整個(gè)過程，從構(gòu)思開始到用戶反饋結(jié)束。較短的周期通常是可取的，但不會(huì)以發(fā)現(xiàn)缺陷或遵守 SLA 為代價(jià)。
開始衡量 Devops 的成功
在跟蹤關(guān)鍵 DevOps 指標(biāo)時(shí)，不要關(guān)注根據(jù)任何一個(gè)指標(biāo)感知到的成功或失敗，而是關(guān)注這些指標(biāo)在一起檢查時(shí)所講述的故事。當(dāng)與其他數(shù)據(jù)一起分析時(shí)，一個(gè)本身似乎有問題的結(jié)果可能看起來完全不同。仔細(xì)跟蹤上面強(qiáng)調(diào)的 KPI 不僅可以確保更高的開發(fā)和生產(chǎn)效率，更重要的是，可以確保最佳的最終用戶體驗(yàn)。擁抱 DevOps 指標(biāo)，您會(huì)看到應(yīng)用程序部署和反饋方面的巨大改進(jìn)。
