在 Google 我參與了兩個(gè)比較大的 Project。

第一個(gè)是 YouTube，其中包括 video transcoding，streaming 等。Google 的量很大，每個(gè)月會有 1PB 級別的存儲量。存儲、轉(zhuǎn)碼后，我們還做 Global CDN。到 2012 年的時(shí)候，峰值流量達(dá)到 10 TBps，全球 10 萬個(gè)節(jié)點(diǎn)，幾乎每臺機(jī)器都是 16/24 核跑滿， 10G uplink 也是跑滿的狀態(tài)。

然后我加入了 Google Cloud Platform Team， 也就是 Borg 團(tuán)隊(duì)。這個(gè)團(tuán)隊(duì)的主要工作是就是管理 Google 全球所有的服務(wù)器，全球大概有 100 萬臺左右。另外就是維護(hù) Borg 系統(tǒng)，同時(shí)我也是 Omega 系統(tǒng)運(yùn)維的主要負(fù)責(zé)人，很可惜這個(gè)項(xiàng)目最后由于各種各樣的原因在內(nèi)部取消了。

下面我想跟大家分享的是關(guān)于可用性、可靠性上面的一些理念和思考。

一、決定可用性的兩大因素

談可用性不需要繞來繞去，大家只談 SLA 即可。大家可以看下面這個(gè)圖:

要談可用性，首先必須承認(rèn)所有東西都有不可用的時(shí)候，只是不可用程度而已。一般來說，我們的觀念里一個(gè)服務(wù)至少要做到 99.9% 才稱為基本上可用，是合格性產(chǎn)品。否則基本很難被別人使用。

從 3 個(gè) 9 邁向 4 個(gè) 9，從 8 小時(shí)一下縮短到 52.6 分鐘的不可用時(shí)間，是一個(gè)很大的進(jìn)步。Google 內(nèi)部只有 4 個(gè) 9 以上的服務(wù)才會配備 SRE，SRE 是必須在接到報(bào)警 5 分鐘之內(nèi)上線處理問題的，否則報(bào)警系統(tǒng)自動(dòng)升級到下一個(gè) SRE。如果還沒有，直接給老板發(fā)報(bào)警。

大家之前可能聽說谷歌搜索服務(wù)可用度大概是全球 5 個(gè) 9，6 個(gè) 9 之間。其實(shí)這是一個(gè)多層，多級，全球化的概念，具體到每個(gè)節(jié)點(diǎn)其實(shí)沒那么高。比如說當(dāng)年北京王府井樓上的搜索集群節(jié)點(diǎn)就是按 3 個(gè) 9 設(shè)計(jì)的。

有關(guān) SLA 還有一個(gè)秘密，就是一般大家都在談年 SLA，但是年 SLA 除了客戶賠款以外，一般沒有任何實(shí)際工程指導(dǎo)意義。 Google 內(nèi)部更看重的是季度 SLA，甚至月 SLA，甚至周 SLA。這所帶來的挑戰(zhàn)就更大了。

為什么說看這個(gè)圖有用，因?yàn)?99%、99.9% 是基本可以靠運(yùn)氣搞定的哦。到 3 個(gè) 9 可以靠堆人，也就是 3 班倒之類的強(qiáng)制值班基本搞定。但是從 3 個(gè) 9 往上，就基本超出了人力的范疇，考驗(yàn)的是業(yè)務(wù)的自愈能力，架構(gòu)的容災(zāi)、容錯(cuò)設(shè)計(jì)，災(zāi)備系統(tǒng)的完善等等。

說了這么多，作為一個(gè)架構(gòu)者，我們?nèi)绾蝸硐到y(tǒng)的分解“提升 SLA”這一個(gè)難題呢。

這里我引入兩個(gè)工業(yè)級別的概念 MTBF 和 MTTR。

MTBF: Mean time between Failures。 用通俗的話講，就是一個(gè)東西有多不可靠，多長時(shí)間壞一次。
MTTR: Mean time to recover。意思就是一旦壞了，恢復(fù)服務(wù)的時(shí)間需要多長。

有了這兩個(gè)概念， 我們就可以提出：

