2017年1月14日晚上18:54開始，UCloud的北京機房出了什麼狀況？

01-23

收到他們的簡訊通知，到目前21:39為止，仍未恢復。

Dear 知友：

昨晚UCloud北京二區域可用區的確出現了故障，北京二區域可用區B外網以及跨可用區內網同時中斷。通過緊急搶修，當晚22點50分，可用區B的網路故障已經完成修復，現內網、外網均已恢復正常。後續故障賠償事宜正在開展中，賠償金額將陸續發放至受影響用戶的UCloud賬戶。謹在此向所有受故障影響的用戶和所有關心UCloud的朋友說聲抱歉，對不起！

關於此次故障的官方聲明如下：

——————

關於北京二區可用區B故障處理公告

2017年01月14日18時54分，UCloud技術支持收到監控告警，北京二區域可用區B外網以及跨可用區內網同時中斷。隨即，UCloud雲計算團隊立即開始排查處理，逐段定位到北京二區域可用區B到北京城市POP點的光纜因運貨卡車撞倒光纜線桿導致全部中斷。定位到故障點後，傳輸供應商緊急趕赴現場進行熔接修復，最終於1月14日22時50分北京二區域可用區B內外網通訊完全恢復。

故障時間和影響範圍

18:54~20:38，北京二區域部分移動線路中斷

18:54~22:50，北京二區域可用區B外網中斷，B到其他可用區的跨可用區互訪中斷

處理過程

18:54，監控到北京二區域可用區B到北京POP點線路告警，可用區B的跨可用區互訪中斷、公網中斷，北京二區域部分移動數據中斷

19:51，傳輸供應商到達現場展開故障點定位測試

20:30，傳輸供應商確認中斷點在中國移動數據中心外3km處，趕赴現場進行修復

20:38，對於移動線路問題啟動備用方案，北京區域（除可用區B以外）移動線路恢復

21:09，到達現場，發現架空光纜立桿被貨車撞倒，光纜中斷，立即開始熔接維修

22:47，可用區B到北京POP點線路熔接修復，直連通信正常

22:50，確認可用區B到POP點的數據鏈路完全恢復，業務檢查確認恢復

故障原因

北京二區域可用區B到POP點的光纜因架空光纜立桿被貨車撞倒導致中斷，導致該可用區的公網以及跨機房內網互訪全斷。北京可用區B機房同時承載著北京移動數據出口，因此該機房光纜中斷同時導致北京區域自建BGP線路的部分移動數據中斷。

（圖1、2、3：數據中心外3km處，架空光纜線桿因卡車撞倒導致光纜斷裂）

後續改進措施

1、後續將對城域網傳輸系統進行進一步升級，在原雙路光纖冗餘的級別上，對每個可用區再增加冗餘裸纖，達到2+1級別冗餘，確保城域網可靠性。

2、加強應急預案體系建設，縮短應急處理時間，確保災難發生後可快速修復。

——————

對於此次事故受影響用戶及其損失，UCloud深表歉意。我們將秉持「用戶為先」的企業價值觀，根據SLA對受影響的用戶進行相應賠償，賠償金額充值至受影響用戶的UCloud賬戶。

再次抱歉！

以上。

呵呵，某些答案真是避重就輕。說的好像Ucloud的癱瘓還怪用戶咯？要我說，這次癱瘓事件並非意外，根本就是Ucloud「罪有應得。」

某大V答案提到「眾所周知服務是端到端的，中間無論哪個環節發生異常都可能導致服務不可用。如但不限於：服務自身BUG、雲廠商平台問題(如伺服器硬體、平台軟體BUG、雲廠商自身內部網路異常等)、客戶側網路問題(俗稱運營商網路，最遠端就是各位家裡的寬頻接入網哦)。」

是的，這段話沒問題，可是我覺得大V省略了後半段話。現在問題來了：哪些問題應該客戶自身負責？哪些問題應該雲服務商負責？從技術角度來說，客戶自身自然需要負責自己的服務正常，雲平台需要負責雲平台所有的軟硬體和基礎設施的穩定(如伺服器、IDC的風火水電、雲平台自身的網路連通性)。那麼通常大家所說的運營網網路問題都不能雲服務商負責搞定嗎？我認為是有很大區別的，這裡的水就很深，我來詳細分析下：

