阿里雲「掛了」事件深度剖析！
防不住了嗎，關注奇速盾
6 月 27 日下午 4 點 20 分左右，阿里雲出現大範圍故障，手機端和 PC 端都無法訪問，時間持續一個多小時，影響範圍包括阿里雲官網控制台，以及 MQ，NAS，OSS 等產品功能。也有用戶反映阿里巴巴、淘寶、滴滴和石墨文檔等產品也出現了服務不穩定的情況，據說金融雲也出現故障。
阿里雲用戶眾多，此次大規模故障可以說是牽一髮而動全身，影響了中國互聯網的半壁江山。
壹
事件起因
6月27日下午，眾多網友在微博發帖，稱阿里雲控制台訪問出現大面積癱瘓、後台登錄不上、包括圖片服務也已經掛掉。
阿里雲官網的部分管控功能，及MQ、NAS、OSS等產品的部分功能也出現訪問異常現象，部分用戶反饋稱手機端和PC端均無法訪問。
網友紛紛留言，吵成了一片。
網友吐糟：畢竟是自主研發的雲，當然有點小脾氣。 評論引爆了網友間的熱傳。受影響的用戶尚未發聲，吃瓜群眾反而炸鍋了。
貳
恢復正常
隨後沒多久，阿里雲在官網發布公告稱，部分管控功能出現訪問異常，經過工程師緊急處理，受影響業務正逐漸恢復正常。
阿里雲官網通告：6月27日阿里雲部分產品及賬號登錄訪問異常通告
【阿里雲】【網路】【異常通告】
異常時間：北京時間2018年6月27日16:21左右。
異常概述：於北京時間2018年6月27日16:21左右開始，阿里雲部分產品及賬號登陸出現訪問異常，阿里雲工程師正在緊急處理中，請您稍後重試。
【異常更新】
北京時間2018年6月27日 17:30
目前受影響的業務大部分已經恢復正常，請您確認。若還有異常，請您跟我們反饋，謝謝。
但18時許，仍然有網友發文反映阿里雲故障。
關於技術上的原因和過程，一位 twitter網友稱：阿里雲的函數計算掛了，導致線上故障。打算馬上降級到本地計算，結果阿里雲的 Kubernetes 也掛了。想著挨個機器手工改一下，發現 OSS 也掛了…整個過程沒有報警，因為 SLS 也掛了。
還有這樣說原因的：
叄
故障說明
對於這次事件，阿里雲官方微博在28日凌晨 12:54公布了故障的情況進展，直接原因是由於"運維操作失誤，導致訪問異常"，改進措施是"復盤改進自動化運維技術和發布驗證流程"。
更表示：對於這樣的失誤，我們沒有借口。我們不能也不該出現這樣的失誤！我們將認真復盤改進自動化運維技術和發布驗證流程，敬畏每一行代碼，敬畏每一份託付。
而對於這份故障說明，網友卻是吐槽聲一片，大多是「又有一個程序員要祭天」或者「招了兩個實習生」等等看熱鬧的心態。也有人說是阿里基礎設施故障，底層網路出了問題，數據不會丟，只是發生了網路的短時間不可用。
但也有很多人對故障的出現表示理解。每一次的故障確實不應該發生，但有時又難以避免。對此，不少網友表示，理解身為同行的程序員們，解決問題比解決人更重要。
資深技術專家陳皓在微博 @左耳朵耗子上也發表了自己的看法：阿里雲出故障了，任何技術人員都會知道故障不可避免，對於故障我們應該給予更多的理解。只是，希望阿里雲不要處理工程師，因為懲罰事故責任人完全沒有意義。系統的錯誤往往來自於團隊的工程錯誤，應該改善技術工程手段或軟體設計，就算是人沒招對，也怪招聘過程，而事故責任人反而是最無辜的……
肆
故障影響
受影響的不僅包括阿里巴巴、淘寶、天貓等自家網站，因其全球領先的雲計算服務平台的江湖地位，故障的出現，直接導致了國內半個互聯網界的癱瘓。
從下圖可以看到，阿里雲出現故障後，相關輿情量呈現「井噴」狀態，在27日18:00-19:00出現了第一個高峰。
28日，媒體報道了阿里雲對此次故障的說明，相關輿情再度上漲，並在9:00-10:00達到第二個高峰。
隨著故障被修復，官方出來說明道歉，輿情熱度逐漸下降。
影響波動
簡單來說，雲服務可以將企業所需的軟硬體、資料都放到網路上，在任何時間、地點，使用不同的IT設備互相連接，實現數據存取、運算等目的。如果這朵「雲」掛了，就會出現文章開頭的情形。
而阿里雲故障影響有多大，我們可以看一些數據。
美國市場研究機構Synergy Research Group的最新研究數據顯示，2018年第一季度的公有雲市場上，阿里雲在亞太地區排名第二。
再來看IDC數據，阿里雲目前在中國公共雲市場佔有率為50%。且查閱資料獲悉，阿里巴巴2018財年第三季度（2017年10月至12月底）財報顯示，阿里雲計算業務連續第11個季度保持規模翻番，該季度內同比增長104%達到35.99億元。2017全年阿里雲累計收入約112億元，是國內首家百億規模的雲計算服務商。
可以說，阿里雲已經成為公有雲IaaS市場的「中國老大」。阿里雲出現任何失誤和故障都可以說是一榮俱榮，一損俱損了。
伍
事件反思
此次阿里雲出現故障，有人驚訝「阿里雲居然也會掛」，但外行看熱鬧,內行看門道。
1
首先，在網路安全市場，大型安全產商往往沖在第一線，但是，他們也有失手的時候，沒有攔住相關的潛在威脅。這一切又像另外一個潛在的威脅，就像懸在頭頂的一把劍，不知道什麼時候會掉下來。一旦發生，我們又該怎麼保證數據的安全呢？
這個時候，災備就很有必要了，作為信息安全的最後一道防線，是救命稻草般的存在。它們不僅是「風景線」更是「生命源」。
而許多企業都過於依賴大型雲安全產商，認為容災備份是高屋建瓴的東西，其實不然。災備發展到現在，已經不僅僅是數據級簡單的一個數據備份，還有業務連續性相關的需求。對於企業來說，好的災備策略，不僅幫助企業減少了事故的應對時間，還能大規模降低企業因為業務終端而導致的損失，提升用戶體驗。
IT系統問題、計算機網路安全技術問題、信息安全管理問題、災害類問題等都是災備所需要應對的範疇，當發生這樣的情況，我們需要有保護數據和整個系統完整性的措施。
2
其次， 對於此次事件，大多數業界人士都提出這樣的看法：系統越複雜，越集中，越容易出故障，而且一旦出故障，還會引起雪崩效應，從而造成更大的損失。從而使更多用戶更偏向於選擇分散式架構來保障自己的安全。
客觀分析，集中式架構在設計上是一個單點，單機不可用即全部不可用，所以集中式的系統只能在停機維護時暫停業務，這一點在很多互聯網場景下是難以接受的。而且集中式架構成本較高、恢復時間較長、業務影響面較大。
而分散式架構是如何提高可靠性的呢，因為分散式架構天然就有多個節點，每個節點出故障的概率均等，所以多節點同時出現故障的概率就小很多，從而實現高可用。
且分散式架構相對於集中式架構在價格成本、安全自主、靈活兼容、伸縮擴展方面有顯著優勢。隨著網路系統需要處理的信息數據量越來越大，分散式架構在這方面的優勢也會越來越明顯。
奇速盾-區塊鏈式分散式架構
充分保障防禦網路的安全
奇速盾作為用戶安全的保險箱，以強大的分散式網路存儲架構，通過眾多公有雲、IDC資源，實現防禦網路的容災備份，不會出現系統性的風險，充分保障用戶安全，為伺服器提供多節點的容災保護。
奇速盾是基於SDN技術和分散式防禦機制獨創的全終端DDOS、CC攻擊防禦系統，以分散式架構、自定義通信協議、256位安全加密實現全面可靠的安全防護，不解析任何協議，採用報文基因技術，百分百確保只有合法報文流入受保護的伺服器。
簡單來說，奇速盾分散式解決方案是多個節點之間實現動態負載均衡，任何一個節點出故障，其承載業務將自動並發遷移至其它所有服務正常雲節點，防護性能好，不誤封IP，保證業務不中斷，實現24小時無死角全方位保護。
守護數據安全，就應該做全套，不僅僅是單純地數據保護，還應該具有相應的災備措施。而奇速盾，從數據級和應用級都提供了相應的防範措施，真正做到了為企業的數據安全保駕護航。
奇速盾圖解：
解決方案
奇速盾通過自身實踐，證明了分散式系統能夠實現網路安全業務所需要的高度一致性與可維護性，並將這種技術沉澱到其雲計算平台上，支撐用戶更好地運用分散式架構和雲計算能力，共同用新技術的力量推進網路安全的發展。
最後，超級科技網路安全團隊認為：
此次阿里雲方面能坦誠的公布問題，而不是用系統抖動或者光纖挖斷之類的詞來敷衍大家，這一點值得肯定。
除了公告提到的增強發布流程驗證之外，超級科技認為阿里雲應重新審視系統整體的隔離保護體系、以及容災備份機制等深層次的問題。並且應該對故障恢復時間偏長，對突發問題處理手段及預案的匱乏等方面進行深刻反思。
雖說任何技術人員都不可能做到100％無故障發生，但事故痛點並不能成為造成客戶損失的由頭。作為雲計算廠商們，我們應該從維護客戶的利益出發，嚴於律己，從平台安全、穩定、服務和技術支持等方面為客戶做好支持，贏得客戶信賴，避免故障類似事件的發生。
失望也好，難受也好，看熱鬧也好，激動也好，以此為契機，提升中國雲服務的水平，以及提升每個用戶對雲的使用能力、對業務可靠性的正確認知、對系統性風險的充分認知和保障才是目前最重要的。
——超級科技
QSY
· 技術大牛都在這裡 ·
Hi，我是奇速盾
從現在開始
我的每一句話都是認真的
如果，你被攻擊了
別打110、119、120
來這裡看著就行
TAG:奇速盾 |