初識大促保障，常會有這樣的疑問：保障保的到底是什么，確保沒有問題或者不出問題嗎？這似乎是個(gè)偽命題。而作為保障這件事本身，不僅要堅(jiān)信所為有意義，更要有所為，這就需要把不可能的偽命題轉(zhuǎn)化為可以不斷深入的可行任務(wù)。談及保障的根本，其實(shí)我們要面對的是對抗不確定性，這個(gè)不確定性來自四面八方。比如大地震，會導(dǎo)致整個(gè)機(jī)房中斷，如何應(yīng)對？比如負(fù)責(zé)核心系統(tǒng)的工程師離職了，如何應(yīng)對？再比如下游接口掛了，如何應(yīng)對？系統(tǒng)磁盤壞了，數(shù)據(jù)面臨丟失風(fēng)險(xiǎn)，如何應(yīng)對？我想關(guān)于上述問題的應(yīng)對方式，大家在工作中或多或少都有所了解，而這個(gè)不確定性的處理過程，就是容災(zāi)，其不同的‘災(zāi)難’，對應(yīng)不同的容災(zāi)級別。

超過十多年行業(yè)經(jīng)驗(yàn)，技術(shù)領(lǐng)先，服務(wù)至上的經(jīng)營模式，全靠網(wǎng)絡(luò)和口碑獲得客戶，為自己降低成本，也就是為客戶降低成本。到目前業(yè)務(wù)范圍包括了：網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)，成都網(wǎng)站推廣，成都網(wǎng)站優(yōu)化，整體網(wǎng)絡(luò)托管，重慶小程序開發(fā)，微信開發(fā)，重慶App定制開發(fā)，同時(shí)也可以讓客戶的網(wǎng)站和網(wǎng)絡(luò)營銷和我們一樣獲得訂單和生意！

為了對抗這些不同級別的不確定性，就要付出不同級別的成本，因此可用性也應(yīng)是有標(biāo)準(zhǔn)的。這標(biāo)準(zhǔn)就是大家常說的N個(gè)9。隨著N的增加，成本也相應(yīng)增加，那如何在達(dá)到業(yè)務(wù)需要的可用性的基礎(chǔ)上，盡量節(jié)省成本？這也是一個(gè)值得思考的話題。除此之外，100%減去這N個(gè)9就說所謂的平均故障時(shí)間（MTBF），很多人只關(guān)心那些9，而忽略了故障處理時(shí)間，這是不該的：你的故障處理速度越快，系統(tǒng)的可用性才有可能越高。

上面扯了一些可用性概念上的東西，下面嘗試使用‘事情’來分個(gè)類。這里的‘事’就是故障，分為：事前（故障發(fā)生以前）、事發(fā)（故障發(fā)生到系統(tǒng)或人感知到故障）、事中（故障發(fā)生到故障處理這段時(shí)間）、事后（故障結(jié)束之后）。

按照上述分類，不同的階段應(yīng)有著不同的技巧：

1. 事前：副本、隔離、配額、預(yù)案、探知

2. 事發(fā)：監(jiān)控、報(bào)警

3. 事中：降級、回滾、應(yīng)急預(yù)案

4. 事后：復(fù)盤、思考、技改

部分技術(shù)概念解釋如下：

副本：無狀態(tài)服務(wù)集群便是副本的一個(gè)應(yīng)用，因?yàn)闆]有狀態(tài)，便可水平伸縮，而這些無狀態(tài)服務(wù)器之間需要一層代理來統(tǒng)一調(diào)度管理，這便有了反向代理。當(dāng)代理通過心跳檢測機(jī)制檢測到有一臺機(jī)器出現(xiàn)問題時(shí)，就將其下線，其他‘副本’機(jī)器繼續(xù)提供服務(wù)；存儲領(lǐng)域也是經(jīng)常使用副本技術(shù)的，比如MySQL主備切換，rabbitMQ的鏡像隊(duì)列，磁盤的RAID技術(shù)，各種NOSQL中的分區(qū)副本，等等數(shù)不勝數(shù)，幾乎所有保證高可用的系統(tǒng)都有冗余副本存在。

隔離：線程隔離、進(jìn)程隔離、集群隔離、機(jī)房隔離、讀寫隔離、動(dòng)靜隔離、爬蟲隔離、熱點(diǎn)隔離、硬件資源隔離。這些隔離其實(shí)就是一種，即資源隔離，無論線程、進(jìn)程、硬件、機(jī)房、集群都是一種資源；動(dòng)態(tài)資源和靜態(tài)資源也不過是資源的一種分類；熱點(diǎn)隔離也即是熱點(diǎn)資源和非熱點(diǎn)資源的隔離；讀寫隔離不過僅僅是資源的使用方式而已，相同的兩份資源，一份用來寫，一份用來讀。因此，隔離的本質(zhì)，其實(shí)就是對資源的獨(dú)立保護(hù)。因?yàn)槊總€(gè)資源都得到了獨(dú)立的保護(hù)，其中一個(gè)資源出了問題，不會影響到其他資源，這就提高了整體服務(wù)的可用性。

配額：配額技術(shù)通過限制資源供給來保護(hù)系統(tǒng)，從而提高整體可用性。限流是配額技術(shù)的一種，它通過調(diào)節(jié)入口流量水位上線，來避免供給不足所導(dǎo)致的服務(wù)宕機(jī)。限流分為集群限流和單機(jī)限流，集群限流需要分布式基礎(chǔ)設(shè)施配合，單機(jī)限流則不需要。除此之外，限流這里我們還需要考慮幾點(diǎn)：