先從一個故事講起：

客戶小游是X雲廠商的重要客戶，在X雲廠商北京機房部署了服務，服務於全國所有用戶。

當初X雲告訴小游，他們給出有BGP多線，至少有電信、聯通、移動可靠穩定、並且提供運營商故障容災切換，小游聽得十分受用，感覺好高大上哦，所以小游就在X雲上安家落戶了。

畫面跳轉到上海寬頻用戶小客。

小客是小游業務的客戶。小客家中安裝了電信、移動兩家的寬頻接入，就是為了保障自己可以穩定的訪問小游的業務(小游業務很大哈)。

可是某日小客再次訪問小游的服務，發現一直處於異常狀態。小客小聲嘀咕"不靠譜，還好老子準備了兩條線路"；於是小客不慌不忙的切換到移動寬頻接入(小客還是很資深的哈，知道自己來冗餘最後一公里接入網)，信心滿滿的再次訪問小游的服務發現依然無法訪問，這下小客有些不淡定了……難道小游的服務掛了？

於是小客撥通了小游的電話，那頭反饋是」運營商網路異常導致雲服務商平台不可訪問」，但是小客反駁說自己通過電信、移動都不能訪問，難道兩家運營商同時出現異常，這下小游無言語對，說馬上再核實；這次導致小游很是納悶，非常不解，於是小游開始認真研究…….

用戶訪問雲服務網路路徑圖

小游很認真的研究起互聯網訪問路徑，發現還挺複雜，故畫了如上一張」用戶訪問雲服務網路路徑圖」，從上到下分成四個階段性路徑：分別是

1.用戶寬頻接入網；

2.運營商骨幹；

3.運營商IDC接入層；

4.雲服務商自身網路(BGP出口和DCI網路以及長傳)；

從邊界來看BGP出口這層是雲服務商和接入運營商共同負責，但就雲上客戶來說，BGP出口依然屬於雲服務商提供，故目前國內上的檯面的雲服務商一定有對BGP出口具備容災能力(哪些雲服務商有我就不累贅表述了)。

而雲基礎設施穩定性是個最為基礎的工作，必須從搭建底層網路的風火水電以及每一個光纖、每一根租用的線路開始仔細設計，不能走捷徑。

靠譜的雲服務商在IDC選址開始就會納入對IDC出局光纜局向、環境進行詳細的設計和實地勘察，一般的服務商會要求2條完全不同的物理路徑，但大的雲服務商一定會要求含3路由以上路徑保護。

為什麼呢？

事實告訴我們雲基礎設施僅做雙保險是不夠的(不然對不起各位看官)，本人也經歷多次遇到完全獨立的雙路由同時中斷(注意不是「假」雙路由，概率事件一定會發生，還沒發生表示你還沒遇到，下一秒可能就是你)；同時對不同物理路由路徑也需要仔細考察：如是否存在架空、路由之間平行距離是否大於100M等、以及IDC機房出局5KM內重點勘察是否潛在隱患(是否會存在後續大面積施工)；

光纜中斷總是不開避免，在出現光纜中斷時就需要雲服務商冗餘性設計避免對用戶產生影響，在冗餘性產生作用後雲服務商需迅速的組織運營商進行維修，一般光纜中斷報障後都是通過OTDR檢測中斷點(如不懂原理問」百度」)，正常情況下30分鐘可明確中斷點開始奔赴現場搶修，這裡修復越快越好；

接近雲服務商的運營商BGP接入點之間雖然屬於運營商和雲服務商共同管理，但是從服務角度和對象來說，應該而且必須是由雲服務商完全控制，減少和避免因此節點異常影響雲服務。

而運營商骨幹故障，在風涌雲起的雲市場助推下，有節操和有能力的雲服務商各展其能推動提升運營商骨幹穩定性的、側面改善和推動運營商故障響應和處理能力的，但這裡需要提醒下這是需要廣大看官和雲服務商一起努力推動的，不僅僅是雲服務商的事情，畢竟真正受傷的還是我們這些可愛和忠實的用戶。

