事件三：Rackspace云服務(wù)中斷。

2009年6月，Rackspace遭受了嚴(yán)重的云服務(wù)中斷故障。供電設(shè)備跳閘，備份發(fā)電機(jī)失效，不少機(jī)架上服務(wù)器停機(jī)。這場事故造成了嚴(yán)重的后果。

為了挽回公司聲譽(yù)，Rackspace更新了所有博客，并在其中詳細(xì)討論了整個(gè)經(jīng)過。但用戶并不樂意接受。

同年11月，Rackspace再次發(fā)生重大的服務(wù)中斷后。事實(shí)上，它的用戶是完全有機(jī)會(huì)在服務(wù)中斷后公開指責(zé)這位供應(yīng)商的，但用戶卻表示“該事故并不是什么大事。”看來Rackspace不是走好運(yùn)，而是持續(xù)提供了充足更新并快速修復(fù)了這些錯(cuò)誤。

在服務(wù)中斷致使其業(yè)務(wù)脫機(jī)15到20分鐘后，博客服務(wù)提供商Posterous的創(chuàng)建者之一Sachin Agarwal就發(fā)表了自己的觀點(diǎn)。Agarwal對此并不生氣，相反，他表示Rackspace在這件事上做得“很透明”，處理問題也很及時(shí)到位。

看來，如果沒有嚴(yán)重?cái)?shù)據(jù)的丟失，并且服務(wù)快速恢復(fù)，用戶依舊保持愉快的使用體驗(yàn)。對于所謂的“100%正常運(yùn)行”，大多數(shù)用戶似乎不會(huì)因?yàn)榕紶柕男∈鹿识艞壒?yīng)商，只是不要將問題堆積起來。

事件四：Salesforce.com宕機(jī)。

2010年1月，幾乎6萬8千名的Salesforce.com用戶經(jīng)歷了至少1個(gè)小時(shí)的宕機(jī)。

Salesforce.com由于自身數(shù)據(jù)中心的“系統(tǒng)性錯(cuò)誤”，包括備份在內(nèi)的全部服務(wù)發(fā)生了短暫癱瘓的情況。這也露出了Salesforce.com不愿公開的鎖定策略：旗下的PaaS平臺(tái)、Force.com不能在Salesforce.com之外使用。所以一旦Salesforce.com出現(xiàn)問題，F(xiàn)orce.com同樣會(huì)出現(xiàn)問題。所以服務(wù)發(fā)生較長時(shí)間中斷，問題將變得很棘手。

這場服務(wù)中斷還沒有對公司造成很大影響，它同VMware合作的VMforce在今年春季引起很大反響，同時(shí)Salesforce.com首席執(zhí)行官在服務(wù)中斷出現(xiàn)后的一個(gè)月內(nèi)又開始宣稱Salesforce.com是“最大的云計(jì)算企業(yè)”。

這次中斷事故讓人們開始質(zhì)疑Salesfore.com的軟件鎖定行為，即將該公司的Force.com平臺(tái)綁定到Salesforce.com自身的服務(wù)。但總之，這次事件只是又一次地提醒人們：百分之百可靠的云計(jì)算服務(wù)目前還不存在。