这是一个创建于 896 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 · 2022-07-15 13:41:44 +08:00
2022.07.16 14:00-17:00 直播预告
B 站“713 事故”后的多活容灾建设优化
分享嘉宾曾深度参与 713 故障处理，本次分享将对 713 部分问题做答疑解惑，同时还会分享 B 站常见的高可用方案和故障后的多活容灾建设优化。
https://www.bilibili.com/read/cv17581401
B 站“713 事故”后的多活容灾建设优化
分享嘉宾曾深度参与 713 故障处理，本次分享将对 713 部分问题做答疑解惑，同时还会分享 B 站常见的高可用方案和故障后的多活容灾建设优化。
https://www.bilibili.com/read/cv17581401
103 条回复 • 2022-07-16 10:48:31 +08:00
 |
1
chendy 2022-07-15 08:43:10 +08:00  16
出门左转知乎
|
 |
2
elfive 2022-07-15 08:46:22 +08:00 via iPhone 11
有什么好看的？
站在程序员的角度，没人能写出 100%不出问题的代码，都是一种概率妥协而已。 |
 |
3
storyxc 2022-07-15 08:46:42 +08:00
昨天用手机看的。
|
 |
4
Xhack 2022-07-15 08:47:50 +08:00
楼主 感觉像是键盘侠之类的，我坐着 拿手机看的 然后呢？
|
 |
5
teenight 2022-07-15 08:49:11 +08:00 via Android
以平常心看待
|
 |
6
imdong 2022-07-15 08:52:04 +08:00 via iPhone
|
 |
8
jinliming2 2022-07-15 08:59:58 +08:00 via iPhone
事故发生一周年，B 站出了事故分析报告……
重启没用，回滚没用，最终还是重装解决 99 ％ 的问题…… |
 |
10
R18 2022-07-15 09:07:06 +08:00
希望大公司多出这种文章内容
|
 |
11
krly0912 2022-07-15 09:07:24 +08:00
@jinliming2 看了事故分析报告解析，是 7 层 slb 的负载均衡更新了功能，一行 lua 代码因为类型转换原因导致无限递归造成的。cpu 直接打到 100%。重启后诱发因子消失了，所以正常了
|
 |
12
lixiaobai913 2022-07-15 09:07:27 +08:00
2022.07.14 的 QQ 上午发送不了离线文件怎么看待？
|
 |
13
EastLord 2022-07-15 09:09:18 +08:00 1
我还以为是 2022 年
|
 |
14
equationl 2022-07-15 09:11:36 +08:00
@jinliming2 要是重装也没用是不是该到重买了（
|
 |
15
leido 2022-07-15 09:11:41 +08:00 5
重点是, 去年的事怎么今年才出报告...
|
 |
17
MEIerer 2022-07-15 09:15:40 +08:00
我觉得很正常，代码不能顾及全部，没影响用户数据就行。还有你这贴在知乎有人发过了，不会是来骗铜币的吧
|
 |
20
ChicC 2022-07-15 09:25:11 +08:00
递归
|
 |
21
ccagml 2022-07-15 09:29:43 +08:00 via Android 1
原来大家都是，重启->回滚代码->重装
|
 |
22
QuinceyWu 2022-07-15 09:31:51 +08:00 3
Block List + 1
|
 |
23
xingyuc 2022-07-15 09:33:05 +08:00
如何看待 QQ 大规模盗号
|
 |
24
shyrock 2022-07-15 09:33:26 +08:00
挺佩服的，大厂有资源和决心花这么长时间做根因分析。
换成我，感觉挖不到这么深的原因。只能作为悬案归档。 |
 |
25
zhoudaiyu 2022-07-15 09:34:17 +08:00
原来 SLB 也可以写扩展逻辑
|
 |
26
Leviathann 2022-07-15 09:36:41 +08:00
我的评价是：动态弱类型语言就是个 jb
|
 |
27
kkocdko 2022-07-15 09:46:07 +08:00
有很多人给出了各种答案，比如类型检查，写测试等等。
但我想说的是，一切缓解和检查措施总有失效的时候。我更看重备份与回滚，以及快速的介入，保证事故发生时的控制权。 |
 |
28
liuliangyz 2022-07-15 09:47:20 +08:00
@leido 人家没有衣服公开报告，而且这么大的事，牵扯多少部门，多少同学。最终报告要层层递交。
|
 |
29
didilili 2022-07-15 09:52:06 +08:00
写的如此详细，着实是受教了~
|
 |
31
bxb100 2022-07-15 09:54:09 +08:00 via Android
B 站解决问题的方案：猜，线下重试，现场火焰图
|
 |
