摘要：當和類似的服務(wù)誕生后，對于很多初創(chuàng)的互聯(lián)網(wǎng)公司，簡直是久旱逢甘霖，的持久性，和的可用性爽的不能再爽，于是紛紛把自個的存儲架構(gòu)布在了上。所以，當今早主要是宕機時，整個北美的互聯(lián)網(wǎng)呈現(xiàn)一片哀魂遍野的景象。

事件回顧

美西太平洋時間早上 10 點（北京時間凌晨 2 點），AWS S3 開始出現(xiàn)異常。很多創(chuàng)業(yè)公司的技術(shù)人員發(fā)現(xiàn)他們的服務(wù)無法正常上傳或者下載文件。有人在 hacker news 上問：Is S3 down? 然后迅速得到大伙的確認。

然而，AWS 自己的 status page (https://status.aws.amazon.com) 卻后知后覺，放眼望去，一片讓人喜滋滋的綠油油。就在大伙兒以為自己神經(jīng)過敏，一切都是虛妄的猜測時，AWS 的工程師驚悚地發(fā)現(xiàn)，由于這個頁面依賴于 S3，所以它實際上也掛了，于是趕緊放了個 banner 上去說明狀況，然后在 twitter 上昭告天下綠油油是假象：

11:35am，經(jīng)過一番努力，這個頁面總算顯示正常的狀態(tài)了：

可以看到，重災區(qū)是 North Virginia 的 S3。由于 S3 不工作，那些高度依賴 S3 的服務(wù)，比如 Elastic Map Reduce（需要 S3 存儲中間過程和結(jié)果），以及去年 re:invent 剛發(fā)布的 Athena（查詢的數(shù)據(jù)要放在 S3 上），也完全掛掉。依賴 S3 不那么重的服務(wù)，狀態(tài)也不是太好。

S3 是 AWS 最早發(fā)布的云服務(wù)，simple storage service，解決存儲的問題。存儲是任何互聯(lián)網(wǎng)服務(wù)的基石 —— 只要有大的數(shù)據(jù)對象，無論是圖片，視頻還是文本，我們都需要一個合適的存儲方案保存它們。在沒有云的日子里，這些內(nèi)容要么存儲在無比昂貴的 SAN (Storage Area Network) 中，要么存儲在大量 PC 服務(wù)器的磁盤陣列中，通過一些特殊的文件系統(tǒng)，如 HDFS 來訪問。為了維護這些數(shù)據(jù)的持久性和可用性，互聯(lián)網(wǎng)公司需要在這樣的基礎(chǔ)設(shè)施上花費巨大的人力物力，無法集中所有的工程能力處理業(yè)務(wù)。當 S3 和類似 S3 的服務(wù)誕生后，對于很多初創(chuàng)的互聯(lián)網(wǎng)公司，簡直是久旱逢甘霖，99.99999% 的持久性（durability），和 99.9% 的可用性（availability）爽的不能再爽，于是紛紛把自個的存儲架構(gòu)布在了 S3 上。時至今日，使用 S3 的網(wǎng)站，已經(jīng)多達 148, 213 個（數(shù)據(jù)來自 techrunch）。

所以，當今早 S3（主要是 North Virginia）宕機時，整個北美的互聯(lián)網(wǎng)呈現(xiàn)一片哀魂遍野的景象。

Slack 無法上傳文件，進度條永遠在走：

Trello 表示老子都被收購了，休息，休息一會也無妨：

收購了 Trello 的 Atlassian 也不遑多讓，文案好一本正經(jīng)撲克臉（我都懷疑他們的工程師發(fā)現(xiàn)問題了么）：

最近 VC 的寵兒 giffy，表面上一切正常（CDN 扛起了 gif 的下載），但如果你要上傳 gif，對不起，偶們也不知道發(fā)生了神馬事情：

至于高冷的 quora，干脆連個暖心的頁面都不給，直接說，老子不玩了：

。。。

照理來說像 quora 這樣的服務(wù)，面向用戶閱讀的部分本不該高度依賴 S3，要掛也不該全站掛，頂多是掛用戶撰寫答案的部分，不知道為何死的這么徹底。

我們看看當問題出現(xiàn)時，一個普通的 S3 GET 返回什么：

AWS 赤果果地告訴你，Internal Error 了。從 error handling 的角度，我們在寫代碼的時候都應(yīng)該捕捉這個異常，然后做合適的錯誤處理。很遺憾的是，S3 這樣的服務(wù)是如此基礎(chǔ)，就像互聯(lián)網(wǎng)的水和電一樣，大家默認為它永遠不會出錯。因此，好多工程師干脆不做錯誤處理，像 slack 那樣，任由進度條一直傻乎乎地跑；或者，讓錯誤一路冒泡，直到把整個服務(wù)掛掉了事，像 quora / trello 那樣。這樣對用戶都不太友好。

Murphy 定律告訴我們，凡事可能發(fā)生，就將要發(fā)生。所以比較好的處理方法是，捕捉到異常，讓錯誤只局限在特定的頁面，如：atlassian / giffy?；蛘撸袀€ plan B 應(yīng)對突發(fā)事件。

使用 S3 的用戶如何自救？

類似的事情發(fā)生在任何公司上都是不幸的，尤其是給客戶以 SLA 保障的 SAAS 公司。大家能做得就是：

當云服務(wù)商的宕機發(fā)生時，盡量控制它影響面。像 trello 這樣連 landing page 都一并掛掉實在不可取，起碼 S3 影響不到的頁面，如 landing page，用戶注冊 / 登錄頁面，應(yīng)該還保持正常服務(wù)；而像 quora 這樣的服務(wù)，其實是可以準備一個靜態(tài)化的鏡像，一旦出問題，起碼讓讀者可以無障礙地閱讀。

盡可能地把動態(tài)內(nèi)容緩存起來，甚至靜態(tài)化。Redis cache，nginx cache，HA proxy，CDN 都是把內(nèi)容緩存甚至靜態(tài)化的一些手段。盡管多級緩存維護起來是個麻煩，但當?shù)讓臃?wù)出現(xiàn)問題時，它們就是難得的戰(zhàn)略緩沖區(qū)。cache 為你爭取到的半個小時到幾個小時幾乎是續(xù)命的靈芝，它能幫你撐過最艱難的時刻（這次 S3 宕機前后大概 4 小時，最嚴重的時候是 11點到1點），相對從容地尋找解決方案，緊急發(fā)布新的頁面，或者遷移服務(wù)，把損失降到較低。否則，只能像這次事件中的諸多公司一樣，聽天由命，雙手合十祈禱 aws 的工程師給力些解決問題。

