Quantcast
Channel: 電腦王
Viewing all articles
Browse latest Browse all 6062

Facebook當機事故,告訴我們上雲端不是企業唯一的答案

$
0
0
公共雲、私有雲、混合雲或傳統資料中心,如何選擇應該按照不同企業、不同資料隱私敏感度、成本預算等來綜合考量。

前陣子網路巨頭Facebook發生了長達6小時的全球大當機。 

據說,這是Facebook創辦以來最嚴重的一次網路事故,除了Instagram、Whatsapp、Messenger這幾大社群必備平台,虛擬實境平台Oculus的遊戲,部分企業端服務以及很多需要聯動Facebook帳號登錄的平台都上不去了,就連Facebook公司的內網也受到影響。要知道,這裡可彙聚了全球最厲害、薪酬最高的一大批程式設計師啊! 

網路公司當機,並不是一件很稀奇的事。 

更早的時候,中國Bilibili線上串流影音平台就因為伺服器突然故障,一度崩潰,大量使用者「流浪」到其他網站,巨大的流量洪峰又讓AcFun、豆瓣、晉江等平台也連鎖式癱瘓了,各公司程式設計師們都感受到了被當機統治的恐懼,一度登上熱搜,被網友戲稱為——網路內卷之《誰也別想睡覺》。 

Facebook當機事故,告訴我們上雲端不是企業唯一的答案

同樣是當機,為什麼Facebook就面臨著「非死不可」的吐槽聲,而不是一笑了之呢? 

這可能是因為Facebook龐大的產品生態,已經不再是娛樂的一部分,而成為了數位生活的基礎設施。 

尤其是在疫情之後,許多企業服務、辦公教育等都依賴網路來完成,服務中斷會直接導致嚴重的經濟損失。 

在WhatsApp(Facebook旗下一款即時通訊的軟體)的官網就顯示,巴黎的醫療人員會在WhatsApp 群組內更新醫院病床、資源等資訊;印度企業依靠WhatsApp售賣產品;巴西政府、醫療和教育系統都透過WhatsApp提供終端服務,像是接收考試成績、遠端預約掛號等等。 

可想而知,作為數位化基礎設施的網路服務,一旦中斷,將連帶產生不少衍生災害。 

而面對當機,我們第一時間總會想到雲端服務商,雲端中斷導致的問題,網路企業自然也是受害者。 

不過,像Facebook這樣的巨頭,往往核心業務和資料都放在自家資料中心的伺服器上。這次當機之後,就有不少工程師坐飛機到位於加州的主資料中心參與維修,科技媒體The Verge還曾爆料,因為門禁卡失效,工程師們使用切割機,鋸開了資料中心的伺服器鐵籠才能進去維修。 

Facebook面臨的挑戰,也是許多網路巨頭的縮影:一方面,作為數位化基礎設施,最大程度地保證基礎設施的穩定性、可靠性,是巨頭們應盡的社會責任;同時,又不能將希望全部都放在雲端服務上,增加了IT系統的複雜度和運維難度。 

這次大型當機事件也掀開了全面上雲端的另一面,為什麼網路巨頭們都沒有把雞蛋放在一朵雲端上? 

不是唯一的答案:雲端服務的另一面

網路公司,可謂是雲端服務的先遣部隊。在傳統行業還不知道什麼是網路浪潮、什麼是雲端的時候,網路公司就成了雲端服務商的高價值客戶。 

一般情況下,網路企業會將行動應用、電商之類前端流量業務放到雲端上,以節省自建機房的高昂成本。 

不過,別看網路企業上雲端這麼積極,它們可是「狡兔三窟」,一邊遷移上雲端,一邊也有本地設施。2018年,Facebook斥資10億美元在新加坡打造了亞洲首個資料中心,這也是它在全世界的第15個資料中心。等於一邊從發電廠買商業用電,但也在造自己的發電機。 

這兩年來,上雲端浪潮如火如荼,出現了一些觀點,認為雲端服務會徹底消除自己建置的資料中心,但事實上,越來越多的企業在嘗試讓部署資料中心上的舊應用升級,而不是將一切業務都雲端化。 

甚至有企業IT人員說,他們可能會讓自家的資料中心永遠運轉下去。 

Facebook當機事故,告訴我們上雲端不是企業唯一的答案

要知道,資料中心幾乎佔據了企業網路支出的最大組成部分,每年需要支付不小的租金和改造、維護費用,這無疑會增加額外的成本,為什麼網路企業依然堅持這麼做呢? 

第一,傳統機房可能會當機,但上雲端也未必完全穩定。 

雲端服務雖然不需要維護傳統機房,資料儲存和運算都在雲端,但幾乎沒有哪個雲端服務廠商實現過100%的連續性,都出現過計畫外的停機。2017年,IBM、AWS、Google、Apple等主要雲端服務提供者也都經歷過服務中斷,將Netflix、Quora、Reddit和 Foursquare等熱門應用停擺,影響了大大小小的企業。 

第二,成本效益很重要,但資料資產安全更重要。 

雲端服務能夠避免維護機房帶來的麻煩,但除非付費搭建私有雲,否則依然要與其他雲端使用者共用硬體資源,這就使得企業無法對遠端硬體擁有足夠的控制權。任何擁有憑據的人可以從任何有網路連接的地方存取雲端資料,也意味著廣泛的接入點如果不能在每個位置都部署安全措施,那麼傳輸的資料風險也很大。 

