云服務是很討人很喜歡的概念。畢竟，丟棄那些笨重的服務器，只要給自己弄一只大容量的云硬盤就可以了。反正別人會負責維修；你想把數據放在哪里，就可以放在哪里。

當然，現實情況是喜憂參半。一方面，你可以避免維修；但另一方面，你喪失了控制。另外還需要考慮安全問題。但是一旦云服務宕機，那真的是一個活生生的噩夢。

那只要問一問今年4月受到亞馬遜網絡服務的重大宕機事件影響的隨便一家公司。

Nick Franci說：“當時我們完全給搞蒙了；我們絕對是毫無防備。”就在亞馬遜出現問題一周前，他的新興公司Help Scout才開業。

措手不及的并非只有Francis一人。當亞馬遜的云服務出現故障時，像Reddit和Foursquare這些大牌公司同樣動彈不得。

Lew Moorman是Rackspace的首席戰略官，這家云服務提供商也遇到過宕機事件。他說：“人們覺得云計算是一項切實可用、完全可靠的神奇技術。事實上，通過云來購買是另一種購買計算的方式，而計算本身是有缺陷的。如果你想確保那些缺陷不會影響到自己，就必須未雨綢繆。”

為了幫助貴公司在云環境下高枕無憂，我們分享了這些來之不易的經驗教訓，它們源自互聯網經歷的十大云服務宕機風暴。

第一大云服務宕機事件：亞馬遜網絡服務完蛋

可以擺脫繁瑣的網絡維護工作是在云環境開展業務的一個主要賣點。那有什么缺點嗎？當云服務提供商的日常配置變更導致貴公司的業務陷入停頓時，你會有一種孤立無援的感覺。

亞馬遜網絡服務的許多客戶在去年4月就經歷了這一幕，當時亞馬遜建在北弗吉尼亞州的數據中心遭到了一個故障，最后徹底歇菜了。

這個錯誤在網絡升級升級中開始出現了，當時流量轉移到錯誤的路徑上傳送后，亞馬遜的一組彈性塊存儲（EBS）卷不斷地重新映像，于是它們尋求可用的設備以便對自己進行備份。結果就引發了一連串事件，最終導致該公司在美國東部地區的服務大部分癱瘓。

這個問題持續了大約四天。但是就在許多公司苦苦掙扎的同時，Netflix等其他公司順利渡過了難關。存活下來的關鍵是什么呢？那就是在設計系統時要考慮到這些類型的故障。

Netflix的幾名工程師在《Netflix從亞馬遜網絡服務宕機中汲取的經驗教訓》博文中寫道：“我們的架構避免使用EBS作為我們的主數據存儲服務，我們實際上依賴的SimpleDB、簡單存儲服務（S3）和Cassandra服務沒有受到這次宕機的影響。”無狀態服務和數據的多個冗余熱副本分散在多個可用區是避免云服務故障的關鍵。

是否認為自己非得像Netflix這等規模的公司才能保持安全？那你就錯了。Twilio公司專門幫助開發人員把通信功能集成到自己開發的Web應用程序中，它使用亞馬遜的彈性計算云（EC2）來托管其基礎架構的核心部分——不過亞馬遜的宕機事件對于該公司的穩定運行幾乎沒什么影響。

Twilio的聯合創辦人兼首席技術官Evan Cooke說：“將業務建立在云環境上的基本前提是，要假定網絡會有這樣那樣的故障和毛病。我們在建立基礎架構時就設想主機可能會出現故障，于是我們沒有依賴核心架構中的任何一臺機器或任何一個組件。”

第二大云服務宕機事件：Sidekick宕機

智能手機讓你出門在外時很容易訪問自己的數據，但就因為某樣東西的名字里面有“智能”（smart），并不意味著它就萬無一失。一個典型例子就是：T-Mobile的Sidekick在2009年秋天前后搞砸了。

還記得那次慘敗嗎？微軟旗下的Sidekick遭遇了服務將近一周宕機的尷尬，導致用戶們無法訪問電子郵件、日歷信息及其他個人數據。后來雪上加霜的是，微軟承認自己完全丟失了存儲在云環境中的數據，自己無力恢復。顯然，來自雷德蒙的那群技術精英們之前忘了備份數據。

也許此后技術有所發展，但教訓仍然一樣：說到關鍵數據，千萬不要想當然地以為別人會自動保護你。確保你了解云服務提供商的災難恢復系統；如果你自己作了安排，獨立備份重要數據，那就更好。