再者遠端寬頻接入網故障導致客戶無法訪問雲上服務，這種事件每天都會發生，如果你真的100%需要隨時訪問一個服務，那真的只能像文中的」小客」一樣準備多條最後一公里的接入網，當然在移動網的盛行下通過4G來備用最後一公里也是不錯的…….

鋪墊了這麼多，回到14日Ucloud故障事件本身針對廣大看官的疑問，本人有話要說：

1、按照上圖「用戶訪問雲服務網路路徑圖」，本次Ucloud故障發生在灰色方框內，是DCI網路區域內，根本不屬於第三方運營商網路範疇，完全是由於IDC選址初期對物理路由選擇不夠嚴謹導致，注意：真的是只有單物理路由，而且是架空哦；

光纖物理上不是雙鏈路被，光是架空線路，很容易出事。所以我說出事不是意外，長期看從概率上是必然。

2、關於故障處理時長，從定位中斷點的時間來看，故障發生初期懷疑處理人員可能一頭霧水或者協調運營商處理不給力，按照正常處理邏輯來看，報障運營商後運營商30分鐘可以通過OTDR完成光纜故障中斷點的定位(這裡Ucloud反饋時間點來看用了近100分鐘)，開始奔赴維修；不過客觀的來說，4小時完成光纜修復還是正常的；

光纖理論上是在地下的，在北京這種電線杆上的光纖非常上了，也就是說肯定不是三大供應商的，這種老的地上光纖故障率非常高，未來故障可能還會源源不斷的來。其次，兩個小時定位光纖
這個服務商能力很差。

3、通過本文雲服務商與運營商故障範圍的分析，各位看官應該很情況可以看到：Ucloud引用的阿里雲對外通告的運營商異常」1月15日凌晨廣州電信訪問華東1地域網路異常通告」和」1月13日青島地域電信網路異常通報」與本次故障事件其實是風馬牛不相及的。

所以我說，雲服務商還是建議選擇有錢的大廠商。Ucloud這種小廠商一向以價格吸引人。但是比如說Ucloud的這次癱瘓故障，實際上雲服務的機房應該接三家運營商的互聯網，而且每家運營商應該接雙線，啟用BGP協議選錄，平台這邊應該多台路由器做虛擬化，出這種事那就是有單故障點。

根本原因是Ucloud為了省錢（同時給客戶省錢），把網路的成本降下來（不用BGP），他掛了就切換不了。使用IDC的客戶們，到底是錢重要還是安全重要呢？讓你用三根線連說好好的，比其他雲商BGP便宜太多，斷了就是這下場。

另外Ucloud物理上沒有冗餘備份，一個斷全掛了。這一點說明UCloud家硬體設計和採購不到位，不做物理冗餘的下場。

為什麼硬體採購不到位？歸根結底還是錢的問題。小廠商資金不夠雄厚，背後也沒有爸爸。

就說這麼多，各位看官，選雲服務商，且行且珍惜。

以上個人觀點，不喜勿噴。

正在開年會的ucloud兄弟們，搶抽獎變成搶電源插座，都不容易

伴隨著雲計算的發展，雲計算技術、應急響應機制都日趨成熟和完善。多數情況，雲計算平台都能持續、穩定的正常運行。

不過，比如這次Ucloud14日晚間發生重大故障，癱瘓了將近4小時，耽誤了客戶4小時的生產活動，這已經算是重大事故了。

Ucloud的用戶眾多，其中不乏各行各業的重要企業。4小時的癱瘓，對企業用戶的影響是非常大的，因為每個企業客戶又有很多個人用戶，蝴蝶效應的累疊，造成的經濟損失和信用損失不可估量。

其實，因為天氣或者其他原因，全球各地大大小小的雲計算廠商過去幾年，總是比免不了發生過幾次大大小小的「著名」故障。

現在雲故障不像以前那樣特別頻繁，但它給企業客戶帶來的傷害卻比以前更大了。

前車之鑒後事之師。其他問題大家都說得很多了，我來嘗試從經驗教訓的角度來看看Ucloud這次的癱瘓事件。

首先我們先來看看Ucloud給出的處理措施，是按SLA進行百倍賠償。

l SLA承諾

SLA是個什麼概念呢？

