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

做者 | Tina

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 也已经比较成熟，只是国内企业在这块投入比较‘节约’。”

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

 

有道无术，术可成；有术无道，止于术