昨晚，B 站崩了！

昨晚 10 点多，我朋友圈忽然热闹了起来，不少人都在转发 B 站没法访问的消息，各类截图满天飞。

 

不仅是 B 站，包括 A 站和豆瓣在内的产品都出现了没法访问的状况。不少人说，睡前的快乐没有了。

 

很快，B 站崩了的消息登上了微博热搜。

 

也难怪，一个月活 2 亿多的产品忽然宕机半小时，正好又遇上晚上活跃高峰期，引发的关注度天然也特别高。

 

凌晨 2 点多，B 站官方在微博发布了道歉声明。

 

在这个声明中并无说起具体的事故缘由，只说是由于部分服务器机房发生故障致使没法访问。

 

相对来讲，此次宕机时间之长、影响范围之大，估计怎么说也是个 P0 级别的线上事故了。

 

这个夜晚，B 站的产品经理、程序员、测试、运维、公关们估计都没睡好觉。

 

吃瓜归吃瓜，不过我相信更多人仍是会好奇这种大范围的技术故障究竟是怎么产生的？

 

不过，我以为首先能够排除掉的就是什么机房被烧了、程序员删库跑路之类的说法。

 

像这种大型产品都不会把自家的服务器放在一个机房，数据也不会仅此一份，多地多机房多副本是常规操做，但凡一个机房出问题，会立马切换到其余可用的服务上。

 

即使是某一个云服务提供商出了问题，他们也通常会切换到其余可用的云服务上去。

 

不少公司都会同时使用多个云服务商提供的服务，好比阿里云、腾讯云、金山云等等，怕的就是其中一家出毛病。

 

截止到目前，官方依然没有给出具体的事故缘由。因此，只能基于看到的现象来作一些推测。

 

首先，B 站、A站、豆瓣同时出现没法访问的状况，说明问题出在他们所使用的公共技术服务上，好比云服务。而其中出问题几率最大的，或许就是 CDN。

 

关于 CDN，我以前写过一篇文章介绍过，简单说就是用来应对高并发和大流量访问的内容分发系统。

 

其次，B 站先是报出了 404 异常，而后又报出了 502 异常，这些状态码也反映了系统出现的一些可能性问题。

 

之前我作技术时，在开发阶段和改 bug 的时候就常常遇到 404 或 502，但这类错误码是一个合集，并不能所以定位到准确的具体问题。

 

404 表明的是找不到可访问的系统资源，好比网页不存在、文件错误、接口 URL 异常等，但前提是服务可用。

 

而 502 的出现意味着网关错误，多是服务器异常致使的系统故障。

 

简单说，碰上 404 时说明系统仍是可用的，只是其中一个功能失效了。碰上 502 则表示系统不可用了，崩掉了。

 

回到前面说的，此次线上事故若是是由于第三方 CDN 服务商的问题，那使用他们服务的这些产品就会受到集体影响。

 

CDN 失效，大量的网络请求直接绕过它做用在应用服务器上，服务器请求量激增超过了自身的承载极限，因而开始启动容灾降级策略。

 

所谓的「降级」，就是服务器根据策略设置进行的自我保护，本来能提供 100 分的服务，如今由于特殊状况降为只提供 80 分的服务，以确保自身可以安全运行。

 

按理说，B 站这样的大型系统也会有这样的机制，但不知道为啥没起做用。

 

可能 CDN 失效后大量的请求过来后直接把服务器干崩了，还没等容灾启动，一个接一个，而后全崩了。

 

当雪崩来临时，没有一台服务器是无辜的。

 

最后，在 A 站和豆瓣相继恢复系统使用后，B 站仍然没法访问，说明他们的内部系统对异常处理和容灾机制的差别。

 

我看朋友圈有作技术的朋友转了一篇 B 站的技术负责人曾经作过的架构分享，其中提到 B 站的容灾系统是自研的，并无直接使用第三方服务，或许这也是他们恢复较慢的可能缘由。

 

一样从现象推测缘由。

 

11 点多的时候我打开 B 站的网页，首页陆续能刷出一些内容来了，但这时候基本处于「只读」状态，只能看，包括一些操做和登陆功能都无法用。

 

这多是运维在恢复数据时的刻意控制，目的是防止恢复过程当中由于数据写入致使的数据紊乱。

 

过了一下子再刷新时，登陆状态就出来了，且我仍是处于登陆状态。

 

虽然我平时不怎么刷 B 站，但以前留下的搜索记录和浏览行为也让 B 站对我进行了用户画像，因此推荐的内容基本都是和我感兴趣的相关的。

 

但此次打开的首页内容基本都是我不感兴趣的，并且类型比较多。我也问了下朋友，他们说看到的内容差很少。

 

这说明了一个可能的缘由，B 站的容灾启动了，但重启恢复有一个过程，先确保总体可用是第一步。

 

这时候，可能推荐系统的服务还没恢复，因此你们看到的东西差很少，是公共池里的内容，没有个性化。

 

又过了一段时间，当再次打开刷新时，推荐的内容发生了变化，和以前正常推荐逻辑下的内容基本差很少了。

 

这说明，系统在恢复初期依然处于容灾降级状态，以后才慢慢恢复其余服务。

 

足以可见，技术系统是一个多么庞大且复杂的工程。咱们看到的每每只是冰山一角，更多的复杂性都在看不到的背后。

 

以上，只是对于现象的一个推测，不构成结论。再说，B 站官方大几率也不会公布真实的故障缘由，即使说了，普通用户也不理解。索性用机房服务器异常来给出解释。

 

包括在产品上的体现，也只是提示服务器不可用或数据异常，并无把一些复杂的技术代码和错误信息展现出来，这也是一种处理机制。

 

一般，若是是在代码层面出现的问题，系统报出的异常都是一堆别人看不懂的乱码。

 

程序员会根据产品经理的定义把这些乱码翻译成用户可理解的文案，好比密码错误、服务器异常。

 

可是，若是想找到异常的真实缘由，光看产品表现层的文案提示是没用的，仍是获得技术层面去看。

 

因此，出现这样的问题，只要不是产品逻辑的错误，最忙最紧张的应该就是程序员和运维了。固然，还有测试。

 

没出事不可怕，线上事故最要命。

 

真正体验过一次处理线上事故的过程，才知道那种紧张而刺激的切身感觉。

 

B 站的兄弟们，辛苦了！

 

················· 唐韧出品 ·················

安可时刻

昨天京东普调，从 14 薪逐步调整到 16 薪，没想到朋友圈京东的朋友没一个出来欢呼的。

 

真是应了那句话，你没钱的时候恨不得全世界知道，你有钱的时候恨不得全世界都不知道，哈哈！