任何時(shí)候發(fā)生網(wǎng)絡(luò)服務(wù)中斷，都會(huì)對全球業(yè)務(wù)造成極大的影響和破壞，而且還會(huì)導(dǎo)致收入和聲譽(yù)的重大損失。盡管應(yīng)用程序交付依賴于許多網(wǎng)絡(luò)服務(wù)提供商（ISP），但它也越來越依賴于面向網(wǎng)絡(luò)的服務(wù)的大型且復(fù)雜的生態(tài)系統(tǒng)，例如CDN、DNS、DDoS緩解和公共云。這些服務(wù)共同為用戶提供卓越的數(shù)字體驗(yàn)，即使是短暫的中斷也會(huì)產(chǎn)生重大影響。
同時(shí)，企業(yè)越來越依賴Internet傳輸來連接其站點(diǎn)并訪問業(yè)務(wù)關(guān)鍵的應(yīng)用程序和服務(wù)?，F(xiàn)在應(yīng)用程序完全托管在私有數(shù)據(jù)中心和辦公地點(diǎn)，那些主要通過MPLS進(jìn)行連接的日子已經(jīng)一去不復(fù)返了。隨著企業(yè)逐漸采用SD-WAN技術(shù)，互聯(lián)網(wǎng)正在取代/補(bǔ)充MPLS等服務(wù)。因此，Internet現(xiàn)在實(shí)際上是企業(yè)的骨干網(wǎng)，作為一種“盡力而為”的傳輸方式，可能會(huì)對企業(yè)產(chǎn)生重大且無法預(yù)見的后果。
在過去的一年中，幾次大規(guī)模的宕機(jī)對全球互聯(lián)網(wǎng)產(chǎn)生了連鎖反應(yīng)，對企業(yè)和消費(fèi)者都產(chǎn)生了不同程度的影響。我們匯總了一些比較嚴(yán)重的宕機(jī)事件，以下是按時(shí)間順序排列的2019年最具破壞性的宕機(jī)事件：
事件
01
2019年5月13日，中國電信宕機(jī)事件揭示了其全球影響力
雖然這不是2019年最具破壞性的宕機(jī)事件，但從這次事件也可以看出中國電信的業(yè)務(wù)范圍遠(yuǎn)遠(yuǎn)超出了中國大陸。2019年5月13日，中國電信經(jīng)歷了一次重大故障，持續(xù)了將近5小時(shí)，后續(xù)又持續(xù)幾個(gè)小時(shí)。中國電信在其主干網(wǎng)上遭受了嚴(yán)重的數(shù)據(jù)包丟失，主要是中國大陸的網(wǎng)絡(luò)基礎(chǔ)設(shè)施受到較大影響，但是也波及了中國電信的新加坡和美國包括洛杉磯等多個(gè)節(jié)點(diǎn)，全世界有一百多種服務(wù)受到干擾。
此次整個(gè)長時(shí)間持續(xù)中斷過程中，路由轉(zhuǎn)發(fā)到受到影響故障節(jié)點(diǎn)的流量全都被丟棄了，也就是說部分在中國國內(nèi)和國外的用戶，使用瀏覽器或者應(yīng)用程序訪問的大量國外網(wǎng)站均出現(xiàn)了中斷。中國的用戶嘗試訪問架設(shè)在國外的網(wǎng)站會(huì)受到影響，與此同時(shí)，國外的用戶試圖訪問中國國內(nèi)網(wǎng)站也受到影響。
同時(shí)這次宕機(jī)事件也讓美國的網(wǎng)站服務(wù)受到了影響，如蘋果，亞馬遜，微軟，Slack，Workday，SAP等等網(wǎng)站服務(wù)，下圖展示了受到網(wǎng)絡(luò)故障波以及影響的部分網(wǎng)站和服務(wù)。
此次事件說明了中國對全球互聯(lián)網(wǎng)的一些影響力，同時(shí)中國電信網(wǎng)絡(luò)提供商維護(hù)著全球因特網(wǎng)的互聯(lián)，和全球很多地方的網(wǎng)絡(luò)提供商保持聯(lián)系。
事件
02
2019年6月2日-“宕機(jī)之夏”始于Google Cloud
在2019年6月2日，Google Cloud Platform發(fā)生了嚴(yán)重的網(wǎng)絡(luò)中斷，影響了美國西部、美國東部和美國中部地區(qū)的托管服務(wù)。此次宕機(jī)也影響了Google自己的應(yīng)用程序，包括GSuite和YouTube。該宕機(jī)持續(xù)了四個(gè)多小時(shí)，幾天后，Google就此事件發(fā)布了官方報(bào)告。ThousandEyes 的優(yōu)勢在于能夠?qū)崟r(shí)查看宕機(jī)情況，并在更詳細(xì)的信息公開之前有效地揭示宕機(jī)的特點(diǎn)和規(guī)模。
大約從美國東部時(shí)間上午9點(diǎn)開始，相關(guān)工作人員觀察到試圖連接到GCP us-west2-a中托管服務(wù)的全局監(jiān)視器的數(shù)據(jù)包丟失率達(dá)到100％。在GCP美國東部幾個(gè)地區(qū)（包括us-east4-c）托管的站點(diǎn)也看到了類似的損失。
事實(shí)證明，部分Google網(wǎng)絡(luò)完全不可用是由于Google的網(wǎng)絡(luò)控制平面意外脫機(jī)導(dǎo)致的。谷歌后來透露，在宕機(jī)期間，一套自動(dòng)策略確定了哪些服務(wù)可以在未受影響的網(wǎng)絡(luò)中部分訪問或不能訪問。
從云服務(wù)中斷中獲得的最重要的教訓(xùn)是，確保任何云架構(gòu)都具有足夠的彈性措施（無論是在多區(qū)域基礎(chǔ)上還是在多云基礎(chǔ)上），以防止將來再次發(fā)生中斷，這一點(diǎn)至關(guān)重要?？梢哉f即使在云中，IT基礎(chǔ)架構(gòu)和服務(wù)有時(shí)也會(huì)出現(xiàn)中斷。
事件
03
6月24日-Cloudflare用戶淪為路由災(zāi)難的受害者
就在WhatsApp用戶遭遇大規(guī)模路由泄漏事件的幾周后，互聯(lián)網(wǎng)又發(fā)生了另一起與路由相關(guān)的事件，并且造成的破壞要大得多。
Cloudflare是一家CDN服務(wù)提供商，2019年6月24日，在將近兩個(gè)小時(shí)的時(shí)間里，一個(gè)重大的BGP路由錯(cuò)誤對試圖訪問Cloudflare服務(wù)的用戶造成了嚴(yán)重影響，包括游戲平臺Discord和Nintendo Life。經(jīng)分析發(fā)現(xiàn)，該BGP路由泄漏來自多方因素。DQE是一家傳輸提供商，是此次泄漏的源頭，該泄漏是通過DQE和Verizon的客戶Allegheny Technologies傳播的。不幸的是，Verizon進(jìn)一步傳播了路由泄漏，從而擴(kuò)大了影響。
此次重大宕機(jī)影響了Cloudflare約15％的全球流量，并影響了Discord、Facebook和Reddit等服務(wù)，持續(xù)時(shí)間約兩小時(shí)。路由泄漏也影響了對一些AWS服務(wù)的訪問。
該事件的根本原因可歸因于DQE使用的BGP優(yōu)化軟件，該軟件創(chuàng)建了到Cloudflare服務(wù)的路由，而這些路由只能在DQE的內(nèi)部網(wǎng)絡(luò)中使用。當(dāng)這些路線意外地泄露給其中一位客戶時(shí)，混亂就隨之而來了。
這次事件再次提醒我們，在以云為中心的世界中，企業(yè)要想成功地向用戶提供服務(wù)，就必須對網(wǎng)絡(luò)具有可見性。
事件
04
7月4日-Apple服務(wù)在7月4日受到影響
2019年7月4日，連接到Apple網(wǎng)站及其部分服務(wù)（例如Apple Pay）的用戶經(jīng)歷了長達(dá)90多分鐘的嚴(yán)重丟包。這個(gè)問題導(dǎo)致許多用戶無法成功連接到Apple。該數(shù)據(jù)包丟失是由BGP路由震蕩引起的。當(dāng)一個(gè)路由公告被快速連續(xù)地（通常是反復(fù)）發(fā)出和撤回時(shí)，BGP路由就會(huì)出現(xiàn)問題。
此次事件蘋果在早期成功阻止了事情的發(fā)酵。
從這次事件中得到的教訓(xùn)是，宕機(jī)不會(huì)憑空發(fā)生，有時(shí)僅根據(jù)其時(shí)機(jī)和環(huán)境來判斷，即使是嚴(yán)重的中斷也可能會(huì)被忽視（或者反過來，明明不嚴(yán)重卻引起嚴(yán)重的騷動(dòng)）。
事件
05
9月6日-DDoS攻擊者瞄準(zhǔn)維基百科
由于大規(guī)模持續(xù)的分布式拒絕服務(wù)（DDoS）攻擊，2019年9月6日，世界各地對維基百科網(wǎng)站的訪問中斷了將近9個(gè)小時(shí)。DDoS攻擊可以擊垮目標(biāo)網(wǎng)絡(luò)的基礎(chǔ)設(shè)施，并在服務(wù)提供商網(wǎng)絡(luò)內(nèi)部造成擁塞，從而導(dǎo)致數(shù)據(jù)包丟失。
在事件過程中，世界各地的HTTP服務(wù)器可用性顯著下降，并且HTTP響應(yīng)時(shí)間急劇增加。許多地區(qū)的用戶無法建立Internet連接，無法與維基百科服務(wù)器進(jìn)行持續(xù)通信，此次攻擊造成了高達(dá)60％的數(shù)據(jù)包丟失，這進(jìn)一步阻止了對維基百科網(wǎng)站的訪問。
雖然DDoS事件在Internet上時(shí)有發(fā)生，但組織應(yīng)該主動(dòng)了解這些事件的范圍和影響，并驗(yàn)證DDoS緩解措施是否有效。
來源：SDNLAB，