使用 simian army 在平日里操練系統(tǒng)的容錯性。這個適合大一些的，工程團隊有余力的公司。netflix 重度使用 aws，卻在歷次 aws 的宕機中毫發(fā)無損，是因為他們之前也深深地被云的「不穩(wěn)定性」刺痛過。他們的 chaos monkey（之后發(fā)展為 simian army）服務(wù)，會隨時隨地模擬各種宕機情況，擾亂生產(chǎn)環(huán)境。比如說對于此次事件的演練，你可以配置 simian army 去擾亂 S3：simianarmy.chaos.fails3.enabled = true。這樣，這群討厭的猴子就會在你不知情的情況下隨機把你的服務(wù)器的 /etc/hosts 改掉，讓所有的 S3 API 不可用。這樣你就可以體驗平時很難遇到的 S3 不可訪問的場景，進而找到相應(yīng)的對策（注意：請在 staging 環(huán)境下謹慎嘗試，否則老板把你開了不要賴程序君）。

如果 AWS 真的發(fā)生大規(guī)模宕機，而你又沒有采取任何措施，天也不一定就塌下來了。此時此刻，你的投資人，你的客戶，你的合作伙伴也許都忙著解決他們各自的宕機問題呢，hacker news 上（https://news.ycombinator.com/item?id=13755673）有個笑話這么說：

Why do we host on AWS?

Because if it goes down then our customers are so busy worried about themselves being down that they don"t even notice that we"re down!

看，這就是 CIO / CTO 們的狡黠之處（自建的出了問題都得自己擦屁股）。

如何利用這樣的宕機機會？

Google 的工程師忙不迭地過來補刀加教育用戶：

你看，這個社會就是這么群狼環(huán)飼。你別說不努力了，你努力著，但只要摔上一跤，就有猛獸過來蹭肉吃。對于甲方來說，狼越多選擇越多，開心都來不及；作為乙方，則欲哭無淚。這次事故，我們作為乙方，看看熱鬧。但要知道，每家公司，甚至每個人，都在不同的上下文中扮演不同的角色，一會是甲方，一會是乙方?？礋狒[娃哈哈時，不要忘了有一天自己也可能遇到相同的境地，被自己的客戶放在火上烤。

什么？你問 Tubi TV 宕沒宕機？雖然我們有我們操蛋的煩惱，但是托 CDN 的福，在過去的幾個小時，我們好好的。

軟件開發(fā)技術(shù)群

興趣范圍包括：Java，C/C++，Python，PHP，Ruby，shell等各種語言開發(fā)經(jīng)驗交流，各種框架使用，外包項目機會，學習、培訓、跳槽等交流

QQ群：26931708

Hadoop源代碼研究群

興趣范圍包括：Hadoop源代碼解讀，改進，優(yōu)化，分布式系統(tǒng)場景定制，與Hadoop有關(guān)的各種開源項目，總之就是玩轉(zhuǎn)Hadoop

QQ群：288410967