“B站崩了”火遍互联网，背后是复杂而脆弱的企业IT架构|焦点分析

作者 | 咏仪
编辑 | 苏建勋
万万没想到，B站崩了，让全互联网经历了一次深夜狂欢。
7月13日23时左右，B站主站、App、小程序均出现访问故障，无法正常使用，页面提示“正在玩命加载数据”。而B站的邻居A站，以及晋江、豆瓣也出现不同程度的故障，加载显示404、502等。
B站崩了，才让大家发现原来“小破站”的流量如此惊人。上不了网站、没得看视频直播的“B站难民”冲向知乎、微博以及著名游戏网站NGA。“b站崩了”“陈睿”“豆瓣崩了”等词迅速走红，甚至连B站名梗“蒙古上单”也一同霸榜微博热搜，传遍全网，颇为壮观。

文章插图
微博热搜
23时45分，B站网页端和App才初步恢复正常访问，但像直播、会员购等板块，以及一些站内互动、评论、投币功能，还无法正常使用。
B站崩溃后，许多故障页面截图在网上流传。但具体是什么导致服务器故障，多种说法迅速出现。不过，无论是最初的停电说，还是后面的B站大楼/上海云海服务器中心着火说，都被迅速辟谣。

文章插图
上海消防对B站总部大楼着火一事辟谣
直到凌晨2点20分，B站正式发布声明，表示因部分服务器机房发生故障，造成无法访问，经过排查修复后，现已陆续恢复正常。不过，更具体的原因是什么，B站还未披露。
服务器崩溃数小时，灾备没做好？企业IT架构越来越复杂，这也意味着故障原因往往是系统性问题，难以单一归因。此次B站崩溃，除了服务器出问题，补救的备份方案大概率也没有快速应用到位。
故障通常可从硬件故障和软件故障两方面来分析——硬件故障即是机房、服务器等物理因素；而软件故障则有可能来自版本升级、代码bug等带来的影响。
尽管不同行业有差异，但大互联网平台的技术架构，核心组件基本不会少。最简单的访问路径就是客户端和网站直接交互，比如一个视频访问请求从用户端发出，经过一系列处理后到达B站的前端、后端服务器、分布式存储等多个组件，B站处理完请求后再返回。
而当晚的情况是，B站崩溃，网友们收到的页面大多显示502，基本可以确定是服务器故障导致。
但具体是哪些服务器故障，目前还不清楚。B站这般体量的视频平台，上云是肯定的，也都会采用公有云+私有云架构。也就是说，出故障的服务器有可能在B站自己或托管的机房，也有可能在公有云服务商的机房。
若自家机房出问题，一个可能原因是，版本升级、网站维护失败，导致用版本回滚紧急解决。若没上云的刚好是核心业务，还需要运维人员手动修复，耗时就很长了。知乎答主“k8seasy”就认为，B站核心业务恢复时间在30分钟左右，并且几乎100%恢复，说明应是B站某个核心组件崩溃，导致核心服务不可用。有可能的原因是B站上线新版本时有bug，不可用后，紧急回滚到老版本也没扛住访问压力，最后网站环境崩溃。
若公有云厂商出问题，那么同一个服务器集群服务的其他企业，也会出现类似问题。但当晚的A站、晋江、豆瓣等大流量app都很快恢复了服务，故障程度和B站也不是同一个量级。再者，为B站提供云服务的厂商囊括了阿里云、腾讯云、京东云、金山云，公有云厂商一起出问题的概率是极小的。
【“B站崩了”火遍互联网，背后是复杂而脆弱的企业IT架构|焦点分析 | 负载均衡】分析完原因，再来看补救措施。服务器崩溃后的第一道防线，是企业的容灾和备份，这能够保证核心业务尽快恢复，最大程度减少损失。