一個(gè)服務(wù)的可用度，取決于 MTBF 和 MTTR 這兩個(gè)因子。從這個(gè)公式出發(fā)，結(jié)合實(shí)際情況，就很好理清高可用架構(gòu)的基本路數(shù)了。那就是： 要么提高 MTBF, 要么降低 MTTR。除此之外別無他法。

要注意的是，考慮 MTBF 和 MTTR 的時(shí)候都不能脫離現(xiàn)實(shí)。

理論上來說，作為一個(gè)正常人類，收到突發(fā)報(bào)警、能正確的分析出問題所在、找到正確的解決方案、并且 【正確實(shí)施】的時(shí)間極限大概是 【兩分鐘】。這個(gè)標(biāo)準(zhǔn)我個(gè)人覺得是高到天上去了。作為一個(gè)苦練多年的 Oncall 工程師，我 2 分鐘能看清報(bào)警，上了 VPN，找到 dashboard，就不錯(cuò)了。就算是已知問題，有應(yīng)對方案，能敲對命令，完全成功，也至少需要 15 – 20 分鐘。所以如果按照這個(gè)標(biāo)準(zhǔn)的話，管理的服務(wù)如果想達(dá)到 4 個(gè) 9，那么一年只能壞 1 次，2 次就超標(biāo)了。實(shí)現(xiàn)高可用基本靠運(yùn)氣～

回過來接著說說 MTBF 吧。請各位想一下，影響服務(wù)MTBF的三大因素！

• 發(fā)布

• 發(fā)布

• 還是發(fā)布！

這個(gè)術(shù)語上叫 Age Mortality Risk。

一般一個(gè)服務(wù)只要你不去碰他一年都不會壞一次。更新越頻繁，壞的可能性就越大。凡是 Software 都有 BUG，修 BUG 的更新也會引入新的 BUG。發(fā)布新版本，新功能是 MTBF 最大的敵人。

二、高可用性方案

說了 MTBF 和 MTTR 這兩個(gè)定義，那么具體究竟應(yīng)該如何落地實(shí)踐來提高可用性呢？

首先說幾個(gè)大家可能都聽膩了的方案

一、提高冗余度，多實(shí)例運(yùn)行，用資源換可用性。

雖然道理很簡單，實(shí)現(xiàn)起來可不簡單，有很多很多細(xì)節(jié)上的東西需要考慮。

第一個(gè)細(xì)節(jié)：N + 2 應(yīng)該是標(biāo)配。

N + 2 就是說平時(shí)如果一個(gè)服務(wù)需要 1 個(gè)實(shí)例正常提供服務(wù)，那么我們就在生產(chǎn)環(huán)境上應(yīng)該部署 1 + 2 = 3 個(gè)節(jié)點(diǎn)。大家可能覺得 N + 1 很合理，也就是有個(gè)熱備份系統(tǒng)，比較能夠接受。但是你要想到：服務(wù) N + 1 部署只能提供熱備容災(zāi)，發(fā)布的時(shí)候就失去保護(hù)了。

因?yàn)閯偛耪f了， 發(fā)布不成功的幾率很高！

從另一個(gè)角度來講，服務(wù) N + 2 說的是在丟失兩個(gè)最大的實(shí)例的同時(shí)，依然可以維持業(yè)務(wù)的正常運(yùn)轉(zhuǎn)。

這其實(shí)就是最近常說的兩地三中心的概念有點(diǎn)像。

第二個(gè)細(xì)節(jié)： 實(shí)例之間必須對等、獨(dú)立。

千萬不要搞一大一小，或者相互依賴。否則你的 N + 2 就不是真的 N + 2。如果兩地三中心的一個(gè)中心是需要 24 小時(shí)才能遷移過去的，那他就不是一個(gè)高可用性部署，還是叫異地災(zāi)備系統(tǒng)吧。

第三個(gè)細(xì)節(jié)：流量控制能力非常重要。

想做到高可用，必須擁有一套非?？煽康牧髁靠刂葡到y(tǒng)。這套系統(tǒng)按常見的維度，比如說源 IP，目標(biāo) IP 來調(diào)度是不夠的，最好能按業(yè)務(wù)維度來調(diào)度流量。比如說按 API， 甚至按用戶類型，用戶來源等等來調(diào)度。

