如何看待 2021.07.13 B 站崩溃事件

[Stendan]

分析报告： https://www.bilibili.com/read/cv17521097

2022.07.16 14:00-17:00 直播预告

B 站“713 事故”后的多活容灾建设优化
分享嘉宾曾深度参与 713 故障处理，本次分享将对 713 部分问题做答疑解惑，同时还会分享 B 站常见的高可用方案和故障后的多活容灾建设优化。

https://www.bilibili.com/read/cv17581401

[chendy]

出门左转知乎

[elfive]

有什么好看的？
站在程序员的角度，没人能写出 100%不出问题的代码，都是一种概率妥协而已。

[storyxc]

昨天用手机看的。

[Xhack]

楼主 感觉像是键盘侠之类的，我坐着 拿手机看的 然后呢？

[teenight]

以平常心看待

[imdong]

怎么看？直播围观咯。

https://files.catbox.moe/gky3wt.jpeg

[manshisan]

@imdong 关注了

[jinliming2]

事故发生一周年，B 站出了事故分析报告……
重启没用，回滚没用，最终还是重装解决 99 ％ 的问题……

[Stendan]

@Xhack 生活如意，没空对线

[R18]

希望大公司多出这种文章内容

[krly0912]

@jinliming2 看了事故分析报告解析，是 7 层 slb 的负载均衡更新了功能，一行 lua 代码因为类型转换原因导致无限递归造成的。cpu 直接打到 100%。重启后诱发因子消失了，所以正常了

[lixiaobai913]

2022.07.14 的 QQ 上午发送不了离线文件怎么看待？

[EastLord]

我还以为是 2022 年

[equationl]

@jinliming2 要是重装也没用是不是该到重买了（

[leido]

重点是, 去年的事怎么今年才出报告...

[isno]

@leido 大公司信息公开都是要审核 走流程的

而且 B 站又没有义务一定要对外出这个故障报告

[MEIerer]

我觉得很正常，代码不能顾及全部，没影响用户数据就行。还有你这贴在知乎有人发过了，不会是来骗铜币的吧

[qping]

@krly0912 #11 这有点厉害，怎么能定位到这个 lua 代码的

[technet]

@elfive 微信似乎比 Facebook cloudflare 谷歌推特等网站还要稳定,几乎很少出现宕机

[ChicC]

递归

[ccagml]

原来大家都是，重启->回滚代码->重装

[QuinceyWu]

Block List + 1

[xingyuc]

如何看待 QQ 大规模盗号

[shyrock]

挺佩服的，大厂有资源和决心花这么长时间做根因分析。

换成我，感觉挖不到这么深的原因。只能作为悬案归档。

[zhoudaiyu]

原来 SLB 也可以写扩展逻辑

[Leviathann]

我的评价是：动态弱类型语言就是个 jb

[kkocdko]

有很多人给出了各种答案，比如类型检查，写测试等等。

但我想说的是，一切缓解和检查措施总有失效的时候。我更看重备份与回滚，以及快速的介入，保证事故发生时的控制权。

[liuliangyz]

@leido 人家没有衣服公开报告，而且这么大的事，牵扯多少部门，多少同学。最终报告要层层递交。

[didilili]

写的如此详细，着实是受教了~

[ElliotQi]

@qping Flame Graph 看出来的?

[bxb100]

B 站解决问题的方案：猜，线下重试，现场火焰图

[DingJZ]

01:50 此时在线业务基本全部恢复。

当晚已定位到诱因是某个容器 IP 的 weight="0"。此应用在 1:45 时发布完成，weight="0"的诱因已消除。所以后续关闭 jit 虽然无效，但因为诱因消失，所以重启 SLB 后恢复正常。

一顿操作之后，还是外部变化消失+重启恢复的，中间重建之类的操作其实都没用

面对故障，一找出变化，二回滚。

[newmlp]

关键服务还搞 lua 脚本这种花里胡哨的东西，该

[zapper]

v2 知乎化
知乎贴吧化
贴吧粪坑化

[nomagick]

根本原因还没意识到呢

硬件防火墙一般都有一个非常方便切换的旁路模式，可以迅速消除防火墙对网络的影响。

像 WAF 这种东西充满不确定性，其行为飘忽不定，代码质量堪忧，流量处理能力和流量内容相关，更有复杂的过滤逻辑，搞不好啥时候就出问题。

