如何看待 7 月 13 日 B 站服务器疑似突然崩溃？

使用CN2/CN2GIA顶级线路，支持Shadowsocks/V2ray科学上网，支持支付宝付款，每月仅需 5 美元

## 加入品葱精选 Telegram Channel ##

知乎用户 SINGLE 发表

众说纷纭之下，一个简单的猜测。

一些情报：

1.b 站，豆瓣，a 站等都崩了

2. 豆瓣，a 站等很快恢复了，b 站在编写回答的目前还没有恢复。

3. 疑似云服务提供商因意外断电。

以下是猜测：

因为云服务提供商出现意外，a 站和豆瓣很快接到报警，然后启动容灾方案，重新部署了环境。

至于 Bilibili，从这篇文章

https://cloud.tencent.com/developer/article/1618923

可以得知 b 站的 LB 是自研的，还有容灾系统也是自研的，一种比较靠谱的可能流程是：

1. 云服务提供商提供的 CDN 出现意外之后，大量请求绕过 CDN 直接打到网关。

2. 网关收到大量请求，自动启动了容灾策略。

3. 容灾策略启动服务降级。服务降级了但没完全降。

4. CDN 挂了，网关也跟着挂了，服务雪崩，一直崩到整个环境。

5. 整个环境炸了，重启全部容器需要相当长的时间。

至于一些其他有的没的，各种各样的情况可能性就太低了。鸡蛋不可能放在一个篮子里，bilibili 这么大一公司也不可能把机器全放在一栋楼，然后楼里断电还没 ups。

大家都是冷备热备冷热备，多机房异地容灾。这么久还没恢复我目前认为合理的情况只有这一个了。

有朋友告诉我恢复了，但是我这里还没有恢复。进一步是证实了容器组启动成功了，但是副本还不够多，现在还是降级状态。

刷出来了的朋友给我发了一下图，我发现他们刷到的视频都涉及差不多的，而且根本不是他看的东西，看起来是先把主战跑起来了推荐系统还没跑起来。

知乎用户 余歌​ 发表

睡不着啊，作为一只后端程序员，还是没想通小破站为什么会崩！！！

事故发生时，我在现场直播，完全没有任何的中断提示，害的我傻傻对着断了网的直播间哔哔了好久。 ‍

去年我很认真地听了 B 站技术总监的【B 站高可用架构分享】，刚刚又读了一遍文章，里面的设计架构没啥毛病，感觉就是细节和实施上可能出了问题。

B 站高可用用架构实践 - 云 + 社区 - 腾讯云​cloud.tencent.com

自己的猜测是：由于小破站和其他站点都崩了，说明是它们依赖的公共服务出了问题，而唯一有能力导致大规模服务瘫痪的就是 CDN 了，CDN 一挂，流量全打网关上。按道理来讲，网关应该是有熔断降级自我保护的，并且提供了对服务的保护，所以猜测网关是在熔断未开启的时刻被流量瞬狙的，网关一挂，服务没爹，自然就全局瘫痪。

还有一种猜测是由于 CDN 导致某服务执行耗时增加，导致上游执行耗时也增加，再加上上游不断积压请求，最终导致整个调用链血崩，所有服务从儿子到爸爸全部灭门。

但为啥这么久还没重启恢复呢？说好的异地多活呢？本人专业水平有限，等待一个解释。

-—– 补充 ——

关于总部大楼停电和机房火灾那个解释，不大可能，不会真的有人把机器放在一个地方吧？（狗头）

-—– 补充 ——

14 日凌晨 2 点，官方给出解释，事故原因是：服务器机房故障。

看到一些老师的分析，官方的解释是合理的，的确直接 B 站在对外分享高可用架构时没有怎么提到 灾备 和 多活 方面的设计，更多的是在本地应用内部去设计（限流、降级、熔断、重试、超时处理等），所以在设计大规模分布式系统时还是要考虑更全面一些，引以为戒~

所以机房为什么故障呢？蒙古上单出来！

另外刚刚收到了 B 站官方送来的 1 日大会员 补偿，还是很温暖的~

（没想到睡前不经意的回答竟然有那么多赞，谢谢大家~ 我是一名程序员 up，欢迎大家关注我呀）

知乎用户 程序员鱼皮​​ 发表

就非常想吐槽，现在不是以前那个小破站了，但是这服务器的容灾备份怎么这么糟糕……

公司平常这方面都在干啥 |･ω･｀)

哪怕是整个机房被端掉。都应该有异地的容灾备份吧！不指望你能做到秒切，但起码别这样都接近一个小时了，还不能正常使用。

知乎用户 锦瑟安华共卿度​ 发表

昨天睡得早，没赶上亲眼目睹 B 站的崩溃，今早一看，不只是 B 站，似乎 A 站、豆瓣、晋江都在同时间段产生了访问故障，具体原因当然要等官方说明，当然，官方也许不会公开说明，但是，我么可以猜想一下，脑补一下这次各服务宕机的理论，毕竟，哥德巴赫也只是一种猜想，进化论和相对论也是一种理论。

现在任何一个上规模的服务，架构都趋于复杂了，系统复杂，意味着组件多，而每一个组件都可能产生故障的，这不是玄学，是很实际的科学，所谓的『墨菲定律』，单个组件有 N 种理由产生故障，可能是刚部署上去的代码有 bug，可能是长期潜伏的 bug 被新情况触发出来，可能是机房断电，可能是机房光缆被挖土机挖断了，可能是机房内网线被巡查人员踢断了……

也正因为这个原因，每一个上规模的系统，都需要工程人员精心部署，考虑到每一个组件都可能发生故障，然后系统要能对故障自动反应，但是，工程人员对自己控制范围内的事情有把握，对于自己控制外的事情….. 就往往考虑不足，这些控制外的事情，包括（但不限于）：

• 云服务，现在很多服务都直接部署在各种云上面，使用云服务当然省事，但是，云服务也是一个复杂系统，你的服务能产生的故障，云服务也可能发生，就看他们的工程人员能不能规划好，还好他们专门干这个的，靠这个吃饭，所以大部分情况狂都能规划好，但也不是 100%，人孰无过。
• CDN，CDN 也算是云服务的一种，这里单独列出来，是因为在各种云服务品牌出现之前，CDN 行业已经很成熟了，CDN 是应对大流量的利器，每一个大流量平台都会依赖于 CDN，但是，如果 CDN 完蛋，那服务也要玩完，所以，如果要提高可靠性，最好不要只依赖于一家 CDN，要签下多家，能够在不同 CDN 之间切换。
• 突然激增的流量，这也是一个超出工程人员控制的事情，谁知道什么突发事件会发生呢，谁知道会不会一天之内一个排的明星出轨了呢。坦白说，虽然现在各种云都号称有『自动扩容』的功能，但是『自动扩容』这事需要一些反应时间，对于有些场景，还真不顶用，所以，即使使用云服务，工程人员也不要以为不用操基础设置的心了，该动脑子的还要动脑子。

以上只是理论分析，对于 B 站这事，因为和其他服务一起出问题，我猜想可能是几家公用的云服务或者 CDN 提供商发生了故障，当然，对于 A 站，还有一个可能，就是因为 B 站挂了，大批用户无片可看，就涌入 A 站，造成 A 站的流量激增，哪怕 A 站和 B 站不共用云服务，也可能被压垮。

当然，这些都是我的猜测和理论，不承担任何责任，大家就当技术科普文看好了。

最后说一点，一个服务崩溃之后引起轩然大波，说明这个服务影响大啊！这是好事，总比崩了之后都没人关心要好吧:-)

知乎用户 程墨 Morgan​​ 发表

我在重启手机，还是太年轻了。

说是豆瓣也崩了，那就是托管机房的问题了。

考验这些大厂栽备的时候到了，不说几地几中心吧，备用机房切换总该有吧。

知乎用户 albert lu 发表

目前可以确认的是：不只是国内版，国外版所有内容也都已经炸掉

理论上逼站应该不是有统一的固定服务器分发，肯定是有各种下端 cdn 的，在这种情况下，包括国外的所有 cdn 都炸掉了。

这…… 恕我直言。我觉得应该是逼站炸掉了。

还有一个问题啊，B 站你们没有任何保障措施吗？

到现在连客服都无法联络了，你们确定你们这不是搞信任危机呢？

而且我现在要是叔叔的话，我现在就连夜买 cloudflare，我都要赶紧把 cdn 再搞起来吧？自己家游戏聊天室都开始聊这种东西呢你们真的不觉得得赶快搞好吗？

算了，毁灭吧，赶快的！

评论区＋自己的体验，再补充几件事情

1. 国外服务器在 22：15 分左右，似乎部分恢复效果，可以打开主界面，但仍然无法进行操作。

而很快国外服务器也崩溃，目前已完全无法显示

2. 在该时间内，通过 B 站登录游戏，仍然可以使用 B 站的游戏，游戏也仍然持续运营

3. 目前官方无任何回复

4. 上接 3，现在已经有各种怀疑论了

5. 必剪可以使用，也仍然可以上传视频（这不赶紧成为炸服完第一个发视频的人）

知乎用户 旧时代的残党 发表

更新： 看到了评论热评，热评比我回答的赞还多是在闹哪样 捂脸. jpg

原回答：

哈哈哈

不止 B 站，A 站也崩了，晋江，豆瓣在微博热搜会晤，新浪服务器果然挺住了。然后现在知乎热度也爆表了。

起因是疑似 b 站停电后崩了，大量用户涌入 A 站，A 站承受不住这么大流量，然后也崩了，随后网友又一起涌入豆瓣、晋江想看看是怎么回事，这两个平台也没 hold 住齐刷刷瘫痪，最后所有网友齐聚在微博，热搜话题爆了，最后就是新浪程序员连夜加班扩容，互联网内卷之《谁也别想睡觉》

ps：我当时进不去 b 站还以为我路由器断网了，还傻乎乎的过去看了一下，检查没问题又重开了 vpn……

知乎用户 未来知乎大 V 发表

蒙古上单或为最大赢家。

知乎用户 冰河 Glacier​​ 发表

短短几分钟，整个论坛社交软件变成百家讲坛

- 停电说

- 火灾说

- 删库跑路说

- 刑事案件说

- 服务器供应商说

- 外星人说

- 黑客攻击说

- 大楼坍塌说

- 陈睿遇刺说

- 网警查封说

-decade 破坏说

- 墨茶显灵说

- 黄旭东毒奶说

- 境外势力说

- 反二次元吧吧友说

- 原神 c++ 大佬爆破说

- 腾讯恶意攻击说

- 孙笑川恶意踹机房说

- 李老八机房自焚说

- 抽象山庄 b 站团建说

- 嘉心糖咬断电缆说

- 刀哥最新整活说

-V 吧吧友不满国 V 说

- 国 V 友不满狗罕见说

（期待最新版本）

知乎用户 李森科博士 发表

卧槽，B 站这波炸的好彻底啊。网页端、App 端、直播、漫画、会员购等等，所有相关页面和服务全部阵亡，挂工具换节点也没用可见不是一个两个 CDN 节点的问题，这么久时间了一点恢复的迹象都没有，真的是完完全全的硬挺了。。。身为程序，不得不怀疑，这么大的公司，如果是纯技术问题能炸到这个程度吗。。。

知乎用户 正逍遥 0716 发表

大家都知道虽然我是一个程序员，但是我非常热爱运动，比如跳舞，这不每天回家睡前我都会在 B 站舞蹈区学习相关的舞蹈。

昨天也不例外，我一洗漱完就飞奔坐在电脑前，打开 B 站舞蹈区准备学习咬人喵，欣小萌、小仙若他们新的舞蹈动作，不得不说老婆们跳的真好，连我这种内向的人也不自觉的跟着扭动了起来。

正当我准备学下一个动作的时候，我发现怎么 404 NOT found 了。

坏了，作为开发的我第一直觉是系统崩了，我甚至怀疑是我网的问题，我发现手机网络正常电脑访问其他网页也正常，我就知道开发要背锅了。

我刷新了几次，发现还是这样，我就有点同情对应的开发同学了，年终应该没了。（到我写这个文章的时候网站还没恢复）

作为前程序员的我，就习惯性的去想 B 站的网站架构组成，以及这次事故复盘下来，可能会出问题的点。（老职业习惯了）

首先我们可以大致画一下简单的一个网站组成的架构图，我们再去猜想这次问题可能出在什么地方。

因为熬夜写文章哈，我也没在这种主要靠视频直播的公司呆过，技术栈也不是很了解，所以就用电商的大概逻辑，画了一个草图，大家轻点喷。

从上到下，从入口到 cdn 内容分发，到前端服务器，后端服务器，分布式存储，大数据分析，风控到搜索引擎推荐这我就随便画了一下，我想整体架构应该不会差异特别大。

我去网上随便查了一些类似斗鱼，B 站，a 站这样的公司，主要技术栈和技术难点主要有：

视频访问存储

• 流
• 就近节点
• 视频编解码
• 断点续传（跟我们写的 io 例子差多）
• 数据库系统 & 文件系统隔离

并发访问

• 流媒体服务器（各大厂商都有，带宽成本较大）
• 数据集群，分布式存储、缓存
• CDN 内容分发
• 负载均衡
• 搜索引擎（分片）

弹幕系统

• 并发、线程
• kafka
• nio 框架（netty）

其实跟我们大家学的技术都差不多，大部分技术体系差不多，不过语言应该是 go 为主，前端框架 vue，node 为主。

我们分析下这次事故可能出事的原因和地方：

1. 删库跑路

之前微盟发生过这个事情，我觉得各个公司应该都不会把运维的权限给这么大了，比如主机权限直接禁止了 rm-rf、fdisk、drop 这样的命令。

而且数据库现在大概率都是多主多从，多地备份的，容灾也应该是做的很好的，而且光是数据库炸了，那 cdn 的很多静态资源应该也不会加载不出，整个页面直接 404 了。

2. 单微服务挂掉拖垮大集群

现在都是前后端分离的，如果是后端挂了，前端很多东西依然是能加载只是数据出不来报错，所以集群要挂也可能是前端挂了，或者前后端一起挂了，但是还是那个问题，现在看起来是所有静态资源都无法访问了。

不过这个点我觉得也有一点可能，因为部分服务挂了，导致大量报错，拉挂了集群，而且越是这样大家越会不断刷新页面，给其他服务重启增加难度，但是这个可能性没我最后说的可能性大。

3. 服务器厂商出问题了

这种大网站都是 cdn+slb + 站集群，各种限流降级、负载均衡按道理都会做的很好，而且他们按道理不会不做容灾。

所以只有可能是这些前置服务的服务器厂商出问题了，CDN 如果挂了那网关负载均衡啥的压力都大了，最后导致连锁的雪崩效应打挂了整套系统。

但是我比较疑惑的是 B 站的 BFF 应该会路由到一些接入节点比较进的机房，这样全国各地的小伙伴刷的时候，应该是有些人好，有些人坏，有些人时好时坏才对，但是现在看来是全坏了，难道他们押宝了一个厂商的一个节点片区？

我看网上也在传云海数据中心起火了，不知道真假，只能等醒来看看 B 站官宣了，B 站原则上，理论上，从 CDN、分布式存储、大数据、搜索引擎都应该做了很多保证措施才对，如果真 all in 了一个地方那确实不太明智。

我的感觉就是没做好全部上云，线下的服务器出了问题，刚好是没上云的是关键业务，现在公司都是公有云 + 私有云这样的混合云搭配用的，但是私有云部分都是 B 站自己的内部业务，所以应该不会他自己的机房出问题。