要論最安全、最可控,還是要屬自建資料中心,只允許擁有憑證和設備的人才能存取本地網路,可以讓企業完全控制資料,以及基礎硬體,更適合那些業務複雜多元的組織。 

第三,多雲/混合雲有幫助,但無法徹底解決顧慮。 

既然這樣,不要把雞蛋放在一個籃子裡,一次用兩個甚至兩個以上的雲,不就可以在出現故障時快速啟動「備胎」嗎?道理雖然如此,但多雲部署的成本很高,並且依然不能完全防止短期終中斷,有時還需要人工參與,並不像我們想像的那樣能夠瞬間絲滑切換。 

比如Gov.uk 就在Amazon的 CloudFront服務上運行了備份 CDN, 但需要人工干預才能切換到備份。  

Facebook當機事故,告訴我們上雲端不是企業唯一的答案

而適合建設雲端基礎設施條件和環境的地方大家都喜歡,於是所有的服務商都會挑上該地,進而導致幾家雲端服務商要停機就一起停的尷尬。此前,Amazon和微軟在愛爾蘭都柏林的雲端設施,就因為遭遇雷暴天氣,讓使用AmazonEC2和微軟BPOS服務的客戶都當機了。 

另外,並不是所有的雲端都是完全開放、可互動操作的,這時候為了用好每一個雲端平台,企業還需要透過多個系統來配合,增加了額外的支出和運作維護的難題。 

所以說,只有足夠可靠的雲端服務,才能打消客戶的顧慮,從本地容災備份、混合雲等其他方案,轉變為全面依賴雲,並且只依賴某一朵雲。 

當許多人呼籲著,把雲端看作萬能神藥的時候,必須考慮一個前提:雲端服務怎樣才能變得足夠穩定和安全?而這一點,似乎跟現實還有點距離。 

安全力Max:Facebook的冗餘啟示錄

歸根究底,想要業務更可靠,每個組織都沒有「一刀切」的解決方案。 

公共雲、私有雲、混合雲或傳統資料中心,如何選擇應該按照不同企業、不同資料隱私敏感度、成本預算等來綜合考量。 

簡單來說,傳統資料中心成本高,控制強,很適合那些已經在IT方面進行了大量投資,對資料隱私要求謹慎的組織,所以像Facebook這樣涉及到全球幾十億使用者資訊的網路企業,資料中心是必須配置的。 

而大多數企業,完全沒有自己搭建伺服器的必要。直接上雲端省心又省力,可以快速搭建起網路業務,但過程中必須對隱私存取進行密切監控。 

而即擁有IT 基礎設施的大型組織,但也希望開始雲端之旅的大型企業和組織,可以同時嘗試混合雲,將雲平台的所有優勢都「一網打盡」。不過,跟蹤多個雲可能會比較棘手,往往需要協力廠商的協助。 

Facebook當機事故,告訴我們上雲端不是企業唯一的答案

看到這裡,你可能會發現數位時代業務安全的核心密碼:冗餘思維。分別來自: 

硬體的冗餘,有充足的伺服器保障,如果整個資料中心受到衝擊,資料可以複製到其他地理位置的資料中心上; 

服務的冗餘,利用多個雲端服務商的服務耦合,像是主要雲端服務商停電期間,二級供應商的雲端服務可以作為補救措施,確保業務繼續; 

視角的冗餘,更多資料來源頭也被納入考量中來,比如工業部門常見的邊緣運算設備,感測器、監視器和控制/驅動設備等,就正在成為雲端時代的「新資料來源」,需要被納入到主動管理中來,比如增加DNS(網域名稱系統)解決方案,避免單一DNS中斷或減速。 

VMware的一些統計資料表明,未來五年內,許多組織的工作負載將按 30% 資料中心、40%公有雲,以及 30% 的邊緣計算來分布。 

從這個角度來說,雲端市場還有不少空間可待挖掘,廠商之間的明爭暗鬥還將持續一段時間。 

而企業在數位化過程中考慮雲端服務時,也需要重視三個基本前提。 

  1. 將雲端安全作為優先事項。網路充滿了機會,也意味著無法繼續躲在防火牆背後得到充分的保護,因此安全必須作為重中之重。 
  2. 引入多雲和混合雲策略。如果對雲端安全不瞭解,那麼引入多個雲端供應商可以有效降低被單一雲端鎖定的風險,為雲端策略的後續優化留下空間。 
  3. 優先將前端流量處理業務遷移上雲端。尤其是大量影片和音樂流量的業務,可以遷移到雲端上,靈活擴展頻寬,避免網路使用高峰時回應不及時的情況發生。而一些放在原本資料中心的應用,仍然留在本地設施上。 

Facebook的故事背面,是網路巨頭托舉起國家和社會服務的現實景象,這也使我們反思,一味強調雲端,是不是將數位化想得過於簡單。 

雲端服務產生的變革固然讓人興奮不已,但這並不代表,雲端就會幹掉傳統資料中心,或者某朵雲「獨霸天下」。 

容納共存,在這個基礎上重新定義雲和網路服務,或許會幫我們看清新資訊技術的新模式,以及雲端市場的新機會。

加入電腦王Facebook粉絲團

Viewing all articles
Browse latest Browse all 6062

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>