32
DingJZ 2022-07-15 09:56:17 +08:00
01:50 此时在线业务基本全部恢复。
当晚已定位到诱因是某个容器 IP 的 weight="0"。此应用在 1:45 时发布完成，weight="0"的诱因已消除。所以后续关闭 jit 虽然无效，但因为诱因消失，所以重启 SLB 后恢复正常。 一顿操作之后，还是外部变化消失+重启恢复的，中间重建之类的操作其实都没用 面对故障，一找出变化，二回滚。 |
 |
33
newmlp 2022-07-15 10:09:09 +08:00
关键服务还搞 lua 脚本这种花里胡哨的东西，该
|
 |
34
zapper 2022-07-15 10:10:13 +08:00 10
v2 知乎化
知乎贴吧化 贴吧粪坑化 |
 |
35
nomagick 2022-07-15 10:11:24 +08:00 5
根本原因还没意识到呢
硬件防火墙一般都有一个非常方便切换的旁路模式，可以迅速消除防火墙对网络的影响。 像 WAF 这种东西充满不确定性，其行为飘忽不定，代码质量堪忧，流量处理能力和流量内容相关，更有复杂的过滤逻辑，搞不好啥时候就出问题。 在自己流量路径上串行设置 WAF 类似物而没有旁路机制，这才是症结。 我看这报告问题还是归咎在开发上，开发是有问题，但不至于影响全业务，真正的问题在架构上，首席架构师引咎吧 |
 |
38
joyyu 2022-07-15 10:55:18 +08:00
"0" != 0
|
 |
39
Mac 2022-07-15 10:58:09 +08:00 via Android
昨天我家洗衣机崩了，不脱水，原因就是一个字，便宜。
|
 |
40
EminemW 2022-07-15 11:06:21 +08:00 via iPhone
所以算是自测的时候没考虑到边界条件？”0” != 0
|
 |
41
Zerek 2022-07-15 11:25:00 +08:00
7 月 13 ？定眼一看哦。。。2021
|
 |
42
wanacry 2022-07-15 11:29:25 +08:00 via iPhone
昨天我家里的洗衣机修好了
|
 |
43
wangyzj 2022-07-15 11:41:05 +08:00 3
这个文章就说明 B 站最基本的运维流程都没有，还是几个关键人物在支持，核心组件没有冗余，问题还很多
但归根结底，搞运维嘛 没事的时候你是成本 有事的时候是你的责任 给运维花钱总觉得亏得慌 又让马儿跑，又不给吃草 做得好是让自己失业，做的不好就得背锅一样失业 总之，运维，都这个 B 样 |
 |
44
abuabu 2022-07-15 11:41:15 +08:00 30
为什么一个很好能够讨论技术的帖子会被冷嘲热讽？
|
 |
45
lookStupiToForce 2022-07-15 11:43:26 +08:00
v2 上还有玩鄙视链的
真是有人的地方就有恶臭的圈子习气 |
 |
46
nyakoy 2022-07-15 11:48:29 +08:00
堪称精彩，但是代码得防御边界做的如此弱确实没想到
|
 |
47
Baloneo 2022-07-15 11:56:36 +08:00
要么用电脑看 要么手机看
|
 |
48
crazytudou 2022-07-15 11:57:26 +08:00
逼乎：你怎么看？
|
 |
50
mmnnyycc 2022-07-15 12:04:48 +08:00 4
几分钟前章亦春说的原话：
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/ |
 |
51
28Sv0ngQfIE7Yloe 2022-07-15 12:20:09 +08:00
|
 |
52
dxppp 2022-07-15 13:13:47 +08:00 via Android
官方微信公众号也发了相同的文章
https://mp.weixin.qq.com/s/nGtC5lBX_Iaj57HIdXq3Qg |
 |
53
VZXXBACQ 2022-07-15 13:33:22 +08:00
技术讨论文章为什么会有这么多莫名奇妙的回复？怎么看待不是很正常吗？
弱类型真不行。 |
 |
54
Huelse 2022-07-15 13:38:41 +08:00
LUA 这种弱类型语言在这种地方真的要命
|
 |
55
siweipancc 2022-07-15 13:47:30 +08:00 via iPhone
草，又是弱类型
|
 |
56
edward1987 2022-07-15 14:19:55 +08:00
主题值得讨论，但是能别用逼乎标题吗。。。不喜欢
|
|
57
edward1987 2022-07-15 14:21:11 +08:00
只要有无限递归的可能，我觉得最好都打个日志，配个上限。。。曾经也遇到过😂
|
 |
