Amazon網(wǎng)絡(luò)服務(wù)的中斷事件暴露了用戶對在線服務(wù)的期望與云計算實際運(yùn)行交付能力之間深深的鴻溝。

如果你的系統(tǒng)在本周的Amazon云計算中發(fā)生故障，那并不應(yīng)該由Amazon公司來承擔(dān)責(zé)任。

有一個戲劇性的場景值得我們思考，那簡直就是上個世紀(jì)那場電信危機(jī)的一個縮影：Amazon公司的冗余彈性塊存儲（EBS）的服務(wù)中斷事件不僅涉及諸如Reddit之類的熱門網(wǎng)站，而且還殃及Heroku等沒有備用資源的互聯(lián)網(wǎng)服務(wù)供應(yīng)商。

“問題在于我們沒有可供托管數(shù)據(jù)庫或其它任何資源使用的替代場所，”Architectural Overflow公司的CEO Lee Buescher說，Architectural Overflow是一家向全美各地建筑商和建筑公司銷售建筑藍(lán)圖和提供建筑規(guī)劃服務(wù)的公司。

Buescher在Heroku基礎(chǔ)上構(gòu)建他們的業(yè)務(wù)，Heroku為其提供了一個不需要Buescher運(yùn)行或維護(hù)該公司本身擁有服務(wù)器的應(yīng)用程序平臺。他表示，直至上周發(fā)生事件之前，相關(guān)服務(wù)的所有便利性和成本效益都是物有所值的。

現(xiàn)在，他的信心已經(jīng)開始了極大的動搖，Buescher表示他仍十分看好云計算，只不過是錯誤地對Heroku在實際運(yùn)行能力方面產(chǎn)生了過于單一的依賴性。但是云計算開發(fā)平臺卻因為此次其供應(yīng)商Amazon網(wǎng)絡(luò)服務(wù)（AWS）所面臨的危機(jī)而獲益匪淺。

“我錯誤地認(rèn)為他們知道他們正在做什么，”Buescher說，“我從未遇到過停機(jī)時間如此之長的服務(wù)中斷事件。我曾使用過其他的應(yīng)用托管服務(wù)，但從來沒有這樣的中斷服務(wù)事件。”

他補(bǔ)充道，由于他本人擁有數(shù)據(jù)中心運(yùn)營的背景，他對Heroku所遭遇的麻煩和AWS經(jīng)營者不得不修復(fù)這些級聯(lián)故障均表示了深深的同情。與此同時，還有一些尚不為人知的東西。

“我深知那些工作人員正通宵達(dá)旦地修復(fù)故障，因此我被他們感動，”他說，“但與此同時，由于我正為該服務(wù)支付費(fèi)用，所以我希望它能正常運(yùn)行。”

Buescher說，他正在積極地尋覓Heroku的替代者，包括托管他自己的服務(wù)器和一個針對他的應(yīng)用的災(zāi)難恢復(fù)計劃，但他目前主要是在等待Heroku宣布如何防止類似的服務(wù)中斷事件再次發(fā)生。他目前最關(guān)心的是客戶與供應(yīng)商之間缺乏溝通的問題。

Buescher是眾多在線服務(wù)的用戶之一，例如ERP軟件即服務(wù)（SaaS）NetSuite和協(xié)同服務(wù)37signals.com。但當(dāng)事件發(fā)生時他們對用戶們的考慮呈現(xiàn)了極為不同層次上的考慮。

“當(dāng)他們發(fā)生中斷事件時，他們會積極地進(jìn)行溝通，即使他們的東西并不是客戶的關(guān)鍵業(yè)務(wù)，”他說。

#p#

Amazon用戶表達(dá)了對服務(wù)中斷事件的憤怒

Buescher（和其他許多用戶，從Amazon技術(shù)支持論壇和社交媒體網(wǎng)站的評論和反應(yīng)來看）對Amazon公司在服務(wù)中斷事件期間缺乏補(bǔ)償而感到極大的不滿。他說，每個人都會遇到中斷事件——這就是我們所身處的現(xiàn)實世界——但是不確定感和缺乏溝通則是令人非常沮喪的。他補(bǔ)充說，他并沒有真正理解為什么他從其他服務(wù)供應(yīng)商得到的客戶響應(yīng)等級和他試圖提供給他自己客戶的響應(yīng)等級并不適用于AWS。

