DevOps的可用性（Availability）長期以來是前端維運和後端開發所關注的一大課題，除了需要保障產品上線後服務不中斷，也要在產品面臨緊急事故時及時修復和補救，縮短平均回復時間（MTTR）；而SaaS業者Stackify之創辦人Matt Watson針對DevOps的可用性議題，提出了15項指標，作為產品上線前可靠性檢驗、上線後可用性檢視的參考指引。 

【15項DevOps可用性指標概說】

從事開發工作超過15年的Stackify創辦人Matt Watson，藉由自己從事並帶領公司內DevOps團隊之經驗，觀察DevOps專案和產品面臨的可用性議題，並歸納為15點可用性指標：

部署頻率：藉由小而密集的部署頻率，可減少大型專案冗長的部署時間。
變更量：藉由不斷提升產品部署的品質，產品需要改版變更的幅度就會較小。
部署時間：在一定的時間之內，若一項功能的部署時間較短，代表開發較為容易。
前置時間：又稱為交付時間，亦即專案啟動到上線營運的時間長度。
客戶反饋：基於客戶反映的問題，開發團隊需要依照客戶意見進行改版修正。
自動化測試合格率：常見於單元測試、功能測試等自動化情境，合格率愈高則更動的需求就愈少。
缺陷漏失率：在產品上線之前總有看不到的漏網之魚，這些被忽視的缺陷也會影響產品上線的品質。
可用性：需要時常監控、追蹤的DevOps上線品質議題之一，得力求減少未預警的停機時間（Downtime）。
服務水準協議：SLA是一種如何達成客戶期待的目標值，並且力求在整個產品上線運作過程，確保與SLA需求一致。
部署失敗率：部署過程中總會有非預料的失敗狀況，可用「造成失敗的平均時間（MTTF）」來衡量。
錯誤率：例如部署後發生的Bug、資料庫串接問題、反應時間過長等問題，在一定時間內發生的多寡。
應用程式資源占用與流量：主要針對大量連線的議題，或者異常登入、異常流量等狀況，進行監控並保持連線順暢。
應用程式效能：可用視覺化的方式進行應用程式上線運作狀態的監控，例如SQL資料庫查詢量、Web服務請求次數等。
平均檢測時間：若偵測到異常事故時，需要花多少時間辨識、判斷異常狀況，以進行修復、改版的處置對策。
平均還原時間：若發生異常事故時，需評估開發團隊多久才能修復、改版並重新正常上線運作。 
【小結】

上述15項可用性指標都是相互影響的，除了需要在改版上線前進行安全、正確的檢核以外，還要持續進行異常狀態的監測，並針對主動偵測的異常狀態、或使用者的錯誤回報，加以補救，如此可保障現有運作中系統（Live）的可用性和完整性，也能在開發新產品、新功能時，改良主動偵測和使用者反映的缺陷，讓系統更臻完善、符合SLA的運作水準需求。 

參考來源：
Watson, M. (2017, December 11). 15 Metrics for DevOps Success. Retrieved from Stackify: https://stackify.com/15-metrics-for-devops-success/