当我谈云计算宕机时,我在谈些什么?


  • 邀请注册用户

    7月22日和23日,青云召开用户大会的时候,北京机房2区(PEK2)宕机了,历时[宕机时间计算中]完全恢复。

    6月21日,阿里云香港节点9点30分左右突然全线崩溃,历时13小时,并且还不是全面恢复。

    6月6日,LeanCloud 的多项服务发生了大约4小时的中断或不稳定。

    。。。。。。

    云计算宕机时有发生,那么当我谈云计算宕机时,我在谈些什么?

    1. 宕机信息透明度

    作为云厂商,云主机宕机了,你有没有及时并尽量透明的披露宕机的信息,这体现了一个厂商的责任心和担当。你宕机了,第一时间告诉给客户(短信,邮件,后台公告,微博等),比你遮遮掩掩最后被客户电话或工单追问是不是宕机了要好。宕机期间,云厂商会进行紧张的恢复工作,更紧张的可能是客户,那么时不时的报告恢复进展,至少让用户看到你在负责任的解决问题,这样能比较好的照顾用户情绪。

    7月22号中午,主页君在从青云用户大会会场回公司的路上,就收到了青云的短信,距离宕机仅仅半小时,可谓很及时。并且,整个恢复的过程都进行了比较透明的汇报。(具体可以查看青云官方微博@青云QingCloud)

    2. 恢复时间

    由于不可抗力或人祸导致云主机机房宕机,用户获取了宕机信息后,最关切的消息是什么时候会恢复。厂商估计的恢复时间是否比较短,并且接近实际恢复的时间,极大的考验着云厂商的能力。

    下面是LeanCloud官方宕机报告的一段话。

    「在这个过程中,除了事故本身,我们在沟通上也犯了一些错误。当用户询问服务恢复时间时,我们给出了过于乐观的估计,但因为以上所说的原因,多个 MongoDB 节点经过了多次重启,实际恢复服务的时间晚了很多,这给用户造成了进一步的困扰。」

    LeanCloud预估恢复服务时间和实际恢复时间的差距较大,这就是对恢复时间严重的估计不足。作为码农的主页君其实还能谅解,记得曾经预估一个bug,大概需要40分钟fix,结果,主页君真真花了4个小时。LeanCloud和主页君都需要再苦练内功。

    3. 道歉

    “有些厂家的服务没有做好就上线,出了问题只能say sorry喽。” --青云CEO黄允松在2015年用户大会上

    出了问题,笑着脸道个歉至少会让用户至少让用户看到了你的诚意。请查看原文,阅读青云的道歉。

    4. 赔偿

    云主机服务宕机造成了用户损失,云厂商应该有赔偿措施,云厂商应该有赔偿措施,云厂商应该有赔偿措施。重要的事情还是要说三遍。

    迄今为止,宕机的厂商不少了,但是,鲜有对宕机做出赔偿的。影响最深刻的是在公司班车上读完了LeanCloud长长的,详尽的和感人的宕机事故报告,纳闷的是赔偿呢?

    据主页君了解到,暂时只有青云对用户做出了赔偿。下面是青云的赔偿邮件。

    「对所有受到本次网络故障影响的用户,我们决定返还您一个月在PEK2的全部消费金额作为赔偿。 虽然赔偿并不能挽回对您的业务造成的影响,但我们希望通过这种方式体现我们最真诚的歉意,也希望您能够一如既往地信任我们。有您的理解与支持,青云必不辱使命。」

    从青云云主机管理端可以看到赔偿的金额。主页君得到了242元的赔偿。
    qingcloud_repay.PNG

    青云在这一块,可谓业界良心!

    后话

    1. 取巧

    这其实是赞美。青云在宕机当天,在主机控制台冒出了宕机提示,并在微博上发布了宕机信息及恢复进度,并没有发布在网站或他自己的社区里。这种取巧的做法,主页君还是要赞美一下。

    一来,青云发布了信息,让用户有了实时了解的渠道。

    二来,避免了宕机信息在互联网大面积蔓延。控制台信息提示在宕机恢复后就消失了,微博不支持Google(现在要叫Alphabet了)和百度的直接检索。可谓取巧的高招。

    相反,LeanCloud真可谓勇气尤嘉,各位可以去它官网上感受下https://blog.leancloud.cn/。

    ** 2. 用户自己做可用性**

    差钱儿的用户,比如主页君,同一个应用只会购买一个机房的服务器,如果这个机房宕机了,只能呵呵了。

    如果不差钱儿的用户,建议同一个应用通过负载均衡,部署到不同机房的主机上,即使是同一个云提供商。不过,这就涉及到数据同步和一致性的问题了,这个暂时不表,以后可另开专题讨论。

    题图: 个人收藏“背影”系列图片,来源不祥,或许本科四年
    关注Geek2014公众号
    640.jpg


登录后回复
 

与 青云QingCloud 社区 的连接断开,我们正在尝试重连,请耐心等待