維運穩定性問題的關鍵–可用性

複盤更多的是基於事後的總結與提升。那我們要如何發現、測量穩定性問題呢？那我們就需要請出今天的主角了——可用性。

什麼是可用性？

可用性作為評估業務穩定性的重要指標，它可以透過資料量化、建立基準的方式來發現業務中存在的週期性問題，並由此更有針對性的進行服務品質改進。

那麼，什麼是可用性呢？可用性是指在一個指定的時間間隔內，對於一個功能個體來講，總的可用時間所佔的比例。換句話說，是指在指定的時間內，系統能夠正常運作的機率或占比。對於我們現在的網路業務來說大部分都屬於「即時」、「線上」，即Real-Time Online System，即時線上系統。對於我們的大部分業務說上面所指的指定時間段，應該是7*24小時。

可用性的結果經常使用小數點或百分比表示。我們通常使用一個被稱為幾個九的量測，對應小數點後連續9的個數。例如，「五個九」就是指該系統在指定時間內有0.99999（或99.999%）的可用性。

怎麼理解對應的量級呢？

例如，某系統在一個指定的時間內，如1天，即24小時。同時我們的監測粒度是分鐘，即1440分鐘。在我們監控的1440分鐘內，系統正常運作了1430分鐘。那麼在這個指定的時間內，系統的可用性為1430/1440≈0.99306（99.306%）。也就是我們常說的2個9。

那麼，99.306%這個值就代表該系統處於正常可用的Availability狀態佔比，那麼1-99.306%得到的0.694%這個值就代表該系統處理異常不可用的Unavailability狀態佔比。簡單的羅列為公式，即為：

業務在線總時長 ＝ 業務的正常可用時長 業務的異常不可用時長

更進一步，可用性就是指：

可用性＝業務的正常可用時長 / 業務在線總時長

#如何建立可用性

#理解了什麼是可用性，接下來我們來講如何建立可用性。建立可用性的方法有很多，常見的方法有幾種：

撥測法

撥測法即是依照各業務的應用、功能、模組進行週期性測試其運作狀態是否正常的一種方法。

舉例：我們業務有一個名為A的模組，那麼就週期性的（例如，每5分鐘一次）對這個模組使用模擬用戶行為的方法對其運行狀態進行抽樣檢查。如果該模組運作正常，就記為Availability，如果為非正常，就記為Unavailability。累加至一個時間週期內（例如，1天）Availability狀態的佔比即是這個模組的可用性。

那麼，如何判斷業務或模組是否正常呢？我們以一個web類型的業務為例，我們可以檢查該服務下的主頁、分類頁或內容頁的關鍵內容。一般來說，我們可以符合指定頁面Head、Body、bottom的指定欄位或關鍵字。如果可以配對到指定的一個或一組欄位或關鍵字，那麼即為正常，反之為異常。我們可以透過腳本、Nagios、Zabbix等工具來實現對業務的週期性撥測。

這種方法的優、缺點都很明顯。優點是這種方法實施難度較低且可以與透過模擬使用者行為的方式來測量，也業務實際情況可以比較吻合。但透過這種週期性抽樣的方法，有抽樣樣本不足或偏差的問題。例如每5分鐘撥測一次，如果故障出現和修復都在這5分鐘內完成，那麼撥測法就很難去捕捉到這種錯誤。

日誌分析法

日誌分析法即是透過各業務的應用、功能、模組日誌進行分析得到可用性的一種方法。

舉例：我們業務有一個名為A的模組，那麼就週期性的（例如，每小時一次）對這個模組上1個小時日誌進行分析。從日誌層面區分出正常請求在佔比，也就是這個模組在過去1小時的可用性。還是以web類型的業務為例，我們可以從日誌中將2XX、5XX狀態分別進行統計、分析，可以理解2XX即是Availability，5XX即是Unavailability。 （3XX與4XX可以依照實際的業務情況再考慮是否參與分析）

這種方法上很明顯的解決了撥測法抽樣樣本不足或偏差的問題，但也存在與實際業務影響指數可能會存在較大差別的情況。例如，我們在過去1小時的錯誤都發生在1分鐘內，剩餘的59分鐘業務都是正常的。很顯然這樣得出來的可用性和實際業務情況是有一定偏差的。那麼要怎麼解決這種偏差呢？日誌分析閾值法就應運而生了。

日誌分析閾值法

#日誌分析閾值法是在日誌分析法的基礎上添加了狀態閾值判斷的一種可用性計劃方法。

舉例：我們業務有一個名為A的模組，我們透過日誌分析法得到，這個模組每分鐘正常情況下的請求數約為10W次，那麼我們可以設定一個閾值為10次。這10次的意思就是指，我們容許在1分鐘內發生萬分之一以內的錯誤。如果1分鐘內發生的錯誤在10次以內，我們就認為在過去1分鐘的狀態為正常，就標記為Availability。如果1分鐘內發生的錯誤超過10次，那麼我們就認為在過去1分鐘的狀態為異常，就標記為Unavailability。最後再統計Availability狀態的佔比即是這個模組的可用性。當然這個閾值需要根據業務的實際情況進行調整。

這種方法上就很好的解決了撥測法抽樣樣本偏差與日誌分析法差生實際業務影響脫節的不足，達到很好的一種平衡。

還有一個問題，如果一個業務由A、B、C三個模組構成，那麼怎麼透過模組的可用性，怎麼算出業務的可用性呢？簡單的方法就是透過最三個模組可用性的平均值即可。但這存在與業務目標相反的問題。那麼我們可以透過與業務目標對齊，進行加權平均的方法。例如A模組對業務來說更加關鍵，那麼我們在計算可用性時就給出A模組更多的權重；C模組是業務的旁路系統，那麼就可以在計算時降低對C模組的權重。以此類推，我們得出的可用性就可以盡可能的貼近業務及其目標了。

其它的方法

#我們還可以透過利用像是基調、博睿這種第三方的測試平台的節點，對業務進行更廣泛的撥測，以提高採集樣本的精度，減少其偏差。當然其結果也受限於第三方平台及連結間的穩定性的影響
對於有客戶端的業務，我們可以透過在客戶端關鍵路徑上進行打點，然後將使用者的打點日誌集中到服務端後再進行集中分析。這種方法雖然可以反應出最真實的使用者狀態，但也存在實施成本相對 較高、日誌上傳延遲等問題。

寫在最後

#計算可用性的方法有遠不至上面寫的幾種，並且有哪一種方法可以解決所有的問題和痛點。從成本、效益、時間等角度選擇一種或多種最適合自己業務或團隊的方法，用於持續改善業務的服務品質才是王道。

以上是維運穩定性問題的關鍵–可用性的詳細內容。更多資訊請關注PHP中文網其他相關文章！