為什么？因?yàn)橐粋€(gè)高可用系統(tǒng)必須要支持一下幾種場景：

1. Isolation。A 用戶發(fā)來的請求可能和 B 用戶發(fā)來的請求同時(shí)處理的時(shí)候有沖突，需要隔離。

2. Quarantine。用戶 A 發(fā)來的請求可能資源消耗超標(biāo)，必須能將這類請求釘死在有限的幾個(gè)節(jié)點(diǎn)上，從而顧全大局。

3. Query-of-death。大家都遇到過吧。上線之后一個(gè)用戶發(fā)來個(gè)一個(gè)異常請求直接搞掛服務(wù)。連續(xù)多發(fā)幾個(gè)，整個(gè)集群都掛沒了，高可用還怎么做到？那么，對這種類型的防范就是要在死掉幾臺服務(wù)器之后可以自動(dòng)屏蔽類似的請求。需要結(jié)合業(yè)務(wù)去具體分析。

但是想要達(dá)到高可用，這些都是必備的，也是一定會遇到的場景。還是那句話，靠人是沒戲的。

二、變更管理（Change Management）

還記得影響 MTBF 最大的因子嗎？發(fā)布質(zhì)量不提高，一切都是空談。

第一點(diǎn)： 線下測試（Offline Test）

線下測試永遠(yuǎn)比線上調(diào)試容易一百倍，也安全一百倍。

這個(gè)道理很簡單，就看執(zhí)行。如果各位的團(tuán)隊(duì)還沒有完整的線下測試環(huán)境，那么我的意見是不要再接新業(yè)務(wù)了，花點(diǎn)時(shí)間先把這個(gè)搞定。這其中包括代碼測試、數(shù)據(jù)兼容性測試、壓力測試等等。

臺上一分鐘，臺下十年功。

可用性的階段性提高，不是靠運(yùn)維團(tuán)隊(duì)，而是靠產(chǎn)品團(tuán)隊(duì)。能在線下完成的測試，絕不拍腦門到線上去實(shí)驗(yàn)。

第二點(diǎn)：灰度發(fā)布

這個(gè)道理說起來好像也很普通，但是具體實(shí)施起來是很有講究的。

首先灰度發(fā)布是速度與安全性作為妥協(xié)。他是發(fā)布眾多保險(xiǎn)的最后一道，而不是唯一的一道。如果只是為了灰度而灰度，故意人為的拖慢進(jìn)度，反而造成線上多版本長期間共存，有可能會引入新的問題。

做灰度發(fā)布，如果是勻速的，說明沒有理解灰度發(fā)布的意義。一般來說階段選擇上從 1% -> 10% -> 100% 的指數(shù)型增長。這個(gè)階段，是根據(jù)具體業(yè)務(wù)不同按維度去細(xì)分的。

這里面的重點(diǎn)在于1%并不全是隨機(jī)選擇的，而是根據(jù)業(yè)務(wù)特點(diǎn)、數(shù)據(jù)特點(diǎn)選擇的一批有極強(qiáng)的代表性的實(shí)例，去做灰度發(fā)布的小白鼠。甚至于每次發(fā)布的 第一階段用戶（我們叫 Canary / 金絲雀) ，根據(jù)每次發(fā)布的特點(diǎn)不同，是人為挑選的。

如果要發(fā)布一個(gè)只給亞洲用戶使用的功能，很明顯用美國或歐洲的集群來做發(fā)布實(shí)驗(yàn)，是沒有什么意義的。從這個(gè)角度來想，是不是灰度發(fā)布可做的事情很多很多？真的不只是按機(jī)器劃分這么簡單。

回到本質(zhì)：灰度發(fā)布是上線的最后一道安全防護(hù)機(jī)制。即不能過慢，讓產(chǎn)品團(tuán)隊(duì)過度依賴，也不能過于隨機(jī)，失去了他的意義。

總之，灰度發(fā)布，全在細(xì)節(jié)里。

第三點(diǎn)：服務(wù)必須對回滾提供支持

這點(diǎn)不允許商量！

這么重要的話題，我還要用一個(gè)感嘆號來強(qiáng)調(diào)一下！

