FIND研究員:李啟榮
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/
沒有留言:
張貼留言