如果真像我说的，押宝了一个服务器厂商，只是 cdn 出问题还好，如果物理机还出问题了，那数据恢复可能就慢了，我自己之前做大数据的，我知道数据备份都是增量 + 全量，恢复的时候真的好了一部分还可以从其他地区节点拉，但是如果是放在一个地方了，那就麻烦了。

复盘

我想不管最后是什么原因造成的，我们技术人和公司应该思考的就是怎么去避免这样事情的发生。

数据备份： 备份一定要做，不然如果真发生什么自然灾害，那是很难受的，所以很多云厂商现在都选在贵州我老家这样自然灾害比较少的地方、或者湖底、海底（比较凉快成本能下去不少）。

全量、增量基本上都是一直要做的，分天、周、月不断的增量数据，以及按时的全量数据备份，这样可以让损失降低很多，就怕所有地区的机械盘都坏了（异地容灾除了地球毁灭不然都能找回来）。

运维权限收敛，还是怕删库跑路，反正我是经常在服务器上 rm-rf，不过一般有跳板机才能进去的都可以做命令禁止。

上云 + 云原生： 云产品的各种能力现在很成熟的，企业应该对对应的云厂商有足够的信任，当然也得选对才行，云产品的各种能力是其一，还有关键时刻的容灾、应急响应机制都是很多公司不具备的。

云原生是近些年才大家才重视的技术，docker+k8s 这对应的一些组合，加上云计算的各种能力，其实可以做到无人值守，动态缩扩容，以及上面说的应急响应，但是技术本身是需要一些尝试成本的，而且我也不知道 B 站这样视频为主的体系，适不适合。

kubernetes 的设计上也会存在一些编排、通信的问题。

自身实力打造： 其实我觉得不管是上云，还是不上云，都不能太依赖很多云厂商，自己的核心技术体系和应急机制还是要有，如果云厂商真的靠不住怎么办？怎么去做真正的高可用，这我觉得是企业技术人员需要去思考的。

举个例子，很多云厂商都是一个物理机隔成多个虚拟机售卖，然后就会存在单物理机多宿主的情况，假如其中一方是电商玩双十一，一方是游戏厂商，对方大量占用网络带宽，你就可能存在丢包的情况，这对游戏用户来说是体验极差的，这样就是我说为啥不要过于信任和依赖云厂商的原因。

对方万一买了去挖矿，那更过分，把算力榨干，满负荷跑更难受。

B 站这次，好在这样的问题提前暴露了，而且是晚上，应该有不少流量低谷的时间去恢复，我写到这里的时候，网页大部分恢复了，但是我发现还是部分恢复。

不管怎么说下次就可以完全杜绝了，相信 B 站后面很长一段时间都会忙于架构体系改造，去保证自己真正的高可用。

希望以后能让我稳定的在晚上看看舞蹈区，而不是盯着 502、404 的 2233 娘发呆，嘻嘻

知乎用户 敖丙​​ 发表

B 站崩了后 3 个小时内都没有完全恢复，部分恢复也仅仅恢复了视频播放和上传，直播、评论 / 私信 / 点赞、论坛客服、钱包等功能均无法正常加载，这对 Bilibili 来说已算得上重大事故。

从舆论反馈可以看到，多数人在 B 站挂掉以后并没有第一时间认为是 B 站自己出了问题，反而是第一时间责怪网络运营商或手机的问题，侧面反映了广大用户对 B 站的忠诚度，但下一次就不一定了。

其次，B 站崩掉后巨量用户涌入其他平台，也反映了 B 站庞大的用户数和自身的影响力。

那么此次事故会造成什么影响？

1、在事故期间，有概率丢失你的互动信息和上传的视频，比如你在事故期间发表的评论、私信、动态（图文）等。

2、直播系统、账户系统、交易系统有没有问题有待观察，但开屏广告和站内广告均正常展示。

3、数据完整性和安全性需要观察验证，可以确定的是此次事故会使用户（尤其是内容生产者）降低对其的信赖度。因为视频平台最重要也是最根本的就是内容服务稳定性，连基本的稳定都做不到，会严重影响用户和内容之间的正常流通。

4、严重影响众多 Bilibili 网友的睡眠，严重利好知乎、微博、豆瓣、头条。

5、次日必然会有不少 Bilibili 用户要求 B 站补偿一个大会员。

感觉知乎也有点儿甭了…

知乎图片服务器的图片偶尔加载不出来，草稿有概率保存失败…

希望明天的新闻可以让 B 站崩溃事件出乎所有人的意料~

知乎用户 李嫑嫑​ 发表

不仅是 b 站，貌似很多平台的服务器都崩了

此刻充分体现了知乎的优越性

我对知乎只有感恩

知乎用户 茕尘幻梦​ 发表

叔叔我啊，真的要跑路了（不是

凌晨十一点崩了能秒上热搜，再一次证明了小破站流量真的多啊，股价要涨！

知乎用户 Mr 脑洞君​ 发表

都半个小时了！

看来 B 站的确没有备用计划。

否则半个小时还没能启动？

PS：如果真的如流传仅仅是个停电就造成这种破坏，B 站高层还是集体辞职吧。

PS2：A 站没事，最多是人流量太大挤到了。

这玩意能完整的打开并且每个页面都能打开就很神奇了……

知乎用户 幻想乡的洛克马戏​ 发表

根据现在看到得事实。

主站 404，其他站 502

同时有其他公司服务暂停

RPO 在一小时内，RTO 几乎为零

这是分发部分的事故了。至于是云坏了还是硬件坏了外人就不知道了。多数是云坏了，否则其他公司不会有问题，要么就是某个国内的托管机房整个端了，这也不是没有过。

RPO 和 RTO 概念是看灾备的一个重要方式。

也就是灾难恢复时间和灾难恢复速度，一般来说，冷备做不到灾难在一小时内恢复服务，而主服务器集群或者主储存直接下线做不到灾难数据损失为 0. 通常来说，RTO 为零或者几乎为零，又全面服务停止的灾难事故，大多是由于分发网络或者网关出了问题，但是一般不是 DDOS，因为 DDOS 会有部分访问幸运可以到。

而 RPO 在一小时左右也符合恢复流量分配的时间花费。

如果是主服务器整体下线，切换到备份服务器一般要 4 小时左右，如果是主存储损失，比如 NAS 损失其数据不太可能做到 0 损失。

知乎用户 萝魏紫​​ 发表

联通说不是他干的….

当然我们早就知道了，毕竟我家宽带都是电信的。

附带官方公告。

昨晚，B 站的部分服务器机房发生故障，造成无法访问。
技术团队随即进行了问题排查和修复，现在服务已经陆续恢复正常。
耽误大家看视频了，对不起!

确实是机房出问题了，

程序员们的年终奖保住了，

手动狗头。

知乎用户 李国宝 发表

叔叔我啊，要做中国的 youtube，看来成功了快。

知乎用户 Sithferia​ 发表

好家伙这才几分钟就两百多条答案，亏这两个网站平时还相互鄙视。

-————– 刷新一下四百多了。

23 时 02 分，507 条了

23 时 03 分，605 条了

23 时 04 分，702 条了

23 时 05 分，806 条了

23 时 06 分，925 条了

23 时 07 分，1079 条了

23 时 08 分，1245 条了

23 时 09 分，1461 条了

23 时 10 分，1678 条了

23 时 11 分，1954 条了

23 时 12 分，2193 条了

23 时 13 分，2452 条了

23 时 14 分，2715 条了

23 时 15 分，3009 条了

23 时 16 分，3278 条了

23 时 17 分，3549 条了

23 时 18 分，3802 条了

-————– 我停了，高估叔叔和我自己了。

-————– 网站已恢复，大家继续冲浪捏。

-————– 网站 \ APP 半恢复，首页可打开，视频、弹幕可播放，消息、动态系统 502。

-————– 先睡了，不刷新了免得 DDOS，今晚把 B 站留给运维。

知乎用户 尚山北 发表

B 站崩了以后，顺便带火了一个人：蒙古上单。有人说 “肯定是蒙古上单立功了”。

他其实是 B 站忠实用户，因为骂了 B 站老板陈睿而爆火，甚至成为一些 B 站用户的精神图腾。

去年大家知道，B 站发了个《后浪》视频，被全网群嘲，在 B 站平台也是引起巨大争议，

蒙古上单也因为反感《后浪》的价值观，对陈睿骂出了那句经典的

“你妈什么时候 X 啊”。

也是因为这种勇敢，他被 B 站老用户拥护，更重要的是，他并非普通的喷子，在 B 站手握 uid 六位的五级号和 uid 七位数的六级号，相当于 QQ 的 5 位靓号，地位非凡。

所以某种意义上说，算是 B 站第一批老用户的代表，但恰恰是这批老用户，对 B 站今天的很多行为非常厌恶，尤其是去二次元化和过度商业化。

这也是很多平台破圈后的必然之路：

大量用户涌入后，平台把重点放到更广大的人群，导致老用户的体验受损，甚至有被背叛的感觉。（听起来是不是很熟悉）

不过我最佩服的，还是 B 站用户阴阳怪气的内涵能力：

知乎用户 李小粥​​ 发表

妈妈呀，这就一万多回答了，平时知乎 B 站水火不容的，结果知乎上 B 站这么多回答。

果然玩 B 站的远比想象中的人多。

最搞笑的是 A 站进不去，连个问问题的也没。

这波 B 站看似崩了，但胜在无形啊。

知乎用户 叶夹心 发表

虽然我上一个回答是骂叔叔的而且刚刚才发不久。

但不得不说 B 站的这次崩溃反而证明了其强大的用户粘度和数量。

泥潭（nga 论坛），知乎，微博，QQ 群甚至朋友圈，全都是 B 站崩溃的消息，

微博短时间内冲上热搜，知乎直接空降热榜第一回答过万，论坛回复数上千。

在晚上十点后，不到一个小时内达成全网热议，这反映的就是这个网站的比重，已经占据了人们生活的一部分。

可以看出来，B 站近年的扩张实际上非常成功，陈睿作为资本家堪称一流，风评每况愈下也就不难理解了。

这次崩溃看似事故，实际上却是数据和流量的真实铁证，从个人的角度上看，这次打不死 B 站的，反而会让它更强大。

