昨天下午（10月23日）语雀崩了，今天互联网上讨论的特别热烈。因为据说半夜才恢复，修复时间接近10个小时。想想数月之前，阿里云刚刚经历了香港机房停摆48小时的重大安全事故，真是祸不单行啊。
背景
有些同学可能不了解语雀是什么？我简单解释下。语雀就是一个在线文档服务，在线文本、表格这种，可以用来做笔记、知识库、产品文档等。个人可以用，也可以做团队协作。能免费用，也有一些收费功能。
有些同学可能也不了解这和阿里有什么关系，我解释下：语雀目前是蚂蚁集团下的产品，蚂蚁集团的主要产品是支付宝，支付宝和阿里是什么关系不用多说吧，语雀和阿里的关系大家也就懂了。
其实我所在公司的业务也受到了一点点影响，有个产品的帮助文档放到了语雀上，昨天下午客户给我们反馈打不开帮助，我们才知道语雀崩了。不过好在还可以人工服务，所以客户的反应并不激烈。然后技术这边就不断的尝试访问，看看什么时候能恢复，结果到下班时间了也没恢复。本着对阿里的信任，我们也下班了😂（实际是没人喜欢看文档）
故障原因
今天语雀恢复了，本着对技术的强烈好奇心，我们特别想了解下到底是什么样的故障导致这么长的恢复时间。然后先去官网看看有没有什么公告，结果什么也么有，这就有点诡异了，按说这种知名大企业不应该如此啊。
没有就没有吧，看看大家怎么说的。
先看吐槽型的评论：
- 两地三中心灾备 就是骗领导的 数据一致性 很难做到 基本是切过去就切不回来 还是12306的多中心 多写靠谱
两地三中心一般是金融级的故障防范措施，虽然语雀是蚂蚁金服的，但是产品定位够不上金融级，异地多活也够呛，顶多是在存储和加密上下下功夫。
- 服务器能瘫痪10小时，真TM人才，应急处理能力太差！
一个系统做的久了，里边会产生各种各样千奇百怪的组件，没有人能面面俱到，所以有些问题会很难找。不过10小时确实夸张了，估计今年的3.25提前锁定了。
- 估计裁了不少35岁以上老员工。。。出一点小故障都没人搞的定......
35岁转行虽然不是阿里最先搞出来的，但是向社会输送人才可是马老师说的，这个锅不好甩。程序员的流动还是比较频繁的，特别是3.25的存在，如果系统的设计没有管理好，就会出现某个模块谁也不想管、谁也不敢动的问题，动了就game over，而且很难排查。
再看原因分析型的评论：
- 语雀崩了，维修指南在语雀里，所以修了这么长时间。
当然这是个搞笑的说法。不过也说明了多处备份的重要性。比如银行，不仅将数据保存到计算机系统中，还保留了纸质的凭证。对于我们普通人来说，也很有必要将个人信息保存在不同的地方，比如不同的云盘、本地磁盘、电子邮箱等，以及定时备份数据。
- 3系列重定向报错，问题多半出在LSB或者网关配置上。
这个原因确实很有可能，也就是url跳转死循环了，浏览器停止访问，有用户看到了 too many redirects 的错误。
不过语雀不应该只有一个负载均衡和网关节点，配置的变更也要经过一系列的流程处理，如果因为修改配置出现了问题，应该能快速的回滚，或者下线存在问题的节点，不应该搞这么久。
- 据说是底层数据库机房挂了...
这个说法不知如何考证。不过数据库出现问题也是很有可能的，某个程序可能向数据库中做了大量数据的变更，因为数据库比较大，或者数据逻辑比较复杂，恢复数据的变更需要很长的时间。
以上都是根据网络传言做的一些分析，至于真实原因，没有进一步的可靠消息，我们也很难搞的清楚了。
赔偿问题
按说出了这么大的问题，语雀应该对付费用户有所补偿，特别是一些重度用户、把语雀用在核心业务上的用户，不过目前还没看到这方面的消息，可能还在评估吧。
如果语雀要对用户进行补偿，那么也就是承认自己存在责任，服务没有达标。那么怎么评估服务是否达标呢？
一般来说服务都有一个质量保证，像这种网络服务，一般会保证每年多少小时以内的中断时间，常见的说法是几个9，比如99.9%代表一年最多允许8小时46分钟服务不可用。我在网上公开资料中没有找到语雀的SLA，所以接近10个小时的中断服务是否可以认定为服务不达标也是不明确的。
那么还有什么办法来认定责任呢？很多产品都有一个服务协议，上边会说免责事由，我们看看语雀的，不在免责范围内的就是它要承担的。
协议中提到了一些不可抗力，在这些情况下语雀不承担责任，也很有道理，语雀也没办法解决嘛。只是不知道这次的问题是否属于不可抗力。
下面还有一段是关于赔付额度的，我粗略解释下：即使语雀承担责任进行赔付，也不会超过你交给它的服务费；对于你使用语雀带来的业务损失，语雀不承担责任。
总结
语雀这次的事故比较离奇，故障原因不清，赔偿问题不清。作为技术开发者，任何时候都要对系统保持敬畏之心，一个小小bug就可能导致业务上的重大损失。
后记
写完文章后，看到语雀在微博上发了个新的公告，详细解释了问题出现的原因，也给出了赔偿方案，后续我再解读下。