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

事件回顧

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

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

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

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

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

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

Slack 無法上傳文件，進(jìn)度條永遠(yuǎn)在走：

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

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

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

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

。。。

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

我們看看當(dāng)問題出現(xiàn)時(shí)，一個(gè)普通的 S3 GET 返回什么：

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

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

使用 S3 的用戶如何自救？

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

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

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

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

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

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 們的狡黠之處（自建的出了問題都得自己擦屁股）。

如何利用這樣的宕機(jī)機(jī)會(huì)？

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

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

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

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

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

QQ群：26931708

Hadoop源代碼研究群

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

QQ群：288410967