SmartBear旗下AlertSite公司的監控產品副總裁Ken Godskind說：“同樣的操作規則甚至適用于云環境。使用云服務的企業千萬不要想當然地以為，就因為數據在云環境中，業務連續性規劃方面的全部責任可以一股腦兒地扔給提供商了。”

第三大云服務宕機事件：Gmail故障

在所有云服務iv 中，谷歌的Gmail是比較有可能在企業領域危及微軟預置型軟件的勁敵之一。把需要精心維護的Exchange服務器換成由Postini支持的一種廉價而可靠的電子郵件服務。誰不喜歡呢？

此后出現了一連串令人惱恨的宕機事件，最近一次是15萬個Gmail用戶登錄進入到帳戶，結果卻發現里面空空如也：沒有電子郵件，沒有文件夾，沒有什么可以表明他們看到的就是自己的收件箱。值得肯定的是，谷歌定期提供更新版，承諾很快會拿出權宜之計。但對于一些受到影響的用戶來說，維修過程前后長達四天。

谷歌工程副總裁Ben Treynor當時在一篇博文中問道：“如果我們將客戶數據的多個副本放在多個數據中心，怎么可能會發生這種事？在一些罕見的情況下，軟件缺陷會同時影響數據的數個副本。這種事偏偏落在了我們頭上。”
谷歌最后不得不使用實際的物理磁帶備份來恢復數據。最終，這家公司的多層數據保護體系確實發揮了效果，卻使得成千上萬個用戶在數天內無法使用電子郵件服務。

那這是不是可以成為對任何云服務避而遠之的理由？恐怕不是。但確實有必要認真關注你自己的數據保護措施，考慮立即著手制定一套備份或離線訪問解決方案。

AlertSite公司的Ken Godskind說：“從總體上來看，云成功運行的機率比個人運行要大得多。只不過面對互聯網時，故障造成的影響會被放大好多倍。”

第四大云服務宕機事件：Hotmail亂成一團糟

當然，盡管微軟大力推行云服務，但它并非總是能夠給出最好的例子。以微軟的Hotmail服務為例：這項服務在2010年底同樣遭到了數據庫錯誤，導致成千上萬個收件箱在辭舊迎新之際空空如也。

據微軟聲稱，這個錯誤歸咎于一段腳本，這段腳本原本用于刪除為自動測試設立的假設帳戶。但結果這段腳本誤把17000個真實有效的帳戶當成了虛設帳戶。

微軟花了三天的時間才為大多數受影響的用戶恢復服務。遺憾的是，8%受影響的電子郵件用戶不得不多等三天，之后數據才恢復如初。

面對這樣的棘手問題，連Office助手Clippy都笑不出來。

第五大云服務宕機事件：Intuit接連兩次宕機

Intuit在去年很不走運：在短短一個月內，其基于云的服務接連宕機了兩次，包括TurboTax、Quicken和QuickBooks等大受歡迎的平臺。最糟糕的情況是6月份宕機了整整36個小時。電源故障顯然導致服務出了毛病，該公司的主系統和備用系統從電網完全斷開。

屋漏偏逢連夜雨，幾個星期后Intuit遇到了另一次明顯的電源故障。除了帶來其他問題外，第二次宕機似乎還引起眾多用戶在網上大爆粗口。

一個用戶當時在Twitter上發送了這樣的消息：“宕機25個小時讓人很難接受。Intuit的一套被動的、缺乏透明的、死板的溝通方法無助于事。”

真是要命。

惠普Secure Advantage計劃的首席戰略師Chris Whitener說：“現實情況是，如果你需要絕對的可用性，現在有比選擇單單一家云服務提供商更好的解決方案。你沒必要什么都復制，但是如果另外采取一個步驟（可能是你自己備份關鍵數據），情況就完全不一樣了。”#p#

第六大云服務宕機事件：微軟的BPOS致歉

如果你那基于云的生產力套件無法使用，工作效率就很難有保障。僅僅幾周前，依賴微軟商業云服務解決方案的公司企業就遭到了這種情況：名為微軟商業生產力在線標準套件（BPOS）的這項服務在5月10日前后開始停頓。結果，付費客戶的電子郵件被延遲了長達9個小時才發送。

兩天后，就在看起來BPOS沒有故障時，郵件延遲發送的毛病又來了，發出去的郵件開始堆積如山。好像嫌這個問題不夠糟糕，微軟遇到了另一個問題：用戶們還無法登錄到微軟基于互聯網的Outlook門戶網站。

