雲計算宕機警示錄

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

那麼，在雲宕機發生時，到底什麼地方出錯了？ 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%的服務利用率。 」而這一次，幾位受到影響的使用者抱怨，在服務中斷期間，亞馬遜並沒有及時公佈最新的資訊。 退化了難道？

嚴重程度：高

總結

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

(責任編輯：蒙遺善)