這一不確定性導(dǎo)致了一些AWS客戶采用某些怪異把戲來引起別人的注意和AWS對其的支持：一個用戶發(fā)帖子說，此次服務(wù)中斷事件是一次醫(yī)療緊急事故，有可能對數(shù)百名心臟急癥病人造成潛在的生命威脅。

“對不起，我無法采用任何其他的方法來達(dá)到目的，”后續(xù)帖子中如是寫道。該用戶表示，他們在AWS上運(yùn)行了三個實例來監(jiān)控數(shù)以百計家居患者的ECG信號，但自從4月21日以來就無法再看到這些信號了。

這一令人震驚但漏洞百出的帖子卻招致其他用戶對AWS猛烈的口誅筆伐。醫(yī)療IT系統(tǒng)，特別是那些有可能涉及威脅生命的系統(tǒng)，都是采用了具有極高冗余性和可用性的標(biāo)準(zhǔn)；用戶本可能對犯罪持無所謂態(tài)度。此后該用戶退而宣稱監(jiān)控應(yīng)用是至關(guān)重要的，或者患者可能已身處危險之中，但這一戲劇性的事件凸顯了用戶在服務(wù)中斷事件期間由于缺乏來自于AWS的響應(yīng)而感受到的絕望情緒。AWS的工作人員并未對用戶最初的支持請求做出反應(yīng)。

其他用戶在Amazon的論壇上討論可供替代的供應(yīng)商和服務(wù)，如Rackspace和Azure等。大家達(dá)成的共識是，可行的方案可能都缺少對妥善業(yè)務(wù)處理支持的要素。

“比較明智的做法，Azure比較接近于AWS”在線協(xié)作服務(wù)NextSlide的CTO Stephane Legay說，“他們把排隊、存儲、CDN、關(guān)系型數(shù)據(jù)庫作為一種服務(wù)，把分布式緩存作為一種服務(wù)，計算節(jié)點、EBS（Azure 驅(qū)動）和現(xiàn)在已解決的視頻流，而通常來說微軟對這些服務(wù)的支持相當(dāng)好。”

在服務(wù)中斷開始之后的幾乎一周時間里，對于AWS如何處理該故障的困惑和失望仍舊是一個問題。Amazon在其狀態(tài)頁面（順便說一句，該頁面運(yùn)行于Amazon.com上；零售巨頭的網(wǎng)站不會在AWS的云計算上運(yùn)行）公布了其詳細(xì)的常規(guī)報告，但還未作出有關(guān)該問題的公開聲明，在其12小時的運(yùn)行高峰期間，有可能已導(dǎo)致數(shù)以千計的網(wǎng)站和業(yè)務(wù)無法正常運(yùn)行。

云計算管理服務(wù)供應(yīng)商RightScale的CTO和創(chuàng)始人Thorsten von Eicken在一篇博客中對這一狀態(tài)更新的情況提出了批評。他說，在某種程度上，他們幫助RightScale對這一危機(jī)做出了次優(yōu)的決策。

“事后回想起來，我們本應(yīng)當(dāng)在事件早期就有意識地使我們在‘可用性受影響區(qū)域’中運(yùn)行的主數(shù)據(jù)庫停機(jī)，”他說，“但是Amazon并沒有提供足夠的詳細(xì)信息來幫助我們做出這一決定。”

#p#

Amazon云計算服務(wù)中斷事件的詳細(xì)信息

