1000＋公司業務癱瘓 損失過億！阿里雲故障真正原因竟是這樣

關注一下，更多精彩等著你！

關注一下，更多精彩等著你！

27日，技術圈又出了攪動全技術人的一次重大技術故障。記得上一次是攜程2015年癱瘓了11小時，損失高達7000W+。

阿里雲是國內最大的雲服務商，服務著製造、金融、政務、交通、醫療、電信、能源等眾多領域的領軍企業，包括中國聯通、12306、中石化、中石油、飛利浦、華大基因等大型企業客戶，以及微博、知乎、鎚子科技等明星互聯網公司。在天貓雙11全球狂歡節、12306春運購票等極富挑戰的應用場景中，阿里雲保持著良好的運行紀錄。

6月27日下午，阿里雲出現重大技術故障，故障於北京時間2018年6月27日，16：21左右開始，16：50分開始陸續恢復。官方給出的故障時間大概持續30分鐘，陸續恢復時間有一個小時多。

在6月27日凌晨時分，阿里雲給了官方說明，最後官方給出的說明是：「我們在運維上的一個操作失誤，導致一些客戶訪問阿里雲官網控制台和使用部分產品功能出現問題。」引發了大量吐槽。

對於此故障的原因，網上傳的各種版本都有，傳的最多的是以下2個版本:

網上流傳故障原因版本一

網上流傳故障原因版本二

小編邀請原美團點評運維架構師&馬哥教育聯合創始人張sir對本次故障解讀：

「至於實習生誤刪登陸服務之說，應該是不存在的，一方面，大型互聯網公司尤其是阿里雲這樣的公司，對工程師許可權有著極為嚴格的控制，因為阿里雲數十萬台伺服器，支撐了全國各行各業千億以上規模的線上業務，不可能讓實習生不熟悉的情況下，給予過高的管理許可權。這是極其不專業的做法"

」對於版本二的說法，說的比較含糊和籠統，我通過內部了解到原因：」

"這個說法跟阿里雲官方通告是比較符合的，本次故障的嚴重程度是非常高的，故障級別定義在S1級別，整個阿里集團的核心業務，以及依託阿里雲的公司，很多都受了影響。"

"對於企業來說，上線都是開發-測試-上線大致都是以下這樣的流程，通常開發會開發出來程序，然後交給測試工程師，測試工程師測試完成後，後提交給運維工程師進行線上服務配置以及業務上線。"

「本次故障，阿里官方說明：工程師團隊，在上線一次自動化運維新功能的時候，執行了一項變更驗證操作，這一項功能在測試環境驗證中未出現問題，上線生產環境中，觸發了一個未知的bug。這個bug後來通過阿里的同學證實：具體原因是一個核心的應用在拉VIP列表的時候，返回了空列表，這就會導致上千VIP被禁用了。VIP = Virtual IP Address，虛擬IP地址，主要作用為集群的負載均衡的入口地址，可通過一個VIP的地址，實現一組業務的訪問，通常也叫集群負載均衡技術。VIP是集群業務的入口，如果數千個VIP被禁用了，可能後端上萬台的服務、應用、資料庫等將直接無法訪問，本次故障盲點，是測試通過了，在生產環境觸發了一個未知bug，導致核心應用在拉取VIP列表時，為空了，導致內部的上千台負載均衡不可用，從而後端的應用也不可達。」

"如圖所示，對於大型互聯網公司，運維技術架構都是多層機構。在內部負載均衡上配置的VIP如果不可達的話，後端的service層和資料庫等內容，都是不可達的，這也是為什麼故障的時候，頁面能打開，但是報錯為502故障，502錯誤一般常為後端伺服器不可用，這也說明了故障的根源所在。阿里的運維團隊故障響應還是比較給力的，數千個VIP配置錯誤，在半小時內從發現，到定位，到故障排除，以及解決，還是挺快的。」

「在一個龐大複雜的架構體系中，會涉及到成千上萬的配置以及幾十種技術的應用，有時候可能因為一條配置的錯誤，會導致整個服務崩盤。而出故障時，一位優秀的運維工程師，可為公司挽回巨大損失。運維工程師目前已經是各家互聯網公司必不可少的重要崗位，是要求有極高的技術能力和心理素質(當出現故障時，耽誤一分鐘損失上百萬的時候，那種壓力是常人無法理解的)，所以這也是，為什麼業內優秀的運維工程師是比較稀缺的。一個優秀的運維工程師或者雲計算工程師，是需要不斷的提升和學習，因為公司的業務需要不斷的完善架構體系，保障服務正常運行，以及服務性能和工作效率不斷的優化和改進。」

阿里雲對於本次故障，還是非常坦誠的：

"對於這次故障，沒有借口，我們不能也不該出現這樣的失誤!我們將認真復盤改進自動化運維技術和發布驗證流程，敬畏每一行代碼，敬畏每一份託付。"

此次阿里雲重大故障，網友們紛紛討論，運維都要背鍋啦。其實，運維工程師這個群體，比你想像的要厲害，如果不是他們為互聯網的業務保駕護航，可能故障遠不止此。所以，對於錯誤，我們應該包容，錯誤是成長的必經之路，更何況，人非聖賢孰能無過?

總結

一直以來國內的雲計算被阿里雲、華為雲、騰訊雲、京東雲，以及國外的AWS霸佔，如果只看國內的這幾個雲計算服務商其實也只有阿里雲用的比較多了，其他幾個服務商都起步相對晚些。國內的大企業要不是強到已經用自己的伺服器了，要不大多數企業用的還是阿里雲或者AWS的服務。

可以說大部分的企業對雲計算服務依賴是極其強的，找到一個穩定性極強的提供商更是一件大事。這件事情至少阿里雲在前幾年做得還不錯。

但是呢昨天卻掛了，昨天下午四五點的時候看到不少微信群先是在說知乎掛了，然後一會兒又變成了說阿里雲登陸不上去了，登陸不上去這事兒讓挺多人挺鬧心的，畢竟有不少人工作對雲服務是強依賴的。後來等了很久大概一個小時才等來了阿里雲的公告：說是上了一個登錄模塊的代碼，這個代碼在線下測試的時候沒有bug，但是上線之後出了bug.

這種情況是經常出現的，也是讓人頭疼的一件事情了，可以說每次改動上線對於開發來說都是不小的挑戰，大的改動上線甚至都是要燒香拜佛的。你永遠不知道你的代碼到了線上之後會出什麼樣的問題，一旦出了bug就是一個不眠之夜。

阿里雲還在公告中申明此次並不是阿里雲宕機，而只是登陸服務掛掉了，同時MQ、NAS、OSS等產品的部分功能出現訪問異常，以及圖片服務。也就是如果你的網站或者app使用了阿里雲的這些服務，在那一個小時內都會出現網路延時、消息不同步、消息載入不了等一系列的問題。這對於用戶來說跟宕機沒啥區別。

昨天那一宕機還是影響不了不少的網站的，譬如：石墨文章、知乎等等。那一宕機估計還讓不少運維開發的同學昨天加了班。

雲服務的優勢顯而易見，方便又便宜，隨著雲服務的普及，以後只會有越來越多的事情放到雲上，這樣對於雲服務的穩定性就是一個極大的挑戰。對於有些服務來說穩定性問題是零容忍的。

所以在未來，雲服務鋪開到各行各業，生活中的方方面面的時候，如何保障雲的穩定，保證不出現類似的宕機情況，將會是對每一個雲服務商的挑戰。

（來源：馬哥Linux運維）

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！