昨晚，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 薪，没想到朋友圈京东的朋友没一个出来欢呼的。
真是应了那句话，你没钱的时候巴不得全世界知道，你有钱的时候巴不得全世界都不知道，哈哈！