我建议能入股的都去试试。(狗头保命

最后放下一个蒙古上单. jpg

知乎用户 假面 发表

昨天晚上刚和女友做完刺激的事情，累了点根烟刚抽了一口，刷了一下 B 站，然后 …….

难顶，这该让我如何是好？？？？然后我的手不断下滑下滑，速度远远超过了我平常右手的速度，滑了半个小时还没好 。。。。。。 我心里一想，B 站得火了，这 P0 级别事故没跑了，啥事 P0 级别事故？这里科普下

可以理解为，基本上能直接把人立即开除的这种，不要求索赔已经是很好的了。

一时间众说纷纭，什么 B 站大楼停电了，台湾人民以为军队打过来了 。。。

还有更牛皮的猜测。。。。。。

然后蒙古上单是什么鬼？难道 lol 有个叫蒙古的，他正在打上单？？？？

这种上来直接问候母亲的是什么心态？？？小学生吧？没有陈老总还能有你今天躺空调屋里刷 B 站？

不只是 B 站，什么 A 站，豆瓣，腾讯官网都上不去了。

然鹅，最靠谱的我觉得还是这个。

大家莫慌，人 B 站虽然挂了，但是股票涨了啊！

所以我们大家还是抱着吃瓜的心态来看待这件事情吧，不过在吃瓜之余也不要忘了理性的思考，比如毛剑老师讲的 B 站的高可用架构是如何搭建的？

[腾讯云技术社区：bilibili 技术总监毛剑：B 站高可用架构实践​zhuanlan.zhihu.com

](https://zhuanlan.zhihu.com/p/139258985?utm_source=wechat_session&utm_medium=social&s_r=0&wechatShare=2)

这篇文章从最开始的没人看，到现在直接过白赞，B 站成就了毛剑老师。。。。。。

最后一瓜，大家紧急通知周围的小伙伴们

如果这篇回答对你有帮助的话，欢迎给

@程序员 cxuan

点个赞哦！！

知乎用户 程序员 cxuan​ 发表

明儿一早：

B 站技术总监：悄悄删掉 Linked in 最新一段履历并打开 Boss 直聘..

阿里云销售： 快，打车去 B 站，PPT 路上做..

（腾讯云：那我走？）

知乎 ： 好家伙，昨晚我差点也崩了..

微博： 好家伙，昨晚我差点也崩了..

A 站： 好家伙，昨晚我真崩了.. （┬＿┬）

01:30 上海恢复，B 站股价丝毫不受影响，甚至还涨了一点！

23:45 恢复了但又没有完全恢复… 据说是外星人袭击了 B 站内蒙机房，希望机器没事！

23:31 已修复！

知乎用户 Calvin​​ 发表

B 站挂了，大家都看不了，然后去逛逛 A 站

但 A 站平时根本就撑不起这样的流量，所以也顺便弄挂了

现在大家来知乎问，是不是也想把知乎弄挂？

你们有何居心，看热闹不怕事大？

现在是 0 点 20 分了，依然在线等 B 站恢复，真捉急啊

0 点 21 分，在线等，随便看这篇文章学习一下 B 站高可用架构，但软件架构在机房起火停电这种降维打击面前毫无抵抗力啊，一力降十会！

[腾讯云技术社区：bilibili 技术总监毛剑：B 站高可用架构实践​zhuanlan.zhihu.com

](https://zhuanlan.zhihu.com/p/139258985)

作为一名专业的运维工程师，我和大家科普一下系统的稳定性问题

以往很少人知道运维工程师（或者叫 SA|DevOps|SRE 等等…）的存在，而保障系统的稳定性就是运维团队的头号 KPI

互联网的技术人员应该都知道，没有什么系统是 100% 稳定的，每年能把稳定性做到 99.9% ~ 99.99% 就是不错了

这也是业界俗称的咱们要把可用性做到 3 个 9 或者 4 个 9

目前业界常用的 “系统可用性（Availability）” 这个概念，用一个专门的术语就是服务等级协议（Service Level Agreement，简称 “SLA”）

目前业界有两种衡量系统可用性的方式，一个是时间维度，一个是请求维度

时间维度：Availability = Uptime / (Uptime + Downtime)

请求维度：Availability = Successful request / Total request

对非本专业的同学来说，两者的统计原理差别不大，所以下面我主要用时间纬度来描述

不同等级 SLA 的每年允许的故障时间：

• 90%：36.5 天
• 99%：3.65 天
• 99.9%：8.76 小时
• 99.99%：52.56 分钟
• 99.999%：5.26 分钟

上面的含义是，如果是 SLA 为 90%，则意味着每年允许故障时长为 36.5 天，每个月大概可以故障 3 天，这是非常低的可用性

如果是 99.9%，每年允许故障时长为 8.76 小时，每个月大概可以故障 43.8 分钟，这已经是不错的可用性

可以看出，每多一个 9，允许的故障时间就会缩小到原来的 1/10

这意味着 SLA 越后面难度提高会越来越大，对于技术挑战、团队实力、资源成本的要求也会越来越高！

**我之前在一次技术分享里面有提到过，在运维工作中，质量（Quality）、效率（Efficiency）、成本（Cost），**三者不可兼得，我简称它为 QEC 定理。

一般互联网公司的要求是做到 99.9% ~ 99.95% 就是不错的了，如果一个刚创立的小公司，盈利模式还没搞清楚就大谈怎么把稳定性做到 4 个 9 的话，基本就是扯淡！

而一些对可靠性要求十分高的，比如云服务商基础设施、国民级的应用或者金融级的业务，就会要求做到 99.95%~99.99%，比如阿里云、支付宝、微信、银行业务这种级别，才会有刚需和资源去倒逼技术团队把稳定性做到 4 个 9 以上

当然，一个大的业务体系内部也是会有分级的，比如支付宝，它里面有账单、转账、支付、余额宝等等高级业务模块的需要 4 个 9 的保障，而它里面的用户信息、第三方服务之类就可以降低要求到 3 个 9（这是我的猜测，不代表支付宝内部真实数据，仅供参考）

我拿一个阿里云 ECS（即云服务器）的 SLA 协议作为样例参考

原文：ECS 服务等级协议

在 ECS 单实例的情况下，强如阿里云，也只能做到 3 个 9，不到 4 个 9 的稳定性，可见稳定性的提高在 3 个 9 之后是非常难的，我们在应用层要采用双机互备甚至异地双活的形式来保障更高的可用性

这时候可能有同学会来杠：我看新闻知道阿里云不是经常故障吗，是不是技术很菜逼，所以才做不到 4 个 9 啊

我只能说不知者不惧，你可以问问腾讯云、华为云的技术总监、大牛们，是不是都是以 AWS 和阿里云作为标杆来对标，如果阿里他们都是菜逼的话，其他云服务商得立即原地解散了

支付宝最大的黑历史莫过于 2015 年光缆被挖断导致停机好几个小时的故障

2015 年 5 月 27 日下午，部分用户反映其支付宝出现网络故障，账号无法登录或支付。支付宝官方表示，该故障是由于杭州市萧山区某地光纤被挖断导致，这一事件造成部分用户无法使用支付宝。随后支付宝工程师紧急将用户请求切换至其他机房，受影响的用户逐步恢复。到晚上 7 点 20 分，支付宝方面宣布用户服务已经恢复正常。

后来阿里巴巴痛定思痛，经过几年的技术、人力、金钱投入稳定性保障工程建设，终于在 2018 年云栖大会上秀了一把肌肉

从 “挖光缆” 到“剪网线”

2015 年 5 月 27 日，因市政施工，支付宝杭州某数据中心的光缆被挖断，造成对部分用户服务不可用，时间长达数小时。其实支付宝的单元化架构容灾很早就开始启动了，2015 年也基本上成型了。当时由于事发突然，还是碰到很多实际问题，花费了数小时的时间，才在确保用户数据完全正确的前提下，完成切换、恢复服务。虽然数据没有出错，但对于这样体量的公司来说，服务不可用的社会舆论影响也是非常大的。
527 这个数字，成为蚂蚁金服全体技术人心中悬着那颗苦胆。我们甚至把技术部门所在办公楼的一个会议室命名为 527，把每年的 5 月 27 日定为技术日，来时刻警醒自己敬畏技术，不断打磨技术。

经过几年的卧薪尝胆，时间来到 2018 年 9 月。云栖大会上，蚂蚁金服发布了 “三地五中心金融级高可用方案”。现场部署了一个模拟转账系统，在场观众通过小程序互相不断转账。服务端分布在三个城市的五个数据中心，为了感受更直观，把杭州其中一个数据中心机柜设置在了会场。工作人员当场把杭州两个数据中心的网线剪断，来模拟杭州的城市级灾难。

网线剪断之后，部分用户服务不可用。经过 26 秒，容灾切换完成，所有受影响的用户全部恢复正常。这个 Demo 当然只是实际生产系统的一个简化模型，但是其背后的技术是一致的。这几年来，其实每隔几周我们就会在生产环境做一次真实的数据中心断网演习，来不断打磨系统容灾能力。
从大屏幕上可以看到，容灾切换包含了 “数据库切换”“缓存容灾切换”“多活规则切换”“中间件切换”“负载均衡切换”“域名解析切换” 等多个环节。异地多活架构是一个复杂的系统工程，其包含的技术内涵非常丰富，单场分享实难面面俱到。本场是微服务话题专场，我们也将以应用层的微服务体系作为切入点，一窥异地多活单元化架构的真面目。

我们对于 SLA 应该设为多少作为目标？

这个问题没有标准答案，可以从公司的发展阶段、团队的发展现状、业务模式对可用性的容忍度等等几个方面综合考虑

一、业务发展阶段

从理论上来说，肯定是 9 越多稳定性越好，但是相应付出的成本和代价也会更高。比如为了更高的可用性，要有更多的冗余资源投入，甚至要做主备、双活甚至是多活。如果一家公司的业务量和影响力都发展到一定程度，那这个成本不管多高都是必须要付出的。但是，肯定不是所有的公司都需要付出这么高的成本，而是要先考虑 ROI（回报率）。这时候就要看企业自身对成本压力的承担情况了

二、团队发展现状

根据经验，业务研发团队和技术保障团队，每隔一些时间段都会有一定的侧重点，比如一时追求业务创新、一时追求研发质量、一时追求降本增效，这几个往往都是在往复循环的。比如技术架构发展初期，大家求快求创新，等到用户量大了，大家开始会关注质量和稳定，最后到业务瓶颈期了，大家对于成本的敏感度又会增加…… 这几个过程是往复循环、螺旋上升

三、业务容忍度

稳定性怎么设定，很大程度上还要取决于业务上的容忍度。对于核心业务或核心应用，比如电商的交易和支付系统，我们当然是希望成功率越高越好，一般对系统稳定性要求是 “3 个 9” 或“4 个 9”。因为这些系统一旦出问题，就会直接影响整个网站和公司的收益，这些都是钱，所以对稳定性要求必然就会提高。但是，对于非核心业务或应用，比如商品评论，商品评分等，或许 “2 个 9” 也能容忍。因为短时间的评论看不到，并不会对业务收入和用户体验造成太大的影响

知乎用户 Hi 峰叔​ 发表

做过 IT 运维的路过

很好奇这次有多少码农要被问责，有多少中高层要被撸。这绝对是一级事故了。

在没有热备机实时切换的状态下，要在几个小时内迅速找到问题所在，恢复服务，技术人员压力是非常大的。所以部分关键时候靠得住的码农，可能要升职加薪记功了。

码农 A：放心，你挂了服务器都挂不了。

码农 B：服务器挂了我就真的要挂了。

码农 C：服务器挂了就到我天秀的时候了。

码农 D：服务器挂了不是我们运维的错，一定是某些开发的错。

码农 E：重启大法好！挂了就重启！

码农 F：擦，千万别丢数据！

码农 G：供应商！供应商坑我！天杀的供应商到了没有！

注：此处码农泛指技术人员。

知乎用户 魔导师欧比旺 发表

炸了以后立马就来知乎凑热闹了，这不比拜年祭还让人开心✧ (ˊωˋ*) ✧

芜湖～乐子人永不为奴

话说 b 站没了，a 站也没了，那是不是该去 p…

知乎用户 请从正面刚我​ 发表

哔哩哔哩有力的证明了自己的日活数据确实很高，刚一出事立马上微博和知乎热搜，光速第一。毕竟五千多万日活，这一下崩溃就是上百万人手里的活计停了。

目前的结论似乎是停电，目前只观测到 B 站出了问题。A 站，豆瓣似乎并没有什么影响。

更新一下，A 站和豆瓣出现了一定的卡顿，其中 A 站明确有过崩溃，但目前似乎 B 站是崩的最久的一个。

更新，间歇性的好了，等下跟进公告就行，目前看来是大规模的问题，不止 B 站一家出事，因此说只针对 B 站一类的说法可以停一停了，比如楼塌了，程序员搞事，网警介入应该都不是，大家洗洗睡吧，应该是别的问题。

知乎用户 非生物 发表

1000 万 + 的热度上热榜第一，打破了乎乎近期冷冷清清的热榜。

迅速一万多条回答，连审核都是秒通过…

果然，我们都喜欢看热闹，而且还不嫌事大。

哈哈哈哈哈哈哈哈哈哈…

知乎用户 肆惜​​ 发表

据说是 1-22 楼停电。

a 站也崩了。

好兄弟一起走，谁先恢复谁是狗

顺便，豆瓣好像也崩了

知乎用户 阿源老师​​ 发表

众所周知，B 站今天的规模是 FGO 拉起来的，而 FGO 今天开了活动: 主线物语——深海电脑乐土 CCC 的联动复刻预告

所以……

Hacking……

Success！

BB——Channel！

噔噔蹬蹬噔噔噔噔咚~(心肺停止)

嗨依，这里是可爱的 BB 酱哦，现在正在黑进前辈的服务器哦~

知乎用户 BlickWinkel 发表

布衣之怒，免冠徒跣，以头抢地耳。

C 语言系列大佬之怒，B 站停摆，BU 哀嚎。

截至目前目前本次事件嫌疑人以下几位

A，蒙古上单

B，c 语言系列大佬

C，一定是 tx 的攻击！

请大家自由选择阵营。

评论区新增阵营

D，米哈游

E，境外势力

F，肖战

新增远古势力

F，孙笑川（某种程度也是境外势力了）

知乎用户 皮皮黑 发表

b 站炸了，群也炸了，光速整活，笑死。

知乎用户 一般路过 发表

#B 站崩了# 小破站就这么上热搜了~~

借着这个话题引申一下，B 站这回崩了所反映的是 B 站的容灾有问题，如果 B 站是挂靠在某个云平台，那么那个云平台的容灾也有问题。 对应的云计算平台今年年终奖应该泡汤了。

我估摸着 B 站的容灾能力（可靠性）并不是做的很好，因为追求可靠性的话，并不会因为单点故障就崩了~

知乎用户 MebiuW​​ 发表

B 站技术总监：故障演练，不小心让实习生切换到生产环境了 [旺柴]

十年总监无人问，一朝宕机天下知

知乎用户 大数据峰哥​ 发表

B 站先崩了，于是大家都跑到了 A 站，A 站事先没有准备于是服务器也崩了。

然后这波蝗虫兵分两路， 一路来知乎，一路去微博。 我猜下一个要崩的就是知乎了。 如果知乎再崩，那应该就全部跑去微博了。

微博如果也扛不住的话， 下一波可能就是 P 站了。

颇有当年 D8 百万大军出征的味道啊～

知乎用户 歌者的影子​ 发表

我没想太多。

以前 B 站小水管也经常崩。

我甚至认为是 “服务器重启” 的小调整而已。

结果一觉醒来，这么多瓜，吃都吃不及。

梦回 bishi 下小圆本。

知乎用户 零悠悠​​ 发表

原来大家都没有性生活啊。

知乎用户 阿澄​ 发表

叔叔我啊，最喜欢整烂活了

致敬新上单

知乎用户 快逃 发表

知乎用户 枫叶糖维 发表

今天我们都是蒙古上单！

知乎用户 天启​ 发表

搞工作搞了一天很难受，就想睡前乐一乐。

怎么 b 站刷不出来？

可能是网络问题，于是重启路由器。

没用，再重启一次。

我欠网费了吗？没通知啊。

刚想重启手机，随手点开知乎

知乎居然能用？！

然后热榜上鞭尸 b 站崩溃。

这就上热榜了？

是知乎用户和 b 站高度重叠？

还是知乎管家刚刚在滑水看 b 站！

于是开始一边在知乎上吐槽 b 站看热闹，一边时不时回头刷一下 b 站，看它恢复了没有。

PS: 刚刚恢复了，但是又不是完全恢复

知乎用户 dhchen​ 发表

大家热点把控能力太强了。

→_→

B 站崩的时候我正在回复 b 站评论，崩了之后我想的是 wifi 或者手机问题。

所以我把手机 wifi 切换成移动网络 - 把 wifi 重启 - 卸载重装了 b 站并重新登录 - 换手机登录。

一顿操作下来都不行，问了朋友他们也说不行。

我才开始刷微博和知乎。

结果，好家伙，在我操作这个的时候，2 个平台已经有了上万个 b 站崩了的相关动态。

是人？

我走？

你们为何可以如此敏锐？

知乎用户 王书皮​​ 发表

据说有 up 主播恐怖游戏播到一半看见没观众了，直接被吓哭了。

我就觉得你心理素质太差，建议学三天两觉边播边吐槽试试……

知乎用户 疯魔大校 发表

刚上传完视频就崩溃了

知乎用户 明美无限​ 发表

我刚在陈睿动态底下评论，小陈，你能给我磕个头吗，B 站就崩了，我也是无语了

23:47，b 站好像恢复一点了，通过搜索框搜索 up 主名字可以看视频。再次点开陈睿 B 站最新的那条动态，按照时间顺序翻评论，发现我那条小陈磕头的评论已经被删了，不过我也习惯被删评了，之前关注了一个社会学 up 主叫多罗西 123，经常和她互动，到后面 B 站新的评论系统上线后就经常莫名被吞评论，把我搞得烦了干脆就不写长评了，以前看到陈睿 nmsl 那个 gif 还感觉有点过分，现在… 呵呵，一直很喜欢碧诗的一句话，未来 B 站可能会倒闭，但绝不会变质，陈叔叔，我祝你生意兴隆，阖家安康。

知乎用户 归璨 发表

最后更新：

德国时间 9.39pm（北京时间 3.39am）

恢复正常了

粉丝数依旧是 1w、视频也都在

数据库没有被 “摧毁”（笑~）

再次更新：

又换错误代码了

看来在逐步解决问题

更新：

换了一个错误代码

服务器、数据库高手请在评论区解答

这哪是疑似

是真的服务器崩了，好么？

我（德国）点开 B 站主页：

来自朋友圈 B 站某运营的 “解释”

我觉得不可信

B 站作为一个上市的互联网公司

服务器多地备份是最最起码的事

楼里停电这个解释

估计只能骗骗没有学过数据库的高中生。。

六分教育，四分科普，聚焦硕博

欢迎关注：

[『留德华叫兽』微信公众号​www.zhihu.com

](https://www.zhihu.com/column/c_1328968911354740736)

知乎用户 留德华叫兽​ 发表

这问题有多少关注，就有多少单身狗。

知乎用户 大水怪出没请注意​ 发表

正看睡前视频呢，B 站突然就崩了！上海消防也被惊动？B 站大楼附近网友火速播报：可能是停电了

7 月 13 日晚间，许多网友突然发现 B 站崩了，消息迅速刷屏，空降热搜第一。

有网友感慨：“原来没有 B 站的时间这么无聊！”

据悉，同时崩溃的还有老牌二次元网站 AcFun（A 站）以及豆瓣。

至 14 日凌晨 2 点 15 分，B 站所有功能均恢复正常。

B 站官方 7 月 14 日凌晨发布消息称，昨（7 月 13 日）晚，B 站的部分服务器机房发生故障，造成无法访问。技术团队随即进行了问题排查和修复，现在服务已经陆续恢复正常。

B 站官方称，“耽误大家看视频了，对不起！

B 站深夜突然崩溃，空降热搜第一

7 月 13 日晚 23 点左右，许多网友突然发现 B 站网站和手机端同时崩了，该消息迅速刷屏，空降热搜第一。

与此同时，网传 B 站崩了是因为有火情发生。对此，上海消防迅速辟谣：经了解，位于上海市政立路 485 号国正中心内的哔哩哔哩弹幕网 B 站（总部）未出现火情，未接到相关报警。具体情况以站方公布为准。

另据网友爆料，此次 B 站宕机疑是由 B 站大楼停电导致。

不知是否受此影响，美股 B 站股价盘中一度涨幅收窄，最低至 3.26％。收盘时涨幅为 3.18%。

据澎湃新闻报道，B 站相关人士回复，经过第一时间检修，网页端和移动端正在恢复中。

至 7 月 14 日 0 点 30 分左右，B 站网页端和移动端大部分功能已恢复正常，视频播放和直播功能已可正常使用，但个人收藏、动态、消息等功能尚未恢复。

14 日凌晨 2 点 15 分左右，B 站所有功能均恢复正常。

不断 “破圈”，4 亿用户规模可期？

据财经网报道，6 月 26 日，B 站成立十二周年。当天，B 站董事长兼 CEO 陈睿透露，B 站的月均活跃用户达到 2.23 亿，其中 35 岁及以下用户占比超过 86%。

在创作者数量上，一季度，B 站月均活跃 UP 主达 220 万人，平均每个月创作 770 万条视频。

一季报显示，B 站一季度营收为 39 亿元，同比增长 68%；净亏损为 9.05 亿元，亏损额同比扩大 67.9%。

运营数据方面，一季度 B 站平均每月活跃用户 2.23 亿，移动月活 2.09 亿，分别比 2020 年同期增长 30％和 33％；平均每日活跃用户 6010 万，比 2020 年同期增长 18％；平均月度付费用户达 2050 万，比 2020 年同期增长 53％。

B 站董事长兼 CEO 陈睿曾对外表示，B 站 “2023 年内 MAU 达到 4 亿”。按照目前这个增速，4 亿的目标似乎不难实现。

平安证券认为，B 站牢牢占据年轻人心智，不断 “破圈”，4 亿用户规模可期。截止 21Q1，B 站 2.23 亿月活跃用户中 86% 为 Z 世代 +、50% 生活在一、二线城市，B 站也凭借对年轻人深刻的理解，不断创作和运营年轻人感兴趣的内容，深受年轻人喜爱，形成独特的品牌和商业价值。随着 B 站不断 “破圈”，管理层预计 2023 年底 B 站月活用户将达到 4 亿，对达成此目标持乐观态度，预计 B 站用户增长可能路径是向低线城市 Z 世代扩散以及向高线城市更宽年龄阶段扩散（类似 15Q1-18Q1 微博用户规模从 2 亿增至 4 亿）。

平安证券还表示，商业化加速发展，垂类人群产业化，泛化人群规模化。B 站商业化主要分为两大类，1）基于垂直人群的商业化，包括游戏、增值服务（直播、付费会员）、电商等，2020 年营收占比分别为 40%、32%、13%。2）基于泛化人群的商业化，即广告，营收占比 15%。

针对垂类人群，B 站采取做深产业化的方式，为 ACG 等垂类人群提供更专业的内容服务。针对泛化人群，B 站通过不断扩展内容品类，持续破圈。未来随着 B 站用户规模继续提升，预计广告收入占比将继续提升。

（本文不构成投资建议，据此操作风险自担）

编辑 | 段炼 王嘉琦 杜恒峰

校对 | 卢祥勇

每日经济新闻综合自微博、财经网、澎湃新闻、哔哩哔哩一季报、平安证券研报、公开资料等

知乎用户 每日经济新闻​ 发表

好家伙 B 站一炸，对面 A 站貌似流量激增也炸了。

https://m.acfun.cn/app/download?from=homepage&imgid=0 (二维码自动识别)

或者说 AB 两站后台用了一些一样供应商的 CDN、云主机等服务，要炸一起炸？

但如果公有云炸了，好像其他厂没有报错嘛？

我看了下 DNS 解析，貌似华为云金山云都有。

知乎用户 柴健翌​ 发表

昨天的事儿了。我啃着西瓜，刷着视频，突然弹幕加载不出来了。清后台重进，干脆主页都没了。

然后是微博一堆热搜，现在看知乎也有热搜。。。。。这至少说明 b 站的活跃用户量真的还蛮恐怖的，毕竟我印象中 b 站崩的时间点还挺晚的，10:30-11:00 的样子，我 12:07 分上的时候已经好了。这种阴间时间居然还有那么多人在看。。。。。

我倒还好，蒙了一会儿，刷抖音去了。

知乎用户 早为 发表

正在听 dixie 的我哭了

知乎用户 瓦岗寨主坑爹李 发表

来了来了，我吃着火锅唱着歌儿，突然就 404 了

OK 了，xdm 冲

？？？反复横跳？

好了，但没完全好

知乎用户 The xxx 发表

现在有几个看法：

1. 数据中心起火

2. 陈睿之死

3. 大型黑客团队（c 语言大师）ddos（bushi

4.B 站大楼停电

5.B 站大楼塌了

6. 大反转，B 站换域名了 (http://www.acfun.cn)(233333)

7.vtb 涉黄被封号

8. 直播查户口网警介入

9. 蒙古上单偷袭陈睿

10. 叔叔手 c 到服务器板子上了

11. 叔叔用 B 站服务器看片导致服务器宕机

12.Lex 与党妹受肖战与郑爽支持联合回形针攻击 B 站服务器，真正的幕后黑手竟是孙笑川

不知道各位支持哪一派看法

目前 B 站所有功能均已基本恢复。

本人在青岛市内，具体情况可能根据地区不同而不同，仅供参考。

23:51，目前 B 站波动较大，时不时还会出现 404 和 502 错误。

23:52，目前 B 站仍有波动，但部分视频可以加载并播放。不过还是有可能出现 502 错误。

23:53，投稿管理和个人动态仍然处于爆炸状态。看视频基本上好了很多。

23:58，B 站仍无恢复正常的迹象，反而 bug 和 404 和 502 更多了。

0:12，B 站除了会员购，直播，三连关注和个人中心以外的主要功能均已恢复。

0:32，B 站视频及动态功能仍有波动，个人中心已经基本恢复，个人中心部分功能比如个人收藏有时还无法打开。

0:44，直播中心已经可以访问，但客户端会不停显示 “数据格式错误”，网页版跳转链接失效。

0:46，直播可以看了，但部分直播功能依然无法使用。

0:57，会员购刷出来了一下，之后再次 502。

1:01，客户端个人中心部分选项消失超过一分钟，部分功能比如收藏无法使用。

1:04，客户端个人中心恢复原样，但个人中心部分功能依然无法使用。

1:14，直播中心基本完全恢复。

1:45，个人中心恢复了几分钟；会员购有几分钟可以访问但波动较大，之后再次爆炸；直播中心有几分钟不再提示 “数据格式错误”。

2:01，三连加关注恢复正常，个人中心恢复正常，

2:03，会员购可以正常访问了。

至此，B 站已经基本全部恢复。

期待明天 B 站的说法。

知乎用户 R.BSf 发表

我个人猜测可能的原因是最近 BW 刚过，大量参与 BW 的很多素人 Up 主上传了大量在 BW 现场和头部 Up 主互动的视频。

因为这些头部 Up 主本身就是很多人平时关注的内容，然后根据算法推荐，这些视频都收到了不错的流量，更加鼓励大家创作上传此类视频。

打个比方，吃素的狮子和小仙若，熊卡等 Up 主现场和水友们玩桌游，光我看到的就有几十个视频播放量过万，很多都是新注册的 ID 或者头一次上传视频的 Up 主放出的手机拍摄内容。

再加上六道，视角姬和狮子的好兄弟互动，这些视频叠加的投放量和播放量瞬间就几何数上升了。

同样的，小潮院长团队，怪异君，力元君等等也都被上传了大量素人拍摄到的视频，这些视频本身又用不到多少剪辑技术，又突然这么多流量（对于素人 Up 主来说）当然鼓励大家冲就完事了。

突然这么多人上传这么多 Bw 相关视频，会不会就是这次 B 站突然崩溃的原因呢？

嗨，我瞎猜这么多，转头一看微博原来是 B 站停电了，我真是猜了个寂寞！

知乎用户 例不虚发探花郎​ 发表

劳累了一天的年轻人们，正准备躺平拿出手机，打开那熟悉的小破站 App，一键三连自己最喜爱的 up 主的最新视频。突然发现：

瞬间，「B 站崩了」的消息登上热搜，微博运维心头一紧。

部分网友表示：A 站、豆瓣等网站也出现访问故障，重连 Wi-Fi 也没有用。

今日凌晨，B 站发布公告称，昨晚，B 站的部分服务器机房发生故障，造成无法访问。技术团队随即进行了问题排查和修复，现在服务已经陆续恢复正常。

「小破站」发生什么事了？

这份模棱两可的声明显然无法阻挡住吃瓜群众的热情。

短短几分钟，关于 B 站的各种揣测消息就变成了百家讲坛：

有火灾说、删库跑路说、刑事案件说、服务器供应商说、黑客攻击说、大楼坍塌说、外星人说……

还有人煞有介事地 Po 出了 B 站运营小妹的朋友圈，说 B 站停电了……

随后立刻有专业人士指出：B 站作为一个上市的互联网公司，服务器多地备份是最最起码的事，楼里停电这个解释，估计只能骗骗没有学过数据库的高中生。

至于 A 站和晋江文学网为什么会挂，很可能是因为 B 站挂了，大批用户无片可看，就涌入 A 站和豆瓣，造成网站的流量激增，哪怕 A 站和 B 站不共用云服务，也可能被压垮。

B 站 7000 多万日活网友的威力可见一斑。

下面我们看看几个相对靠谱的猜测：

知乎作者 @黄珏珅 盲猜了一下，应该是 etcd 挂了。

通常来说，能造成几乎所有请求都 502 的，要不就是前端和后端之间的网络通路全挂了，要不就是后端的服务全都挂了。

那么现在的大型互联网公司的基础设施是怎样的呢，大多数使用了 kubernetes，实现全国各地的数据中心的容器编排、网络虚拟化等。

而 kubernetes 的设计上，网络插件和 pod 编排又是相对独立的。

如果只是网络插件出问题了，那么部分服务器上的网络插件的缓存还在，一定有部分用户还能正常使用。

现在所有的都挂了，那只能是 etcd 挂掉，导致反向代理无法通过 etcd 找到对应的 pod 的虚拟 ip，又无法通过网络插件与对应的 pod 通信。

知乎作者 @k8seasy 则认为这个基本属于站点本身故障。从恢复时间看 30 分钟左右，并且几乎 100% 恢复，说明应该是某个核心组件崩溃了，导致核心服务不可用。

出现这种可能的不少，最有可能的原因是上线新版本，开始没问题，升级了部分集群，结果新版本有 bug，到了某个时刻直接挂了，老版本的压力一大也没扛住。然后紧急定位，回滚解决。

也有网友提出，此次事件与云服务商离不开干系：

云服务提供商提供的 CDN 出现意外之后，大量请求绕过 CDN 直接打到网关，网关收到大量请求，自动启动了容灾策略。

容灾策略启动服务降级。服务降级了但没完全降，CDN 挂了，网关也跟着挂了，服务雪崩，一直崩到整个环境。

盘点史上严重的服务宕机事件：最高损失上亿美元

在互联网历史上，「小破站」这样的宕机事件只能算是「洒洒水」，不信？我们来看看其他互联网大咖们是如何玩转宕机的。

**7 小时不能上微信：**2013 年 7 月 22 日，微信服务宕机，造成了将近 7 个小时的网络中断。据微信官方公布信息，由于上海一支施工队挖断了通信光缆，导致腾讯华东数据处理中心的业务请求纷纷转向华南和华北，进而导致了业务的全面瘫痪。

**用支付宝「剁手」失败：**2015 年 5 月 27 日下午，部分用户反映其支付宝出现网络故障，账号无法登录或支付。支付宝官方表示，故障是由于杭州市萧山区某地光纤被挖断导致，该事件造成部分用户无法使用支付宝。随后支付宝工程师紧急将用户请求切换至其他机房，受影响的用户开始逐步恢复。到了晚上 7 点 20 分，支付宝方面宣布用户服务已经完全恢复正常。

而在国外，网络宕机的事件更是屡见不鲜。

**亚马逊云服务罢工：**2015 年 9 月，亚马逊的云服务器因收到来自新上线的 DynamoDB 功能带来的大量数据请求，导致其因过载而宕机。于是，包括 Reddit、Tinder、Netflix 和 IMDB 在内的众多流行应用和网址直接罢工了数小时。

除了 Netflix，绝大多数亚马逊云服务的客户在此次 “突击检查” 中，都被发现毫无准备。而 Netflix 此前已经使用过一种名为 “混沌工程” 的技术来模拟类似服务中断事件的发生，使得这起事故对其影响降到了最小。

**纳斯达克停摆：**2013 年 8 月 22 日，由于纳斯达克交易所的备用服务器中出现了一个严重的 bug，直接导致纳斯达克停摆了 3 个多小时。当其恢复运作时，已经引起了市场恐慌，大量交易员涌向交易窗口，出售交易所运营商纳斯达克 OMX 集团的股票，导致 OMX 集团的股价当日一度大跌逾 5％。

事后有人评估，由于纳斯达克停摆造成的经济损失可能达数亿美元。

**全美大宕机：**2016 年 10 月 21 日早晨，许多美国用户突然发现包括 Twitter、CNN、Spotify 等大型网站均无法登陆。这场网络瘫痪从美国东部开始，一路蔓延至全美区域。事后发现查明，原因是服务器遭受了黑客的 DDoS 攻击。

关于 B 站宕机事故，新智元的热心读者，开源基础软件公司 Zilliz 的质量保障团队负责人乔燕良做了较为专业客观的分析：

现在的网站故障造成的原因主要可分为软件服务引起的故障和硬件服务引起的故障。软件服务故障一般可理解为代码逻辑缺陷，常见的是新增或更新某个功能而引入缺陷导致整个服务中断，硬件服务故障一般是由于某些服务设备的损坏造成的服务中断，比如光纤被挖断了。

如果要降低宕机风险，就需要提高服务的高可用性。首先从架构上，建议采用云原生架构，实现自动容错机制和故障隔离，从而能够在服务出现故障时快速迁移或回滚。

其次为防止硬件故障类风险，需要有完善的灾备方案，同城双活或异地灾备目前都已经有比较成熟的方案，国内企业在这块投入相对比较 “节约”。

Bilibili，下次一定！

知乎用户 新智元​ 发表

起初是发现香港 CDN 节点崩了，在海外碰到 B 站 cdn 蹦了很正常。少部分已经加载出来的视频还能看，但是弹幕和评论功能异常

后来事情不对劲了起来。SG 节点也崩了。接着是啥子域名啥页面都显示不出来了。看见 404 我以为是 DNS 污染，想查查上海节点的 IP。但看到 502 就知道事情，并没有那么简单

知乎用户 东方孤思子 发表

啊…… 这……B 站与知乎的重合度有这么高吗？

睡前想刷一下 B 站，结果总是加载出错，到知乎一看，热榜头条，13066 个回答。

不 可 思 议 ！

问我怎么看？我看这 B 站的股票啊，肯定要大涨一波。

另外 B 站你是有腾讯背景的，用阿里的服务器，是不是、不太妥当啊，哈哈哈哈

知乎用户 世界树的影子 发表

作为 B 站发了二十多作品却只有 35 粉丝的资深透明 UP 主，想知道这么多年积攒下来的 2177 硬币会清零么？

因为就答主第一时间想到的，是前几个月美国某能源管道企业的服务器被黑客组织入侵，文件被加密无法使用，黑客组织勒索 75 个比特币这个事件。万一 B 站也是如此中招，答主损失惨重…

知乎用户 MUMA​ 发表

知乎用户 麥发发​ 发表

我们群有一个小伙伴说：

“一群台湾的朋友，看不了 B 站，还以为解放军打进来了。”

知乎用户 庙祝大人 lord​ 发表

三分钟，让 b 站为我瘫痪 18 小时。

知乎用户 徒步欧欧子 发表

知乎用户 Koigggyear 发表

B 站高可用用架构实践 - 云 + 社区 - 腾讯云​cloud.tencent.com

知乎用户 花生 Peadar​ 发表

应该就是服务器故障了。

崩溃原因众说纷纭，也有高赞 up 爆料说是因为昨晚 b 站服务器遭到了密集攻击，也有说是因为停电的。不过我个人来说更喜欢这个说法：

总之，至高无上的蒙古上单抵达他忠实的哔哩哔哩总部！

以上。

知乎用户 许诺之瑾瑜​ 发表

B 站崩溃刷知乎！

知乎崩溃混 B 站！

都不崩溃轮流刷！

有多少朋友跟我一样的？

知乎用户 谢君楼​ 发表

我勒个去，这也太热闹了。

知乎用户 小朴​ 发表

刚刚 q 群看到的

知乎用户 霉凶兆 发表

我还以为我手机坏了。。

原来大家都是夜猫子 | ᴥ•́ )✧

知乎用户 后来​ 发表

因为 B 站崩溃，menggu 上单和陈睿在 B 站外再次同框，全网都在问蒙 gu 上单是何方神圣！

而真实的他是这样的

而在刚结束的 2021bilibil word 上，陈睿和蒙 gu 上单又一次火了，背后是 b 站破圈的用户反噬！

阿 b 与 2021 年 7 月 13 日炸站目前可知的谣言:

1 叔叔于 11: 36 永久离开了人世

2. 上海服务中心着火烧到 b 站

3.b 站总部停电

4.vtb 涉黄被封

5. 肖战指使蒙 gu 上单偷袭 b 站服务器

6. 有人查户口网警介入

7. 拍到外星人

8.bilbili 大楼塌了

9. 射到机房了

10. 更改域名

11. 上海遭遇核打击

12.PLA 进军台海 ​​​

知乎用户 毛琳 Michael 发表

11 点不到提的问题，现在差不多半个小时多一点，超过八千个回答。

看来没有 b 站看，确实对多数人来说都是有点不适应的。

知乎用户 强袭型吉姆 发表

B 站崩了导致 A 站和豆瓣崩了，说明这些产品互为替代，服务一个人群……

来让我们康康那些说自己是青年大众的社区的还有谁没挂。

西瓜视频果然不是服务年轻人的！

即刻看来还是小众。

知乎用户 王子嬴 发表

在 b 站停摆一个小时以前，我写了个动态

陈睿，你 妈什么时候活啊？

看来陈睿的妈妈大约的确已经复活了罢！

知乎用户 卫宫切嗣​ 发表

11 点 48 分，12000 回答

可以说创造知乎历史了吧

顺便，11 点 41 分左右应该已经好了，修的速度还是挺快的

知乎用户 半盏浮生半盏可乐​ 发表

恭喜恭喜。b 站运维 boss 大概可以开始写简历了，这肯定是一次 P0 级事故。

从这次故障影响面来看，应该是冲了整个服务器，这会儿就光起容器就得起半天。

要是线上全用的云原生，这可以说是一次云上灾备能力的极大信任危机。直到目前还是服务降级状态，看来优先级最低的活动页面之类的还得缓缓，不过直到现在搜推功能好像还没能完全起来。

没什么好说的，复盘对焦，今年整条运维安全的估计都得开会谈这事。两三个小时了还没做到提供服务，看来中国油管的路还很长啊～

知乎用户 敌码师 发表

反转了，是叔叔故意拔下的电源，是想让大家要么多出去走走，大晚上去夜店去酒吧体验一下夜生活。要么早点睡觉，第二天一早还给 999，不要一天到晚刷 b 站，如此良苦用心，结局让人暖心……

好吧，编不下去了，我正刷着小姐姐视频呢，一下子上不去了，心想就这点破事不至于封我吧，结果一看，原来是 b 站自己崩了。

另外，知乎包括微博，和 b 站用户重合度真高，上不去 b 站立马能热搜登顶，回答啪啪的向上涨，不到一小时破万回答，真的可怕。（侧面说明没什么夜生活的不只我一个）

最后这两人真的是相爱相杀啊，排名都是紧靠，建议在一起得了。

ps: 这个 “也” 字很有意思

知乎用户 鱼缸里的沫沫鱼​​ 发表

整了个活儿

这么一会儿回答就破万了

照这热度发展下去，知乎服务器也快崩了（狗头）

23:41 更新

似乎已经修复了

23:46 更新

修复了，但没完全修复（狗头）

知乎用户 刘昌睿​ 发表

救救孩子吧，银魂看的好好的，就点不进去了。

不过银魂是真好看，大家最喜欢里边的哪个角色呀

知乎用户 吃小姑娘啊呜 发表

前几天老断网，差点就又鼓捣自己路由器去了。

然后进知乎一看，这么多 b 站难民，再次证明了，b 站流量有多大，一个不小心就能溢出。

现在时间 23-43，原来这么多人都不早睡，自己本着从众的心理，又多了一个熬夜的理由。

知乎用户 维森 发表

原来这个点你们都在看 B 站啊，你们是不是都没对象所以才在看 B 站啊

知乎用户 Escaper 发表

B 站不是经常崩吗？再说，知乎不是崩得更多？

知乎用户 五方 Fa5​ 发表

广告好好的，一点都不卡!

我们看开屏广告吧。

知乎用户 菜鸟 Office 发表

哈哈哈哈哈哈哈

知乎用户 司马皇​ 发表

转瞬间八千多个回答

这牌面

证明 B 站用户的真实性

等知乎什么时候崩一下做个对比

知乎用户 欢子 发表

这答案更新速度

原来

知乎就是 B 站，B 站就是知乎。

这下我明白了

了然，了然。

知乎:

遭了! 我成替身了!

知乎用户 江睿谨​ 发表

十有八九是缓存击穿了，然后带崩了是所有业务，要不然也不至于这么彻底的炸了

你说会员购？大概… 没啥人看吧…

知乎用户 VeroFess​​ 发表

看刘飞儿直播然后 b 站炸了的路过，所以怎么个不做猩猩法

知乎用户 油面筋塞肉 发表

招聘的时候无论是 jd 还是 cv，高可用大规模分布式经验一个比一个要求高，一个比一个说的好，但是全都是飘的，没用。

防雪崩依赖良好的接口设计和框架设计，否则 gateway 根本无法有效设计熔断降级规则，服务间高耦合导致熔断失效，降级即崩溃。

知乎用户 Chen Moore​ 发表

原来 B 站崩了影响了这么多人的夜生活……

哦也不都是影响夜生活……

知乎用户 留学生日报​​ 发表

B 站确实是个大厂了，他崩了，微博热搜第一，知乎热搜第一，A 站被挤爆，

我本打算睡前刷一下 B 站，再听 ASMR 睡觉的，现在只能自己睡了，B 站不知不觉已经变得不可分割了，

经过我的不断尝试，能偶尔刷出来几次，视频也能看，有的有弹幕有的没有，但几乎都不能评论点赞，

知乎用户 封七天 发表

不止 b 站

甚至可以被称为 蹦 4(D) 之夜

知乎用户 坐于南山 发表

ks-tj-cu-w-06 - 404

ks-tj-cu-w-10 - 502

目前我这里能被分到的服务器就这俩

猜测：

ks 代表金山云

https://www.ksyun.com/cms/customer_case/97.html

tj 代表天津。。。？猜的

cu 应该是联通

剩下的不知道了 emmm

附加解释：能 Ping 通、能 http 跳 https、能显示报错只是因为最前面的负载均衡看起来没炸，而内部的服务器看起来崩了不少所以才左右横跳

所以是哪里引发的全站崩溃呢？盲猜数据库

知乎用户 张哲 发表

移动电信联通恐成最大赢家

知乎用户 水鸟​ 发表

知乎用户 小笛手 发表

B 站跌到，知乎吃饱？

知乎用户 王之葵托利​​ 发表

我在看嘉然的二创，怎么突然看不成了。

唉，只能看看收藏夹的嘉然 gif 了。

看到这条回答的小伙伴待会可以去 B 站关注 嘉然今天吃什么

拜托了，这对我很重要！

知乎用户 翔宇情​​ 发表

我想不通，明明平时在知乎大家都是把 B 站骂臭的节奏。

怎么 B 站一崩都跑到知乎寻求答案来了？？？

究竟是 B 站变大了，还是知乎 B 站化了

知乎用户 秋月司徒 发表

我正在看马三立怼北京大妈呢，结果连点赞收藏都不行了还好有缓存我给录下来了。

知乎用户 景勝 发表

知乎用户 LittleDannier 发表

很难不怀疑是不是 B 站在测试自身影响力【手动狗头】

知乎用户 汪叽 发表

现在舆论真的是太厉害了，这才炸毛一会儿，直接上热搜第一。

B 站好了，好了，然而还是上热搜

全民都在给 B 站做生产测试，好家伙，这哪个 BU 不会在做生产压力测试，压挂了吧。

还是机房网线被老鼠咬断了，逃。。。

知乎用户 左耳听风​​ 发表

知乎用户 十一 发表

别怕！我们还有知 乎 视 频 ！

知乎用户 Fisher​​ 发表

蒙古上单的亡魂回来了？

知乎用户 李昂​ 发表

今夜，我等皆为蒙古上单 (￣O￣;)

填空，请

知乎用户 Blumenkranz 发表

1. 总部火灾能影响服务器，这可真不该

2. 据说用户之后转移其它平台，也导致服务器挂掉，说明 B 站用户真的是游手好闲

3. 知乎没挂

知乎用户 常有晴​ 发表

不知道，早上打开时是好的？

晚上？

晚上谁有空看 b 站…

知乎用户 光棱镜​ 发表

我以为我欠费了，赶紧跑知乎来搜一下，原来是崩了啊。。。。。

知乎用户 想去跳伞 发表

没想到大公司能这么垃圾、

知乎用户 岩王帝姬 发表

7 月真是科技行业水逆呀！B 站今晚也….

看这个话题，微博热搜第一 [旺柴]

知乎也增长了那么多回答，唉 [叹气]

在别人伤口上撒盐，然后说，好可怜的娃～[吃瓜]

据说，上海云海服务器大楼火灾现场！！

知乎用户 大头妹​ 发表

你们一个个戒断反应一样，记住你们今天所展现出来的一切！都会成为晋元帝日后有恃无恐的资本。狗罕见又怎样？骂两句社会底层穷人又怎么样，你们还不是离不开叔叔我……

知乎用户 setsuCROW 发表

知乎到现在还崩，真没面子啊。

知乎用户 import 潘多拉 发表

以下内容均为主观臆测

从 502 到 404，盲猜先是全挂，后来修好了网关，现在在修 cdn

应该又是什么奇怪的测试（

先睡觉，看看明早啥情况

知乎用户 lwzheng 发表

事实证明，B 站的用户规模，影响力比你我想的大的多。停一会儿就会影响很多人。还在知乎几千个回答上了热搜。

而隔壁 A 站也停了，很长时间连个问题都没有。评论区还有人问 A 站是什么。（滑稽）

闲来无事，我谈谈自己对于 B 站的个人看法吧。

可能有人会好奇，为什么国内那么多视频网站，论资源论规模 B 站都算不上最强，还经常出现负面新闻，为什么反而越做越大以至于占据一席之地？论资源，影视综艺体育等，优酷，腾讯视频，爱奇艺等财大气粗资源众多；论用户，抖音快手等短视频可谓全民大多数。为什么 B 站在列强林立中商业运转能脱颖而出？

因为 B 站找到了自己生态位，有自己比较优势。

首先一个，是动漫，即商业动画漫画。这个领域 B 站就是正版网站中国大陆第一。占据全国互联网动漫资源半壁江山。总有老用户吐槽抱怨什么 B 站去二次元化了叔叔只看钱，但这点并不成立。B 站只是在各种内容题材增加破圈情况下，动漫 ACG 的相对比例被稀释而已。绝对数量，无论是每季新番还是购买老番，B 站都是在持续扩张。当然因为各种波折，尤其是 2021 先审后播政策和审核等影响，B 站正版番剧会受到冲击。但毋庸置疑的是，其源源不断资源依然会吸引更多用户。B 站可以做到让你每周甚至每天都有新番看。更不用说买的那些老番。原来新番争夺战还有爱奇艺，优酷，腾讯等参与，但近几年越来越少，只剩下 A 站还在积极竞争。

在国产动画领域，B 站和腾讯视频可谓五五开，各自占据半壁江山。靠着几部拳头 IP 国漫的兴起出圈。（灵笼，罗小黑，刺客伍六七，雾山五行，我的三体，凡人修仙传，元龙等），B 站在国产动画领域也是占据一席之地。2021 年甚至像日本动漫一样，有了 1 月，4 月，7 月，10 月等每季新番动画。

在漫画领域，哔哩哔哩漫画和腾讯动漫两超并列。腾讯是侧重国产漫画，B 漫则是日本漫画国产漫画都有不少。

游戏领域，B 站以网游手游为主。虽然不像腾讯那样财大气粗，但依然依靠自身特色，尤其是二次元手游等有自己一席之地。型月的 FGO，米哈游《崩坏三》《原神》，鹰角《明日方舟》，以及如《碧蓝航线》，《少女前线》，《公主连结》等作品，B 站游戏平台领域也有自己比较优势。

综合下来，B 站在 ACG，动画漫画游戏等各领域都有自己一席之地，尤其是在动画领域牢牢占据一哥地位。

其次是用户自制中视频这个独特生态位。

爱奇艺腾讯优酷等视频网站，在突出用户自主投稿视频这块并不突出。就算有投稿，大家也往往只记得视频，不知道投稿人。不像 B 站，UP 也能成为名人明星。虽然各种 UP 主良莠不齐鱼龙混杂，但总有一些天才脱颖而出。

用户投稿自制视频这块，比较强的是抖音快手等短视频。但抖音们有个劣势，短视频很方便，短平快吸引眼球流量。但时间太短内容不够无法满足全部需求。而 B 站中视频就有优势，B 站投稿视频时长很灵活，有几十秒，1～3、5 分钟的短视频，有 5～30 分钟的中视频，也有 30 分钟以上的长视频。其中尤其是中视频，在相对短平快同时，还能有足够时长接受内容表达观点。这是抖音不具备优势。这种中视频不仅吸引大量普通用户眼球，也能吸引很多新媒体人入驻。比如知乎很多大 V（马前卒山高县小约翰可汗等）转职 B 站 UP 主。

B 站视频没有贴片广告，这吸引很多用户。为了不看广告浪费时间，很多人甚至养成了只在 B 站看视频习惯。

动漫 ACG 和中视频吸引主要是年轻人（儿童，青少年，刚工作的人），和爱奇艺优酷腾讯等主要吸引成年人还不同。B 站内容重点经营年轻人生态位。

市场经济里，讲的是你的比较优势，占据生态位与规模优势。一个产品服务一个公司成败，不在于犯了多少普通错误（不是底线红线原则性问题）引起差评，也不是一些小资口中没有有思想内涵，而是在于市场上其生态位重要性，有没有同类或者更加先进竞争者取代其生态位。在没有取代生态位竞争者情况下，这个公司产品是不会倒下的。马与骑兵不是被大炮火枪取代的，而是内燃机车坦克汽车卡车取代其生态位；坦克不会被什么直升机无人机火箭弹导弹等对手淘汰，而只可能会出现更加先进便捷能取代其生态位的载具才会淘汰坦克。

知乎用户 鹏鹏 发表

目录

1、CDN 节点崩，导致的大崩盘。

2、应该不是云商的服务器问题

3、更不可能是停电导致的

4、B 站没做年度容灾恢复演练或者没认真做

5、大流量导致的各网站被冲崩的概率较低

我的建议

目前来看，B 站崩了后，A 站也崩了，豆瓣也崩了，晋江也崩了。

几种猜测：

1、CDN 节点崩，导致的大崩盘。

CDN 会承载部分负载均衡的工作，而且通常会是先判断哪个节点近、哪个时延低、哪个负载低，就把用户分过去。

部分 CDN 大节点崩了，然后访问量很大，负载分给另外一些 CDN 直接冲爆，连锁下 CDN 就崩了。

这会比较好解释为什么突然访问不了，然后蔓延到其他的站点（共用 CDN 的资源池）。

2、应该不是云商的服务器问题

目前底层 infra 通常服务器是用 x86 做虚拟化资源池，然后存储也是冗余级别够高的高可用。

再怎么出问题，infra 端的冗余是常规的，恢复也非常的快。

3、更不可能是停电导致的

目前数据中心都是双路市电 + UPS + 柴油发电机，加上动环监控、电路监控，基本会在出问题后有足够时间切换到其他的中心跑，不会影响服务。

如果是停电导致，那会有大量的服务中断，那就不只是 P0 级别重大事故，那是灾难级的了。

4、B 站没做年度容灾恢复演练或者没认真做

从时间点来看，爆出来有问题大概是 23 点后，恢复时间的发出公告在 02:20。

也就是重大事故处理完成时间大概是 3 小时，

这可以从侧面说明 B 站的 IT 团队没有认真执行年度容灾恢复演练，

因为演练后人员的熟悉程度会很高，能大大的降低排障的时间。

5、大流量导致的各网站被冲崩的概率较低

网上流传的是这样的

B 站先崩了，亿万网友涌入 A 站找寻快乐，但没想到 A 站承受不住这么大的流量，自己也崩了。然后网友们激情澎湃涌入豆瓣晋江吐槽，但架不住人太多也崩了

那为啥微博没问题？都上热搜了。

那为啥抖音没问题？不看长视频看短视频吧。

部分用户下滑的网站可能会削减资源供给，容易被冲烂。

但大部分都做了防 DDoS 的，大概率是不会全部用户都访问不了的。

我的建议

1、梳理 B 站的所有服务，把服务分级成一级二级三级服务目录，一级服务目录优先级调高分配更多资源和高可用架构。

如视频播放、弹幕等，保障基本服务运行。其余如购物、大会员、分区、直播等分二三级，实时性不高的，可以降低服务保障级别。

2、成本许可下，建设两地三中心，在各节点出现服务降级时，可以进行切换。保证服务可达的情况下，再慢慢排障恢复。

3、整顿团队对于灾难演练的重视程度，每半年执行一次大的事故演练，形成方法论，为每一次消除重大事故做好准备。

毕竟，这种隐患，会影响股价不是？

知乎用户 瑞恩的奇幻博物馆​ 发表

复杂的业务链条里有时候可能刚好有那么几个点，故障了之后没办法立刻恢复，并且引起上下游所有业务都出问题。这些点可能是硬件的，软件的，或者业务逻辑上的。

举个我们最近的例子，IDC 和 AWS 完全中断 76 分钟，因为专线供应商的两条异地光缆，一条在上海一条江苏，相继挖断了。

国内 IT 行业很多人对基础设施的脆弱性事实都缺乏理解，特别是互联网行业，迷恋于各种花式业务高可用架构，于是出现这样的事也就没什么好奇怪的了。

知乎用户 蓝莓的铲屎官​ 发表

我啊，最喜欢叔叔亏钱了

知乎用户 ooooooo 发表

阿 b 与 2021 年 7 月 13 日炸站目前可知的谣言：

1. 叔叔于 11：36 永久离开了人世

2. 上海服务中心着火烧到 b 站

3.b 站总部停电

4.vtb 涉黄被封

5. 有人直播开户网警介入

6.B 站大楼塌了

7. 肖战唆使孙笑川让郑爽色诱哔哩哔哩首席执行官陈瑞并趁机让蔡徐坤攻击哔哩哔哩服务器导致 B 站崩溃

8. 肖战指使桐生可可嫁给孙笑川导致陈睿心态爆炸于是要求米哈游今天公开未定新 PV 腾讯见状发动水军于是米卫兵和魔怔人对喷导致 b 站服务器炸裂

9. 陈睿射到 b 站服务器主板上

10. 陈睿和肖战在服务器机房………

知乎用户 辉夜​ 发表

第一反应：好耶

然后看着接下来一周要考的试，想了想还没看的网课：不好耶

什么，有百度网盘网课资源？

好耶

疑似的瓜？

10 分钟榜一, 三千 + 回答

这不比买热搜便宜？

叔叔成功证明了自己的流量，又赢麻了

叔叔我啊，这波在大气层

知乎用户 江流子​ 发表

大晚上怎么那么多人还在逛 B 站，你们都不睡觉的吗？（双重意义）

听说因为 B 站掉线了，搞得一群吃瓜群众跑去隔壁 A 站观察情况，结果把人家 A 站也搞没了。

A 站：请打开麦克风交流。

B 站还魂了？（doge）

B 站：我挂了，但没完全挂。

知乎用户 你的阿笑笑 发表

我个人有两种看法，

一种是 404

一种是 502

出现了 404 和 502 两种常见问题

知乎用户 程序猿旺旺​ 发表

结石，刚做完碎石手术，目前躺在床上奄奄一息，疼得实在受不了，想看点视频转移下注意力，没成想还没看就崩了。

本来以为是自己路由器问题，没想到打开某度竟然还能打开。

这波背刺让我雪上加霜… 现在疼得只想爆粗口…

Ps：B 站崩了，但是竟然同时登上了阿乎和阿博的热榜第一，虽然大家互相鄙视，但是用户重合度真的意外地高。。

搬一张远古老图…

知乎用户 Puddle​​ 发表

停电了停电了！叔叔生气了，把电源拔了！

群里又看到另一种说法，不知真假:

更新: 移动端已经能看了，以上纯属娱乐。这热度，就能看出来 B 站和知乎用户重合度有多高，原来你我都是二刺螈。

接着看嘉然啦！！！

知乎用户 风吹五角​ 发表

晚上睡觉前，票圈发现 B 站崩了，但我还是睡了，因为这点小破事，对于 B 站这么大体量的视频网站来说，不就是分分钟恢复的事！你们这些票圈刷屏的是不是西瓜吃多了！

结果早上起来刷票圈的时候发现 B 站的热度还没有过去，并且知乎还送了热榜第一。

一时间惊呼，当年没有坚持做 B 站，真亏！B 站的黏性原来真的高呀！原来这么多人睡觉前喜欢逛 B 站啊！

嗯，接着刷票圈，我发现这篇《bilibili 技术总监毛剑：B 站高可用架构实践》的文章火了，B 站的技术总监火了，不知道这下要不要拉出去祭天，我只能说程序员真的太难了！

贴一下原文吧，是时候再重读一遍了。

一、负载均衡

负载均衡具体分成两个方向，一个是前端负载均衡，另一个是数据中心内部的负载均衡。

前端负载均衡方面，一般而言用户流量访问层面主要依据 DNS，希望做到最小化用户请求延迟。将用户流量最优地分布在多个网络链路上、多个数据中心、多台服务器上，通过动态 CDN 的方案达到最小延迟。以上图为例，用户流量会先流入 BFE 的前端接入层，第一层的 BFE 实际上起到一个路由的作用，尽可能选择跟接入节点比较近的一个机房，用来加速用户请求。然后通过 API 网关转发到下游的服务层，可能是内部的一些微服务或者业务的聚合层等，最终构成一个完整的流量模式。基于此，前端服务器的负载均衡主要考虑几个逻辑：

• 第一，尽量选择最近节点；
• 第二，基于带宽策略调度选择 API 进入机房；
• 第三，基于可用服务容量平衡流量。

数据中心内部的负载均衡方面，理想情况下会像上图右边显示那样，最忙和最不忙的节点所消耗的 CPU 相差幅度较小。但如果负载均衡没做好，情况可能就像上图左边一样相差甚远。由此可能导致资源调度、编排的困难，无法合理分配容器资源。因此，数据中心内部负载均衡主要考虑：

• 均衡流量分发；
• 可靠识别异常节点；
• scale-out，增加同质节点以扩容；
• 减少错误，提高可用性。

我们此前通过同质节点来扩容就发现，内网服务出现 CPU 占用率过高的异常，通过排查发现背后 RPC 点到点通信间的 health check 成本过高，产生了一些问题。另外一方面，底层的服务如果只有单套集群，当出现抖动的时候故障面会比较大，因此需要引入多集群来解决问题。通过实现 client 到 backend 的子集连接，我们做到了将后端平均分配给客户端，同时可以处理节点变更，持续不断均衡连接，避免大幅变动。多集群下，则需要考虑集群迁移的运维成本，同时集群之间业务的数据存在较小的交集。

回到 CPU 忙时、闲时占用率过大的问题，我们会发现这背后跟负载均衡算法有关。第一个问题，对于每一个 qps，实际上就是每一个 query、查询、API 请求，它们的成本是不同的。节点与节点之间差异非常大，即便你做了均衡的流量分发，但是从负载的角度来看，实际上还是不均匀的。第二个问题，存在物理机环境上的差异。因为我们通常都是分年采购服务器，新买的服务器通常主频 CPU 会更强一些，所以服务器本质上很难做到强同质。

基于此，参考 JSQ（最闲轮训）负载均衡算法带来的问题，发现缺乏的是服务端全局视图，因此我们的目标需要综合考虑负载和可用性。我们参考了《The power of two choices in randomized load balancing》的思路，使用 the choice-of-2 算法，随机选取的两个节点进行打分，选择更优的节点：

• 选择 backend：CPU，client：health、inflight、latency 作为指标，使用一个简单的线性方程进行打分；
• 对新启动的节点使用常量惩罚值（penalty），以及使用探针方式最小化放量，进行预热；
• 打分比较低的节点，避免进入 “永久黑名单” 而无法恢复，使用统计衰减的方式，让节点指标逐渐恢复到初始状态（即默认值）。

通过优化负载均衡算法以后，我们做到了比较好的收益。

二、限流

避免过载，是负载均衡的一个重要目标。随着压力增加，无论负载均衡策略如何高效，系统某个部分总会过载。我们优先考虑优雅降级，返回低质量的结果，提供有损服务。在最差的情况，妥善的限流来保证服务本身稳定。

限流这块，我们认为主要关注以下几点：

• 一是针对 qps 的限制，带来请求成本不同、静态阈值难以配置的问题；
• 二是根据 API 的重要性，按照优先级丢弃；
• 三是给每个用户设置限制，全局过载发生时候，针对某些 “异常” 进行控制非常关键；
• 四是拒绝请求也需要成本；
• 五是每个服务都配置限流带来的运维成本。

在限流策略上，我们首先采用的是分布式限流。我们通过实现一个 quota-server，用于给 backend 针对每个 client 进行控制，即 backend 需要请求 quota-server 获取 quota。这样做的好处是减少请求 Server 的频次，获取完以后直接本地消费。算法层面使用最大最小公平算法，解决某个大消耗者导致的饥饿。

在客户端侧，当出现某个用户超过资源配额时，后端任务会快速拒绝请求，返回 “配额不足” 的错误，有可能后端忙着不停发送拒绝请求，导致过载和依赖的资源出现大量错误，处于对下游的保护两种状况，我们选择在 client 侧直接进行流量，而不发送到网络层。我们在 Google SRE 里学到了一个有意思的公式，max(0, (requests- K*accepts) / (requests + 1))。通过这种公式，我们可以让 client 直接发送请求，一旦超过限制，按照概率进行截流。

在过载保护方面，核心思路就是在服务过载时，丢弃一定的流量，保证系统临近过载时的峰值流量，以求自保护。常见的做法有基于 CPU、内存使用量来进行流量丢弃；使用队列进行管理；可控延迟算法：CoDel 等。简单来说，当我们的 CPU 达到 80% 的时候，这个时候可以认为它接近过载，如果这个时候的吞吐达到 100，瞬时值的请求是 110，我就可以丢掉这 10 个流量，这种情况下服务就可以进行自保护，我们基于这样的思路最终实现了一个过载保护的算法。

我们使用 CPU 的滑动均值（CPU > 800 ）作为启发阈值，一旦触发就进入到过载保护阶段。算法为：(MaxPass * AvgRT) < InFlight。其中 MaxPass、AvgRT 都为触发前的滑动时间窗口的统计值。

限流效果生效后，CPU 会在临界值（800）附近抖动，如果不使用冷却时间，那么一个短时间的 CPU 下降就可能导致大量请求被放行，严重时会打满 CPU。在冷却时间后，重新判断阈值（CPU > 800 ），是否持续进入过载保护。

三、重试

流量的走向，一般会从 BFE 到 SLB 然后经过 API 网关再到 BFF、微服务最后到数据库，这个过程要经过非常多层。在我们的日常工作中，当请求返回错误，对于 backend 部分节点过载的情况下，我们应该怎么做？

• 首先我们需要限制重试的次数，以及基于重试分布的策略；
• 其次，我们只应该在失败层进行重试，当重试仍然失败时，我们需要全局约定错误码，避免级联重试；
• 此外，我们需要使用随机化、指数型递增的充实周期，这里可以参考 Exponential Backoff 和 Jitter；
• 最后，我们需要设定重试速率指标，用于诊断故障。

而在客户端侧，则需要做限速。因为用户总是会频繁尝试去访问一个不可达的服务，因此客户端需要限制请求频次，可以通过接口级别的 error_details，挂载到每个 API 返回的响应里。

四、超时

我们之前讲过，大部分的故障都是因为超时控制不合理导致的。首当其冲的是高并发下的高延迟服务，导致 client 堆积，引发线程阻塞，此时上游流量不断涌入，最终引发故障。所以，从本质上理解超时它实际就是一种 Fail Fast 的策略，就是让我们的请求尽可能消耗，类似这种堆积的请求基本上就是丢弃掉或者消耗掉。另一个方面，当上游超时已经返回给用户后，下游可能还在执行，这就会引发资源浪费的问题。再一个问题，当我们对下游服务进行调优时，到底如何配置超时，默认值策略应该如何设定？生产环境下经常会遇到手抖或者错误配置导致配置失败、出现故障的问题。所以我们最好是在框架层面做一些防御性的编程，让它尽可能让取在一个合理的区间内。 进程内的超时控制，关键要看一个请求在每个阶段（网络请求）开始前，检查是否还有足够的剩余来处理请求。另外，在进程内可能会有一些逻辑计算，我们通常认为这种时间比较少，所以一般不做控制。

现在很多 RPC 框架都在做跨进程超时控制，为什么要做这个？跨进程超时控制同样可以参考进程内的超时控制思路，通过 RPC 的源数据传递，把它带到下游服务，然后利用配额继续传递，最终使得上下游链路不超过一秒。

五、应对连锁故障

结合我们上面讲到的四个方面，应对连锁故障，我们有以下几大关键点需要考虑。

第一，我们需要尽可能避免过载。因为节点一个接一个挂了的话，最终服务会雪崩，有可能机群都会跟着宕掉，所以我们才提到要做自保护。

第二，我们通过一些手段去做限流。它可以让某一个 client 对服务出现高流量并发请求时进行管控，这样的话服务也不容易死。另外，当我们无法正常服务的时候，还可以做有损服务，牺牲掉一些非核心服务去保证关键服务，做到优雅降级。

第三，在重试策略上，在微服务内尽可能做退避，尽可能要考虑到重试放大的流量倍数对下游的冲击。另外还要考虑在移动端用户用不了某个功能的情况下，通常会频繁刷新页面，这样产生的流量冲击，我们在移动端也要进行配合来做流控。

第四，超时控制强调两个点，进程内的超时和跨进程的传递。最终它的超时链路是由最上层的一个节点决定的，只要这一点做到了，我觉得大概率是不太可能出现连锁故障的。

第五，变更管理。我们通常情况下发布都是因为一些变更导致的，所以说我们在变更管理上还是要加强，变更流程中出现的破坏性行为应该要进行惩罚，尽管是对事不对人，但是还是要进行惩罚以引起重视。

第六，极限压测和故障演练。在做压测的时候，可能压到报错就停了。我建议最好是在报错的情况下，仍然要继续加压，看你的服务到底是一个什么表现？它能不能在过载的情况下提供服务？在上了过载保护算法以后，继续加压，积极拒绝，然后结合熔断的话，可以产生一个立体的保护效果。 经常做故障演练可以产生一个品控手册，每个人都可以学习，经常演练不容易慌乱，当在生产环境中真的出现问题时也可以快速投入解决。

第七，考虑扩容、重启、消除有害流量。

如上图所示的参考，就是对以上几个策略的经典补充，也是解决各种服务问题的玄学。

这让我又想起了，电脑上的那几本经典的架构书：

再重新读几遍吧：读完这些计算机经典书籍后，我飘了！

-—- 人肉分割线 –

有一说一，崩了和技术总监没太大关系，毛剑老师还是比较有实力的。我觉得可能是技术落地的时候，有些地方没有实施，

所谓祸兮福所倚福兮祸所伏，这热度，我觉得 B 站这波不亏。

从昨天晚上瞬间到知乎热榜第一，现在依然还在。
不过，作为同行，昨天晚上，B 站的程序员小哥哥和小姐姐有的忙活了，心疼。

知乎用户 沉默王二​ 发表

昨晚 11 点多准备去看下，发现一直转圈，半天出来个漫画图片，觉得不可思议，又刷新了一次还是一样。以为是我红杏软件设备出了问题，试了下打开各国外网站都正常，国内网站也基本没问题，上网看了下新闻也没说服务器出问题了，然后就去睡觉了。

到今天醒来才发现上了头条。

这次的情况是，多个网站都有问题，估计肯定是机房或者云服务商出了问题。

知乎用户 二炮手​​ 发表

很多生产队偷懒的驴，找到借口了。

欧耶！

知乎用户 曹小灵​​ 发表

短短几分钟 登顶微博热搜第一，知乎答案快破万，足见 B 站影响力之大，股票可以继续买

知乎用户 无火的余灰 发表

这是 B 站新的营销方式 ？瞬间热榜第一｜一分钟几百回答

想起来之前豆瓣营销 ：豆瓣卡了｜微博营销 ：微博爆了

………

知乎用户 来去的加菲 发表

正准备三连呢，就崩了，好吧，又白嫖了，下次一定！

原来是服务器中心着火了，不知真假，但大楼也停电，要不咱用爱发电吧！恢复供电…… 哈哈哈哈哈。

倒是把湾湾那边吓着了

知乎用户 鵝鵝鵝​ 发表

看群里说 B 站炸了，然后我就说 B 站是微服务架构啊咋能炸的这么彻底，

然后群里一通人就各种分析可能是负载均衡崩了、可能是数据库崩了什么什么的……

然后你告诉我是机房整个没了？

知乎用户 有木桑 发表

昨晚 b 站短暂的好过。

看到自己首页推荐居然有肖战王一博处 cp 的视频以为自己号废了。

叔叔你不会喜欢这个吧？

知乎用户 寂静的河流​ 发表

b 站炸了，看到知乎这个热度，才发现原来有这么多 b 乎 er。狗头. jpg

知乎用户 清苦 发表

挺突然的

我刚刷完老邪发的视频，转战下一个，结果刷不出来。显示断网

重新连 WiFi，无

换流量，无

然后我以为是手机问题，用手机管家清理修复了一下，还是无

手机重启，无

我以为是我没更新 APP

卸载，重新安装，无

看看微信，咦有网啊?

我电脑也登了 B 站，看网课来着

刷新一下，无

我：……

打开知乎，搜 B 站登不上，看到了这个问题

我：原来我不是一个人，哦，那没事了

PS. 我刚看到这个问题的时候回答还只有个位数，就顺手评论了第一个回答，盲猜 B 站崩了，转一会儿知乎回来，好家伙回答已经上五位数了，B 站也是真的崩了哈哈哈

现在 B 站崩了成了知乎热搜第一，笑死

B 站崩了，A 站也崩了，我准备去猫耳或者网易云了哈哈哈

知乎用户 天地舟行客 发表

这才叫 “热榜”

那种百十来个回答的问题，也好意思在热榜上？

知乎用户 牙不膏 发表

不理解。。。。这个问题有必要都来回答吗？不就一件小事吗？至于这么火吗？

知乎用户 拾年​ 发表

【小道消息】据说是因为陈睿跟肖战私奔了，所以 B 站炸了。

知乎用户 sky 和霍去病​ 发表

B 站完全没的看 (好了一下)

又好了。。。

A 站现在也完全看不了 了

应该是知乎和微博搞得鬼。

诶嘿

我靠，我现在感觉知乎刷新都变慢了。。。

各位都没有对象吗？这么晚还刷手机？

A 站也上不了，B 站也上不了，知乎都卡，那应该是 271 搞的鬼。

知乎用户 改个名​ 发表

武功再高，也怕菜刀。

昨天正在看《罗小黑战记》，结果突然发现 B 站挂了

一开始还以为是自己的手机有问题，又怀疑是无线网有问题

最后都正常——那就是 B 站真的挂了。

从风险管理的角度，这也是一个正常的，可知范围的风险，但需要注意的是，这个风险背后我们能够反思到什么东西？

现在的互联网公司，比以往任何时候都要更加重视安全风险。而这个安全风险，不是传统的打雷下雨烧了电脑，也不是脚崴了或者被车撞了。

而是一个更加广阔的大安全风险。

1. 政治安全风险：TIKTOK 在海外的风波——背后不仅仅是商业风险？

2. 金融安全风险：民间互联网金融行业，包括蚂蚁金服都是例子——真不知道自己是干什么的？

3. 数据安全风险：滴滴就是例子，还有其他获取个人信息的——国家得数据岂能被外人窥伺？

4. 技术安全风险：华为等企业的芯片荒——难道国家的导弹要用洋人的芯片？

5. 形象安全风险：某东高管在北美发生的 XX 事件 / 某宝高管在微博发生的互撕事件——精英们，请你们不要说一套做一套好吗？

6. 经济安全风险：被垄断法影响的那些企业——最后一点一滴的利益都要和老百姓争，而且你们的避税方式又那么复杂，真当我我 GS/SW 都是泥捏的吗?

7. 健康安全风险：大量的 996，大小周，你让年轻人都不敢生孩子哪还了得？快递员就是危险源，感情你是不送外卖了，那些道路交通安全风险谁来买单？

8. 不可抗力及人为原因导致的安全风险：大雨，暴风，火灾，地震，疫情，蓄意破坏，袭击所导致的损失，是否有充分的应急预案进行响应？

以上这些 “菜刀”，本质就是风险，任你互联网大厂武功再高，也要小心，否则，就要你小命。

知乎用户 嘉天​ 发表

大概率是 Go 写的服务出问题了（内存泄露、死锁），导致数据库连接爆了，最终就是数据库宕机。

靠重启服务短暂恢复服务，治标不治本。

知乎用户 eechen 发表

模拟或真实黑客 ddos 攻击，结果证实只要攻击强度够大，是可以攻击的，因为攻击后可以用户的反复访问请求进一步提高了并掩护了攻击力度。

知乎用户 易冷轩​ 发表

吓得我以为是知乎崩溃了。

有这么多回答了，还是两个小时都不到的时间。

网的世界！

知乎用户 亚东​ 发表

这一定是 lex 的阴谋

知乎用户 orchimike​ 发表

阿 b 跌倒，知乎吃饱

知乎用户 米夏埃里斯 发表

服务器是叔叔搞坏的。叔叔为了赚钱，把服务器弄掉了不让我们使用，真是恶心到为所欲为了

知乎用户 混沌之子 发表

今晚，我们人人都是蒙古上单

蒙古上单走后，我们就是他

蒙古上单重返他忠实的 B 站

知乎用户 喂不饱的兔兔伯爵 发表

赶紧买知乎股票，今天铁定涨停！财富密码：

蒙古上单！蒙古上单！蒙古上单！重要的话说三遍！

叔叔我啊，最喜欢发财啦！

膜拜老威预言帝！

知乎用户 小学体育老师 发表

昨天 a 站，豆瓣，晋江也都崩了……

如果是多家同时宕机，大概率是云服务提供商的锅，这几家应该都是阿里云或者腾讯云吧。

另一个说法，是 B 站流量如滔天洪水，崩了以后大量的用户没地方去，跑到微博，知乎，a 站，豆瓣，晋江等入口吐槽，然后其他几家没抗住，也崩了……

并不是说这些网站太弱，接纳不住这么多用户，而是技能树没点这个分支。

一般来讲，没有双十一秒杀场景的话，能够支撑同时在线的用户数足够即可，所以一般网站或 APP 不太需要 “瞬时高并发” 的处理和承载能力，但是昨天这种情况，就是瞬时高并发，类似微博突然爆了个大瓜，一般网站都没有应对这种突发流量的应对方案，所以就崩了。

B 站股票先跌后涨，大家都看到 B 站流量之大，可以冲垮其他站点，用户粘性之强，接近凌晨依然有这么大的流量，未来可期。

大家都觉得不可能停个电就断网这么弱鸡，那问题就更大了。

如果不是基础设施遭遇不可抗力，比如停电，自然灾害，或者光缆被挖断，那就是被攻击，或者内部管理出现问题。

被攻击说明网络安全有漏洞，特别 B 站还是美股上市的，超过 100 万用户的，符合最近网络安全审查的条件，是不是搞内部审查或者演练搞出事情了？

内部管理问题也很麻烦，除了上面说的情况，会不会是工程师删库跑路，或者低级错误？

不管怎么样，这么长时间的服务不可用，都是重大生产事故，明天股价不好看了。

应该是停电了。

不过让人非常好奇啊，没有 UPS？没有同城灾备？（异地灾备就不强求了）

看来互联网公司（非金融类）的运维比起金融行业就是个弟弟。

知乎用户 Kevin Zhang​​ 发表

看完波士顿胖子，去点超想吃番茄，发现 404 了。还以为大的要来叻，结果一看就他家炸哩。奈奈滴。

知乎用户 十八千坛女儿红​ 发表

我是从群里得到消息的，试了一下果然崩了。这人真的很奇怪，本来第一时间没在看视频，得知服务器崩了反而想看了，于是我点开缓存视频，想看一看有没有缓存视频可以看：

国玉不是无情物，化作尊尼更获嘉。

寄了。

知乎用户 吉吉国王电棍儿 发表

B 站炸了，知乎爆了。

所以 B 乎这个名字，到底具不具有预言性质？

知乎用户 韩鹏大魔王​ 发表

还就那个 b 站后花园

知乎用户 世最新一期​ 发表

是不是被拜登给黑了？毕竟今天疫情防护第一可能有点尴尬了，顺手把 B 站给黑了！

这波不会直接带崩微博吧！

不过突然发现大家都没有夜生活啊！

知乎用户 IT 烟酒僧​​ 发表

阿 b 与 2021 年 7 月 13 日炸站目前可知的谣言：谣言多到能创小说了，现场可编一个爱恨情仇。
1. 叔叔于 11：36 永久离开了人世
2. 上海服务中心着火烧到 b 站
3.b 站总部停电
4.vtb 涉黄被封
5. 肖战指使蒙古上单偷袭 b 站服务器#
6. 有人查户口网警介入
7. 网图传央视报道叔叔手术失败
8. 网传 NASA 拍到了外星人
9.b 站大楼倒塌

知乎用户 季俊峰 发表

wifi 和流量都打不开。

我还在看京酱肉丝的做法呢！

知乎用户 糖飘人间 发表

微博直接话题爆掉，知乎几分钟一万回答，很多无家可归的人去了后花园，后花园没见过这场面，服务器爆了。

想念蒙古上单。

知乎用户 凌晨三点半​​ 发表

注意 B 站大楼着火纯属谣言，B 站服务器里有博人传，不可燃

知乎用户 沸羊羊的感觉 发表

知乎现已开放收养 B 站流浪孩童。

（豆瓣和 B 站都无了，大楼停电服务器炸了）

今夜是安静的一夜，无事可干，睡觉。

看昨晚美股阿里巴巴和 B 站的变化…

知乎用户 BIG 梦想家​​ 发表

抛开现在众说纷纭的各种崩溃原因，来看看这个问题的数据：

这个数据仅仅是从晚上 11 点左右发布到现在，截图为止是 14422 个回答，还在增加，浏览量上千万。

足以说明，资本下一步应该着重看重的是 B 站了。

知乎用户 黑崎绘海奈 发表

凶手找到了！

蒙古上单狂暴鸿儒日本？

知乎用户 斯徒登特 发表

我还以为 DNS 问题，后来刷了下群

然后看了下知乎，居然上热搜了。

果然都是没有 x 生活。

另外，B 站没有火灾，好着呢（这该是有多闲，这也造谣..）

知乎用户 豪斯大叔​ 发表

a 站也炸了，感觉跟电缆有关？

知乎用户 呆呆狗 发表

有人说 a 站和豆瓣也炸了，有评论说没炸，我也能打开了。

我整理了半小时知乎热度动态，图有点多，感觉像是物理嗨客搞的。

11 点 15 分知乎三千回答。

11 点 20 分四千多回答

6000 整回答留念，11 点 23 分，

7000 回答，热度 6000 多万，11 点 27 分，

11 点 31，马上九千答案了。

现在 q 群疯传，一分钟看几十个版本的说法。

11 点 35 分，b 站复活留念

看到个顽梗的因果律武器。

11 点 37 分，10000 回答，

主服务器备份启动，但是数据没通，假复活状态。

11 点 45

11 点 49，12000 回答，b 站基本复活。

最后一次更新

7 月 13 日 11 点 55 分，热搜 ab 站合影留念。

知乎用户 楚烈​ 发表

草

我还重启了好几次电脑，结果是服务器崩了？？？

叔叔真有你的

知乎用户 诸葛南北 发表

本 社 爆 破

知乎用户 到处挖坑蒋玉成 发表

阿 B 难民能把 A 站、豆瓣、晋江给挤爆了，知乎半小时内上万条回答，发个东西都卡。

这用户体量活跃度，怪不得上次三大平台一块挤兑 B 站，毕竟谁拥有年轻人，谁就拥有未来。

还小破站？叔叔怕是做梦都能笑醒。

知乎用户 程子 JUN​ 发表

…… 这个问题的关注数和回答数暴涨，充分说明了 “单身经济” 的潜力有多么巨大吧。

万幸刚才会员购补款付好了_(:* ｣∠)_……

好，很有精神_(:* ｣∠)_

知乎用户 Tomo​ 发表

B 站炸了，A 站炸了，豆瓣炸了，神秘啊

知乎用户 TESLAGUN​ 发表

我问问 (๑•ㅂ•)

——第一次更新——

问了，我说：“叔叔，你们出什么问题了？” 们字说了一半，叔叔就把电话挂了，疑惑，叔叔听成什么了啊？

——第二次更新——

不行，气不过，我问问其他人

——第三次更新——

您拨打的电话未接通，请稍后再拨。

这个也没打通。

——第四次更新——

b 站崩溃的元凶找到了

——第五次更新——

了 转 反

啊这……

孙笑川你坏事做尽ψ(*｀ー ´)ψ

——第六次更新——

a 站热搜它 lei 了哈哈哈，我想死你啦！

——第七次更新——

上单正在极力奔跑中，怪不得没回我电话

不要停下来啊上单酱——

——第八次更新——

上单和叔叔的 cp 我吃定啦！

知乎用户 水离执云 发表

这是怎么了，希望解决。

知乎用户 闹东大师 发表

据有人说停电？但这种超大流量网站怎么可能把所有鸡蛋接在一个变电站里

而且还是主站、漫画站、APP 全面崩溃，这该不会是被墙了吧？

知乎用户 蒋甬杭​ 发表

这技术有点差啊，都快一个小时了，还不恢复。

知乎用户 qlc Matrix 发表

其实是我叫陈睿把服务器给关了的

不好意思啊各位

知乎用户 南飞​ 发表

知乎用户 没有 ID​ 发表

这可能证明，思路不是原来那个小破站了

但技术可能还是。

所以，至少从服务器上来看。

如今的 b 站还不是忒修斯之船。

对吧，叔叔

知乎用户 诗与方腿 发表

这说明啥？

说明 B 站正式成为互联网一线大厂，可喜可贺啊！

接着奏乐，接着舞！！！

知乎用户 运营老司机深元哥 发表

昨天？

我正在看这个，所以对我影响不大：

https://mzh.moegirl.org.cn/Bilibili/%E4%BA%89%E8%AE%AE%E5%92%8C%E5%BD%B1%E5%93%8D#/media/File%3AB%E7%AB%99%E5%9B%BD%E7%AD%96%E6%A0%91.jpg​mzh.moegirl.org.cn

知乎用户 摩擦起電​ 发表

随便水两句：有条件就赶紧去买 B 站股票吧。

从短期来看，其实并没有什么太大影响，最多给吃瓜群众一点讨论素材，过几天就散了。

毕竟事情发生在深夜，其实大多数用户已经入睡，早上起来就恢复了，不会造成太大损失。

但长期来看，B 站股价可能将会有一定攀升。

无论如何，当一个平台仅仅因为几个小时无法访问，就成为各大社交平台热议焦点时，这本身就是影响力的最好证明。

明明同一时间 ACFUN 跟豆瓣都出现了问题，恢复速度还比 B 站快，但有多少人在乎？

B 站出点事儿，热度立刻接近 90 度。

如此强大的用户黏性，如此高的曝光率，没有理由不被资本垂青。

叔叔这一波，赢麻了。

知乎用户 三叔侃侃​​ 发表

B 站官方回应：服务器机房发生故障，造成无法访问。

7 月 13 日凌晨，B 站的网页端和移动端都出现了无法打开的情况。此事引发了众多网友关注，话题 “B 站崩了” 更是冲上微博热搜第一名。不过，在官方还未给出回应的时候，网上对于此次 “B 站崩溃” 的原因有较多猜测，其中流传较广的是“火情说”，即有谣传指出，“B 站大楼出现火情”，也有的谣言说是“上海云海服务器管理中心着火”。经证实，上述两个地点昨夜均未发生火情。

知乎用户 中国商报​ 发表

我以为手机坏了呢，我以为网坏了呢，

上了知乎才知道，原来是服务器坏了。

啥时候好？？？？

我举报了个光撅屁股，不做瑜伽的视频，

题目叫什么水蜜桃，我看了半天，觉得不像水蜜桃，

就举报了标题党。

我以为 B 站把我给封锁了呢

知乎用户 旅行者一号 发表

为什么我没发现

这不是告诉大家 “我的夜生活精彩纷呈么”

知乎用户 鸢海​ 发表

说明现在的 B 站 已经有了影响力 正在逐渐扩大 影响人们的日常生活

我在当时正在看视频 突然就断线 一直在加载中 然后还以为是我的问题

原来高估了自己 然后在 wb 需求答案 才知道不止我这么一个人有问题

互联网一线大厂标准

崩了后立刻热搜

知乎用户 努力成为你的男人 发表

我以为送大会员是个梗，没想到真送了

啊，就一天啊

知乎用户 GUXUE 的黄瓜精 发表

别的不知道

贴吧删帖是真的快

问问也不行了？

知乎用户 述风 发表

见识过很多网站崩了上热搜，但是像 B 站这样知乎问题下一个小时一下一万多回答，并且是高频增加的，还是少见。

而且微博也上热搜了。

原来大家都是平时骂骂咧咧，真突然崩了谁不直呼一句 “快乐没了”。

这波叫做众网友与 B 站的相爱相杀。

知乎用户 高地保安 发表

几个小时，1.5 万回答。“知乎是 b 站后花园” 实锤了

知乎用户 Fate-stat 发表

叔叔我啊，被蒙古上单搞了啊

知乎用户 Aquiles 发表

7 月 14 日 02:08 更新两则较早数据

23:27 7458

23:28 7808

现在是北京时间 7 月 13 日 23:32

本问题共有 8997 条回答

23:34 9469 条

23:35 9672 条

23:36 9921 条

23:37 10155 条

23:38 10381 条

23:39 10604 条

23:40 10748 条

23:41 10927 条

23:42 11104 条

23:43 11249 条

23:44 11382 条

23:45 11587 条

（才发现最高赞也是在数回答）

23:50 12215

23:51 12340

23:52 12459

23:53 12574

23:54 12617

23:55 12967

23:56 12806

23:57 12920

23:58 13024

23:59 13101

7 月 14 日 00:00 13236

00:05 13502

00:10 13710

00:15 13862

00:20 14036

00:25 14146

00:30 14211

00:35 14287

00:40 14334

01:15 14540

02:00 14634

08:30 12730

10:30 12835

14:00 12873

未完待续。

知乎用户 齐东路莱芜二路 发表

好家伙，app 崩了没关系，开屏广告还在就行

知乎用户 夹卡夹卡酱酱夹卡酱 发表

真热闹啊

网友们一边整活讲段子，一边上单冲锋

叔叔看着热搜和股价，晚上睡觉都笑醒了

知乎用户 守护修仙 发表

最滑稽的还是猴

知乎用户 嗜金水狙​ 发表

好家伙，我正看着躲汉子呢，一下就这样了。

知乎用户 深山修炼的板蓝根 发表

难怪 B 站炸了，是小明哥来了。

世界的破坏者

知乎用户 瓦尔特 发表

刚听同事说 B 站崩了，11:54 分，一看已经 12606 个回答了

B 站一崩，立马就上知乎热榜第一

几年前知乎崩了的时候，好像没上 B 站的热榜吧

虽说人群有重合，但也不一定高度重合

另外还看使用黏度，习惯，时长等等

所以吧，市值也没啥毛病

也就一崩，现在不又好了

后面 A 站也崩了

没啥感觉

洗洗睡吧

操啥心呢

知乎用户 evanxu 发表

你们只看到 B 站崩了，却没看到 A 站也崩了，你们一点也不关心 A 站，你只关心你自己（狗头）

——————————

A、B 站、豆瓣都崩了，这波啊，这波叫做崩坏三！

知乎用户 萧不乐 发表

台湾省的好朋友说自己用的台版 B 站，突然崩了，还以为解放军打过来了。

现在看来应该不是这个原因。

知乎用户 猪猪自闭 发表

7.13

坐等修复奥

7.14 官方通牒

【B 站就服务器故障致歉 官方回应：现已恢复正常】

7 月 14 日消息，昨天深夜，视频网站哔哩哔哩突然出现网页及客户端无法正常访问的情况，很快 “B 站崩了” 相关话题登上微博热搜。

在今天凌晨 B 站方面发布消息称，“昨晚，B 站的部分服务器机房发生故障，造成无法访问。技术团队随即进行了问题排查和修复，现在服务已经陆续恢复正常。耽误大家看视频了，对不起!”

此外，当时网上还流传 B 站有火情的传闻，对于该传闻，上海消防回应，位于上海市政立路 485 号国正中心内的哔哩哔哩弹幕网 B 站（总部）未出现火情，未接到相关报警。具体情况以站方公布为准。

在昨晚，除了 “B 站崩了” 话题登上热搜之外，豆瓣、A 站疑似也出现了无法正常访问的现象。网友猜测是 B 站出现访问故障后，大量用户涌入豆瓣、A 站，导致后者也出现了访问异常。

老预言家了 https://www.zhihu.com/answer/1477381166

知乎用户 木子与舟 发表

第一次发现知乎和 B 站的用户重合度有这么高。

但为啥 B 站市值吊打了知乎呢…

知乎用户 极萨学院冷哲​​ 发表

b 站故障公告出来了：https://vdse.bdstatic.com//192d9a98d782d9c74c96f09db9378d93.mp4?authorization=bce-auth-v1/40f207e648424f47b2e3dfbb1014b1a5/2021-07-12T02:14:24Z/-1/host/530146520a1c89fb727fbbdb8a0e0c98ec69955459aed4b1c8e00839187536c9

知乎用户 ProfessorBrian 发表

笑死了 b 站一崩什么话都传出来了

有人说是蒙古上单，该有人说是 xz 携手 b 站 CEO 炸了机房

最离谱的一个是说有人开户口

太牛了

还有这个：

接下来给大家欣赏一些谣言

还有网友们的勇敢发言

甚至还有 b 站变 p 站

内行

接下来是好活

哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈好

知乎用户 Caramel 卷卷​ 发表

b 站崩了，知乎回答不到一小时上万回答；

A 站崩了，目前也就二百回答，

谁赢谁输一目了然。

A 站时代已经过去了啊。

知乎用户 给我一瓶冰可乐 发表

你们是同一个服务器？

嗶哩嗶哩被玩壞了！

這肯定不是嗶哩的問題！

絕對不是！

知乎用户 SnowyLake​ 发表

问题上热榜上得这么快……

看来 B 站知乎是一家。

知乎用户 午夜晨曦​ 发表

显示 502 还能看看 22 娘

知乎用户 樱欢抱月 发表

停电？黑客？党妹 + 回形针？开始整治网络？

知乎用户 wyx191​ 发表

@蒙古上单

知乎用户 西从南来​ 发表

好奇 b 站这么大互联网公司没有搞同城双活、异地灾备吗？

30 分钟，这要是在银行就是一次严重的生产事故，非常恐怖

知乎用户 闻道​ 发表

笑死。

B 站一炸，所有群的人都在笑阿 B。

知乎用户 白夜城​ 发表

先是微信 bug，然后 B 站就崩了，我在想这几家是不是都在赶着修改什么东西？

噢知道答案了叔叔正在和蒙古铁骑展开激烈的争夺战

知乎用户 漢軍將至務動 发表

#蒙古上单指使肖战联手桐生可可开泥头车创黑掉 bilibili，技术竟是孙笑川提供 ### 有人疑似在 B 站总部打爆破联合蒙古上单指使肖战联手桐生可可开泥头车创黑掉 bilibili，技术竟是孙笑川提供#

知乎用户 妮隔壁的对 A​ 发表

不给我发一个月大会员这事我忘不了（确信）

知乎用户 浑身上下脑袋疼​ 发表

我真搞不懂 视频网站崩了就崩了呗 干点其他的，吃瓜也行，骂娘的是什么心态？

知乎用户 沈文 发表

从未见过如此厚颜无耻之行为！

奔溃的不只是小破站，还有我未完成的靖哥哥！

知乎用户 锋谈怪论​ 发表

没有 b 站的夜，真真的好无聊。

知乎用户 D.Han​​ 发表

估计弹幕刷多了，b 站用户真牛 ，谁都敢怼：

知乎用户 兼职程序员 发表

B 站崩溃，一群无家可归的人纷纷打开了知乎…

知乎用户 年青 发表

看到回答一万四千多的时候，我还以为这是几年前的老问题。再仔细一看，居然是刚刚发布不久的问题。

B 乎, 你还敢说你跟知站不是一起的。

知乎用户 汲取灵魂的幽灵 发表

看起来 Tengine 返回的 404 页面里有 CDN 节点，各地 CDN 节点不一样，应该不是 CDN 的锅

那么问题来了，到底是哪个可爱的程序员将得到叔叔的宠爱呢？

===

补：活了，23:31。

再报：活了一点，又躺下了，23:39。

（主站）基本活了，散了散了，0:17。

知乎用户 空格 发表

终于明白了 B 站的恐怖流量。

B 站崩溃 15 分钟后，知乎热搜登顶。

这得有多少人快 12 点了还在刷 B 站啊。

知乎用户 lee 发表

b 站用户跟知乎重合度这么高么？

我还以为我家 wifi 出问题了，pad 重启了好几回～百度打开三次，抖音两次，手机上关了数据打开 b 站两次，抖音两次～

就是没想到知乎，刚想起来看看知乎就热榜第一～

知乎用户 王山石 发表

会员购都没了，我才知道是真的崩了。

我赶紧打开知乎想蹭一波热度：

晚了，知乎顶流把热度都炒到两千多楼了，

不晚，正合适。

不合适啊，水友都没热度了！

劳资从来就没想过捞水友的热度！

不捞沙雕网友的热度你蹭谁的去啊？

谁热度大，蹭谁的

蹭过热度么？

没有

蹭热度，得巧立名目，挑唆对立，跪舔大 V。水友的涨粉三七分成。

怎么才七成？

七成是人家的！能有三成还得靠大 V 点赞！

说到最后，我还是小小的蹭了一下张牧之的热度，下一步就是硬蹭热点当大 V，再然后就是开公众号（我公众号因为喷马某被警告了，凉了）再然后就是恰烂钱割韭菜，再然后就是吃着火锅唱着歌。

总结一句话：

知乎就是微信，微信就是微博

知乎用户 紫慕​​ 发表

小管家：报告老爷们，b 站今晚崩了，死了俩人，我们的人安然无恙！

观众老爷：上单显灵，叔妈暴死，听起来多么的顺耳！

知乎用户 疾风之科基​ 发表

现在已经有 b 站 713 崩盘的十六种谣言:

…………….

还有一件非常恐怖的事情:

没有 B 站，今天晚上干什么？

厚码，估计是出了点状况大家不要惊慌，过一会儿估摸着就好了。

破案了，官方说的为准吧，不要散发谣言了。

知乎用户 Bboy 丶 LilYu​ 发表

A 站也没了，二次元の末日属于是。

啊这。

知乎用户 不净言灵 发表

b 站知乎关联性太强了吧，秒热搜

知乎用户 Christ 发表

复原之后的 b 站

up 觉得得赞两次

知乎用户 妄与稚 发表

确实奔溃了，我上不去了，只能去小 h 网了。哎。

知乎用户 初来乍到诚惶诚恐 发表

好耶，b 站可能会_，但永远不会_

今天叔叔真的要生气了！

知乎用户 雾雨看视界 发表

确实，发现崩了，本来以为是我的问题结果是叔叔拉跨了

知乎用户 御树月 发表

知乎用户 Cat Like​ 发表

服务器崩了？我以为是我网络问题……

知乎用户 叶落 发表

这个问题的回答数和关注度不断刷新。

知乎用户 空灵​ 发表

我以为是我浏览了太多不健康的内容

知乎用户 Rain 发表

当年我一直以为它就是说说而已，没想到。。。

知乎用户 大狸​​ 发表

B 站高可用用架构实践 - 云 + 社区 - 腾讯云​cloud.tencent.com

这是今天的课后作业啊，大家认真温习下

最简单好用的 VPS,没有之一，注册立得 100 美金