SLA通常是指服務提供商對用戶提出的可用性承諾，如99.99%的可用性承諾，表示在一年的時間裡，服務提供商會有萬分之一的時間（52.56分鐘）有可能不能正常提供服務（如基礎架構的升級，機房的搬遷，各種的故障等），而超出52.56分鐘之後，按照購買服務的價格進行百倍賠償。

百倍賠償基本是一個業界規範，算是一個責任的態度，無論什麼原因導致的，先對未達到的承諾進行賠償。但對用戶來講，造成的損失可能比這個賠償要多的多，並且有些損失是不能用金錢來衡量的。

眾所周知服務是端到端的，端和端之間有多個環節。包括但不限於：服務自身BUG、雲廠商平台問題(如伺服器硬體、平台軟體BUG、雲廠商自身內部網路異常等)、客戶側網路問題(俗稱運營商網路，最遠端就是各位家裡的寬頻接入網哦)。

這其中中間無論哪個環節發生異常都可能導致服務不可用，所以故障也是避免不了會發生。

尤其是中小廠商，因為某些原因，硬體或者技術上存在不足，可用性也不那麼好。所以當企業把IT基礎設施託付給雲服務商的時候，千萬別忘了你才是這些系統的主人。

美國知名電腦周刊雜誌eWeek 資深科技記者Mike Elgan曾表示：「雲計算不是萬靈丹，我們不過是租別人的計算機而已。因此自己數據中心可能出現的問題就算是轉向了雲計算也依然存在」，他建議「企業有自己的替代方案很重要」。

Netflix的技術人員認為，不論在何種情況下，每個系統必須靠自己存活。所以，他們在設計系統時考慮了其所依賴的其他系統的故障並且能夠容忍故障。

那麼作為用戶，該如何在現有SLA承諾的基礎之上，提升自身應用的可用性呢？

主要有兩個方面：並聯和多可用區。

1. 並聯

可用性的傳導，有一個基本特性：串聯的環節，可用性是相乘的，如A，B兩個環節可用性為SLA1，SLA2，則A，B串聯時（指有依賴關係），則全系統可用性為SLA1*SLA2，假設都為90%，則系統可用性最終只有81%；而如果兩個環節是並聯的，則兩個環節都失效，整體服務才失效，可用性為 1-（1-SLA1）*（1-SLA2），同上都為90%的情況下，整體系統可用性為99%。

理解了這個概念，我們就能知道上述矛盾的解決辦法之一，就在於服務商和用戶，都在可能的情況下，去增加並聯的環節。

服務商通常做法有基礎設施的物理冗餘（UCloud的光纖冗餘，2+1備份，磁碟的Raid10），軟體層面的冗餘（數據的三副本，資料庫的主備等），以及服務商的代碼質量提升，灰度發布驗證等。

而對用戶來說，則可以考慮在各個層面進行並聯的部署。

2. 多可用區

提高自身應用可用性的方法還建立在可用區的概念之上。

縱觀本次UCloud的癱瘓事件，可以發現大量受癱瘓事件影響的客戶，基本都是沒有跨可用區來進行部署和災備的。單可用區其實不可靠。

那麼什麼是可用區呢?

AWS的定義裡面，Region是一塊特定的地理區域，而每個Region里會包含有多個不同地點的可用區。通俗點講，北京是一塊區域，而北京的亦庄機房，大興機房則可以分別成為一個可用區（當然也可能在同一個機房會分為兩個可用區）。可用區之間基本都會通過光纖直連，通過內網網路通信。

所以為了提高自身應用的可用性，在基礎設施層面，可以考慮多可用區（規避機房失效，如本次的UCloud故障），多Region（規避地震等地域性失效，以及提供就近服務用戶的能力），多雲（規避雲供應商的整體服務失效），多實例（規避常見的硬體故障），負載均衡（規避單機故障），資料庫主備；

而業務系統層面，1. 設計之初考慮業務系統盡量模塊化，每個模塊之間松耦合，用更小的代價來代替失效模塊（只需要重新部署失效模塊，可以更快速恢復）； 2. 提供受限服務的能力，某些環節和模塊的失效，還能提供受限的功能。

為了提高可用性，需要客戶在使用的時候，單可用區自己做availability，跨AZ做冗餘，達到2+1經典「可用性架構」。

---------------------------------------------------------------------------------------------------------------------------------

