上周，有媒體爆料，谷歌Gmail網絡郵件服務再次發生中斷事件，導致Gmail服務中斷了90多分鐘。不過，谷歌坦誠地公布了這一消息，承認在美國東部時間周四上午11點，發生了這樣的故障并且宣布它在12點40分解決了這個問題。
據了解，谷歌稱這個故障影響到1.38%的Gmail用戶。目前據統計，Gmail擁有3.5億活躍用戶。假如這個故障影響到1.38%的活躍用戶，那么，這個數字就是大約479萬。受影響的用戶不能訪問谷歌Gmail賬戶。
可以斷定，這不是IT巨頭第一次出現網絡故障，也肯定不是最后一次。
2012年谷歌網絡服務再中斷
在上周初，谷歌也發生Spreadsheets服務發生了大約兩個小時的故障，許多用戶受到影響。這個故障是當用戶試圖打開一個文件的時候，屏幕上頻繁地顯示驗證碼。并且，在2012年的四月中旬，谷歌同樣是Gmail服務也曾發生一次故障，那一次影響的面積更大，影響到3300多萬用戶。
另外，在2011年3月，谷歌郵箱再次爆發大規模的用戶數據泄漏事件，大約有15萬Gmail用戶在周日早上發現自己的所有郵件和聊天記錄被刪除，部分用戶發現自己的帳戶被重置，谷歌表示受到該問題影響的用戶約為用戶總數的0.08%.
谷歌在Google Apps狀態頁面表示：“部分用戶的Google Mail服務已經恢復過來，我們將在近期拿出面向所有用戶的解決方案。”它還提醒受影響的用戶說：“在修復帳戶期間，部分用戶可能暫時無法登錄郵箱服務。”
Google過去也曾出現故障，但整個帳戶消失卻是第一次。在2009年出現最嚴重的一次故障，有兩個半小時服務停頓，許多人當時曾向Google投訴需用這個系統工作。接二連三出錯，令全球用戶數小時不能收發電郵。Google及微軟等科技企業近年大力發展云計算，盼吸引企業客戶，但云計算儲存多次出事，恐打擊用戶信心。
早在2009年2月24日，谷歌的Gmail電子郵箱爆發全球性故障，服務中斷時間長達4小時。谷歌解釋事故的原因：在位于歐洲的數據中心例行性維護之時，有些新的程序代碼(會試圖把地理相近的數據集中于所有人身上)有些副作用，導致歐洲另一個資料中心過載，于是連鎖效應就擴及到其它數據中心接口，最終釀成全球性的斷線，導致其他數據中心也無法正常工作。
事件過去數日之后，Google宣布針對這一事件，谷歌向企業、政府機構和其他付費GoogleAppsPremier Edition客戶提供15天免費服務，補償服務中斷給客戶造成的損失，每人合計2.05美元。
遭遇這樣悲慘命運的不僅只有谷歌一個，例如，亞馬遜、谷歌、Salesforce.com等一些云服務提供商都有過類似的衰事。
亞馬遜云安全事件。
2011年4月21日凌晨，亞馬遜公司在北弗吉尼亞州的云計算中心宕機，這導致包括回答服務Quora、新聞服務Reddit、Hootsuite和位置跟蹤服務FourSquare在內的一些網站受到了影響。
這些網站都依靠亞馬遜的這個云計算中心提供服務。Quora網站周四上午和下午在英國都無法訪問。這個網站完全由亞馬遜的EC2(彈性云計算)服務托管，就像FourSquare和許多其它網站一樣。
受到影響，Hootsuite網站的響應速度很慢，而Reddit網站的搜索服務不能使用。Reddit網站稱，亞馬遜目前正出現服務下降的情況。亞馬遜云服務中斷持續將近4天，截止編者發稿時，Hootsuite、Reddit、FourSquare、Quora等網站已經基本恢復正常。
根據分析，亞馬遜的云計算狀態網頁目前顯示故障發生在北弗吉尼亞州的云計算中心。這個中心為許多Web 2.0公司提供服務。這次宕機故障發生在美國西海岸的大約凌晨1點40分，英國夏令時上午9點40分，并且從那時起一直有故障。
分析人士稱，北弗吉尼亞州云計算中心是亞馬遜經營的許多云計算中心之一，按照常規，系統的設計之處應用會考慮，一個中心宕機不會中斷其它的云計算中心，也不會影響使用那個服務的用戶。
此次，亞馬遜云計算中心沒有繞過北弗吉尼亞州云計算中心的故障把工作量轉移到許多其它的云計算中心，令人生疑。服務器宕機，這在人們預想當中，沒有那么嚴重。最簡單的，雙機熱備，一臺服務器宕機，另外一臺服務器在短時間內可以啟動，并不會影響用戶的服務。但是，亞馬遜的云計算中心這次不同，宕機影響了這么多用戶的正常云服務，而且引起用戶服務中斷的，還是亞馬遜引以為傲的彈性云，這對于云計算服務商剛剛建立起來的信任，絕對是一次沉重的打擊。
經過一番緊急的搶救，亞馬遜的云服務恢復了正常。但是，這個事件留給用戶的惡劣影響有些深遠，用戶大呼“傷不起”.
好在亞馬遜的態度還算坦誠。4月30日，亞馬遜為宕機事件向用戶發表了5700多字的道歉信，聲稱亞馬遜公司已經知道漏洞和設計缺陷所在的地方，它希望通過修復那些漏洞和缺陷提高EC2(亞馬遜ElasticComputeCloud服務)的競爭力。亞馬遜已經對EC2做了一些修復和調整，并打算在未來幾周里擴大部署，以便對所有的服務進行改善，避免類似的事件再度出現。
在賠償方面，亞馬遜表示，將向在此次故障中受到影響的用戶提供10天服務的點數(Credit)，這些點數將自動充值到受影響的用戶帳號當中。但是，對于以后如何避免出現類似事件，并沒有提到任何法律上的保證。
據了解，亞馬遜云服務中斷持續了近4天，但是在法律上卻沒有違反亞馬遜EC2服務的服務等級協議(簡稱SLA)。亞馬遜的解釋是，亞馬遜出現故障的是EBS和RDS服務，而不是EC2服務，從法律上講，它并沒有違反服務等級協議。并且，對于亞馬遜提出的應對宕機事件的建議--多點備份，僅僅是一個技術規范并非合同保障。這些，似乎都不能給云服務的用戶帶來信心。
表面看來，亞馬遜宕機事件似乎有一個完美結局：廠商及時修復漏洞，書面道歉，賠償損失。但是，用戶心理上對云服務的恐懼似乎并不那么容易康復，未來，亞馬遜可能不僅僅要在技術上、還需要在制度和法律上給予用戶更多的保證，才能才能漸漸修復被此次宕機事件損壞的名聲。
Rackspace云服務中斷事件
2009年6月，Rackspace遭受了嚴重的云服務中斷故障。供電設備跳閘，備份發電機失效，不少機架上服務器停機。這場事故造成了嚴重的后果。
為了挽回公司聲譽，Rackspace更新了所有博客，并在其中詳細討論了整個經過。但用戶并不樂意接受。
同年11月，Rackspace再次發生重大的服務中斷后。事實上，它的用戶是完全有機會在服務中斷后公開指責這位供應商的，但用戶卻表示“該事故并不是什么大事。”看來Rackspace不是走好運，而是持續提供了充足更新并快速修復了這些錯誤。
在服務中斷致使其業務脫機15到20分鐘后，博客服務提供商Posterous的創建者之一Sachin Agarwal就發表了自己的觀點。Agarwal對此并不生氣，相反，他表示Rackspace在這件事上做得“很透明”,處理問題也很及時到位。
看來，如果沒有嚴重數據的丟失，并且服務快速恢復，用戶依舊保持愉快的使用體驗。對于所謂的“100%正常運行”,大多數用戶似乎不會因為偶爾的小事故而放棄供應商，只是不要將問題堆積起來。
Salesforce.com服務器宕機。
2010年1月，幾乎6萬8千名的Salesforce.com用戶經歷了至少1個小時的服務器宕機。
Salesforce.com由于自身數據中心的“系統性錯誤”,包括備份在內的全部服務發生了短暫癱瘓的情況。這也露出了Salesforce.com不愿公開的鎖定策略：旗下的PaaS平臺、Force.com不能在Salesforce.com之外使用。所以一旦Salesforce.com出現問題，Force.com同樣會出現問題。所以服務發生較長時間中斷，問題將變得很棘手。
這場服務中斷還沒有對公司造成很大影響，它同VMware合作的VMforce在今年春季引起很大反響，同時Salesforce.com首席執行官在服務中斷出現后的一個月內又開始宣稱Salesforce.com是“最大的云計算企業”.
這次中斷事故讓人們開始質疑Salesfore.com的軟件鎖定行為，即將該公司的Force.com平臺綁定到Salesforce.com自身的服務。但總之，這次事件只是又一次地提醒人們：百分之百可靠的云計算服務目前還不存在。
小結：早在2010年5月份，埃森哲與中國電子學會共同發布了一份名為《中國云計算發展的務實之路》的報告。報告指出，安全問題是全球對云計算最大的質疑。而這種擔憂在中國尤為突出，“以至于首席信息官們如履薄冰，特別是面對公有云服務時”.
云安全問題一直是全球政府和企業都較為頭痛的難題，如果能夠跨越這一關，那么，云服務則能夠順利地得到大范圍應用，反之則止步不前。所以，可以斷定宕機事件的發生，在很大程度上，將使得其在全球特別是在中國推廣云服務業務更加困難。這正是，國內很多企業和政府更加相信私有云的安全性。
但是，如果僅僅從這些云服務宕機事件，就得出結論：云計算一無是處，不該被推廣!這似乎有些太過于武斷。安全事件，并不僅僅是云計算的專利，任何IT系統都將承受來自安全方面的壓力，不管是來自于天災，還是人禍。
宕機事件使得人們進一步思考，公有云面臨的安全問題。盡管公共云擁有眾所周知的成本優勢，但是用戶不得不提防其存在的安全性、法規遵從和服務質量的隱患。既然數據由第三方托管，客戶就希望服務提供商保證數據安全，既不丟失也不被非法訪問，遵從法規對存儲系統和數據保存位置的要求，并通過網絡提供低延遲、高可用的服務。
京公網安備 11010502049343號