中國電信為谷歌背鍋?揭秘本月幾樁離奇宕機事故
宕機月月有,本月特別多。
比如今天,又有兩個互聯網巨頭被爆出現宕機事故。
早間消息,蘋果App Store出現全球性宕機!有網友在社交網絡媒體上反饋,自己的App Store出現了打不開的情況,隨后這個情況蔓延到iTunes Store上,不過那時只是國外用戶反饋,所以跟國內用戶影響并不大。
隨后,這個問題開始蔓延到國內,不少iPhone、iPad用戶都表示,自己的App Store出現了打不開的情況,至于是什么原因并不清楚。對此,有外媒報道稱,App Store和iTunes Store今天出現了宕機,而且影響是全球性的。
顯然蘋果也注意到了這個問題,目前他們已經修復了這個情況。根據宕機追蹤器DownDetector給出的看,報告故障在美國東部時間晚上8點開始出現。
另外,據彭博社報道,隨著美國傳統“黑色星期五”促銷日的臨近,Facebook的廣告購買系統在本周二發生了故障。
根據媒介購買者等知情人士透露,美國當地時間周二早些時候,企業和廣告公司用來購買Facebook廣告的系統發生了宕機。目前該系統正在恢復,但運行速度仍然很慢。
Facebook發言人在電子郵件中表示:“正在開展的廣告營銷活動不應受到影響,廣告將繼續投放。然而,創建新營銷活動,或是對現有營銷活動進行調整的廣告主可能會遇到問題。”
此次問題發生在“黑色星期五”來臨之前,這是一年中美國最重要的購物日之一。廣告主目前正在社交媒體、電子郵件和網站等渠道大舉投放廣告,以吸引人們在此期間消費。
這兩起宕機事故,目前宕機故障報告還未出現,具體宕機原因還未可知。不過除了今天的宕機事件,本月已經有不少互聯網巨頭因各種奇葩的理由而宕機,比如騰訊云、谷歌、百度等。
谷歌網絡服務宕機,卻讓中國電信背鍋
北京時間11月11日,谷歌旗下的云服務、YouTube等網絡服務在全球范圍內均發生了數小時的宕機,外媒稱因遭到來自中國電信IP的BGP劫持導致故障發生。雖然這次事件為中國電信帶來了“寶貴”的谷歌流量,但是黑鍋我們真的不背。
本次事件是由一家名為Main One的西非電信公司進行網絡更新引發的。Main One是位于尼日利亞拉各斯的一家商業ISP供應商,在葡萄牙和南非之間運營著一條海底電纜。
該公司表示:由于更新時采用了錯誤配置,導致Google的流量被重定向至中國電信,持續時間長達74分鐘。
在這期間,全球范圍內的用戶再嘗試連接Google、YouTube、Spotify和Nest等網絡服務時,流量會通過一個名為TransTelekom的俄羅斯ISP供應商重定向至中國電信,中國電信無法解析這些莫名其妙的流量和請求,因此導致宕機事件。
騰訊20歲生日之際,騰訊云DNSPod 被惡意攻擊了
11月9日晚間到凌晨,DNSPod出現問題,遭到大量用戶在微博、朋友圈吐糟。恰巧昨天是騰訊20歲生日,因為這事兒,有點兒掃興,有人故意而為之?
系統安全不能忽視,第十三屆中國產業年度大典特設智能運維安全論壇,探討安全技術與應用。
以下是騰訊云對11月9日DNSPod域名解析失敗的技術復盤:11月9日21:46至11月10日00:06期間, DNSPod出現云解析服務異常,導致用戶域名解析失敗, 給用戶業務造成比較大的影響,對此我們表示誠摯的歉意。同時, 我們對本次故障的整個過程進行了深入的技術復盤。
并解釋了此次的故障原因:部分基于DPDK的NS服務器集群被大量惡意請求包攻擊,導致部分域名解析服務異常, 技術人員通過緊急封堵后恢復。
被DNSPod連累宕機的百度
而在11月9日上午,多名網友反饋稱百度網站疑似崩潰,移動端和網頁端均無法打開。
針對此事,下午,百度官方微博也作出了回應,并給出了解決方案,百度表示,是由于運營商DNS的問題影響了部分北京地區的聯通網絡用戶的正常訪問。經過雙方的緊急處理,目前相關問題已經解決。
GKE全球大宕機長達19小時
11月9日,Google公有云下的Kubernetes服務(GKE),從清晨4點30分開始,宕機將近19小時,直至當日深夜11點才完全完成修復。但是在修復過程中,卻因為GCP的不穩定性,而使Google被大量網友詬病。
根據Google所發布的公告,GKE服務從11月9日清晨4點30分起,Kubernetes節點池構建功能出現異常,管理員無法通過Cloud Console UI創建新節點,Google隨即開始進行調查故障原因,并開始處理。
到11月9日清晨5點57分,Google表示,受到影響的企業用戶,可以先改為使用GCP內置的gcloud command,創建新Kubernetes節點。
但11月11日,在知名開發者Hacker News網站上,網友發布《Google Kubernetes Engine連續第三天服務中斷》表示,他目前正在評估兩個獨立的Google GCP項目,發現自提交支持請求以來,即使在40多個小時的時間內,他們也沒有收到GCP支持的響應。
相關人士針對這些疑問,使用Google故障聲明進行解答:通過云控制臺用戶界面創建Google Kubernetes引擎節點池的問題已于2018-11-09 14:30美國/太平洋地區解決。只是Google忘了將其標記為如此,因此才會引起誤會,讓大家認為此次宕機事件沒有及時進行解決。
實際上,經過10個小時的維修,在11月9日下午2點30分時,Cloud Console UI建立節點池功能已經恢復正常。
以上梳理的宕機事故,故障緣由都較為奇葩,不過本月一系列的宕機事故也為各公司帶來了不少經濟上的損失。
早有調查顯示表明,網絡宕機損失已增加了38%,從2010年的平均505,502美元增加到2015年的740,357美元。企業和用戶的宕機事件的損失變得更加昂貴,并增加企業的網絡依賴性,意味著這一趨勢將繼續上升,其中損失最高的行業包括金融服務、通信、醫療保健、電子商務,以及托管數據中心。