談到云計算，用戶和廠商在采用新的基礎架構時，都仍在探索一種未知領域。故障問題以及意料之外的宕機都會不可避免地發生。即便是最大且最好的云廠商，在其服務偶爾的“停轉”時，之前萬全的計劃也是徒勞。

那么，在云宕機發生時，到底什么地方出錯了？IT經理和用戶可以從每一次的事件中學到什么？為了幫助讀者更好的運轉自己的服務，這里根據宕機事故的嚴重程度對一些宕機事件進行了排序。

微軟

即便是在測試時期，云服務都會遭遇意外宕機。微軟在2009年三月就發生了這樣的事情，Azure宕機22小時。試用期中只有試驗的應用程序受到影響，因此沒有什么大的損失。

在云計算的發展歷程中，Azure宕機相當早了，但是IT經理已經知道在云端的災備和故障時間計劃是明智的第一步。然而，Azure處于初始階段，沒人知道它會對云計算產生多少影響，或者說它會如何影響宕機對于人們對于云計算的信心。

嚴重程度：低

太平洋時間2012年2月28日，下午5：45，全球很多Azure用戶經歷了Azure服務管理功能電力中斷。對于大多數用戶，電力中斷沒有影響他們的服務交付，而且他們能夠對其進行管理。微軟聲明大多數客戶在閏年2012年的宕機中，在十二小時之內進行了管理功能修復，盡管對于很多用戶來說，在電力中斷開始之后并沒發生什么，平穩度過24小時。

嚴重程度：低

Rackspace

2009年6月，主機托管轉變成云廠商的RACKSPACE經歷了一次嚴重宕機，當時電源跳閘，一系列的發電機備份失敗，多數服務器機架安靜了，這可不是危言聳聽！

為了該公司的信譽，RACKSPACE在官方博客上報道了整個事件，并且在微博（推特）上就整個經歷現身說法，但是評論家還是# rackspacefail #的標簽滿天飛。

嚴重程度： 高

但是在2009年11月份Rackspace又發生了一次嚴重宕機，糟糕的回復就沒有滿天飛了。實際上， Rackspace的客戶有機會公然地重傷廠商的宕機時，他們卻將其描述為“沒什么大不了的。”這就意味著Rackspace逢兇化吉，繼續提供了合適的升級和快速修復。

客戶表示，在其業務脫機15-20分鐘后，Rackspace非常透明且快速地處理了這個問題。這次事件，為該公司帶來了保證，還解決了其公關危機。要是沒有重要的數據丟失，服務也能快速復原，客戶該滿意還是滿意的。其實那些滿口“100%正常運行時間”的廠商，大多數客戶似乎還是不會因為一次偶然的事故而放棄。

嚴重程度： 低

Salesforce.com

2010年一月，Salesforce.com的68，000名客戶遭遇了至少一個小時的宕機時間。

該公司在其數據中心中報告“系統失敗”，所有的一切，包括備份在這一時期都歇菜了。這樣招致了一些負面關注，Salesforce.com的鎖定策略Force.com成為眾矢之的，這是一種平臺即服務（PaaS）產品，在Salesforce.com之外就不能使用了。因此當Salesforce.com有問題了，Force.com也就掛了。

盡管此次宕機并沒有對該公司造成多大傷害，其同VMware 的VMforce合作在童年春天引得熱議紛紛，馬克貝尼奧夫在宕機后不到一個月的時間，還夸夸奇談Salesforce.com“是最大的企業云計算公司。”他們好像對這個不太在意。

嚴重程度：中

HEROKU

Heroku是一家為Ruby編程語言服務的PaaS企業，預估有大約44，000個應用安裝在上面，2010年一月，價值兩萬美元的高容量亞馬遜EC2實例在這上面掛了。

亞馬遜在一小時之內讓這些實例由“復活”，但還Heroku產品開發者還是受到了打擊。Heroku在一個單一的可用性局域運轉其所有的實例，這就導致他們主要的完整服務中斷，缺少云計算最佳實踐，意味著這樣的宕機會阻礙其繼續發展。

