语雀宕机整整8个小时，数字花园裂开了

昨天10月23日14点到22点半，凉了8小时有余

这故障时长，放眼整个互联网也是炸裂般的存在

要是再晚个半小时修复，差点连 3 个 9 的（99.9%）可用性都保证不了

3个9可用性是用来衡量系统的可用性

目前，业界衡量系统可用性的方式主要有2种：

• 时间纬度的系统可用性。
• 请求纬度的系统可用性。

上述两个可用性的计算方式为：

• 时间纬度的系统可用性：
  Availability = 程序正常运行时间 / (程序正常运行时间 + 系统故障时间)
• 请求纬度的系统可用性：
  Availability = 成功请求数量 / 请求总数量

其中对于时间纬度的系统可用性，其概念为：从时间纬度，来评估系统的正常运行时间及系统可用性。

时间维度的系统可用性，就是我们经常提起的X个9。

X个9表示以年/月/日等为单位，在指定的时间范围内，系统可以正常使用时间与总时间之比。 例如，我们以1年为时间单位，可以得出：

• 3个9：(1-99.9%)36524=8.76小时，表示该系统在连续运行1年时间里最多可能的业务中断时间是8.76小时
• 4个9：(1-99.99%)36524=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟
• 5个9：(1-99.999%)36524*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟

根据如上的定义，我们可以总结出一张表格：

从上面的表格，我们也可以得出一个结论：

• 系统的99数越高，系统的可用性越高。

如果你不知道语雀的话，我先用一句话给你铺垫一下：语雀是孵化自蚂蚁集团，背靠蚂蚁，这样你再想想长达 8 小时的宕机，是不是就更加的有点匪夷所思

作为程序员，大家聊到这里的时候，一遍都会谈到高可用、容灾备份、两地三中心、异地多活、同城双活…

可见语雀并没有搭建这样的策略，实际上要建设上述这样工作成本也非常大

这件事儿也给大家提了个醒，自己写的文档，记得还是在本地留存一份。

笔记类软件现在是很卷的，除了大家耳熟能详的有道云、印象笔记、网易、为知，现在的 Notion、obsidian、Logseq......以及越来越多的本地软件，几乎可以说，每个大厂都有各自的笔记类产品，有的是偏向于在线 文档，比如金山文档、腾讯文档。有的是夹在办公软件里面，以协同为主，比如飞书文档

这是语雀面临的外部竞争

而语雀作为阿里系，内部还有一个钉钉文档与之赛马，而语雀的创始人玉伯与今天 4 月底离开蚂蚁，传言入职了飞书

这就很巧了，飞书文档也很厉害

语雀，这波属实焦灼，内忧外患啊

具体的故障原因相信官方不久就会发布公告进行同步，故障不可怕，毕竟没有什么服务敢保证是一定不会挂的。

像之前 B 站也挂过，然后还发了一篇关于故障的公众号文章，所以故障不可怕，作为技术人员，我们需要的是从故障中学会成长。

作为笔记软件，多端同步是肯定需要的，了不起没做过笔记软件，但是感觉笔记软件本地化是不是也是需要的。

像这次故障，不仅网页打不开，连本地的客户端都无法使用，这无疑增加了影响面。

另外看到了搞笑的说法

当然上面的说法笑一笑就好，因为在阿里内部使用的并不是公网的语雀，而是内部的阿里语雀，两个虽然是一样的软件，但是是独立的

相信这一次的故障也会给语雀团队一个警钟，不管最终的原因是什么，都希望语雀可以越来越好