Part One 可用性概念一覽

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

概念一：MTBF (mean time between failure)

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

概念二：MTTR (mean time to repair)

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

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

MTBF / (MTBF + MTTR)

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

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

Part Two 高可用的保障

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

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

Level1: 配置修改出錯(cuò)

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

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

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

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

Level2: 代碼BUG

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

解決方案有兩個(gè)方面：

把控研發(fā)質(zhì)量 + 測(cè)試質(zhì)量：

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

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

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

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

解決方案包括：

依賴梳理+指標(biāo)約定+故障解決

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

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

讓業(yè)務(wù)按我們預(yù)先計(jì)劃的線路增長(zhǎng)是不切實(shí)際的。吭哧癟肚做個(gè)需求想讓它漲10%，結(jié)果沒(méi)漲反而掉了，當(dāng)你不注意的時(shí)候，突然來(lái)了一波上漲，都是很常見的事~

應(yīng)對(duì)方法有兩個(gè)方面：

流量規(guī)律預(yù)估 + 異常流量防護(hù)

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

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

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

應(yīng)對(duì)方案有四個(gè)方面：

容量規(guī)劃+限流降級(jí)+冗余+全鏈路壓測(cè)

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

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

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

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

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

Part Three 總結(jié)

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