前車之鑒：各大云服務那些“成長的煩惱”
云計算時代正迎面而來，但在適應這些新型基礎設施方面，用戶與供應商似乎一樣都在摸著石頭過河。
突發的宕機、意外的服務中斷……這些問題隨時都會發生。就連當今最大最好的云計算供應商在面對服務中斷時都顯得束手無策。
針對以上問題，我們就云計算服務中斷問題進行深入探討，并揭示隱藏在問題背后的成因，幫助IT管理者與用戶從中吸取經驗教訓。該文總結了各大云服務廠商的宕機事件，并根據故障的嚴重性給予了不同評級，希望以此來作為用戶選擇云供應商的依據。
微軟Azure
即使是在測試階段，云服務也有可能發生意想不到的服務中斷故障。2009年3月微軟云服務就出現了這種狀況，當時Azure中斷了近22個小時。幸好只有在試用期的測試應用受到了影響，其他應用都還沒有造成重大損失。
Azure的服務中斷發生在它的成長初期，但是IT管理者學會對災難與宕機的處理方法將會明智之舉。由于Azure尚處在應用早期，還沒有人知道這些云計算問題會對IT造成怎樣的影響，也不了解這些服務中斷會對用戶的信心造成多大打擊。
嚴重等級：低
#p#
Rackspace
這家由主機托管商成功轉型成云供應商的知名企業，在2009年6月同樣遭受了嚴重的云服務中斷故障，當時由于跳閘，備份發電機失效，不少機架上服務器停機。這場事故造成了嚴重的后果。
為了挽回公司聲譽，Rackspace更新了所有博客，并在其中詳細討論了整個經過。但用戶并不樂意接受。
嚴重等級：高
2009年11月，當Rackspace再次發生重大的服務中斷后，卻沒有受到輿論攻擊。事實上，它的用戶是完全有機會在服務中斷后公開指責這位供應商的，但用戶卻表示“該事故并不是什么大事。”看來Rackspace不是走好運，而是持續提供了充足更新并快速修復了這些錯誤。
在服務中斷致使其業務脫機15到20分鐘后，博客服務提供商Posterous的創建者之一Sachin Agarwal就發表了自己的觀點。Agarwal對此并不生氣，相反，他表示Rackspace在這件事上做得“很透明”，處理問題也很及時到位。
看來，一次“溫和”的服務中斷不會讓用戶怨聲載道，也為公司在公共領域上帶來了不錯印象。如果沒有嚴重數據的丟失，并且服務快速恢復，用戶依舊保持愉快的使用體驗。對于所謂的“100%正常運行”，大多數用戶似乎不會因為偶爾的小事故而放棄供應商，只是不要將問題堆積起來。
嚴重等級：低
#p#
Salesforce.com
在2010年1月，幾乎6萬8千名的Salesforce.com用戶經歷了至少1個小時的宕機。
公司稱，由于自身數據中心的“系統性錯誤”，包括備份在內的全部服務發生了短暫癱瘓的情況。這也露出了Salesforce.com不愿公開的鎖定策略：旗下的PaaS平臺、Force.com不能在Salesforce.com之外使用。所以一旦Salesforce.com出現問題，Force.com同樣會出現問題。所以服務發生較長時間中斷，問題將變得很棘手。
這場服務中斷還沒有對公司造成很大影響，它同VMware合作的VMforce在今年春季引起很大反響，同時Marc Benioff（Salesforce.com首席執行官）在服務中斷出現后的一個月內又開始宣稱Salesforce.com是“最大的云計算企業”。但是我們覺得他們還應該吸取足夠的經驗教訓。
嚴重等級：中等
#p#
Heroku
2010年1月，以Ruby程序語言構建的PaaS平臺Heroku的約4萬4千個運行服務中斷，原因是其價值2萬美元的高性能Amazon EC2實例出現了癱瘓。
盡管Amazon在一個小時內重啟了該實例，但故障卻給Heroku的產品開發者Oren Teich造成了影響。Heroku將其全部運行實例都運行在一個單一的可用區域，這樣很容易發生服務中斷故障。同時，缺少云計算的最佳實踐造成的服務中斷將阻礙到公司的發展。
“雖然我們有應急計劃，但卻還是不了解狀況。”Teich表示。
Heroku吃一塹長一智，對于Amazon的事后處理Teich也并沒有挑剔什么。在它看來，在處理云服務問題上，謹慎才是首要的指導方針。
嚴重等級：高
#p#
Terremark
讓我們再回到三月，7小時的服務中斷使得VMware的合作伙伴Terremark險些將vCloud Express的未來斷送掉，受影響用戶稱故障由“連接丟失”導致。據報道，運行中斷僅僅影響了2%的Terremark用戶，但是造成了受影響用戶的自身服務癱瘓。此外，用戶對供應商在此次事情上的處理方式極為不滿意。
Terremark的企業客戶Protected Industries的創立者John Kinsella，在抱怨服務中斷讓他心灰意冷時稱該供應商是“雜貨鋪托管公司”。Kinsella將Terremark與Amazon做了比較，他抱怨說，Terremark才開始考慮使用的狀態報告和服務預警Amazon早已實現。
當然，在對vCloud Director的大肆宣傳以及VMworld 2010興奮地揭幕過后，Terremark服務中斷事件似乎只留下了很小的余波。
嚴重等級：中等
#p#
Intuit
在今年6月，Intuit的在線記賬和開發服務經歷了大崩潰，公司對此也是大惑不解。包括Intuit自身主頁在內的線上產品在內近兩天內都處于癱瘓狀態，用戶方面更是驚訝于在當下備份方案與災難恢復工具如此齊全的年代，竟會發生如此大范圍的服務中斷。
但這才是開始。大約1個月后，Intuit的QuickBooks在線服務在停電后癱瘓。這個特殊的服務中斷僅僅持續了幾個小時，但是在如此短時間內發生的宕機事件也引起了人們的關注。
即使一些用戶要求“武裝”其品牌，Intuit依舊擁有4百萬用戶并繼續進軍PaaS和Web服務供應商之路。公司沒有Amazon和Rackspace這樣的知名度，中斷也沒有造成很大的影響。Intuit主要因Quicken而聞名。
嚴重等級：高
#p#
Amazon Web Services
相比Amazon Web Services的服務中斷，其他的云計算服務中斷故障簡直就是小兒科。作為所有云服務供應商的“鼻祖”，Amazon在最近幾年同樣遭受著服務中斷以及各種災難的困擾。
2009年6月，一場意外事故導致部分用戶盡5個小時不能使用Amazon EC2服務，但是大多數用戶把這場故障視為“成長中需要經歷的痛苦”，但這些令人鼓舞的輿論并沒有持續很久。分布式拒絕服務攻擊和郵件失效顯現出Amazon在災難應對處理和用戶關系協調方面的缺失。
嚴重等級：高
另外還有一場奇怪的事故，由于Amazon位于弗吉尼亞州（Virginia）的數據中心受到雷雨影響，導致系統宕機了近6個小時，但Amazon在對該事故的處理方式上進步不少。Amazon獲得了Apparent Networks主席Jim Melvin高度評價，他對Amazon的應對時間給予很高評價，并暗示Amazon從服務中斷中積累了不少成果。
嚴重等級：中等
隨著云計算的發展與擴大，問題會依舊存在。5月份，一系列看似不相關的事故發生在Amazon位于弗吉尼亞州（Virginia）的數據中心，導致一周之內三次服務中斷。第一次由于不間斷電源（UPS）切換備用電源失敗，同時造成整架的服務器停機；第二次服務中斷發生在4天之后，當時電力調度平臺短路，服務器停機8小時；最后一次發生在兩天后，車輛撞上了電線桿，切斷數據中心供電達半小時之久。對于任何供應商來說，在如此短的時間段內發生三次服務中斷都是大問題。
嚴重等級：高
但是經歷了這些事件，大部分的用戶似乎寬容地接受了Amazon Web Services。他們采納了Amazon的復雜技術，雖然這將有可能帶來未知的問題，最重要的是，他們認同Amazon價格合理的云計算環境下的工作價值。
Amazon也的確沒有辜負用戶的信任。針對2010年4月的服務中斷故障，Amazon借助可視化支持展現出它成熟的響應機制。相關的博客推出，AWS狀態頁面也有服務中斷背后原因相關的簡訊、信息以及解決方案定期性地更新。
嚴重等級：中等（偏低）
總結
部分云計算用戶可能已經注意到，在前面提到的事故中頻繁出現的服務中斷大多源自公司的數據中心。差別在于有些是由內部、成熟技術發生事故，有些是非普及、發展中的未知技術（比如云計算）造成的呢。
云計算并不是完美無缺的，隨時都會有服務中斷故障發生。上述這些大企業要做的就是研究這些錯誤產生的原因，并改正這些問題，以免被后起之秀取代。
【編輯推薦】
