導(dǎo)讀：天天評估系統(tǒng)可用性，每次說5個9 、6個9，那么，可用性到底該怎么評估，幾個9又是怎么算出來的呢？而我們又可以做些什么，來保障系統(tǒng)的高可用呢?

Part One 可用性概念一覽

永不停機(jī)總歸是不現(xiàn)實的。那么，在可操作性的范圍內(nèi)，怎樣把影響降到最小，而影響又該怎么衡量呢？

概念一：MTBF (mean time between failure)

MTBF是指兩次相鄰的系統(tǒng)失效(服務(wù)故障)之間的工作時間長度。也可以叫它無故障時間?或?失效間隔。這個值越大，說明系統(tǒng)的故障率越低，系統(tǒng)越可靠。因此，我們通常希望這個時間間隔越大越好。

概念二：MTTR (mean time to repair)

MTTR是指從出現(xiàn)故障到修復(fù)中間的時間長度。也叫做修復(fù)時間。這個值越低，說明故障越容易恢復(fù)，系統(tǒng)可維護(hù)性越好。因此，我們通常希望這個時間間隔越小越好。

因此，系統(tǒng)可用性可以量化為：

MTBF?/ (MTBF?+?MTTR)

示例：系統(tǒng)的可用性要求?99.999%?，那么，按一年365天來算:

全年允許的宕機(jī)時間只有5分鐘多一點。

Part Two 高可用的保障

全年宕機(jī)5分鐘？從上一部分可以知道，我們的目的，是要盡可能的增大系統(tǒng)的無故障運行時間，同時，在發(fā)生故障時，盡可能迅速的完成恢復(fù)。

故障的發(fā)生多種多樣，經(jīng)過了這么多年的研發(fā)前輩的踩坑，我們可以將其分類匯總，并給出分析和對應(yīng)的方案。

Level1: 配置修改出錯

最不應(yīng)該犯的錯，但是感覺很多人都沒少犯。

原因也很簡單，要不就是格式錯了，要不就是配置的數(shù)據(jù)不對，而且錯誤的配置還被直接發(fā)到了線上，直接導(dǎo)致業(yè)務(wù)異常，甚至宕機(jī)。

解決方案主要是兩部分：變更管控?+?配置灰度

?用工單+審批的方式，讓配置變更流程化、正規(guī)化，提升配置變更的被重視程度。?利用配置灰度發(fā)布平臺功能，通過測試和灰度多環(huán)境的上線前驗證加上版本可回滾的能力，減少由于配置問題造成的可用性降級。

Level2: 代碼BUG

人為BUG往往是系統(tǒng)異常的罪魁禍?zhǔn)?。coder? 不，請叫我buger ~ 雖然最是常見，但這一部分又是相對最容易應(yīng)對的。

解決方案有兩個方面：
把控研發(fā)質(zhì)量?+?測試質(zhì)量：

?需要通過系統(tǒng)分析文檔的撰寫和評審提前分析業(yè)務(wù)問題和系統(tǒng)邊界。?通過容錯設(shè)計、單側(cè)、CR來完善代碼的健壯性。?通過測試分析來明確測試重點和影響點。?通過線上請求錄制回放等仿真測試來保證原有的邏輯不受影響。

Level3: 依賴服務(wù)故障

業(yè)務(wù)高速發(fā)展，系統(tǒng)被水平垂直拆分，越來越復(fù)雜，幾乎沒有哪個系統(tǒng)可以獨立存在，總歸會有依賴。

然而，依賴系統(tǒng)在整個業(yè)務(wù)流程中占比很重，但我們自己又無法把控，因此，服務(wù)的依賴治理，是可用性保障中的非常重要的一環(huán)。

解決方案包括：
依賴梳理+指標(biāo)約定+故障解決

