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%花的值 |