盤點：十大雲計算服務中斷事故

為了説明企業避免在雲服務中出現故障，美國《NetworkWorld》專門列出了全球眾多網站曾經歷過的十個最嚴重的雲服務中斷故障以及我們能夠從中吸取的教訓。

嚴重的雲中斷1：亞馬遜Web服務中斷

免除乏味的網路維護工作是在雲中做生意的主要賣點。 但這種服務的缺點是：當雲廠商例行性改變配置讓你的業務中斷的時候，使用者會束手無策。

這是許多亞馬遜Web服務使用者在今年4月經歷的事情。 當時，亞馬遜北弗吉尼亞州的資料中心出現故障，完全無法使用。

這個故障是在網路升級期間發生的。 當時，資訊尋找可用的設備把自己作為備份嵌入到這些設備中時，一個錯誤路線的通訊移動把一連串的亞馬遜EBS(彈性塊存儲)通訊量發送到一個重新鏡像的風暴。 這是一種反常的現象。 這引起了一系列事件，最終導致亞馬遜在美國東部地區的許多服務中斷。

這個故障持續了大約四天時間。 但是，在許多企業陷入困境之中的同時，Netflix等其它公司的排除了故障。 生存的關鍵是什麼?設計系統的時候就要考慮到這種類型的故障。

Netflix工程師在題為「Netflix從亞馬遜Web服務中斷故障中吸取的教學」的博客中稱，我們的架構避免使用EBS作為我們的主要資料存儲服務。 我們依靠的SimpleDB、S3和Cassandra服務從而沒有受到這次中斷事故的影響。 無國家的服務和可用地區的資料的多個冗餘熱拷貝是避免亞馬遜Web服務雲故障的關鍵。

考慮一下你必須是Netflix規模的企業才能保證安全嗎?再考慮一下。 説明開發人員把通訊與其Web應用程式集成在一起的Twilio公司利用亞馬遜的EC2服務託管其核心的基礎設施。 儘管如此，4月份的中斷故障對它的穩定性幾乎沒有影響。

Twilio共同創始人和首席技術官EvanCooke稱，建立雲的前提是假設這個網路將出現故障。 我們圍繞著主機能夠並且將發生故障這個思路建立了一個基礎設施。 因此，我們不依賴于核心架構本身的任何一台機器或者一個元件。

嚴重的雲中斷2：Sidekick關閉

智慧手機讓你很容易在移動中訪問自己的資料。 但是，某些東西並不能因為名字中有「智慧」二字而不會傻。 例證：大約在2009年秋季發生的T-MobileSidekick中斷故障。

還記得這次大慘敗嗎?微軟擁有的Sidekick遭受了將近一個星期的服務中斷，使使用者不能訪問電子郵件、日曆資訊和其它個人資料。 後來，微軟承認它完全失去了雲存儲的資料並且也許不能回復這些資料。 微軟的人員顯然忘記了做備份。

這個技術從那以後也許已經發展了。 但是，教訓是相同的：當涉及到重要資料的時候，永遠不要假設其他人將自動保護你。 要保證你理解你的雲供應商的災害復原設置。 最好是制定獨立地備份你的重要資料的計畫。

AlertSite公司負責監視產品的副總裁KenGodskind稱，同樣的運營規則甚至適用于雲。 使用雲的機構不能僅僅假設因為它是在雲中，業務持續性計畫的全部責任已經交給了供應商。

嚴重的雲中斷3：Gmail故障

在所有的雲服務中，谷歌Gmail是對微軟在企業中內部安裝的郵件服務堡壘的最大威脅之一。 使用Postini支援的便宜的獨立的電子郵件服務取代你的維護成本高的Exchange伺服器。 有什麼不一樣?

許多令人討厭的中斷。 最近的中斷故障讓15萬Gmail使用者在登錄自己的帳戶之後只看到一個空白頁，沒有郵件和資料夾，沒有任何東西表明他們實際上在看自己的收件匣。 值得讚揚的是，谷歌提供了週期性更新並且承諾迅速修復故障。 但是，對於某些受影響的使用者來說，谷歌修復這個故障用了4天時間。