在自己流量路径上串行设置 WAF 类似物而没有旁路机制，这才是症结。

我看这报告问题还是归咎在开发上，开发是有问题，但不至于影响全业务，真正的问题在架构上，首席架构师引咎吧

[yujinchn]

@shyrock 原因没找到，这次可以了不代表下次就不会又出现，找到原因直接解决更好

[shyrock]

@yujinchn 我看原文不是定位到了具体的 lua 代码了？怎么你说没找到

[joyyu]

"0" != 0

[Mac]

昨天我家洗衣机崩了，不脱水，原因就是一个字，便宜。

[EminemW]

所以算是自测的时候没考虑到边界条件？”0” != 0

[Zerek]

7 月 13 ？定眼一看哦。。。2021

[wanacry]

昨天我家里的洗衣机修好了

[wangyzj]

这个文章就说明 B 站最基本的运维流程都没有，还是几个关键人物在支持，核心组件没有冗余，问题还很多

但归根结底，搞运维嘛
没事的时候你是成本
有事的时候是你的责任
给运维花钱总觉得亏得慌
又让马儿跑，又不给吃草
做得好是让自己失业，做的不好就得背锅一样失业

总之，运维，都这个 B 样

[abuabu]

为什么一个很好能够讨论技术的帖子会被冷嘲热讽？

[lookStupiToForce]

v2 上还有玩鄙视链的
真是有人的地方就有恶臭的圈子习气

[nyakoy]

堪称精彩，但是代码得防御边界做的如此弱确实没想到

[Baloneo]

要么用电脑看 要么手机看

[crazytudou]

逼乎：你怎么看？

[mmnnyycc]

@qping #18 openresty 商业公司，春哥说的 100%无侵入式的

[mmnnyycc]

几分钟前章亦春说的原话：
B 站这两天发表了一篇总结去年那场大事故的文章： https://mp.weixin.qq.com/s/nGtC5lBX_Iaj57HIdXq3Qg 当时我们 OpenResty Inc 公司团队帮助 B 站在线上快速定位了导致 CPU 100% 的 Lua 代码路径。B 站是我们的 OpenResty XRay 产品的商业客户。

文中提到的 Lua 火焰图就是 OpenResty XRay 在 B 站生产服务器上采样有问题的 OpenResty 服务进程得到的。生成火焰图也就花了几分钟的时间，因为使用 100% 非侵入的动态追踪技术，并不需要对 B 站的进程进行任何修改。根据 Lua 火焰图最终确认根源问题是 B 站的业务往 Redis 服务器里写入了个字符串类型的权重 0 值的坏数据（即 “0”），而 Lua 代码期望的是数值类型的权重值，从而导致了无限递归和无限循环。文中提到的 LuaJIT 的 JIT 编译器的问题其实并不存在； JIT 编译器在这里并没有 bug 。

感谢 Bilibili 对我们公司产品和技术的信任和支持！当然，B 站线上系统使用的也是我们的开源 OpenResty 软件。OpenResty XRay 产品主页： https://openresty.com.cn/cn/xray/

[28Sv0ngQfIE7Yloe]

@shyrock #24

要分锅的，开复盘大会。

[dxppp]

官方微信公众号也发了相同的文章
https://mp.weixin.qq.com/s/nGtC5lBX_Iaj57HIdXq3Qg

[VZXXBACQ]

技术讨论文章为什么会有这么多莫名奇妙的回复？怎么看待不是很正常吗？

弱类型真不行。

[Huelse]

LUA 这种弱类型语言在这种地方真的要命

[siweipancc]

草，又是弱类型

[edward1987]

主题值得讨论，但是能别用逼乎标题吗。。。不喜欢

[edward1987]

只要有无限递归的可能，我觉得最好都打个日志，配个上限。。。曾经也遇到过😂

[zapper]

@VZXXBACQ #52 没看出来哪里讨论技术，lz 甚至没有自己的观点。

[maguowei]

@mmnnyycc 这个有原文出处么？还是来自非公开的信息源？

[VZXXBACQ]

@zapper LZ 附上的文章是很不错的一线技术讨论，分享出来问大家如何看待有什么问题吗😂

[dorothyREN]

@wangyzj #43 我现在都后悔入了运维的坑

[exploreexe]

你去知乎发帖子啊，还怎么看。。。

[GeorgeGalway]

@VZXXBACQ 我感觉也是，前几楼的冷嘲热讽让我怀疑楼主发了个钓鱼文章