?首先，要根據(jù)業(yè)務(wù)本身的情況，梳理出強(qiáng)弱依賴，不同級別的依賴區(qū)分應(yīng)對。比如，弱依賴就可以剝離主鏈路，采用異步或離線等方式進(jìn)行；而強(qiáng)依賴如RPC中間件，就只能增加監(jiān)控，提高問題發(fā)現(xiàn)速率。?其次，定制指標(biāo)，做好指標(biāo)監(jiān)控和百分位預(yù)警。比如對依賴系統(tǒng)的調(diào)用量預(yù)估以及sla約定，達(dá)到百分位閾值時，及時報警?再次，制定故障預(yù)案，如主鏈路的限流、弱依賴的熔斷等。預(yù)案需要多次演練才能上線。

Level4: 突發(fā)流量和流量洪峰對應(yīng)不足

讓業(yè)務(wù)按我們預(yù)先計劃的線路增長是不切實際的?？赃臧T肚做個需求想讓它漲10%，結(jié)果沒漲反而掉了，當(dāng)你不注意的時候，突然來了一波上漲，都是很常見的事~

應(yīng)對方法有兩個方面：
流量規(guī)律預(yù)估 +?異常流量防護(hù)

?規(guī)律方面，要分析業(yè)務(wù)規(guī)律，合理安排策略，如請求排隊，提前擴(kuò)容等。如打車場景，流量高峰(上下班)和流量突發(fā)(雨雪大風(fēng)天)的情況都非常典型。為啥經(jīng)常遇到司機(jī)吐槽接不到單，為啥一到雨雪天就要從派單模式切換成搶單模式，真的是因為選擇性突然變多了么~?異常流量方面，要讓上游協(xié)助減少無效重試，用緩存等策略防止底層服務(wù)雪崩。如電商商品詳情系統(tǒng)，一到晚上流量就徒增，爬蟲無疑；再如系統(tǒng)超時導(dǎo)致用戶不斷刷新的流量放大

Level5: 容量預(yù)估不足

上述的流量預(yù)估其實屬于容量預(yù)估的一個方面，除此之外，還有緩存容量、底層數(shù)據(jù)存儲容量、服務(wù)器容量、帶寬容量等等。

應(yīng)對方案有四個方面：
容量規(guī)劃+限流降級+冗余+全鏈路壓測

?前期，需要做好容量規(guī)劃和容量預(yù)警方案，爭取把可能的突發(fā)流量都考慮在內(nèi)，核心模塊盡量實現(xiàn)冗余部署、容災(zāi)部署；同時，利用多維度的報警，盡量早和及時的發(fā)現(xiàn)容量問題。?故障發(fā)生時，依據(jù)前面提到的依賴服務(wù)治理方案，根據(jù)重要程度的不同，進(jìn)行限流、降級或熔斷。減少對容量的持續(xù)沖擊。?故障發(fā)生后，利用冗余部署，快速切換路由，分擔(dān)當(dāng)前單元的容量壓力。?單服務(wù)壓測只能摸到當(dāng)前服務(wù)的高度，但是這個高度是否滿足全鏈路的要求，就需要全鏈路去呀，這個時候，全局統(tǒng)一的路由、影子庫等的基礎(chǔ)建設(shè)就至關(guān)重要了。

Level6: 硬件甚至整個機(jī)房故障

相比于動則百萬造價的大型服務(wù)器，普通計算機(jī)以及docker的穩(wěn)定性要大打折扣。因此，宕機(jī)是難免的事，除了服務(wù)器，還有交換機(jī)甚至是光纖抖動都有可能發(fā)生。

而應(yīng)對方案有兩個方面：分散+冗余:

?正所謂不要把雞蛋都裝到一個籃子里，而要多分幾個籃子裝。這樣，一個籃子打了，不至于影響全部雞蛋。螞蟻的單元化部署就是這個思路，不同的用戶按ID分到不同的處理單元，因此，就算這個單元全宕了，最差的情況也只會影響到這個單元的用戶群。?冗余，則是有備無患的思想。主從互備、同城機(jī)房互備、兩地三中心、三地五中心則是這個思路的具體落地。

Part Three 總結(jié)

越是重要的系統(tǒng)，對高可用的要求越高。而高可用的治理，會很考驗整個技術(shù)團(tuán)隊的技術(shù)沉淀。如果后面大家遇到對系統(tǒng)可用性非常敏感的情況，希望本文可以對大家的思路和著手點有所幫忙。

高可用方法論！