服務(wù)中斷事件始于美國太平洋標(biāo)準(zhǔn)時間4月21日上午01：30分（上午8：30 GMT），這一事件造成了位于Virginia州Ashburn 的Amazon公司旗艦數(shù)據(jù)中心EBS服務(wù)無法正常使用。在大約12小時后，AWS表示，在除一個區(qū)域以外，所有可用區(qū)域的功能均已恢復(fù)并運(yùn)行正常。至4月24日晚上7:00,AWS表示，該服務(wù)運(yùn)行穩(wěn)定，恢復(fù)過程仍在進(jìn)行中，但是直至4月25日AWS才將美國東部地區(qū)的運(yùn)行狀態(tài)標(biāo)為正常（雖然在關(guān)系型數(shù)據(jù)庫中還存在著問題）。

與EBS相比，有相當(dāng)大一部分關(guān)系型數(shù)據(jù)庫服務(wù)的用戶；那么，其重要性何在？除用戶確實喜歡的Amazon主要計算服務(wù)和存儲云以外，EBS是一個附加的功能，但是該功能卻為AWS的云計算環(huán)境帶來了一個潛在的致命弱點。

EBS甚至為用戶提供了可在啟動和停止虛擬機(jī)實例時保留的狀態(tài)虛擬存儲卷標(biāo)。對于用戶來說，這是一個比Amazon的簡單存儲服務(wù)（S3）有用得多的功能；至于操作系統(tǒng)方面，EBS就如同一個硬盤驅(qū)動器一樣工作。用戶啟用一個虛擬機(jī)實例并將其與他們的非固定EBS卷標(biāo)相連，就如同將他們插在一個外部硬盤驅(qū)動器上。實例可以與大量的本地存儲資源同時啟用，但是當(dāng)實例消失時這些存儲資源也一并消失，這就造成了眾多類型應(yīng)用程序的可擴(kuò)展性問題。

因此，EBS已成為EC2用戶作為存儲區(qū)域網(wǎng)絡(luò)（SAN）服務(wù)的一種替代品。但是，正如許多人所指出的，在設(shè)計和實踐方面，云計算并不是一個傳統(tǒng)的數(shù)據(jù)中心。復(fù)制諸如AWS某些原有的架構(gòu)往往就意味著，潛在的弱點將暴露無遺。已經(jīng)有眾多基于Amazon的高手和供應(yīng)商提出了相關(guān)的警示，但它顯然不是一個簡單的教訓(xùn)而已。

#p#

云計算實施應(yīng)當(dāng)三思而后行

“EBS并不是一個SAN，”IT解決方案供應(yīng)商Atalanta系統(tǒng)公司的技術(shù)總監(jiān)Stephen Nelson-Smith這樣寫道。他說，用戶必須正確看待EBS:EBS是傳統(tǒng)、高可用性光纖支持SAN的一個模型。它完全運(yùn)行于網(wǎng)絡(luò)之上；如果網(wǎng)絡(luò)資源使用已經(jīng)達(dá)到飽和，那么你的存儲功能就將不可用。他補(bǔ)充說，像Reddit這樣對EBS有著大規(guī)模、不適當(dāng)有時甚至是危險的過分依賴性的網(wǎng)站受服務(wù)中斷事件影響極大。其他諸如Heroku之類的受害者顯然只是運(yùn)氣非常差，其實例運(yùn)行于基礎(chǔ)設(shè)施中受影響最大的那部分設(shè)施之上。

Nelson-Smith說，用戶必須能夠看到Amazon所提供可靠性服務(wù)的一切，并在突然想起某些服務(wù)時進(jìn)行運(yùn)行預(yù)估。
“總之，如果你的系統(tǒng)于本周在Amazon的云計算中發(fā)生了故障，那并不是Amazon的錯，”云計算管理工具制造商EnStratus公司的CTO George Reese在一篇博客帖子中這樣寫到。“你要么認(rèn)為這類性質(zhì)的服務(wù)中斷事件是一個可接受的風(fēng)險，要么你的Amazon云計算模型設(shè)計就是失敗的。”

Reese表示，AWS的正確使用要求你進(jìn)行“為故障進(jìn)行設(shè)計”，即期望并預(yù)測故障并采取相應(yīng)的風(fēng)險管理措施，同時千萬不要指望AWS來幫助你解決任何問題。

