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

语雀宕机整整8个小时,数字花园裂开了_第1张图片
语雀宕机整整8个小时,数字花园裂开了_第2张图片
昨天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分钟

根据如上的定义,我们可以总结出一张表格:
语雀宕机整整8个小时,数字花园裂开了_第3张图片

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

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

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

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

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

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

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

这是语雀面临的外部竞争

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

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

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

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

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

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

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

另外看到了搞笑的说法
语雀宕机整整8个小时,数字花园裂开了_第4张图片

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

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

你可能感兴趣的:(1024程序员节)