V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Stendan
V2EX  ›  哔哩哔哩

如何看待 2021.07.13 B 站崩溃事件

  •  1
     
  •   Stendan · 79 天前 · 12844 次点击
    这是一个创建于 79 天前的主题,其中的信息可能已经有所发展或是发生改变。
    第 1 条附言  ·  78 天前
    2022.07.16 14:00-17:00 直播预告

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

    https://www.bilibili.com/read/cv17581401
    103 条回复    2022-07-16 10:48:31 +08:00
    1  2  
    chendy
        1
    chendy  
       79 天前   ❤️ 16
    出门左转知乎
    elfive
        2
    elfive  
       79 天前 via iPhone   ❤️ 11
    有什么好看的?
    站在程序员的角度,没人能写出 100%不出问题的代码,都是一种概率妥协而已。
    storyxc
        3
    storyxc  
       79 天前
    昨天用手机看的。
    Xhack
        4
    Xhack  
       79 天前
    楼主 感觉像是键盘侠之类的,我坐着 拿手机看的 然后呢?
    teenight
        5
    teenight  
       79 天前 via Android
    以平常心看待
    imdong
        6
    imdong  
       79 天前 via iPhone
    怎么看?直播围观咯。

    https://files.catbox.moe/gky3wt.jpeg
    manshisan
        7
    manshisan  
       79 天前 via iPhone
    @imdong 关注了
    jinliming2
        8
    jinliming2  
       79 天前 via iPhone
    事故发生一周年,B 站出了事故分析报告……
    重启没用,回滚没用,最终还是重装解决 99 % 的问题……
    Stendan
        9
    Stendan  
    OP
       79 天前   ❤️ 8
    @Xhack 生活如意,没空对线
    R18
        10
    R18  
       79 天前
    希望大公司多出这种文章内容
    krly0912
        11
    krly0912  
       79 天前
    @jinliming2 看了事故分析报告解析,是 7 层 slb 的负载均衡更新了功能,一行 lua 代码因为类型转换原因导致无限递归造成的。cpu 直接打到 100%。重启后诱发因子消失了,所以正常了
    lixiaobai913
        12
    lixiaobai913  
       79 天前
    2022.07.14 的 QQ 上午发送不了离线文件怎么看待?
    EastLord
        13
    EastLord  
       79 天前   ❤️ 1
    我还以为是 2022 年
    equationl
        14
    equationl  
       79 天前
    @jinliming2 要是重装也没用是不是该到重买了(
    leido
        15
    leido  
       79 天前   ❤️ 5
    重点是, 去年的事怎么今年才出报告...
    isno
        16
    isno  
       79 天前
    @leido 大公司信息公开都是要审核 走流程的

    而且 B 站又没有义务一定要对外出这个故障报告
    MEIerer
        17
    MEIerer  
       79 天前
    我觉得很正常,代码不能顾及全部,没影响用户数据就行。还有你这贴在知乎有人发过了,不会是来骗铜币的吧
    qping
        18
    qping  
       79 天前
    @krly0912 #11 这有点厉害,怎么能定位到这个 lua 代码的
    technet
        19
    technet  
       79 天前
    @elfive 微信似乎比 Facebook cloudflare 谷歌推特等网站还要稳定,几乎很少出现宕机
    ChicC
        20
    ChicC  
       79 天前
    递归
    ccagml
        21
    ccagml  
       79 天前 via Android   ❤️ 1
    原来大家都是,重启->回滚代码->重装
    QuinceyWu
        22
    QuinceyWu  
       79 天前   ❤️ 3
    Block List + 1
    xingyuc
        23
    xingyuc  
       79 天前
    如何看待 QQ 大规模盗号
    shyrock
        24
    shyrock  
       79 天前
    挺佩服的,大厂有资源和决心花这么长时间做根因分析。

    换成我,感觉挖不到这么深的原因。只能作为悬案归档。
    zhoudaiyu
        25
    zhoudaiyu  
       79 天前
    原来 SLB 也可以写扩展逻辑
    Leviathann
        26
    Leviathann  
       79 天前
    我的评价是:动态弱类型语言就是个 jb
    kkocdko
        27
    kkocdko  
       79 天前
    有很多人给出了各种答案,比如类型检查,写测试等等。

    但我想说的是,一切缓解和检查措施总有失效的时候。我更看重备份与回滚,以及快速的介入,保证事故发生时的控制权。
    liuliangyz
        28
    liuliangyz  
       79 天前
    @leido 人家没有衣服公开报告,而且这么大的事,牵扯多少部门,多少同学。最终报告要层层递交。
    didilili
        29
    didilili  
       79 天前
    写的如此详细,着实是受教了~
    ElliotQi
        30
    ElliotQi  
       79 天前
    @qping Flame Graph 看出来的?
    bxb100
        31
    bxb100  
       79 天前 via Android
    B 站解决问题的方案:猜,线下重试,现场火焰图
    DingJZ
        32
    DingJZ  
       79 天前
    01:50 此时在线业务基本全部恢复。

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

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

    面对故障,一找出变化,二回滚。
    newmlp
        33
    newmlp  
       79 天前
    关键服务还搞 lua 脚本这种花里胡哨的东西,该
    zapper
        34
    zapper  
       79 天前   ❤️ 10
    v2 知乎化
    知乎贴吧化
    贴吧粪坑化
    nomagick
        35
    nomagick  
       79 天前   ❤️ 5
    根本原因还没意识到呢

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

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

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

    我看这报告问题还是归咎在开发上,开发是有问题,但不至于影响全业务,真正的问题在架构上,首席架构师引咎吧
    yujinchn
        36
    yujinchn  
       79 天前
    @shyrock 原因没找到,这次可以了不代表下次就不会又出现,找到原因直接解决更好
    shyrock
        37
    shyrock  
       79 天前
    @yujinchn 我看原文不是定位到了具体的 lua 代码了?怎么你说没找到
    joyyu
        38
    joyyu  
       79 天前
    "0" != 0
    Mac
        39
    Mac  
       79 天前 via Android
    昨天我家洗衣机崩了,不脱水,原因就是一个字,便宜。
    EminemW
        40
    EminemW  
       79 天前 via iPhone
    所以算是自测的时候没考虑到边界条件?”0” != 0
    Zerek
        41
    Zerek  
       79 天前
    7 月 13 ?定眼一看哦。。。2021
    wanacry
        42
    wanacry  
       79 天前 via iPhone
    昨天我家里的洗衣机修好了
    wangyzj
        43
    wangyzj  
       79 天前   ❤️ 3
    这个文章就说明 B 站最基本的运维流程都没有,还是几个关键人物在支持,核心组件没有冗余,问题还很多

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

    总之,运维,都这个 B 样
    abuabu
        44
    abuabu  
       79 天前   ❤️ 30
    为什么一个很好能够讨论技术的帖子会被冷嘲热讽?
    lookStupiToForce
        45
    lookStupiToForce  
       79 天前
    v2 上还有玩鄙视链的
    真是有人的地方就有恶臭的圈子习气
    nyakoy
        46
    nyakoy  
       79 天前
    堪称精彩,但是代码得防御边界做的如此弱确实没想到
    Baloneo
        47
    Baloneo  
       79 天前
    要么用电脑看 要么手机看
    crazytudou
        48
    crazytudou  
       79 天前
    逼乎:你怎么看?
    mmnnyycc
        49
    mmnnyycc  
       79 天前
    @qping #18 openresty 商业公司,春哥说的 100%无侵入式的
    mmnnyycc
        50
    mmnnyycc  
       79 天前   ❤️ 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/
    Morii
        51
    Morii  
       79 天前
    @shyrock #24

    要分锅的,开复盘大会。
    dxppp
        52
    dxppp  
       78 天前 via Android
    官方微信公众号也发了相同的文章
    https://mp.weixin.qq.com/s/nGtC5lBX_Iaj57HIdXq3Qg
    VZXXBACQ
        53
    VZXXBACQ  
       78 天前
    技术讨论文章为什么会有这么多莫名奇妙的回复?怎么看待不是很正常吗?

    弱类型真不行。
    Huelse
        54
    Huelse  
       78 天前
    LUA 这种弱类型语言在这种地方真的要命
    siweipancc
        55
    siweipancc  
       78 天前 via iPhone
    草,又是弱类型
    edward1987
        56
    edward1987  
       78 天前
    主题值得讨论,但是能别用逼乎标题吗。。。不喜欢
    edward1987
        57
    edward1987  
       78 天前
    只要有无限递归的可能,我觉得最好都打个日志,配个上限。。。曾经也遇到过😂
    zapper
        58
    zapper  
       78 天前
    @VZXXBACQ #52 没看出来哪里讨论技术,lz 甚至没有自己的观点。
    maguowei
        59
    maguowei  
       78 天前
    @mmnnyycc 这个有原文出处么?还是来自非公开的信息源?
    VZXXBACQ
        60
    VZXXBACQ  
       78 天前
    @zapper LZ 附上的文章是很不错的一线技术讨论,分享出来问大家如何看待有什么问题吗😂
    dorothyREN
        61
    dorothyREN  
       78 天前
    @wangyzj #43 我现在都后悔入了运维的坑
    exploreexe
        62
    exploreexe  
       78 天前
    你去知乎发帖子啊,还怎么看。。。
    GeorgeGalway
        63
    GeorgeGalway  
       78 天前
    @VZXXBACQ 我感觉也是,前几楼的冷嘲热讽让我怀疑楼主发了个钓鱼文章
    blless
        64
    blless  
       78 天前   ❤️ 12
    本老运维出来说一点点。
    核心就是 B 站对运维投入应该不够重视。几个关键字,2021 年,自建机房,OpenResty+注册中心 ,线上网络和办公网络互通,关键业务 SLB 居然还要临时新建,业务回滚极不完善。

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

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

    另外好多人一说事故就提高可用,问题是高可用上限是没有边界的。公司不注重运维体系建设,盲目砸钱搞高可用,本来人就不多,还要加工作量,我只能说下次事故说不定指日可待
    hsiaochi
        65
    hsiaochi  
       78 天前
    用手机看,用电脑看,用平板看。。。
    pastor
        66
    pastor  
       78 天前
    @blless 感觉应该多加一些配置中心分组,不同节点连到不同的配置中心,升级的时候也可以分批次更新配置,按分组从小到大、先更新小分组,跑一阵正常了之后再更新下一批,避免一跪全跪
    zapper
        67
    zapper  
       78 天前   ❤️ 1
    @VZXXBACQ #59
    @GeorgeGalway #62
    我觉得其实这个帖子大可不必使用这个标题,甚至有点文不对题。因为内容主题是这次事件的解决报告,而这次事件本身早就已经过去一年了。
    而我所说的“v2 知乎化”,包括但不限于此类大量以前泛滥于知乎的主题:“如何看待 x“、”x 是什么体验”;
    而“知乎贴吧化”,意为知乎现在泛滥着贴吧以前出现的各种求助类问题例如“windows 未能启动 按 F8 没用怎么办?”。
    而大部分贴吧早就已经断气了
    当然我没有权利去管别人发什么,只是单纯表达对现在帖子标题的一种无奈
    blless
        68
    blless  
       78 天前 via Android
    @pastor #66 能做的话都不是事,但是这种一般工作量太大了。涉及人和部门非常多,协作起来真的要命。除非整个 Ops 平台化建设都很完备才有可能这么搞
    maguowei
        69
    maguowei  
       78 天前
    @mmnnyycc 看到了,在微博上
    HFX3389
        70
    HFX3389  
       78 天前
    @dorothyREN #61 但我学前端的是被 recoil 搞的人都蒙了,最后发现好像我不适合造东西,适合用东西...
    realrojeralone
        71
    realrojeralone  
       78 天前   ❤️ 1
    a90120411
        72
    a90120411  
       78 天前
    我只知道 B 站在每个视频连接后面动态加了 vd_source 参数很恶心。
    wangyzj
        73
    wangyzj  
       78 天前
    @blless #64 万事不决先重启
    重启不行就多重启几遍
    yujinchn
        74
    yujinchn  
       78 天前
    @shyrock 你看我回复的谁,没说找不到啊,我意思就是说这种最好能找出详细原因,不然指不定下次又出现
    flyqie
        75
    flyqie  
       78 天前 via Android
    看完了,着实没想到当时的事故居然由于这种低级错误。

    通过一个缺失的 if type(b) == "number",暴露出来了这么多问题。。
    yujinchn
        76
    yujinchn  
       78 天前
    @shyrock 就你回复的啊,我的问题,说的有歧义,没说 b 站没找到,是说要是原因没找到的话
    A555
        77
    A555  
       78 天前
    去年的事,今年发事故报告
    salmon5
        78
    salmon5  
       78 天前
    我只关心内部管理和绩效上怎么处理的,其他都是渣渣
    pastor
        79
    pastor  
       78 天前
    会不会 2022.07.16 14:00-17:00 直播时又发生宕机,如果赶巧,就更社死了...
    Cbdy
        80
    Cbdy  
       78 天前 via Android
    B 站的网站做的是真烂,令人作呕
    Sixyuan
        81
    Sixyuan  
       78 天前
    重点是,op 为什么不发表自己的看法?我认为这是交流的前提。
    vision4fun
        82
    vision4fun  
       78 天前
    领导,人不够,加点人吧!
    LeegoYih
        83
    LeegoYih  
       78 天前
    草台
    Tussik
        84
    Tussik  
       78 天前
    我昨天在哔哩哔哩节点下也发了相关帖子,楼里关于测试的部分讨论我觉得还挺有意思的,大家有兴趣可以看看
    https://v2ex.com/t/866226
    NiZerin
        85
    NiZerin  
       78 天前
    简单的说就是:弱类型的锅
    frostnotfall
        86
    frostnotfall  
       78 天前   ❤️ 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 的种种小问题,总有种那着精致的小手枪上战场的赶脚。
    salmon5
        87
    salmon5  
       78 天前
    b 站和美团、58 技术就查很远,渣渣
    flyqie
        88
    flyqie  
       78 天前 via Android
    @frostnotfall

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

    这个应该属于弱语言通病,真打算扯到 lua 的话。。难道说应该直接报错而不是返回 nan ?
    flyqie
        89
    flyqie  
       78 天前 via Android
    @flyqie

    弱语言 -> 弱类型语言
    frostnotfall
        90
    frostnotfall  
       78 天前
    @flyqie #88 不好意思,的确看错了,这里是 lua-resty-balancer 的代码不是 lua 的代码,看的时候跑偏了因为前面说是 jit bug 。
    xiangyuecn
        91
    xiangyuecn  
       78 天前
    跟 弱类型语言 不弱类型语言 的 没有任何关系。该死循环的时候,换什么语言 谁都跑不掉🐶🐶
    Pythoner666666
        92
    Pythoner666666  
       78 天前
    @mmnnyycc “根源问题是 B 站的业务往 Redis 服务器里写入了个字符串类型的权重 0 值的坏数据(即 “0”)” 这个如果是真的那么说明 写这段代码的人使用 redis 的经验欠缺,因为从 redis 取值 无论是什么数据类型,取出来的值都是 string 。反之这句话就是假的
    evilStart
        93
    evilStart  
       78 天前 via Android
    @shyrock 啊这,b 站也算大厂啊
    frostnotfall
        94
    frostnotfall  
       78 天前
    @flyqie #90 但紧接而来的问题就是,lua 函数的实现,没有指定传入参数的类型?
    Ansen
        95
    Ansen  
       78 天前
    不看 B 站
    jqsl2012
        96
    jqsl2012  
       78 天前 via Android
    B 站是什么
    HankLu
        97
    HankLu  
       78 天前
    不要递归不要递归不要递归
    omnip
        98
    omnip  
       78 天前
    没人注意到最后一句话么:多活的高可用容灾架构确实生效了。 [doge]
    flyqie
        99
    flyqie  
       78 天前 via Android
    @frostnotfall

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

    好像没办法指定类型。
    liuxu
        100
    liuxu  
       78 天前   ❤️ 1
    代码出的 bug ,老运维来了也没用,哪怕运维能审核代码,lua 这个 nan 的坑该出问题还是的出

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

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

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

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


    这也说明了生产环境添加编译调试信息的重要性,像《高性能 mysql 》里面讲的,给生产环境 mysql 添加调试信息,哪怕增加 20%的 cpu 损耗,但是到了出问题分析的时候,绝对会觉得这 20%花的值
    1  2  
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2030 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 60ms · UTC 04:36 · PVG 12:36 · LAX 21:36 · JFK 00:36
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.