您的位置:知识库 » IT业界

从Google日历宕机事件学到的教训

来源: 51cto.com  发布时间: 2010-10-18 21:03  阅读: 1072 次  推荐: 0   原文链接   [收藏]  
摘要:截至上周二,Google的日历服务中断了8天,时间之长让人咋舌,也让许多用户愤怒,虽然现在事情已经过去,但我们应该从这起非比寻常的事故中学到什么教训呢?

  和许多小公司一样,我们使用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

0
0
 

IT业界热门文章

    IT业界最新文章

      最新新闻

        热门新闻