另外值得一說的是，其實這次Ucloud的癱瘓事件，也說明了一些客觀問題，包括但不限於：

1. 國內大興基建的事實，基礎設施的不完備，供電線路的單一，給雲商帶來了困難重重；

在此次Ucloud的四小時癱瘓事件中，光纖理論上是在地下的，在北京這種電線杆上的光纖非常上了，也就是說肯定不是三大供應商的，這種老的地上光纖故障率非常高，未來故障可能還會源源不斷的來。其次，兩個小時定位光纖這個服務商能力很差。

這一點問題要求企業投入足夠多的資金，對資金不太充足的中小雲商是個挑戰。

2. 國內雲計算用戶，對於雲計算的不理解，也導致了原本很多可以規避的失效，變成了現實；

3. 提升服務的可用性，是需要雲服務商和用戶雙方共同努力的，一起協同。Ucloud這次暴露出一些問題，比如架空線路，不是雙鏈路，比如，物理上沒有冗餘備份，實在需要改進，這次也是一個警鐘。

作為曾經的雲計算從業者，心有戚戚。希望各大雲商有一天能真正做到99.99%甚至小數點後更多位數的穩定性。

進入2017年後，水逆的我司每天都過得很慘……

去年開始逐步搬到租用 UCloud 機櫃的主力物理機房，小公司單數據源全容器化架構。雙路光纖接入，然而並沒有什麼卵用……

本來今晚技術部約好一起玩個桌游吃個管氏烤翅沖沖喜，結果從下午起斷斷續續的鏈路報警就預示著晚上的杯具。實在餓得受不了的我部幾個人，樓下吃了頓烤鴨就開著 10W公里租來的5.6米長老 GL8 在三環上狂飆送餐給公司留守同事……

偌大一個吳鐵強辦事處的同事這次來北京還真是在各種加班哇……

從現狀上來看，UCloud 內網層面完全斷開，外網層面也完全斷開，這一段時間裡面機房是完全的孤島。但是下午我們就已經檢測到至少有一次4分鐘持續時長同等故障了，講光纖挖斷那是可能的，但是同時兩條？在年會的這個時候？概率也太小了吧。

而且作為雲服務商的主要機房，沒預留備用的熱備線路或者跟機房值班人員溝通接入第三方線路緊急救急這個，有點理解不能。

所以要麼

1. 「獨立」雙鏈路光纖騙了我們，在鏈路的某個點上是單點，比如鏈路復用。

2. 真是撞了大運…得去雍和宮拜拜…

至於是1還是2，是有意還是無意，我們也不知道，也不想知道，但是只是賠償個服務損失費還是不太夠吧。周六高峰期晚上，我們這一秒鐘幾百萬上下 GMV 的四捨五入那是一個億啊，全沒了。後續商戶和客戶的處理也不是什麼容易事，恢復不久大面積的工單就已經報上來了。

考慮到以後的話

1. 還是要多雲，防止這種小概率事件發生，同城雙活並不是什麼比較難的事情。

2. 數據儘可能做主從同步，分鐘級的切換也比乾等一晚上要好，事實上今晚我們就是缺了數據源只能被動的等待恢復。

根據目前 UCloud 給出的消息，是 B 區機房與北京匯聚點的兩對光纖連接中斷，但是具體是為什麼中斷官方沒有給出原因，有路邊社消息稱是施工隊挖斷光纖。

我在 UCloud 上有伺服器，根據我使用的阿里雲的 Ping 監控，其實從今天中午開始網路就出現不穩定的情況：

12:01 ~ 12:09 左右，約 8 分鐘（三個監控點報警，丟包 100%）
12:14 ~ 12:17 左右，約 3 分鐘（兩個監控點報警，丟包 100%）
12:46 ~ 12:49 左右，約 3 分鐘（三個監控點報警，丟包 100%）
16:56 ~ 16:59 左右，約 3 分鐘（三個監控點報警，丟包 100%）
17:38 ~ 17:41 左右，約 3 分鐘（三個監控點報警，丟包 100%）

然後就是從 18:57 分左右開始的，已經持續了三個多小時的故障。

個人認為，光纜被挖斷不太可能出現這樣的情況，有可能不是物理故障，而是邏輯層面的故障。其實 UCloud 網路一直不太穩定，我自己也有想換雲服務商的打算，不過考慮到遷移太麻煩，就沒有實施。