有幾個值得注意的服務(wù)中斷的特例。許多Amazon云計算服務(wù)的大型客戶——例如Priceline, Netflix, SmugMug 和Zynga等公司 –并沒有遭遇任何嚴(yán)重的停機(jī)事件。他們可能已經(jīng)注意到了一些小麻煩，一些警告的性能日志，但是都保持在整個功能中。

SmugMug的Don MacAskill曾撰寫過一個為什么他們能夠承受中斷事件影響的高水平評論。首先，他說他的公司將他們的服務(wù)遍布于Amazon的可用區(qū)域；其次，他們要假定服務(wù)故障是必然會發(fā)生的；“再次，我們不使用EBS”。

那么，為什么對如何正確使用云計算的爭論會引起這么多人的興趣呢？其讀者隊伍不斷壯大；據(jù)云計算追蹤網(wǎng)站CloudSleuth估計，目前世界上所有網(wǎng)絡(luò)流量的三分之一強(qiáng)都是通過或涉及由AWS所運(yùn)營的資源的。但是，所有的一切都是由易受到中斷事件影響的個人、自我服務(wù)AWS客戶所管理的。

雖然之前發(fā)生的中斷事件是一個不好的信號，但是這將絲毫不會減緩Amazon網(wǎng)絡(luò)服務(wù)或云計算的發(fā)展速度。它仍然是一個值得注意的警示，用戶需要了解云計算是一個非常不同的、非常新的、偶爾也是非常不確定的工作方式，而部署云計算實施必須牢記這一點。

迄今為止，AWS一直拒絕對此次事件發(fā)表評論，只是表示，他們正在準(zhǔn)備一份詳細(xì)的故障報告。Heroku則剛剛公布了它自己的故障報告，部分內(nèi)容如下：“HEROKU對此次深深影響我們客戶的停機(jī)事件承擔(dān)100%的責(zé)任。”報告中還指出，該平臺還將優(yōu)先考慮在多個地區(qū)的備份和可用性部署，并減少對EBS的使用。

最新更新：AWS已發(fā)布了對本次服務(wù)中斷事件的解釋，并提出了一份在其可用區(qū)域之一中出現(xiàn)事件以天計故障時的解決時間表。在日常升級期間，對備份路由器進(jìn)行不當(dāng)配置；而當(dāng)主路由器因升級而離線時，該操作引起了EBS系統(tǒng)的連鎖性故障。

AWS表示，此次服務(wù)中斷事件在短時間內(nèi)就得到了解決，但恢復(fù)操作花費(fèi)時間過長是由于其存儲陣列的硬盤驅(qū)動器可用空間不足，且不再遵循重用現(xiàn)有能力的標(biāo)準(zhǔn)程序，直至確定數(shù)據(jù)不會丟失。小部分受影響的EBS卷標(biāo)將無法恢復(fù)。希望同時增加災(zāi)難恢復(fù)所需的備用能力及其升級過程中的自動化程度，以避免同類問題的再次發(fā)生。

AWS還承諾為受影響的用戶提供10天的服務(wù)并向他們致以歉意。 

【編輯推薦】

1. SAP稱亞馬遜服務(wù)故障影響其云計算推廣
2. 亞馬遜為宕機(jī)事件道歉 已找到EC2設(shè)計缺陷
3. 亞馬遜服務(wù)器宕機(jī)背后：云計算依然安全嗎？ 
4. 亞馬遜稱云計算服務(wù)故障已大部分解決
5. 云遷移全攻略：哪些應(yīng)用適合遷移
6. 亞馬遜 谷歌 微軟三大試用云服務(wù)大比拼（上）
7. 亞馬遜推出1年免費(fèi)云計算服務(wù)
8. 亞馬遜EC2中斷 “可用區(qū)”遭質(zhì)疑
9. 傷不起！亞馬遜史前最大宕機(jī)事件的啟示
10. 云震 -- 亞馬遜4.21事故的反思
11. 從亞馬遜云服務(wù)故障中吸取的七個教訓(xùn)
12. 云計算與集群：是攜手還是爭斗？