B站崩了：事情不大，影响不小

7月13日晚间，B 站因无法访问登上热搜榜。

昨天深夜，B 站出现访问故障，无法打开，页面提示加载失败。除了网站和移动端显示加载错误之外，B 站出品的轻视频、剪辑软件必剪等均无法打开，显示页面加载出错。

一个网站的短暂崩溃，居然引起这么大的声响?

公司2020年第三季度财报显示，去年8月，B 站的月活用户突破2亿。最新数据则显示，B 站月活用户为2.23亿，其中35岁及以下的月活用户比重超过86%。

B 站故障之后，消息迅速扩散，“B 站崩了”冲上了各种热搜榜。微博热搜第一，知乎的提问下截至目前为止，总共有12727个回复。连朋友圈里，都被 B 站技术总监分享过的“高可用架构实践”演讲刷屏。

故障持续了一个多小时，同时崩溃的还有老牌二次元网站 AcFun（A 站）以及豆瓣、晋江，但豆瓣、A 站等很快就得以恢复了。

一个网站的“崩溃”，让无数习惯了互联网生活的人睡不着觉，也有不少网友一起帮忙分析到底是互联网的哪个环节出了问题，甚至还因此惊动了消防局。

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

今年3月份，曾发生过数据中心失火造成360万网站下线的事故，因此有人猜测是云海数据服务中心发生了火情，消防也对此表示了极大关注。

什么原因会导致网站宕机?

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

但是对于具体宕机原因，B 站并未作说明。InfoQ 联系了 B 站相关技术人员询问具体情况，截止发稿前仍然没有得到答复。

对于网站宕机常见原因，开源基础软件公司 Zilliz 的质量保障团队负责人乔燕良认为，主要可分为软件服务引起的故障和硬件服务引起的故障。

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

互联网服务中链路的每个环节都有可能导致问题发生，据另一位数据库专家分析，因为这次 B 站主站都挂了，应该和数据库没有关系;宕机发生的时候，通过技术分析，可以看出 CDN 查不到相关机房的数据。由此推测，B 站这次应该属于机房级别的故障，需要增强多机房容灾能力。

这次故障，对 B 站的影响不小，综合损失应该也不小，但如果去提升业务的连续性，还需要很大成本。常见的可用性通常以百分比表示，这也意味着高可用性不是绝对的。换句话说，100% 的可用性是不可能达到的，可用性从99.99% 提升到99.999%，每提升一个9，需要十倍百倍的成本。可用性的效果和开销对应的比例并不是线性增长的，每提高一点可用性，所花费的成本都会远超之前。

虽然企业需要在这个非线性增加的成本和可用性之间进行权衡，但对于一些公司来讲，肯定还会去尝试获得更多的 “9”，减少应用的宕机时间，降低宕机成本。

如何用合适手段降低宕机风险、提高服务的高可用呢?乔燕良认为:“首先从架构上，建议采用云原生架构，实现自动容错机制和故障隔离，能够在服务出现故障时快速迁移或回滚。对于网站来说，实现数据服务高可用的挑战可能会比较突出，因为目前架构下多数服务都是无状态的、可以完成平滑迁移，而数据服务往往是有状态的，云原生服务（如目前的一些云原生数据库）通常具有很好的自动容错、弹性伸缩、安全隔离等功能。其次为防止硬件故障类风险，需要有完善的灾备方案。针对传统服务架构已经有比较成熟的同城双活和异地灾备方案，而基于云原生的高可用方案，比如 kubeadm 也已经比较成熟，只是国内企业在这块投入比较‘节约’。”

就像人工智能无法替代人类一样，目前的软件仍然是不可完全信任的。我们的世界瞬息万变，我们的软件（包括人工智能）只是对世界当前场景的理解和判断，随着时间的推进，某一时刻这些理解判断的逻辑会出现不适用甚至错误。这一时刻何时到来、环境又会变得怎样，将永远是最不可预测的因素。

来源：InfoQ公众号