這鍋看來還是要 UCloud 自己來背，不管光纜是不是真的被挖斷，UCloud 自己內部的鏈路沒有在物理層面做冗餘，這本身就是很大的問題。

這次事件給我們的教訓有兩點：

1. 一定要在不同的雲服務商上做熱冗餘，隨時準備切換。

2. 早退 UCloud 早保平安。

看來我得開始做遷移的計划了。

不知道啥原因，我們四點半就開始了斷了了。。

本文充滿了不懷好意的假設，so，估計你們也不信，當然我自己也不太相信。

UCloud-中國最大的中立雲計算服務商 ucloud可用區分布

UCloud可用區 - 構建跨機房容災架構的基石 ucloud可用區設計

解密「雲計算的太祖長拳」系列之一「膽」：基礎網路改造與新架構 - 知乎專欄 ucloud 基礎網路設計

2017年1月14日晚上18:54開始，uCloud的北京機房出了什麼狀況？ - 雲服務 - 知乎

這個是故障說明

本文關於ucloud的認知就從上述4篇文章獲得

看看ucloud架構

從圖中可以看出，同一Region內的任意一個DC都是通過多條專有光纖和兩個POP點相連。外網通信則是通過在POP點和各個上聯運營商之間建設的BGP 線路來保證的。任意兩個DC之間都有兩條全量冗餘的邏輯線路（物理鏈路會依照現實的帶寬和冗災需要進行擴容），因此即使一個POP完全不可用，DC和DC間，DC和Internet間的網路連通也能繼續保證。

這個是ucloud的描述

任意一個DC都是通過多條專有光纖和兩個POP點相連

假設DC1 DC2 DC3 分別代表北京2 A B C 三個可用區

18:54，監控到北京二區域可用區B到北京POP點線路告警，可用區B的跨可用區互訪中斷、公網中斷，北京二區域部分移動數據中斷

為什麼北京2B 到pop點的線路出現問題，會導致網路中斷，難道到2個pop點的線路全部中斷了嗎？還是說只有一線？

同時注意一下

北京二區域部分移動數據中斷

什麼為什麼北京2B跪了導致移動會中斷，說明了一個問題，至少某些流量不走POP點。

20:30，傳輸供應商確認中斷點在中國移動數據中心外3km處

原來如此北京2b 線路中斷與pop點失去連接，說明北京2b是移動機房。

同時搞清楚了一個問題，pop點承擔了全部的入流量和部分出流量，這麼做是價格因素，還是減少POP點壓力，或者說，相對於POP點出流量會節約幾毫秒。

為什麼說承擔了全部的入網流量吶，首先按照架構圖上的可用區內ip可漂移，則必須藉助pop點來實現，同事如果各個idc有獨立的入網口的話，即使pop點斷了，北京2b的移動至少是可達的，實際上是中斷了，所以，北京2b的只是作為移動鏈路的出口，而非入口。

那麼關於此次故障的原因可能會有如下幾種情況

1.現行架構並非，所講架構，文章中描述的架構僅僅是一個理想的架構，實際上，實施的時候並未落地，比如只有單光纖

2.軟體問題，導致了，進出北京2b的數據包無法正常處理，導致網路中斷

雖然可能出現了兩根光纖同時中斷的情況，但ucloud應該不是，公告中描述的，距離移動機房3公里外，就算出機房的兩根光纖很近，但到了3公里外，兩根的距離應該離得也比較遠了，所以不會同時中斷。

由於運營商施工原因導致，UCloud BGP B機房至北京核心匯聚點的兩對光纖同時中斷

這個說明了可用區B是單機房，ok這個說明不了什麼，可用區單多並沒有影響，

可是他說運營商施工，導致兩條光纖同時中斷，這尼瑪是怎樣的施工。

技術沉澱還是差阿里雲跟騰訊雲一點了~~ 不過態度確實很好還一起幫忙排查問題

之前有個遊戲服務阿里雲我放測試環境 ucloud我放生產環境，ucloud上服務老是莫名內網連接中斷排查了好久各種折騰都沒解決，惹毛了直接把服切到阿里雲上面了一直沒出問題