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