61
dorothyREN 2022-07-15 14:43:19 +08:00
@wangyzj #43 我现在都后悔入了运维的坑
|
 |
62
exploreexe 2022-07-15 14:43:31 +08:00
你去知乎发帖子啊，还怎么看。。。
|
 |
63
GeorgeGalway 2022-07-15 14:48:33 +08:00
@VZXXBACQ 我感觉也是，前几楼的冷嘲热讽让我怀疑楼主发了个钓鱼文章
|
 |
64
blless 2022-07-15 14:53:27 +08:00 12
本老运维出来说一点点。
核心就是 B 站对运维投入应该不够重视。几个关键字，2021 年，自建机房，OpenResty+注册中心 ，线上网络和办公网络互通，关键业务 SLB 居然还要临时新建，业务回滚极不完善。 不过也是事后 BB 罢了，线上原因多种多样。运维做多了，个人觉得核心在于不是排查出问题或者解决问题，而是快速恢复，降低影响。所以一个老运维需要很清楚知道，一些改动可能影响的范围。 这里事故的关键点其实在于，利用 OpenResty 的灵活性，接入了一个可以动态获取网关配置的注册中心。也就是说 LB 的配置变更的核心在于注册中心配置下发的配置。(我以前公司任何可能改动到网关的配置审核都是三层审核)。这里我猜很有可能 B 站注册中心下发配置权限在另一个部门，而且可能绕开了线上运维人员的审核。然后整个事故报告里面没有提到一句下发错误配置的部门，整个事故报告围绕自身问题...似乎看到了一个已经被强势业务部门 PUA 成性的背锅老运维了。所以如何把关键变更权掌控在运维手上，或者至少有效通知到运维人员，才是运维的关键。但是这一点往往因为业务线太长，需要公司更高层级的支持，所以往往一个公司的运维好坏是跟公司整体相关的。强势业务部门就会以各种理由抵制这些手段，老板也会站在业务部门角度。没有任何办法，只能等血淋淋的线上事故发生之后，趁机搞一点运维建设。 另外好多人一说事故就提高可用，问题是高可用上限是没有边界的。公司不注重运维体系建设，盲目砸钱搞高可用，本来人就不多，还要加工作量，我只能说下次事故说不定指日可待 |
 |
65
hsiaochi 2022-07-15 14:55:44 +08:00
用手机看，用电脑看，用平板看。。。
|
 |
66
pastor 2022-07-15 14:57:02 +08:00
@blless 感觉应该多加一些配置中心分组，不同节点连到不同的配置中心，升级的时候也可以分批次更新配置，按分组从小到大、先更新小分组，跑一阵正常了之后再更新下一批，避免一跪全跪
|
|
67
zapper 2022-07-15 15:04:43 +08:00 1
@VZXXBACQ #59
@GeorgeGalway #62 我觉得其实这个帖子大可不必使用这个标题，甚至有点文不对题。因为内容主题是这次事件的解决报告，而这次事件本身早就已经过去一年了。 而我所说的“v2 知乎化”，包括但不限于此类大量以前泛滥于知乎的主题：“如何看待 x“、”x 是什么体验”； 而“知乎贴吧化”，意为知乎现在泛滥着贴吧以前出现的各种求助类问题例如“windows 未能启动 按 F8 没用怎么办?”。 而大部分贴吧早就已经断气了 当然我没有权利去管别人发什么，只是单纯表达对现在帖子标题的一种无奈 |
|
68
blless 2022-07-15 15:16:01 +08:00 via Android
@pastor #66 能做的话都不是事，但是这种一般工作量太大了。涉及人和部门非常多，协作起来真的要命。除非整个 Ops 平台化建设都很完备才有可能这么搞
|
 |
70
HFX3389 2022-07-15 15:36:05 +08:00
@dorothyREN #61 但我学前端的是被 recoil 搞的人都蒙了，最后发现好像我不适合造东西，适合用东西...
|
 |
71
realrojeralone 2022-07-15 15:47:08 +08:00 1
|
 |
72
a90120411 2022-07-15 16:18:39 +08:00
我只知道 B 站在每个视频连接后面动态加了 vd_source 参数很恶心。
|
 |
75
flyqie 2022-07-15 16:36:20 +08:00 via Android
看完了，着实没想到当时的事故居然由于这种低级错误。
通过一个缺失的 if type(b) == "number"，暴露出来了这么多问题。。 |
 |
77
A555 2022-07-15 17:16:03 +08:00
去年的事,今年发事故报告
|
 |
