如何評價《AWS S3 雲存儲莫名消失：各大網站和 Docker 紛紛中招！》？

01-14

AWS S3 雲存儲莫名消失：各大網站和 Docker 紛紛中招！

今天終於等到了官方的事故報告。

Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region

總結一下，誤操作的命令導致大量伺服器下線，直接影響了S3兩個最重要的子系統：用來記錄

對象信息的index 系統和用來分配空間的placement系統。由於下線數目過多，導致兩個子系統需要重啟（兩個系統可以在少量節點下線時自行恢復，但多了不行），大概很多年沒重啟了，重啟要做很多safety check 導致花了很長時間。提出的解決方案一個容易：改進命令工具，一個需要大量工作：講系統拆分成更多互不干涉的小系統。

再談一下感想：

1. 報告出來的還算及時，態度也誠懇。

2. 失敗的畫面是似曾相識，相信每個這一行的碼農都能講出類似的故事。我也有好幾個。再次引以為戒吧。

3. 解決方案也很靠譜。但第二個方案恐怕不是一朝一夕能完成的。報告中也提到，其實開發人員也早有計劃想做。不僅讓我再次感嘆，我們有時不得不面向事故編程啊。S3的兄弟們，抓緊時機多提一些高大上的方案，把自己想做的都提了。這個時候沒人出來瞎BB了。

========================分割線==================================

AWS All in 用戶，身處重災區us-east-1

二月二十八，艷陽高照，來到公司，吃完早飯，拿了一杯新鮮出爐咖啡來到工位，計劃著一天的工作，掃了一眼昨天那個push到staging上一千多行的commit運轉的一切正常。於是點下了部署按鈕。畫面切到北方一千公里外的union station，另一個面目模糊的民工，大概也在同樣的早上，也點下了部署，向世界展示了碼農的力量。

咖啡喝完了，點開環境，咦，怎麼部署失敗，看一下log，S3出錯，這時Slack的window也一閃一閃，很多人也遇到了錯誤。AWS的技術服務人員也在Slack中肯定了S3出現了問題。這時時鐘指向了美西上午9:54分，

10點10分，大家都意識到這事情大了

10點24分，AWS的服務人員告之衝擊範圍很大，沒有ETA什麼時候能修復， HackerNews已經炸開了鍋

11點 AWS的服務人員通知root cause找到了，大概要一小時恢復

12點40分 AWS的服務人員說，讀操作在恢復，寫操作要更長

12點55分 AWS的服務人員告之寫操作開始恢復, 看看我們的log還是有錯。

吃完中飯，回來看了一下log，好像恢復了，重新部署了代碼，順利通過。但隨即發現Ec2 API和Autoscaling都不工作

1點54分 AWS的服務人員告之S3應該恢復。Autoscaling還是不工作，隨即又發現AWS Lambda 也不行

2點48分 Autoscaling 和 lambda 同時恢復，世界又清凈了

============================分割線=============================

日誌記完了，談談體會

1. 雲計算就是填坑填出來的，S3已經是很很reliable的服務了，但是今天又一次告訴我們革命尚未成功，同志還需努力。使用其它那些坑還沒填完的雲服務，一定要慎重又慎重

2. 做服務一定要分析critical path和failure model。AWS服務公告欄就是個例子，今天成為了大眾的笑柄。

3. 等待AWS發布事故報告。但為什麼us-east-1 所有的availiability zone 全垮了。這一定是有軟體設計和流程的問題。挖土機可沒法背鍋

4. 大潮退去，誰沒穿褲子，沒有自家的HA，一目了然。 dxxxxxhub，說你呢

5. 要不要做cross region 或cross cloud provider 的HA。真是一件頭疼的事啊。這事平時吃力不討好，可關鍵時候能救命，可轉念一想，就算我做了，我用呢那些其他第三方的服務沒做，也是抓瞎啊，唉，再想想吧

說了這麼多，我還是堅信雲計算最終會越來越穩定的，但作為一個用戶，要時時刻刻想清楚自己的plan B是什麼。

說點題外的

記得剛開始到處是雲主機的時候，當時好高興，簡直覺得雲廠商就是背鍋俠，有問題全是他們的。

後來。。。。各大廠商各種宣傳，可用性，各種質量高，各種 999999 然後老闆跟我說，

XX雲怎麼會出錯，肯定是你們的問題，扣獎金。。。。

老闆已經被各大廠商教育成了，雲萬能，什麼時候都不會壞。。。。崩潰

早上正在寫cc作業的我還以為我一行代碼把aws弄炸了...

亞馬遜今天公布了調查結果, S3團隊在解決一些付款系統的小bug。一位工程師本來想移除一小部分伺服器，沒想到失誤搞大了，把一些重要的系統也刪了。

-------

評論里好多知友指出我的數據有問題，因此我上網查了一下:

Amazon S3:

99.99% availability (4 9"s)

99.999999999% durability (11 9"s)

各位讓我意識到回答問題要嚴謹，對內容負責。

多謝諸位，共勉

-------

亞馬遜真嚴謹 they only guarantee 99.9999999% availability

伺服器掛了兩個小時之後，aws官網的dashboard顯示所有伺服器還是全綠色正常狀態.. 於是他們花了一個小時把dashboard的bug修好...

# fake news # the page is cached

大家都是碼，寫bug 誰不會

aws儼然變成single point of failure

我個人沒有任何看法。

以下是美帝同胞的看法：

以及，

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

當然我並沒有諷刺公有雲的意思，你們不要聽風就是雨，想搞個大新聞。

公有雲比私有雲不知道高到哪裡去了。

以上。

「靠，你們的服務怎麼又掛了！」

「您好，我們的服務現在並沒有掛」

「那老子現在這是什麼情況！！」

「您正在體驗我們新推出的雲增值服務"Increased Error Rate"」

怪不得今天收到aws銷售發來的道歉信，我還想有什麼好道歉的。。。。

所以說一定要選擇大廠的產品，用了s3你說全地球都掛了，我有什麼辦法，你要是用了x牛雲存儲，我靠你要是掛了，這個鍋就是你的。

或者你苦口婆心的讓公司用了mysql pg這要是跪了或者抗不住了，這就是你的鍋，如果你用了oracle，跪了就請專家，專家解決不了，你可以說，對比起這是地球上最好的關係型資料庫產品了，沒辦法，你的要求已經突破地球承載極限了，所以沒辦法滿足。

我們選擇產品的時候寧願花更多的錢去買的不是產品本身，而是他身上的防背鍋保險。

你說我mysql做了分庫分表，做了讀寫分離，我擴展牛逼，好那你就做。

你說我用了多家雲服務，我多區業務部署，做了容災，好你做。

後來你發現如果業務服務穩定老闆會指著你的鼻子說，只這玩意有毛線用，還是業務部門有用，養你們就是白花錢，還有可能就是，你精心設計的容災方案，演練時各種完美，一有災難，你該跪還是得跪。老闆一樣認為白花錢。

最後對存儲不可用就不可用唄，一堆非結構化數據，丟了又能怎樣。

雲計算老師可算找到話題了

我們學校在線系統也掛了

只想提醒一下各位答主： S3 的 99.999999999% 是 durability 不是 availability ，別弄混了。

我就記得之前我寫過一篇回答諷刺「工業級代碼」的，因為他們號稱自己炸天炸天炸天，99.999999999 的可靠率，隨便掛

嗯，看來是隨隨便便就掛了。。。

寫工業級別代碼是怎樣一種體驗？ - 蕭井陌的回答 - 知乎

公有雲的可靠性是高，但是萬一出了問題就不是你能控制的了

這樣的問題，理論上應該是不會發生的，尤其是這樣口碑的服務商。但它就還是發生了

海嘯會被淹，地震房子會垮。你的網站或許有災備，AWS和GCE/AZure各放一份，但是你的網站依賴的其他服務是否也是這樣呢？

所以沒啥好評價的。如今互聯網的複雜度是如此之高，想要在這種級別的災禍裡面倖免，你準備好付出相應的代價了么？只是把自己的雞蛋放到不同的籃子里已經遠遠不夠了。

好幾年前我有一個觀察，Internet每年都要出次大故障，可靠性在99.5%左右的水平。現在這個時代，Amazon和CDN等廠商就是互聯網的核心環節，只有99.5%左右的可靠性就反映在他們身上了。

看到這個新聞，只能呵呵一笑，老外就是會搞…理由也找得很是自然！

你會發現S3掛了，北美滿天下的運維不是哭喪臉的搶救業務，而是點杯咖啡寫寫段子？

為什麼？？

S3存非結構化數據，圖片音頻，丟了就丟了who cares? 可用性比數據一致性重要得多的多得多。既然S3已經掛了，除了寫段子還能咋打發時間？

要是AWS EBS丟數據了。。。呵呵呵呵，畫面太美不敢看。

想想前幾天才打出來的 rm -rf ./* 我表示深深的理解。

有時候並不是手誤。是鍵盤布局的鍋。

aws馬工一枚，事發當天就知道了事故的原因，可以說是「臨時工乾的」，今天s3發布了公開的原因：Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region

簡單地說，一枚馬工同仁寫了一個腳本準備刪除幾個host，但是這個腳本不小心犯了個很大的錯誤，最終把幾乎s3在us east 1區的所有host都刪了，類似於當年nvidia的死亡腳本：一個空格引發的悲劇（詳解如何看懂悲催的技術人員冷笑話）。這個腳本價值。。好幾個億啊。。。

這個事情不禁讓人感嘆，誠然s3理論上很穩定，但是天災當不過人禍，就像絕大多數的空難一樣，避免人為的故障可能更難。我相信刪host的許可權只掌握在少數幾個人手裡，但是這個腳本的出現並且執行成功了，這個問題真的是值得拷問。對於manager們和任何的從業人員，希望不要責怪人為事故，因為人為的錯誤不論怎麼說都是難以避免的，但是在開發項目的時候，要謹記，事故是常態（包括人為），程序必須考慮如果事故發生了，或者人為事故開始了，可以怎麼避免，如果發生了造成大新聞了，可以怎麼挽回。

這麼一想，任何準備離職的s3馬工，都可以在離職之前搞個大新聞啊。