当我谈云计算宕机时，我在谈些什么？

arron刘

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. 用户自己做可用性**

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

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

题图： 个人收藏“背影”系列图片，来源不祥，或许本科四年


更多详情请参阅：青云社区。