78
salmon5 2022-07-15 17:32:46 +08:00
我只关心内部管理和绩效上怎么处理的，其他都是渣渣
|
|
79
pastor 2022-07-15 17:36:13 +08:00
会不会 2022.07.16 14:00-17:00 直播时又发生宕机，如果赶巧，就更社死了...
|
 |
80
Cbdy 2022-07-15 17:38:34 +08:00 via Android
B 站的网站做的是真烂，令人作呕
|
 |
81
Sixyuan 2022-07-15 17:51:03 +08:00
重点是，op 为什么不发表自己的看法？我认为这是交流的前提。
|
 |
82
vision4fun 2022-07-15 17:54:58 +08:00
领导，人不够，加点人吧！
|
 |
83
LeegoYih 2022-07-15 17:56:03 +08:00
草台
|
 |
84
Tussik 2022-07-15 17:56:09 +08:00
我昨天在哔哩哔哩节点下也发了相关帖子，楼里关于测试的部分讨论我觉得还挺有意思的，大家有兴趣可以看看
https://v2ex.com/t/866226 |
 |
85
NiZerin 2022-07-15 17:59:00 +08:00
简单的说就是：弱类型的锅
|
 |
86
frostnotfall 2022-07-15 18:01:39 +08:00 1
根本原因是 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 的种种小问题，总有种那着精致的小手枪上战场的赶脚。 |
|
87
salmon5 2022-07-15 18:04:18 +08:00
b 站和美团、58 技术就查很远，渣渣
|
|
88
flyqie 2022-07-15 18:34:35 +08:00 via Android
|
|
90
frostnotfall 2022-07-15 19:04:17 +08:00
@flyqie #88 不好意思，的确看错了，这里是 lua-resty-balancer 的代码不是 lua 的代码，看的时候跑偏了因为前面说是 jit bug 。
|
 |
91
xiangyuecn 2022-07-15 19:05:44 +08:00
跟 弱类型语言 不弱类型语言 的 没有任何关系。该死循环的时候，换什么语言 谁都跑不掉🐶🐶
|
 |
92
Pythoner666666 2022-07-15 19:19:17 +08:00
@mmnnyycc “根源问题是 B 站的业务往 Redis 服务器里写入了个字符串类型的权重 0 值的坏数据（即 “0”）” 这个如果是真的那么说明 写这段代码的人使用 redis 的经验欠缺，因为从 redis 取值 无论是什么数据类型，取出来的值都是 string 。反之这句话就是假的
|
|
94
frostnotfall 2022-07-15 19:30:20 +08:00
@flyqie #90 但紧接而来的问题就是，lua 函数的实现，没有指定传入参数的类型？
|
 |
95
Ansen 2022-07-15 20:09:16 +08:00
不看 B 站
|
 |
96
jqsl2012 2022-07-15 20:14:09 +08:00 via Android
B 站是什么
|
 |
97
HankLu 2022-07-15 20:15:12 +08:00
不要递归不要递归不要递归
|
 |
98
omnip 2022-07-15 20:55:02 +08:00
没人注意到最后一句话么：多活的高可用容灾架构确实生效了。 [doge]
|
|
99
flyqie 2022-07-15 21:03:42 +08:00 via Android
|
 |
100
liuxu 2022-07-15 22:00:17 +08:00 2
代码出的 bug ，老运维来了也没用，哪怕运维能审核代码，lua 这个 nan 的坑该出问题还是的出
注册中心、自建机房、嫌架构原始的、人员投入不够什么的，这些都是虚的，像 google 、cloudflare 这种不一样该崩还是崩，还有说弱类型语言不行，那强类型语言写的东西不也是 bug 一堆 这个事故只有一个问题，就是拿到 prof 跑的火焰图却不知道怎么分析导致的后面扯的一堆，递归错误从火焰图来看一定是不断重复调用一个方法，哪怕动态解释型语言也会重复一部分代码，对着反推就行了 这个事故出了第一件事应该 top 看哪个进程出了问题，第二件事就是 strace 到进程看看输出，卡到哪里了，然后才会 prof 输出和火焰图，最后再不济 gdb 上去分析，也别说什么生产上 gdb 不合规，生产都崩成这样了，任何能有效恢复服务的分析方式都是正确的方式 看看这报告也说“我们的事件分析平台目前只提供了面向应用的事件查询能力，缺少面向用户、面向平台、面向组件的事件分析能力”，说白了这个事情就是组件底层代码分析能力不够 这也说明了生产环境添加编译调试信息的重要性，像《高性能 mysql 》里面讲的，给生产环境 mysql 添加调试信息，哪怕增加 20%的 cpu 损耗，但是到了出问题分析的时候，绝对会觉得这 20%花的值 |
Select Language