谷歌負責工程的副總裁BenTreynor當時在博客中稱，如果有你的資料的多個副本，怎麼會發生這樣的事情?在很少出現的情況下，軟體瑕疵能夠影響幾份資料。 那就是這裡發生的事情。

谷歌最後不得不改用物理磁帶備份以便恢復資料。 最終，谷歌的多層資料保護確實發揮了作用，但是，還是讓數千使用者在幾天時間裡無法訪問其電子郵件。

故障是不使用雲連接的東西的一個理由嗎?也許不是。 但是，這是在緊迫的需求出現之前，認證檢查你自己的資料保護和考慮建立備份或者離線訪問解決方案的一個理由。

AlertSite公司的KenGodskind稱，當你查看廣泛的平均狀況時，雲的運行成功率遠遠高於你個人的運行成功率。 這只是當你進入到Web規模時，故障的影響以更大的方式放大了。

嚴重的雲中斷4：Hotmail一團糟

當然，微軟也為大力推廣其雲服務提供最好的廣告。 微軟Hotmail在2010年年底出現了資料庫錯誤，導致數萬個收件匣在轉換到新的一年的時候都被清空。

微軟稱，這個故障是一個腳本錯誤造成的。 這是為自動測試創建的一個刪除虛帳戶的腳本。 這個腳本錯誤地刪除了1.7萬個真正的帳戶。

微軟用了三天時間恢復了大多數使用者的帳戶。 大約8%的運氣不佳的使用者必須再等待三天時間才能恢復自己的資料。

嚴重的雲中斷5：Intuit兩次中斷

Intuit去年遭遇一次嚴重故障。 它的基於雲連接的服務，包括TurboTax、Quicken和QuickBooks等流行的平臺在一個月內發生兩次斷網事故。 最最糟糕的一次是去年6月的一次36小時斷網事故。 一次電源故障顯然導致主要設備使用備用電源，該公司主要的和備份的系統完全斷網。

更糟糕的是，幾個星期之後，又發生了一次明顯的電源故障。 此外，第二次中斷顯然引起了人們的大罵。

一個使用者當時在微博中稱，25小時的斷網是很難忍受的。 Intuit的被動的、不透明的和無法接受的溝通沒有説明。

惠普安全優勢計畫主要戰略家ChrisWhitener稱，事實是，如果你需要絕對的可用性，有比一個雲更好的解決方案。 你沒有必要備份一切，但是，你在那裡採取一個額外的步驟(也許僅依靠自己備份重要的資料)就會產生完全不同的結果。

嚴重的雲中斷6：微軟BPOS(商務辦公線上套件)故障

當你的基於雲的辦公套件出現故障時，那是很難有辦公效率的。 那是幾個星期前依賴微軟商務雲服務的機構發生的事情。 在5月10日左右，微軟BPOS服務開始出現斷斷續續地工作的情況。 一些使用者的電子郵件因此延遲了9個小時才收到。

兩天后，就在BPOS好像排除了故障的時候，延遲的現象又發生了，向外發出的資訊也阻塞了。 如果這個事故還不夠的話，微軟還經歷了另一個故障，阻止使用者登錄基於Web的Outlook入口網站。

微軟線上服務部門副總裁在博客中稱，我要因為這個故障引起的這些不便向你們、我們的客戶和合作夥伴表示道歉。

嚴重的雲中斷7：Salesforce服務中斷

一個小時的斷網故障聽起來也許不嚴重。 但是，如果你的公司擁有數萬家企業客戶服務業務的關鍵，許多這樣的機構肯定要把這60分鐘看作是生命期。

當去年1月資料中心關閉的時候，Salesforce.com吸取了深刻的教訓。 在進入新的一年剛剛四天的時候，Salesforce.com報告了一次全面的故障，也就是說服務、備份等全套服務都中斷了。