[blless]

本老运维出来说一点点。
核心就是 B 站对运维投入应该不够重视。几个关键字，2021 年，自建机房，OpenResty+注册中心 ，线上网络和办公网络互通，关键业务 SLB 居然还要临时新建，业务回滚极不完善。

不过也是事后 BB 罢了，线上原因多种多样。运维做多了，个人觉得核心在于不是排查出问题或者解决问题，而是快速恢复，降低影响。所以一个老运维需要很清楚知道，一些改动可能影响的范围。

这里事故的关键点其实在于，利用 OpenResty 的灵活性，接入了一个可以动态获取网关配置的注册中心。也就是说 LB 的配置变更的核心在于注册中心配置下发的配置。(我以前公司任何可能改动到网关的配置审核都是三层审核)。这里我猜很有可能 B 站注册中心下发配置权限在另一个部门，而且可能绕开了线上运维人员的审核。然后整个事故报告里面没有提到一句下发错误配置的部门，整个事故报告围绕自身问题...似乎看到了一个已经被强势业务部门 PUA 成性的背锅老运维了。所以如何把关键变更权掌控在运维手上，或者至少有效通知到运维人员，才是运维的关键。但是这一点往往因为业务线太长，需要公司更高层级的支持，所以往往一个公司的运维好坏是跟公司整体相关的。强势业务部门就会以各种理由抵制这些手段，老板也会站在业务部门角度。没有任何办法，只能等血淋淋的线上事故发生之后，趁机搞一点运维建设。

另外好多人一说事故就提高可用，问题是高可用上限是没有边界的。公司不注重运维体系建设，盲目砸钱搞高可用，本来人就不多，还要加工作量，我只能说下次事故说不定指日可待

[hsiaochi]

用手机看，用电脑看，用平板看。。。

[pastor]

@blless 感觉应该多加一些配置中心分组，不同节点连到不同的配置中心，升级的时候也可以分批次更新配置，按分组从小到大、先更新小分组，跑一阵正常了之后再更新下一批，避免一跪全跪

[zapper]

@VZXXBACQ #59
@GeorgeGalway #62
我觉得其实这个帖子大可不必使用这个标题，甚至有点文不对题。因为内容主题是这次事件的解决报告，而这次事件本身早就已经过去一年了。
而我所说的“v2 知乎化”，包括但不限于此类大量以前泛滥于知乎的主题：“如何看待 x“、”x 是什么体验”；
而“知乎贴吧化”，意为知乎现在泛滥着贴吧以前出现的各种求助类问题例如“windows 未能启动 按 F8 没用怎么办?”。
而大部分贴吧早就已经断气了
当然我没有权利去管别人发什么，只是单纯表达对现在帖子标题的一种无奈

[blless]

@pastor #66 能做的话都不是事，但是这种一般工作量太大了。涉及人和部门非常多，协作起来真的要命。除非整个 Ops 平台化建设都很完备才有可能这么搞

[maguowei]

@mmnnyycc 看到了，在微博上

[HFX3389]

@dorothyREN #61 但我学前端的是被 recoil 搞的人都蒙了，最后发现好像我不适合造东西，适合用东西...

[realrojeralone]

@mmnnyycc 帮补个链接： https://weibo.com/1834459124/LCniJk3dY

[a90120411]

我只知道 B 站在每个视频连接后面动态加了 vd_source 参数很恶心。

[wangyzj]

@blless #64 万事不决先重启
重启不行就多重启几遍

[yujinchn]

@shyrock 你看我回复的谁，没说找不到啊，我意思就是说这种最好能找出详细原因，不然指不定下次又出现

[flyqie]

看完了，着实没想到当时的事故居然由于这种低级错误。

通过一个缺失的 if type(b) == "number"，暴露出来了这么多问题。。

[yujinchn]

@shyrock 就你回复的啊，我的问题，说的有歧义，没说 b 站没找到，是说要是原因没找到的话

[A555]

去年的事,今年发事故报告

[salmon5]

我只关心内部管理和绩效上怎么处理的，其他都是渣渣

[pastor]

会不会 2022.07.16 14:00-17:00 直播时又发生宕机，如果赶巧，就更社死了...

[Cbdy]

B 站的网站做的是真烂，令人作呕

[Sixyuan]

重点是，op 为什么不发表自己的看法？我认为这是交流的前提。

[vision4fun]

