《發現運維穩定性問題的明眸——可用性》要點：
本文介紹了發現運維穩定性問題的明眸——可用性，希望對您有用。如果有疑問，可以聯系我們。

上篇講到了破解運維穩定性問題的利器——復盤.復盤更多的是基于事后的總結與提升.那么我們如何發現、測量穩定性問題呢?那么我們就需要請出今天的主角了——可用性.

什么是可用性?

可用性作為評價業務穩定性的一個重要指標,它可以通過數據量化、建立基線的方式來發現業務中存在的周期性問題,并由此更有針對性的進行服務質量改進.

那么,什么是可用性呢?

可用性是指在一個指定的時間間隔內,對于一個功能個體來講,總的可用時間所占的比例.換句話說,是指在指定的時間段內,系統能夠正常運行的概率或占比.對于我們現在的互聯網業務來說大部分都屬于「實時」、「在線」,即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模塊的權重.以此類推,我們得出的可用性就可以盡可能的貼近業務及其目標了.

其它的方法

• 我們還可以通過利用像基調、博睿這種第三方的測試平臺的節點,對業務進行更加廣泛的撥測,以提高采集樣本的精度,減少其偏差.當然其結果也受限于第三方平臺及鏈路間的穩定性的影響
• 對于有客戶端的業務,我們可以通過在客戶端關鍵路徑上進行打點,然后將用戶的打點日志集中至服務端后再進行集中分析.這種方法雖然可以反應出最真實的用戶狀態,但也存在實施成本相對 較高、日志上傳延遲等問題.

寫在最后

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

作者介紹：

胡楊,目前就職于阿里巴巴移動事業群網絡運維部.高級運維專家.多年工作于大型互聯網領域.對大型互聯網運維體系中的容災體系設計、自動化、性能優化、troubleshoot等方面有著豐富的經驗及獨道的見解.

文章來自微信公眾號：高效開發運維

轉載請注明本頁網址：
http://www.fzlkiss.com/jiaocheng/4179.html