但是估計(jì)現(xiàn)實(shí)情況里，大家都聽過各種各樣的理由吧。我這里有三條買也買不到的秘籍，今天跟大家分享一下，保證藥到病除。

理由1：我這個(gè)數(shù)據(jù)改動(dòng)之后格式跟以前的不兼容了，回退也不能正常！
秘籍1：設(shè)計(jì)、開發(fā)時(shí)候就考慮好兼容性問題?。?！比如說數(shù)據(jù)庫改字段的事就不要做，改成另加一個(gè)字段就好。數(shù)據(jù)存儲格式就最好采用 protobuf 這種支持?jǐn)?shù)據(jù)版本、支持前后兼容性的方案。最差的情況，也要在變更實(shí)施『之前』，想清楚數(shù)據(jù)兼容性的問題。沒有回滾腳本，不給更新，起碼做到有備而戰(zhàn)。

理由2：我這個(gè)變更刪掉東西了！回退之后數(shù)據(jù)也沒了！
秘籍2：你一定是在逗我。把這個(gè)變更打回去，分成兩半。第一半禁止訪問這個(gè)數(shù)據(jù)。等到發(fā)布之后真沒問題了，再來發(fā)布第二半，第二半真正刪掉數(shù)據(jù)。這樣第一半實(shí)施之后需要回滾還可以再回去。

理由3：我這個(gè)變更發(fā)布了之后, 其他依賴這個(gè)系統(tǒng)的人都拿到了錯(cuò)誤的數(shù)據(jù)，再回退也沒用了，他們不會再接受老數(shù)據(jù)了！
秘籍3：這種比較常見出現(xiàn)在配置管理、緩存等系統(tǒng)中。對這類問題，最重要的就是， 應(yīng)該開發(fā)一種跟版本無關(guān)的刷新機(jī)制。觸發(fā)刷新的機(jī)制應(yīng)該獨(dú)立于發(fā)布過程。 要有一個(gè)強(qiáng)制刷新數(shù)據(jù)的手段。

以上三個(gè)秘籍覆蓋了100%的回滾兼容性問題，如果有不存在的，請務(wù)必告訴我！

回滾兼容性問題，是一個(gè)整體難題。只有開發(fā)和運(yùn)維都意識到這個(gè)問題的嚴(yán)重性，才能從整體上解決這個(gè)問題。而解決不了回滾難題，就不可能達(dá)到高可用。

三、可用性 7 級圖表

說完了變更管理，給大家?guī)硪粋€(gè)7級圖表，可以看看自己的服務(wù)到底在哪個(gè)可用性的級別上。

當(dāng)一個(gè)服務(wù)掛了的時(shí)候……

第一級：Crash with data corruption, destruction.

內(nèi)存數(shù)據(jù)庫就容易這樣。出現(xiàn)個(gè)意外情況，所有數(shù)據(jù)全丟。寫硬盤寫到一半，掛了之后，不光進(jìn)程內(nèi)數(shù)據(jù)沒了，老數(shù)據(jù)都丟光了。碰上這樣的系統(tǒng)，我只能對你表示同情了。

第二級：Crash with new data loss.

一般來說 正常的服務(wù)都應(yīng)該做到這一點(diǎn)…… 。掛了之后最多只丟個(gè)幾秒之內(nèi)的數(shù)據(jù)。

第三級：Crash without data loss.

要達(dá)到這一級，需要付出一定程度的技術(shù)投入。起碼搞清楚如何繞過 OS 各種 Cache，如何繞過硬件的各種坑。

第四級：No crash, but with no or very limited service, low service quality.

做的好一點(diǎn)的系統(tǒng)，不要?jiǎng)硬粍?dòng)就崩潰了…… 如果一個(gè)程序能夠正常處理異常輸入，異常數(shù)據(jù)等，那么就給剛才說的高級流控系統(tǒng)創(chuàng)造了條件?？梢园哑渌挠脩袅髁繉?dǎo)入過來，把問題流量發(fā)到一邊去，不會造成太大的容量損失。

第五級：Partial or limited service, with good to medium service quality.

