關(guān)于 Facebook 故障的分析和反思

今天美國東部標(biāo)準(zhǔn)時(shí)間上午11點(diǎn)51分開始，Facebook出現(xiàn)故障，最終六個(gè)小時(shí)以后才恢復(fù)。很多平臺(tái)(CloudFlare[1],ThousandEye[2])都做了故障歸因. 本文的第一部分簡要的概括一下故障原因，以翻譯整理這兩個(gè)參考網(wǎng)站資料為主， 第二個(gè)部分主要是從技術(shù)上和協(xié)議上分析分析一些缺陷， 最后一部分則是從管理的視角來看待基礎(chǔ)架構(gòu)團(tuán)隊(duì)的風(fēng)險(xiǎn)控制和激勵(lì)機(jī)制。

Facebook癱瘓?jiān)?/span>

按照好基友的說法，遇到如此大規(guī)模的癱瘓不是DNS就是BGP出了問題。但是很抱歉，這次是兩個(gè)一起出了問題.

[UTC 15:40]?ThousandEye監(jiān)控到Facebook應(yīng)用出現(xiàn)DNS失效的情況，然后 繼而出現(xiàn)Authoritative DNS服務(wù)器不可達(dá)的情況：

而Cloudflare在自身解析FB DNS服務(wù)出現(xiàn)故障后，懷疑是自己的DNS服務(wù)(1.1.1.1)故障,并在進(jìn)一步的歸因分析中發(fā)現(xiàn)Facebook在UTC 1540時(shí)產(chǎn)生了大量的BGP更新:

進(jìn)一步分析BGP消息發(fā)現(xiàn)了大量的路由并撤銷了關(guān)于DNS服務(wù)器的路由:

[UTC 17:40]?ThousandEye也分析發(fā)現(xiàn)，這些關(guān)于DNS服務(wù)器的路由，在事故前是129.134.30.0/23??129.134.30.0/24?129.134.31.0/24的明細(xì)路由。但事故發(fā)生時(shí)它們可達(dá)的路由變成了129.134.0.0/17，并且數(shù)據(jù)包通過TraceRoute發(fā)現(xiàn)丟棄在FB的邊界路由器上，大概率斷定是人為配置錯(cuò)誤，很有可能是流量調(diào)度時(shí)搞錯(cuò)了。

而另兩個(gè)DNS服務(wù)器的路由已經(jīng)被撤銷,導(dǎo)致路由在運(yùn)營商邊界就不可達(dá)了

Cloudflare在后續(xù)的時(shí)間中發(fā)現(xiàn)，關(guān)于FB的DNS請(qǐng)求放大了30倍:

[UTC 21:00]?CloudFlare發(fā)現(xiàn)FaceBook開始通過BGP通告了一些路由，直到21:17通告大量路由后，流量基本恢復(fù).

任何一起大事故都是一系列偶然因素的疊加，從BGP路由的變化來看，很有可能是在做流量工程的時(shí)候，將路由發(fā)布錯(cuò)了，極大概率又和BGP FlowSpec有關(guān)，但是一個(gè)值得反思的問題是過去幾個(gè)小時(shí)靜悄悄的沒有任何路由器的更新發(fā)出，有傳言稱是DNS掛了導(dǎo)致門禁系統(tǒng)掛了，從而無法進(jìn)入機(jī)房恢復(fù)數(shù)據(jù)。

關(guān)于故障的反思.1 BGP

關(guān)于BGP帶來的重大事故已經(jīng)不止一次發(fā)生了，BGP作為整個(gè)互聯(lián)網(wǎng)的基石，其協(xié)議用了30年了，BGP協(xié)議源于1989年1月第12次IETF會(huì)議, 由Len Bosack, Kirk Lougheed 和Yakov Rekhter提出實(shí)現(xiàn)一種所謂的邊界網(wǎng)關(guān)協(xié)議(Board Gateway Protocol", 其后在三張餐巾紙上完成了BGP設(shè)計(jì)的草稿. 然后在會(huì)議結(jié)束后的不到一個(gè)月的時(shí)間, 他們提出了兩個(gè)BGP的實(shí)現(xiàn)方案, 并在1989年6月發(fā)布了RFC1105.

協(xié)議設(shè)計(jì)之初的想法比較簡單,?第一個(gè)想法在路由信息中包含相關(guān)的路徑屬性, 并且使用它來提供無環(huán)路的路由.?第二個(gè)想法是采用增量更新來盡量減少路由信息在兩個(gè)路由器之間的交互.?第三個(gè)想法則是通過TCP來保證可靠傳輸.?最后一個(gè)想法則是使用TLV的方式來定義數(shù)據(jù)結(jié)構(gòu), 這樣使得協(xié)議擁有了很好的擴(kuò)展性.

但是30年后，其主要的問題是其通信和計(jì)算機(jī)制已經(jīng)不能滿足大量路由(接近1M前綴)的需求了。TCP帶來的Head Of line Blocking導(dǎo)致了BGP通信過程中收斂緩慢。4Byte-ASN和IPv4地址交易帶了路由前綴大量更新。數(shù)據(jù)中心內(nèi)針對(duì)BGP-EVPN的擴(kuò)展和使用BGP FlowSpec使得協(xié)議棧越來越復(fù)雜。互聯(lián)網(wǎng)上各種魔改的開源BGP(FRR-OpenBGP/GoBGP)使得協(xié)議互通時(shí)出現(xiàn)Bug的幾率急劇上升。當(dāng)然最嚴(yán)重的問題是：BGP狀態(tài)機(jī)和TCP的耦合：

其實(shí)早在10多年前我就看到了這個(gè)問題，簡單的修復(fù)方式是使用MultiThread構(gòu)建多個(gè)BGP Peering的會(huì)話來發(fā)送不同的Address-Family信息，另一種是針對(duì)路徑上的一些問題，使用MultiHoming和MultiStreaming的方式，也就是使用BGP Over SCTP的處理方式，并且在10多年前就寫了相應(yīng)的RFC-Draft

但是最終因?yàn)楫?dāng)時(shí)BGP并未承載如此大的流量以及SCTP協(xié)議棧本身的失敗，所以擱置了.

