昨晚 B 站崩了，如何防止类似事故的出现？-技术圈

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

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

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

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

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

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

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

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

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

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

其实跟我们大家学的技术都差不多，不过他们的对应微服务的语言组成可能go、php、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娘发呆，嘻嘻