和許多小公司一樣，我們使用Google共享我們的日歷。不可否認，Google日歷服務很好用，它能和電子郵件及同步服務器很好地集成，并且最重要的是，它是免費的，正因為如此，Google日歷擁有上百萬忠實用戶，按常理來說它不會發生大故障，因為影響的用戶太多了，但截至上周二，Google的日歷服務中斷了8天，時間之長讓人咋舌，也讓許多用戶憤怒，雖然現在事情已經過去，但我們應該從這起非比尋常的事故中學到什么教訓呢？

　　這起事故讓0.2%的Google日歷用戶中斷了多天的訪問，首先我們看看Google在這起事故中的處理方法，然后我們總結一下這起事故的教訓。

　　Peter Sandman開發了一種方法預測人們在不愉快事件中的反應，越高表示風險越大，對局勢的控制難度越大。這就是為什么我們更擔心被鯊魚襲擊，而不是被烤箱電死的原因，即使我們被烤箱電死的可能性要高出30倍。

使用云服務時，用戶是看不到服務器的，因此他們是無法運行診斷程序的，也不能跑到大廳叫IT人員來救援，即使經驗豐富的用戶也無法準確地知道恢復數據需要多少時間，甚至連該做些什么都不知道，服務關閉時，用戶看到的是一個空白頁，不管這是暫時的，還是會造成數據完全丟失，用戶都幫不上忙。

　　Google沒有及時調配合理的資源修復這起事故，導致用戶抱怨非常多，此外，一些用戶使用的第三方產品也受到波及，而Google對此毫無解決辦法，使得事態火上加油，Google也未向用戶及時發出通知，因此用戶的情緒失控是太正常不過了。

　　你的團隊可以學到什么

　　◇不用說，首先學到的教訓是要經常備份重要數據，關鍵時候才不會引起慌張，但沒有人這么做，因為它不是自動的，無論如何，至少要找到一個半自動方法每周完整備份一次所有系統數據，確保數據庫管理員（DBA）擁有定期備份元數據的權限（但遺憾的是，我還沒有在任何SaaS產品上看到這項功能是自動的）。

　　◇在注冊云服務之前，確保他們的服務水平協議（SLA）涵蓋了緊急情況和災難恢復條款，想辦法了解清楚他們的系統性能/正常運行時間，象Google這樣光用“大拇指向上/大拇指向下”的圖標表示是不夠的。

　　◇詢問服務供應商最近一次服務中斷持續了多長時間，最好是要求對方提供一個甘特圖或電子表格–充分描述和分析了歷史上曾經發生的事故，以及他們做出的反應，如果他們不愿意向你提供這些證據，即使你愿意簽署保密協議他們也不愿意提供的話，在這一點上，你應該毫不客氣地給他們打0分，最起碼要對方告訴你最后一次宕機的日期。

　　◇找人了解他們的論壇或其它在線技術社區對他們的評價，確定他們在最近一次服務故障期間和用戶的溝通，重點關注其更新的頻率。

　　◇如果你們公司嚴重依賴于云服務，應該著手建立自己的應急響應系統，以補充云供應商在下面三個方面的不足之處：

　　（1）解答用戶的疑問，確保用戶遇到的問題的確是云供應商的問題。

　　（2）確定問題是否是云服務和其它軟件之間的交互引起的，進一步落實問題的根源。

　　（3）提供清晰和完整的問題、解決過程、結果和時間表，并做好及時更新，不要輕易承諾解決問題的最后期限，那樣會讓你和SaaS供應商的名譽掃地。

　　原文名：Google Calendar Outage: Lessons Learned  作者：David Taber