令人厭煩?絕對如此。 令人意外?不完全意外。

柯尼卡美能達的子公司AllCovered的首席資訊官TimCrawford稱，現實是基於雲的資料中心也中斷了。 那一直是故障的原因並且總是這種情況。 我們對此必須現實一些。

Crawford稱，成功的雲計算需要一個與傳統的伺服器設置不同的思維方式。 你要自己決定你的企業的資料是否能夠承受偶爾的斷網。 如果不能承受，你要保證你的配置有避開斷網故障所需要的彈性。

當你選擇一個雲供應商的時候，你需要做家庭作業以理解他們如何提供這些服務，他們是否能夠建立比你自己做的還要好的冗余水準。 如果答案是否定的，那麼，你為什麼要使用這些雲供應商呢?

嚴重的雲中斷8：雲供應商Terremark可怕的一天

最近，Terremark與Verizon之間的10億美元的交易也許成為了重要新聞。 但是，在2010年年初，主要報導的新聞是Terremark的斷網事故。

在2010年3月17日的聖派翠克節，Terremark的運氣開始變壞。 該公司的vCloudExpress服務在那一天急轉直下，在邁阿密的資料中心斷網了大約7個小時。 在這段時間裡，使用者不能訪問存儲在這個資料中心的資料。

沒有得到更多的冗余。 但是，這帶來的冗余的價值，讓你的重要資料提供到不同資料中心的多台伺服器，或者最好是提供到不同地區的多台伺服器。 作為一種故障保險，你還可以採取額外的步驟把資料分散到不同的供應商。

IBM雲安全戰略計畫首席技術官HaroldMoss稱，你可以選擇一系列廠商託管一個工作量，一個廠商負責備份或者兩個廠商負責備份，然後選擇一個廠商作為你的主要供應商。 然後，你可以在安全的情況下實施你的工作量，有適當的安全並且開始引進你的彈性能力。

嚴重的雲中斷9：PayPal斷網故障

要一個引起廣泛的嚴重影響的雲斷網故障嗎?設法讓PayPal斷網幾個小時就可以看到。

這不是假設的演習：2009年夏季PayPal的斷網故障是真的，讓全球數百萬台機器無法銷售商品。 這項服務在大約一個小時的時間裡完全不可用，在後來的幾個小時裡仍是斷斷續續的。 PayPal稱，硬體故障是事故的原因。

毫無疑問，這種中斷故障是很少發生的。 但是，這個不幸的斷網故障使PayPal輕鬆在雲計算的恥辱堂上贏得一個位置。

嚴重的雲中斷10：Rackspace的坎坷年

當你向TechCrunch和JustinTimberlake等網站提供雲服務網的時候，你最好相信當你的伺服器停止工作的時候，人們會注意到。

Rackspace在2009年吸取了幾次教訓。 這家雲供應商在2009年全年遭遇了四次引人矚目的斷網故障，使該公司的客戶的斷網時間達到幾個小時。 Rackspace不得不向使用者賠償了將近300萬美元的服務費。

Rackspace把這些事故稱作「痛苦的和非常令人失望的」並且承諾以後在很長時間裡都要高水準地提供服務。 目前，該公司繼續把重點放在執行時間方面，但是還説明使用者制定計畫準備應對在雲服務中不可避免地出現的混亂局面。

Rackspace公司的LewMoorman稱，如果你要建立一個服務集群或者建立地理位置的冗余，現在要比以前容易做到。 但是，你必須採取這些步驟。 如果你以前在企業內部做過這個事情，這個雲不會帶來可能出現的弱點。

考慮到所有的故障，這裡最大的教訓是沒有一個單個的伺服器、中心或者服務是百分之百可靠的。 如果你不以這種思路建立你的業務，那麼，我的朋友，你就是在不切實際地到處走。

(責任編輯：杜慶先)