代码：只需七行，让B站为我崩溃三小时

前

言

/ 2022.7.25

最近，B站官方发布了一篇文章"2021.07.13 我们是这样崩溃的"，回顾了B站崩溃事件的诱因、根因、处理过程以及优化改进，才发现事情缘由竟是一个小小的字符“0”。

01

“至暗时刻”起因经过

去年7月13日晚上10点52分，B站大面积崩溃，不少人趁乱搞起了“网络诈骗”，负责搞定站点可靠性的工程师（SRE）和B站的客服都收到了大量网站打不开的报警。

处理方案

CPU 被不知道哪里来的刺客给占用光了算力，跑满100%，无法正常处理业务。

B站相关人员从23：25到23：55一直尝试各种方式恢复服务，甚至使用了“万物重启大法”，但都未能达到预期效果，最后只能全部重建SLB集群。

在紧张刺激的一小时后，新的 SLB 配置成功，原本导向主站的流量也慢慢得开始迁移过去。于是，在崩溃了3个小时之后，B站的业务总算是勉强恢复。

02

崩溃了这么久，问题一定很大吧

早在排查问题时，B站技术团队就已兵分两路，因为不仅得让业务跑起来，也得找到根本原因，防止二度暴雷。于是一队开始重建新的SLB服务，另外一队则继续坚持排查问题。

诡计多端的“0”

负责排查问题的同学也没让人失望，在时间压力大大放缓之后，找出了真相。

没错，不是大楼停电，服务器没有爆炸，程序员也没有删库跑路。B站这次崩的根因，仅仅是因为一个求最大公约数的函数没写好。

咱学过编程都知道，“罪魁祸首”是一种用辗转相除法来计算最大公约数的递归函数。

问题的根本也就是小学数学都会学到的，把 0 当除数的事情发生了。由于Lua的“智慧”，程序的终止条件无法实现。

这样来回跑几个循环之后，原本用来计算 a 和 b 的最大公约数的函数 _gcd(a,b) 就变成了一个停不下来的函数 _gcd(nan,nan)。

吃了炫迈一样，根本停不下来，直接把 CPU 资源给吃满了。

（B站官方说明）

背后一桩桩一件件，归根结底其实就一句话：0，它真的不兴除啊。

03

大雄锐评

事件发生后，为了补偿耽误的时间，官方给所有B站用户都补偿了一天的大会员，据机智网友粗略估算，就是这简简单单的7行代码，让B站少说亏了1亿5750万元。

时隔一年，官方愿意将“至暗时刻”事件的起因、经过、结果复盘分享给普罗大众，不仅是对自己的反思，也是给同行提供的一个学习方向。

这是一次实打实的经验教训，哔哩哔哩也提供了一个较为合理的解决方法，这对于今后突发事件的解决也有很大的帮助。

毕竟，#啥啥崩了#的词条在热搜上还是经常占据一席之地的。

END

阅读原文

了解老九学堂暑期线下班详情