這一級就還好了，如果多個(gè)業(yè)務(wù)跑在同一個(gè)實(shí)例上，那么起碼不要全部壞掉。有部分服務(wù)，比完全沒有服務(wù)要好

第六級：Failover with significant user visible delay, near full quality of service

上升到這一級別，才摸到高可用的門，也就是有容災(zāi)措施。但是可能自動(dòng)化程度不高，或者是一些關(guān)鍵性問題沒有解決，所以業(yè)務(wù)能恢復(fù)，就是比較慢。

第七級：Failover with minimal to none user visible delay, near full quality

of service.

這邊蝴蝶扇了一下翅膀，天空落了個(gè)打雷，打掉了一整個(gè)機(jī)房，結(jié)果業(yè)務(wù)完全沒受影響。藍(lán)翔技校一鏟子下去，互聯(lián)網(wǎng)都要抖一抖。嘿嘿， 高可用就是為了這種事情做準(zhǔn)備。

Q & A

1. 有什么評測系統(tǒng)嗎？

評測系統(tǒng)的第一步是收集足夠的信息。想知道自己的服務(wù)是不是高可用，必須得先監(jiān)測啊！不光黑盒監(jiān)測，還要有白盒監(jiān)測。如果有一個(gè)自動(dòng)化的 SLA 監(jiān)控系統(tǒng)，能顯示實(shí)時(shí)的 SLA 變化 ，會對系統(tǒng)的開發(fā)計(jì)劃有很強(qiáng)烈的指導(dǎo)作用。

2. 能詳細(xì)說一下做到 “crash without data loss” 需要在哪些點(diǎn)上下功夫嗎？

這個(gè)事情說起來簡單，實(shí)際實(shí)現(xiàn)起來非常復(fù)雜。 因?yàn)楹芏鄸|西深究起來都有無數(shù)的坑。 比如說：

OS 的 Cache 如何繞過。
系統(tǒng)硬件可能也有內(nèi)置的 Cache，F(xiàn)irmware 也可能有 BUG 等等等等。還有一些集群系統(tǒng)為了所謂的性能實(shí)現(xiàn)的 fake sync。

這里是列不全的。我提出這個(gè)等級的意思，是想讓大家有這個(gè)意識去系統(tǒng)化的應(yīng)對這個(gè)問題。比如說關(guān)鍵數(shù)據(jù)是不是要多存幾分，然后做一些 destruction 測試。比如多模擬斷電等等的極端情況，這樣才能有備無患。掃雷比觸雷要容易多了。

3. 現(xiàn)在 Coding.net 到幾個(gè)9了，7張圖中第幾級了，改造花了多長時(shí)間，有哪些坑分享下？

首先高可用是按業(yè)務(wù)來的，不是所有業(yè)務(wù)都能做到高可用，也不是所有都需要做到高可用。我們下了很大精力在關(guān)鍵業(yè)務(wù)上，比如說 Git 系統(tǒng)的流控，數(shù)據(jù)安全等等，其他的就沒辦法啦。

4. 開發(fā)團(tuán)隊(duì)要怎樣配合？周期怎么樣配合？側(cè)重點(diǎn)各自在哪 （開發(fā)更側(cè)重業(yè)務(wù)）？

首先就是要確定一個(gè)共同目標(biāo)。高可用是有代價(jià)的，你的業(yè)務(wù)需要做到什么程度，一定是一個(gè)系統(tǒng)性的考慮。給大家舉一個(gè)例子，Youtube 這么多視頻， 但是每個(gè)視頻的每種格式，只存了1份。所以可用性肯定受影響了。但是，數(shù)據(jù)量實(shí)在是太大了，然后各種小貓視頻實(shí)在是不重要。相比之下，廣告視頻經(jīng)常存8 份。所以！想要提高可用性，必須要和開發(fā)團(tuán)隊(duì)找到一個(gè)共同目標(biāo)。這里再給大家一個(gè)秘籍，那就是 error budget。跟開發(fā)團(tuán)隊(duì)確定一個(gè)可用度，比如說 99% 。 如果業(yè)務(wù)團(tuán)隊(duì)搞出來的東西很爛，各種狀況，最后達(dá)不到這個(gè)標(biāo)準(zhǔn)。那么對不起，暫時(shí)別發(fā)新功能，只修 BUG。