BGP另一個(gè)問題是其低效的一致性收斂算法。BGP協(xié)議設(shè)計(jì)時(shí)還是剛到486的年代，自然有一些自身的限制和容量的取舍,eBGP防環(huán)可以通過AS_PATH，而iBGP不同，因?yàn)槌鲇诜拉h(huán)的考慮，iBGP收到更新后不能將其傳給其它iBGP對(duì)等體，因此必須要將AS內(nèi)部的路由器進(jìn)行iBGP Fullmesh連接。事實(shí)上, 對(duì)于一個(gè)大型的運(yùn)營商其內(nèi)部可能有數(shù)以百計(jì)的BGP路由器并需要全互聯(lián)形成iBGP對(duì)等體. 這樣的部署方式對(duì)于運(yùn)營商來說是不切實(shí)際并不被接受的. 因此Tony Bates和Ravi Chandra在1996年6月提 出了RFC1966: Route Reflector 作為一種避免iBGP Fullmesh的備選方案。而提出BGP-RR的Ravi Chandra就是支持我搞ML在網(wǎng)計(jì)算的大佬:

現(xiàn)在說大爺?shù)腂GP-RR有問題，好像有點(diǎn)尷尬。但是事實(shí)如此，畢竟國內(nèi)好多運(yùn)營商還專門拿我們做的某款路由器來做整個(gè)骨干網(wǎng)的RR，所以里面大大小小的問題我都清楚，調(diào)TCP-Stack，優(yōu)化QoS這些都干過...

---

結(jié)論: 其實(shí)不光我說的，以前阿里的依群總也講過BGP這樣的協(xié)議發(fā)展了20、30年了也急需做一些變革了。而這些變革就在分布式一致性上，也就是我為什么建議在域內(nèi)使用ETCD代替BGP路由并構(gòu)建Ruta控制平面[3]的根本原因。

在域內(nèi)將iBGP的一致性轉(zhuǎn)換為分布式K-V數(shù)據(jù)庫同步的處理方式.

另一方面你們可以看到NSDI'21上Google發(fā)布的Orion[4]

Google便是使用其分布式數(shù)據(jù)庫來保存路徑信息和域內(nèi)的一致性。而Ruta同樣如此，采用ETCD來實(shí)現(xiàn)。

具體關(guān)于控制面協(xié)議設(shè)計(jì)，去看今年早些時(shí)候?qū)懙囊晃陌?/span>

包處理的藝術(shù)(2)-控制面協(xié)議設(shè)計(jì)

關(guān)于故障的反思.2 互聯(lián)

當(dāng)然BGP的失效有可能是中間某個(gè)運(yùn)營商的錯(cuò)誤配置導(dǎo)致的，雖然這次FB的故障是FB自身，但是下次有哪個(gè)運(yùn)營商發(fā)布錯(cuò)了劫持了Facebook DNS地址呢？

然后由于公有云和很多傳統(tǒng)運(yùn)營商都有Peering，可以讓本地網(wǎng)絡(luò)可以盡快的接到云上，這樣就規(guī)避了傳統(tǒng)的Internet路由使用BGP跨越多個(gè)運(yùn)營商的缺陷，在不改變Internet架構(gòu)的同時(shí)，構(gòu)建了一個(gè)Overlay將部分云節(jié)點(diǎn)構(gòu)成了Transit-AS

關(guān)于故障的反思.3 DNS

DNS其實(shí)某種意義上來看也是一種基于域名的路由協(xié)議，這也是我前幾個(gè)月要自己開發(fā)一個(gè)開源項(xiàng)目ZaDNS的原因，傳統(tǒng)的主機(jī)只能選擇一主一備兩個(gè)DNS服務(wù)器，然后通常我們又因?yàn)楹芏鄨?chǎng)景需要基于不同的Domain查詢不同的DNS服務(wù)器，因此有了基于DNS的Domain Based Routing的需求。另一方面針對(duì)CDN失效避免和CDN優(yōu)化需要進(jìn)行可達(dá)性探測(cè)，還有針對(duì)網(wǎng)絡(luò)安全需要做ZTNA或者基于ML算法的DNS域名或者Bad Reputation Record的過濾，這些都一起實(shí)現(xiàn)好了開源出來了：