Heroku以這種方式喝了一壺，他們認為處理云服務時，這次事件就是“最高指令”。

嚴重程度： 高

TERREMARK

回顧三月份，VMware合作伙伴Terremark在七小時的宕機后，把vCloud Express的未來至于危險之地，這次事件導致了連接性沒了。這次宕機據報告只有2%的客戶受到影響，但是那些收到影響的人就廠商如何處理這件事上，表達了極為強烈的不滿。

Terremark發言人在客戶咆哮時稱該公司是個“老媽子”托管公司。最厲害的是他居然把Terremark的響應和亞馬遜作對比，這簡直就是告訴客戶，在掙扎這選誰的時候，把狀態報告和服務預警都算進去吧……

當然，vCloud Director持續了一段時間，VMworld 2010上這種興奮勁也就退去了，Terremark宕機似乎沒留下多少話柄。

嚴重程度： 中

亞馬遜

似乎所有的其他云計算宕機和亞馬遜的Web服務宕機相比都是小兒科。所以云服務廠商的鼻祖，亞馬遜在過去數年中遭遇的服務中斷和實際的災難均勻分布。

2009年六月，一次罕見的事故讓一些客戶失去亞馬遜EC2服務5小時，但是大多數客戶都將其看做是成長之痛。這種有點奇怪的回應方式部沒有持續，在一次分布式阻斷式服務攻擊和漫長的電子郵件管制之后，亞馬遜的災難響應協調和客戶關系開始缺失。

嚴重程度： 高

另外一起事件涉及了亞馬遜弗吉尼亞的數據中心，遭遇了雷雨，導致系統宕機6小時，但是也從一個側面顯示了該公司的發展；亞馬遜的響應時間值得肯定。

嚴重程度： 中

隨著云計算持續發展和擴展，問題也接踵而來。五月份，一些列表面上看起來不相關的事故在亞馬遜弗吉尼亞數據中心再次上演，在一周的跨度內導致了三次不同的宕機。第一次是不間斷電源（UPS）轉換到備份電源時失敗，一機架的服務器掛了；第二次發生在四天之后，一個電源分配箱短路，導致服務中斷8小時。最后兩天后，一輛汽車撞擊了電線桿子，切斷了數據中心的電源，導致半小時宕機。不管有關系沒關系，是不是大事件，這么短的時間發生這三次宕機對于任何廠商來說都不可能是個小事。

嚴重程度： 高

有意思的是，大多數客戶似乎對于亞馬遜Web服務都持有一種開放的態度。他們接受了亞馬遜技術的復雜性，以及可能導致的意外問題，最重要的是他們認同亞馬遜云環境的合理價格，提供了他們想要的工作價值。

亞馬遜也沒辜負客戶的“期望”，繼續宕機；當然也展示了期完美價格下的成熟度，在2010年四月份的宕機中快速做出相應。一篇超長博客發布，AWS的狀態頁面也定期更新，一則則簡訊報告了宕機背后的原因以及如何解決的。

嚴重程度： 中

2011年四月，由于亞馬遜在北弗吉尼亞州的云計算中心（這是塊福地啊~）宕機，包括回答服務Quora、新聞服務Reddit、Hootsuite和位置跟蹤服務FourSquare在內的一些網站受到了影響。

令人吃驚的是，亞馬遜云服務中斷將近4天卻沒有違反亞馬遜EC2服務的服務等級協議（簡稱SLA）。亞馬遜FAQ問答解釋說，“它確保在365天的服務期 內一個區域擁有99.95%的服務利用率。”而這一次，幾位受到影響的用戶抱怨，在服務中斷期間，亞馬遜并沒有及時公布最新的信息。退化了難道？

嚴重程度：高

總結

隨著大多數云計算用戶注意到上述的這些事件，這樣的宕機在企業數據中心中頻繁發生。我們所羅列的并不完全，其他的內容可自行參考其他報道。云計算并不完美，更多的宕機事件一直會發生下去。所有的頂尖廠商能做的就是學習哪些地方出錯了，并修正這些問題，以免一些黑馬企業通過更好的追蹤記錄，篡奪了其云廠商的領頭羊地位。