5. 谷歌的 SRE 工程師用了哪些開源工具來管理百萬機(jī)器？

比較慚愧，我們沒用什么開源工具，都是內(nèi)部自己開發(fā)的。企業(yè)內(nèi)部管理用了Puppet，但是生產(chǎn)系統(tǒng)上沒有。

6. 請問一下實(shí)現(xiàn)獨(dú)立對等的N+2服務(wù)使用什么架構(gòu)比較好，LVS+Keepalive 的雙機(jī)熱備是否合適？

莫非現(xiàn)在不都用 haproxy / nginx 之類的7層代理？但是其實(shí)這個(gè)原理都差不多。只要達(dá)到你的目的，可以動(dòng)態(tài)切換就好。

7. “可以把其他的用戶流量導(dǎo)入過來。把問題流量發(fā)到一邊去，不會造成太大的容量損失。” 這句話怎么理解呢？ 另外如何區(qū)分問題流量？

這句話說的是剛才提到的高可用必不可少的流控系統(tǒng)。任何一個(gè)系統(tǒng)都不是完美的，總會有各種各樣的 hot spot，weak spot。問題流量的定義是跟業(yè)務(wù)緊密相關(guān)的。我再舉一個(gè)例子：當(dāng)年 Youtube 的 CDN 服務(wù)器有個(gè)問題，后端存儲慢了之后，前端的請求會聚在一起，就像水管一樣，于是內(nèi)存就爆了。突然壓力過高，肯定就掛了。如何處理這個(gè)問題？ 最后流控系統(tǒng)升級，每個(gè)實(shí)例自己匯報(bào)自己的內(nèi)存狀況，超標(biāo)之后流控系統(tǒng)自動(dòng)繞過他。把這個(gè)問題變成了自動(dòng)化處理的方案，問題面大大縮小了。再舉一個(gè)例子， 搜索系統(tǒng)是典型的熱點(diǎn)密集型系統(tǒng)。有的冷僻詞， 查一次要去各種讀硬盤。而熱詞，消耗很小。所以流控系統(tǒng)做了個(gè)功能每個(gè)請求回復(fù)都帶了 cost 值，流控系統(tǒng)自動(dòng)均衡了整個(gè)集群。

8. 關(guān)于回滾那里，如果我要新增一個(gè)刪除功能，怎么做到把這個(gè)操作拆成兩半，用戶做了刪除操作，可是禁止刪除數(shù)據(jù)，那是否會產(chǎn)生數(shù)據(jù)不一致的？

這個(gè)是剛才說的那個(gè)秘籍第二條。其實(shí)秘籍第二條就是拆！沒有什么發(fā)布是不能拆的。 拆到可以安全的往前滾再往后滾。

9. 100W臺服務(wù)器如何自動(dòng)化管理、及時(shí)發(fā)現(xiàn)故障、自動(dòng)修復(fù)、做出報(bào)警，能否簡單介紹介紹？

這個(gè)問題其實(shí)沒那么復(fù)雜。就是在每個(gè)機(jī)器上運(yùn)行一個(gè)agent，這個(gè)agent定期進(jìn)行檢查操作，有問題就通知管理系統(tǒng)自動(dòng)下線。只要注意平時(shí)收集 問題現(xiàn)象就行了。比如說線上突然出現(xiàn)了一個(gè)時(shí)間不同的問題，那么就把他加到這個(gè)agent里去，下次這個(gè)問題就是自動(dòng)檢測自動(dòng)修復(fù)的了。

10. 有沒有什么好辦法處理 query to death？

這個(gè)問題比較難，一般是要做一層智能一點(diǎn)的業(yè)務(wù) proxy 。業(yè)務(wù) proxy 檢測到請求發(fā)到哪，哪個(gè)后端掛，就可以進(jìn)行一些處理了。還有一個(gè)辦法是在掛之前后端記log，處理之前記上。我要處理這個(gè)請求了，然后處理一半掛掉了。重 啟之后，檢查 log 發(fā)現(xiàn)上次是處理這個(gè)請求掛了，那么就可以屏蔽掉這個(gè)請求。