Amazon網絡服務的中斷事件暴露了用戶對在線服務的期望與云計算實際運行交付能力之間深深的鴻溝。

如果你的系統在本周的Amazon云計算中發生故障，那并不應該由Amazon公司來承擔責任。

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

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

Buescher在Heroku基礎上構建他們的業務，Heroku為其提供了一個不需要Buescher運行或維護該公司本身擁有服務器的應用程序平臺。他表示，直至上周發生事件之前，相關服務的所有便利性和成本效益都是物有所值的。

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

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

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

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

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

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

“當他們發生中斷事件時，他們會積極地進行溝通，即使他們的東西并不是客戶的關鍵業務，”他說。

#p#

Amazon用戶表達了對服務中斷事件的憤怒

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

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

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

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

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

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

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

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

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

#p#

Amazon云計算服務中斷事件的詳細信息

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

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

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

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

#p#

云計算實施應當三思而后行

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

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

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

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

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

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

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

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

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

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

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

【編輯推薦】

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