嚴重的云中斷1：亞馬遜Web服務中斷。免除你乏味的網絡維護工作是在云中做生意的主要賣點。但是他的缺點是：當你的云廠商例行性改變配置讓你的業務中斷的時候，你會束手無策。

 

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

 

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

 

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

 

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

 

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

 

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

 

    嚴重的云中斷2：Sidekick關閉。智能手機讓你很容易在移動中訪問自己的數據。但是，某些東西并不能因為名字中有“智能”二字而不會傻。例證：大約在2009年秋季發生的T-Mobile Sidekick中斷故障。

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

    嚴重的云中斷4：Hotmail一團糟。當然，微軟也為大力推廣其云服務提供最好的廣告。微軟Hotmail在2010年年底出現了數據庫錯誤，導致數萬個收件箱在轉換到新的一年的時候都被清空。

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

    柯尼卡美能達的子公司All Covered的首席信息官Tim Crawford稱，現實是基于云的數據中心也中斷了。那一直是故障的原因并且總是這種情況。我們對此必須現實一些。

 

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

 

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

 

    嚴重的云中斷8：云提供商Terremark可怕的一天。最近，Terremark與Verizon之間的10億美元的交易也許成為了重要新聞。但是，在2010年年初，主要報道的新聞是Terremark的斷網事故。

 

    在2010年3月17日的圣帕特里克節，Terremark的運氣開始變壞。該公司的vCloud Express服務在那一天急轉直下，在邁阿密的數據中心斷網了大約7個小時。在這段時間里，用戶不能訪問存儲在這個數據中心的數據。

 

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

 

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

 

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

 

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

 

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

 

    嚴重的云中斷10：Rackspace的坎坷年。當你向TechCrunch和Justin Timberlake等網站提供云服務網的時候，你最好相信當你的服務器停止工作的時候，人們會注意到。

 

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

 

    Rackspace把這些事故稱作“痛苦的和非常令人失望的”并且承諾以后在很長時間里都要高水平地提供服務。目前，該公司繼續把重點放在運行時間方面，但是還幫助用戶制定計劃準備應對在云服務中不可避免地出現的混亂局面。

 

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

 

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