微軟在線服務部企業副總裁Dave Thompson在博客中寫道：“對于這些問題明顯帶來的不便，請允許我向諸位、我們的客戶和合作伙伴深表歉意。”

第七大云服務宕機事件：Salesforce的不幸事故

宕機一個小時聽起來似乎沒什么大不了，但是當成千上萬家公司的客戶服務運營與貴公司息息相關時，那些客戶勢必會認為那60分鐘漫長得要命。

當Salesforce.com的數據中心在去年1月宕機時，它對此可是深有體會。新年過后才四天，Salesforce.com就宣布遇到了徹底的故障——這意味著服務、備份和其他一切都完蛋了。

令人抓狂？絕對如此。令人驚訝？不完全是。

柯尼卡美能達公司旗下All Covered部門的首席信息官Tim Crawford說：“現實情況是，基于云的數據中心同樣會停止運行。過去一向如此，將來也是如此。我們一定要從現實的角度看待這個問題。”

Crawford表示，成功的云計算需要有一種不同于傳統服務器環境的理念：他認為，決定著貴公司的數據能不能經受得住偶爾宕機的是你自己，而不是別人；你要確保自己的配置具有避免宕機所需的彈性。

Crawford說：“你在選擇一家云服務提供商時，必須事先做好功課，了解對方如何提供這些服務；是否能夠提供與你自己能夠實現的冗余級別一樣好或更好的冗余級別。如果答案是否定的，那干嘛還要使用它們？”

第八大云服務宕機事件：Terremark的可怕一天

近期，Terremark可能因被韋里遜（Verizon）斥資數14億美元收購的交易而見諸報章；但是在2010年初，一起長時間的宕機事件卻讓這家云服務提供商成為被媒體競相報道的對象。

Terremark在2010年3月17日的圣帕特里克節走了霉運。這家公司的vCloud Express服務在那一天一蹶不振，建在邁阿密的數據中心宕機了將近7個小時。在這整段期間，廣大用戶無法訪問該數據中心里面存儲的數據。

不要過于追求冗余，但這起事件表明了冗余機制的重要性——要將你的關鍵數據放在不同數據中心的多臺服務器上；或者更安全的做法是，放在不同地區的多臺服務器上。還可以采取進一步的措施：將關鍵數據分散在多個提供商之間，作為一項保險措施。

IBM公司的云安全策略項目首席技術官Harold Moss提議：“你可以選擇一系列提供商來托管工作負載——某一兩家提供商充當后備提供商，另一家提供商充當主提供商。然后，你以一種安全的方式將工作負載部署到那里，確保合適的安全機制，隨后開始添加你的彈性功能。”

第九大云服務宕機事件：PayPal遭遇宕機

想體驗一把帶來很嚴重的深遠影響的云宕機事件？不妨試試幾小時無法使用PayPal服務的感覺。

這可不是假設性的演練：PayPal在2009年夏天確實遭遇宕機，導致世界各地的數百萬商家根本無法銷售產品和服務。大概有一小時的光景，其服務完全無法使用；接下來的幾小時，服務仍然時斷時續。PayPal表示，問題出在了硬件故障。

毫無疑問，這種宕機很罕見——但由于所有生意都錯失了，這次不幸的服務宕機在云計算的恥辱柱上輕松占得一席之地。

第十大云服務宕機事件：Rackspace的不順年

如果你為像美國科技博客TechCrunch和流行音樂天王Justin Timberlake這樣的知名網站和網絡紅人提供云服務，最好還是相信這一點：一旦你的服務器停止運行，人們肯定會注意到。

Rackspace在2009年數次汲取了這個教訓。這家云服務提供商在那一年前后遭到了四次重大的服務故障，使得這家公司的眾多客戶的停機時間共長達數小時。一次故障就足以讓Rackspace不得不向用戶支付相當于近300萬美元的服務折扣。

Rackspace稱這些事件“讓人痛苦不堪，非常失望”，并承諾之后會“提供長時間的高級別服務”。今天，這家公司繼續關注正常運行時間，但同時也在努力幫助用戶為不可避免的云服務故障作好防備。

Rackspace的Lew Moorman說：“如果你想建立服務器集群或建立地區冗余機制，那么現在比以前更容易做到，但你必須切實地采取那些步驟。如果你以前在企業內部做了這些步驟，你也不用擔心云服務故障了。”

從各方面考慮起來，云服務方面最大的教訓也許就是，沒有哪一臺服務器、哪一個數據中心或哪一項服務是絕對可靠的。如果你使用云服務開展業務時沒有考慮到這一點，那么我的朋友，你在完全無視實際存在的危險。