本文主要是介绍语雀宕机整整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 站也挂过，然后还发了一篇关于故障的公众号文章，所以故障不可怕，作为技术人员，我们需要的是从故障中学会成长。
作为笔记软件，多端同步是肯定需要的，了不起没做过笔记软件，但是感觉笔记软件本地化是不是也是需要的。
像这次故障，不仅网页打不开，连本地的客户端都无法使用，这无疑增加了影响面。
另外看到了搞笑的说法
当然上面的说法笑一笑就好，因为在阿里内部使用的并不是公网的语雀，而是内部的阿里语雀，两个虽然是一样的软件，但是是独立的
相信这一次的故障也会给语雀团队一个警钟，不管最终的原因是什么，都希望语雀可以越来越好
这篇关于语雀宕机整整8个小时，数字花园裂开了的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