领导，人不够，加点人吧！

[LeegoYih]

草台

[Tussik]

我昨天在哔哩哔哩节点下也发了相关帖子，楼里关于测试的部分讨论我觉得还挺有意思的，大家有兴趣可以看看
https://v2ex.com/t/866226

[NiZerin]

简单的说就是：弱类型的锅

[frostnotfall]

根本原因是 lua 传参时传 0 导致异常。

“_gcd 函数对入参没有做类型校验，允许参数 b 传入："0"。同时因为"0" != 0 ，所以此函数第一次执行后返回是 _gcd("0",nan)。如果传入的是 int 0 ，则会触发[ if b == 0 ]分支逻辑判断，不会死循环。”

说实话，lua 语言欠缺的恰恰就是种种类似这样的小细节，也是服务端没有大规模用起来的原因。比如用默认的排序、遍历这些，都需要额外的逻辑来处理，所用不所见，所见不所得。

openresty 将 lua 集成进 Nginx 无疑是非常方便的，开发速度嘎嘎高。曾经需要在 L7 层做加解密逻辑，一天半的时间，从了解 Lua 到代码完成并测试。速度是真的快。

但是 lua 毕竟是缝合进 Nginx 的，天生就不会 100%完全匹配，再加上 lua 的种种小问题，总有种那着精致的小手枪上战场的赶脚。

[salmon5]

b 站和美团、58 技术就查很远，渣渣

[flyqie]

@frostnotfall

B 站的事跟 lua 没太大关系吧。

这个应该属于弱语言通病，真打算扯到 lua 的话。。难道说应该直接报错而不是返回 nan ？

[flyqie]

@flyqie

弱语言 -> 弱类型语言

[frostnotfall]

@flyqie #88 不好意思，的确看错了，这里是 lua-resty-balancer 的代码不是 lua 的代码，看的时候跑偏了因为前面说是 jit bug 。

[xiangyuecn]

跟 弱类型语言 不弱类型语言 的 没有任何关系。该死循环的时候，换什么语言 谁都跑不掉🐶🐶

[Pythoner666666]

@mmnnyycc “根源问题是 B 站的业务往 Redis 服务器里写入了个字符串类型的权重 0 值的坏数据（即 “0”）” 这个如果是真的那么说明 写这段代码的人使用 redis 的经验欠缺，因为从 redis 取值 无论是什么数据类型，取出来的值都是 string 。反之这句话就是假的

[evilStart]

@shyrock 啊这，b 站也算大厂啊

[frostnotfall]

@flyqie #90 但紧接而来的问题就是，lua 函数的实现，没有指定传入参数的类型？

[Ansen]

不看 B 站

[jqsl2012]

B 站是什么

[HankLu]

不要递归不要递归不要递归

[omnip]

没人注意到最后一句话么：多活的高可用容灾架构确实生效了。 [doge]

[flyqie]

@frostnotfall

没记错的话，貌似是这样的。

好像没办法指定类型。

[liuxu]

代码出的 bug ，老运维来了也没用，哪怕运维能审核代码，lua 这个 nan 的坑该出问题还是的出

注册中心、自建机房、嫌架构原始的、人员投入不够什么的，这些都是虚的，像 google 、cloudflare 这种不一样该崩还是崩，还有说弱类型语言不行，那强类型语言写的东西不也是 bug 一堆

这个事故只有一个问题，就是拿到 prof 跑的火焰图却不知道怎么分析导致的后面扯的一堆，递归错误从火焰图来看一定是不断重复调用一个方法，哪怕动态解释型语言也会重复一部分代码，对着反推就行了

这个事故出了第一件事应该 top 看哪个进程出了问题，第二件事就是 strace 到进程看看输出，卡到哪里了，然后才会 prof 输出和火焰图，最后再不济 gdb 上去分析，也别说什么生产上 gdb 不合规，生产都崩成这样了，任何能有效恢复服务的分析方式都是正确的方式

看看这报告也说“我们的事件分析平台目前只提供了面向应用的事件查询能力，缺少面向用户、面向平台、面向组件的事件分析能力”，说白了这个事情就是组件底层代码分析能力不够


这也说明了生产环境添加编译调试信息的重要性，像《高性能 mysql 》里面讲的，给生产环境 mysql 添加调试信息，哪怕增加 20%的 cpu 损耗，但是到了出问题分析的时候，绝对会觉得这 20%花的值