和许多小公司一样，我们使用Google共享我们的日历。不可否认，Google日历服务很好用，它能和电子邮件及同步服务器很好地集成，并且最重要的是，它是免费的，正因为如此，Google日历拥有上百万忠实用户，按常理来说它不会发生大故障，因为影响的用户太多了，但截至上周二，Google的日历服务中断了8天，时间之长让人咋舌，也让许多用户愤怒，虽然现在事情已经过去，但我们应该从这起非比寻常的事故中学到什么教训呢？

　　这起事故让0.2%的Google日历用户中断了多天的访问，首先我们看看Google在这起事故中的处理方法，然后我们总结一下这起事故的教训。

　　Peter Sandman开发了一种方法预测人们在不愉快事件中的反应，越高表示风险越大，对局势的控制难度越大。这就是为什么我们更担心被鲨鱼袭击，而不是被烤箱电死的原因，即使我们被烤箱电死的可能性要高出30倍。

　　使用云服务时，用户是看不到服务器的，因此他们是无法运行诊断程序的，也不能跑到大厅叫IT人员来救援，即使经验丰富的用户也无法准确地知道恢复数据需要多少时间，甚至连该做些什么都不知道，服务关闭时，用户看到的是一个空白页，不管这是暂时的，还是会造成数据完全丢失，用户都帮不上忙。

　　Google没有及时调配合理的资源修复这起事故，导致用户抱怨非常多，此外，一些用户使用的第三方产品也受到波及，而Google对此毫无解决办法，使得事态火上加油，Google也未向用户及时发出通知，因此用户的情绪失控是太正常不过了。

　　你的团队可以学到什么

　　不用说，首先学到的教训是要经常备份重要数据，关键时候才不会引起慌张，但没有人这么做，因为它不是自动的，无论如何，至少要找到一个半自动方法每周完整备份一次所有系统数据，确保数据库管理员（DBA）拥有定期备份元数据的权限（但遗憾的是，我还没有在任何SaaS产品上看到这项功能是自动的）。

　　在注册云服务之前，确保他们的服务水平协议（SLA）涵盖了紧急情况和灾难恢复条款，想办法了解清楚他们的系统性能/正常运行时间，象Google这样光用“大拇指向上/大拇指向下”的图标表示是不够的。

　　询问服务供应商最近一次服务中断持续了多长时间，最好是要求对方提供一个甘特图或电子表格——充分描述和分析了历史上曾经发生的事故，以及他们做出的反应，如果他们不愿意向你提供这些证据，即使你愿意签署保密协议他们也不愿意提供的话，在这一点上，你应该毫不客气地给他们打0分，最起码要对方告诉你最后一次宕机的日期。

　　找人了解他们的论坛或其它在线技术社区对他们的评价，确定他们在最近一次服务故障期间和用户的沟通，重点关注其更新的频率。

　　如果你们公司严重依赖于云服务，应该着手建立自己的应急响应系统，以补充云供应商在下面三个方面的不足之处：

• 解答用户的疑问，确保用户遇到的问题的确是云供应商的问题。
• 确定问题是否是云服务和其它软件之间的交互引起的，进一步落实问题的根源。
• 提供清晰和完整的问题、解决过程、结果和时间表，并做好及时更新，不要轻易承诺解决问题的最后期限，那样会让你和SaaS供应商的名誉扫地。