項(xiàng)目地址:

github.com/zartbot/zadns

關(guān)于故障的反思.4 監(jiān)控

針對(duì)BGP的監(jiān)控比較容易，有現(xiàn)成的BGP Monitor Protocol， 另一個(gè)比較有用的就是快速的TraceRoute，ThousandEye算是比較成功的一家了。當(dāng)然TraceRoute和探針測(cè)量本來就很簡單：

TraceRoute我自己開源了一個(gè)并行的快速探測(cè)軟件：

github.com/zartbot/ztrace

而針對(duì)Internet的測(cè)量和統(tǒng)計(jì)，也有相應(yīng)的最佳實(shí)踐:

Internet 的性能測(cè)量

關(guān)于故障的反思.5 激勵(lì)

基礎(chǔ)架構(gòu)團(tuán)隊(duì)主要是為整個(gè)業(yè)務(wù)提供算力、網(wǎng)絡(luò)等各種資源，基礎(chǔ)設(shè)施建設(shè)本來就是重資產(chǎn)支出的部門，簡單的來說一個(gè)純花錢的部門如何進(jìn)行業(yè)績?cè)u(píng)估和激勵(lì)。從運(yùn)營的角度不出事故永遠(yuǎn)看不到這群人的重要性，而6小時(shí)的故障損失也一定程度上衡量了這種部門的關(guān)鍵性。

其實(shí)我們從另一個(gè)角度來看， 銀行攬儲(chǔ)的部門是不是有額外的獎(jiǎng)金？但是這些部門也是純花錢的部門，畢竟攬儲(chǔ)來的錢不得付利息啊？那么為啥都是花錢一個(gè)有激勵(lì)，一個(gè)沒有呢？關(guān)鍵就是針對(duì)計(jì)算彈性的資源提供方如何進(jìn)行轉(zhuǎn)移定價(jià)的問題。

內(nèi)部資金轉(zhuǎn)移定價(jià)（FTP）是指，商業(yè)銀行內(nèi)部資金中心與業(yè)務(wù)經(jīng)營單位按照一定規(guī)則全額有償轉(zhuǎn)移資金，達(dá)到核算業(yè)務(wù)資金成本或收益等目的的一種內(nèi)部經(jīng)營管理模式。業(yè)務(wù)經(jīng)營單位每筆負(fù)債業(yè)務(wù)所籌集的資金，均以該業(yè)務(wù)的FTP價(jià)格全額轉(zhuǎn)移給資金中心；每筆資產(chǎn)業(yè)務(wù)所需要的資金，均以該業(yè)務(wù)的FTP價(jià)格全額向資金管理部門購買。對(duì)于資產(chǎn)業(yè)務(wù)，F(xiàn)TP價(jià)格代表其資金成本，需要支付FTP利息；對(duì)于負(fù)債業(yè)務(wù)，F(xiàn)TP代表其資金收益，可以從中獲取FTP利息收入。

FTP能夠科學(xué)評(píng)價(jià)績效、優(yōu)化配置資源、合理引導(dǎo)定價(jià)、集中管理市場(chǎng)風(fēng)險(xiǎn)等，具體而言：一是以合理的資金成本或資金收益為基礎(chǔ)，逐步構(gòu)建銀行對(duì)產(chǎn)品、對(duì)客戶、對(duì)個(gè)人的科學(xué)評(píng)價(jià)體系；二是以資金成本的準(zhǔn)確計(jì)量為基礎(chǔ)，逐步建立和完善銀行資源配置機(jī)制、產(chǎn)品定價(jià)機(jī)制以及經(jīng)風(fēng)險(xiǎn)調(diào)整后的績效評(píng)估機(jī)制；三是通過科學(xué)的產(chǎn)品FTP定價(jià)，剝離經(jīng)營單位的市場(chǎng)風(fēng)險(xiǎn)，建立由專業(yè)化團(tuán)隊(duì)集中管理市場(chǎng)風(fēng)險(xiǎn)的經(jīng)營管理模式；四是通過FTP推廣，逐步推進(jìn)資金管理體制改革，以及扁平化、事業(yè)部方式的全行條線為主的組織架構(gòu)改革。而對(duì)于數(shù)字化資產(chǎn)我們同樣可以實(shí)施相應(yīng)的FTP，為解決基礎(chǔ)架構(gòu)部門和業(yè)務(wù)及應(yīng)用部門相互利益分配會(huì)有很大的好處，從而進(jìn)一步從財(cái)務(wù)核算上激勵(lì)雙方進(jìn)行技術(shù)創(chuàng)新

基于FTP的機(jī)制還有一個(gè)好處是在基礎(chǔ)架構(gòu)建設(shè)過程中，通過完整的端到端成本核算，能夠有利于激發(fā)團(tuán)隊(duì)進(jìn)行關(guān)鍵性的節(jié)點(diǎn)的創(chuàng)新和風(fēng)險(xiǎn)補(bǔ)償機(jī)制。

-?END -