1. 如何設(shè)置合理的限流值？限流值的設(shè)定是需要經(jīng)過全鏈路壓測、妥善評估CPU容量、磁盤、內(nèi)存、IO等指標(biāo)與流量之間的變化關(guān)系（不一定線性關(guān)系）、結(jié)合業(yè)務(wù)預(yù)估和運(yùn)維經(jīng)驗(yàn)后，才能確定。

2. 對于被限流的流量如何處理？有幾種處理方式，其一直接丟棄，用溫和的文案提醒用戶；其二，靜默，俗稱的無損降級，用緩存內(nèi)容刷新頁面；其三，蓄洪，異步回血，這一般用于事務(wù)型場景。

3.  會不會導(dǎo)致誤殺？單機(jī)限流會導(dǎo)致誤殺，尤其當(dāng)負(fù)載不均衡的情況下，很容易出現(xiàn)誤殺；單機(jī)限流值設(shè)定過小也容易出現(xiàn)誤殺的情況。 

預(yù)案：一般分為提前預(yù)案（事前）和應(yīng)急預(yù)案（事中）。提前預(yù)案提前執(zhí)行，比如將系統(tǒng)臨時(shí)從高峰模式切換成節(jié)能模式；應(yīng)急預(yù)案關(guān)鍵時(shí)刻才執(zhí)行，主要用于止血，比如一鍵容災(zāi)切換等。預(yù)案技術(shù)一般要配合開關(guān)使用，推預(yù)案一般也就是推開關(guān)了。除此之外，預(yù)案也可和限流、回滾、降級等相結(jié)合，預(yù)案的制定也可通過對歷史故障的分析尋找思路。

探知：探知當(dāng)前系統(tǒng)的可用性能力，其實(shí)無法提高系統(tǒng)可用性，做不好甚至還會降低系統(tǒng)可用性。壓測和演練是最常見的探知技術(shù) 。壓測分為全鏈路壓測和單鏈路壓測，全鏈路壓測用于像雙十一大促活動(dòng)等，需要各上下游系統(tǒng)整體配合，單鏈路壓測一般驗(yàn)證功能或做簡單的場景壓測提取性能指標(biāo)。全鏈路壓測的一般過程是：壓測目標(biāo)設(shè)定和評估，壓測構(gòu)造，壓測腳本編寫部署，壓測數(shù)據(jù)準(zhǔn)備，小流量鏈路驗(yàn)證，通知上下游系統(tǒng)owner，壓測預(yù)熱，壓測，壓測結(jié)果評估報(bào)告，性能優(yōu)化。以上過程反復(fù)迭代，直到達(dá)到壓測目標(biāo)為止；演練一般按規(guī)模劃分：比如城市級別的容災(zāi)演練，機(jī)房級別的容災(zāi)演練，集群規(guī)模的容災(zāi)演練（DB集群，緩存集群，應(yīng)用集群等），單機(jī)級別的故障注入，預(yù)案演練等。

監(jiān)控和報(bào)警：一般出現(xiàn)故障的時(shí)候，老板大多會有三問：為什么才發(fā)現(xiàn)？為什么才解決？影響有多大？即使故障影響面較大，如果能迅速止血，在做復(fù)盤的時(shí)候多少能挽回一些面子，相反如果處理不及時(shí)，即使小小的故障，都可能讓你丟了飯碗。越早識別故障，就能越早解決問題，而這眼睛便是監(jiān)控和報(bào)警了。

降級：降級的內(nèi)涵豐富，我們只從鏈路角度去思考。降級的本質(zhì)是棄車保帥，通過臨時(shí)舍棄部分功能，保證系統(tǒng)整體可用性。降級雖然從整體上看系統(tǒng)仍然可用，但由于取舍的關(guān)系，那么可知所有的降級一定是有損的。不可能有真正的無損降級，而常說的無損降級指的是用戶體驗(yàn)無損。降級一定發(fā)生在層與層之間（上下游），要么a層臨時(shí)性不調(diào)用b層，這叫做熔斷，要么a層臨時(shí)調(diào)用c層（c層合理性一定

• 讀寫降級，實(shí)際上是存儲層和應(yīng)用層之間的降級，采用備用鏈路切換方式，損失了一致性；

• 功能降級，將部分功能關(guān)閉，實(shí)際上是應(yīng)用層和功能模塊層之間的降級，采用熔斷方式，損失了部分功能。

• 爬蟲降級，實(shí)際上是搜索引擎爬蟲和應(yīng)用系統(tǒng)之間的降級，采用備用鏈路切換方式，將爬蟲引導(dǎo)到靜態(tài)頁面，損失是引擎索引的建立和頁面收錄。

回滾：當(dāng)執(zhí)行某種變更出現(xiàn)故障時(shí)，最為穩(wěn)妥和有效的辦法就是回滾。雖然回滾行之有效，但并不簡單，因?yàn)榛貪L有一個(gè)大前提：變更必須具有可回滾性。而讓某一種變更具有可回滾的特性，是要耗費(fèi)很大力氣的。索性的是，大部分基礎(chǔ)服務(wù)已經(jīng)幫我們封裝好了這一特性，比如DB的事務(wù)回滾（DB事務(wù)機(jī)制），代碼庫回滾（GIT的文件版本控制），發(fā)布回滾（發(fā)布系統(tǒng)支持）等等。我們在日常變更操作的時(shí)候，必須要確定你的操作是否可回滾，并盡力保證所有變更均可回滾。如果不能回滾，是否可以進(jìn)行熱更新（比如發(fā)布應(yīng)用到app store）或最終一致性補(bǔ)償?shù)阮~外手段保證系統(tǒng)高可用。