崩了!劳累了一天的年轻人们,正准备躺平拿出手机,打开那熟悉的小破站 App,一键三连自己最喜爱的 up 主的最新视频。突然发现:
瞬间,“B 站崩了”的消息登上热搜,微博运维心头一紧。
部分网友表示:A 站、豆瓣等网站也出现访问故障,重连 Wi-Fi 也没有用。
今日凌晨,B 站发布公告称,昨晚,B 站的部分服务器机房发生故障,造成无法访问。技术团队随即进行了问题排查和修复,现在服务已经陆续恢复正常。
这份模棱两可的声明显然无法阻挡住吃瓜群众的热情。
短短几分钟,关于 B 站的各种揣测消息就变成了百家讲坛:
有火灾说、删库跑路说、刑事案件说、服务器供应商说、黑客攻击说、大楼坍塌说、外星人说……
还有人煞有介事地 Po 出了 B 站运营小妹的朋友圈,说 B 站停电了……
随后立刻有专业人士指出:B 站作为一个上市的互联网公司,服务器多地备份是最最起码的事,楼里停电这个解释,估计只能骗骗没有学过数据库的高中生。
至于 A 站和晋江文学网为什么会挂,很可能是因为 B 站挂了,大批用户无片可看,就涌入 A 站和豆瓣,造成网站的流量激增,哪怕 A 站和 B 站不共用云服务,也可能被压垮。
B 站 7000 多万日活网友的威力可见一斑。
下面我们看看几个相对靠谱的猜测:
①知乎作者 @黄珏珅 盲猜了一下,应该是 etcd 挂了。
通常来说,能造成几乎所有请求都 502 的,要不就是前端和后端之间的网络通路全挂了,要不就是后端的服务全都挂了。
那么现在的大型互联网公司的基础设施是怎样的呢,大多数使用了 Kubernetes,实现全国各地的数据中心的容器编排、网络虚拟化等。
而 Kubernetes 的设计上,网络插件和 pod 编排又是相对独立的。
如果只是网络插件出问题了,那么部分服务器上的网络插件的缓存还在,一定有部分用户还能正常使用。
现在所有的都挂了,那只能是 etcd 挂掉,导致反向代理无法通过 etcd 找到对应的 pod 的虚拟 ip,又无法通过网络插件与对应的 pod 通信。
②知乎作者 @k8seasy 则认为这个基本属于站点本身故障。从恢复时间看 30 分钟左右,并且几乎 100% 恢复,说明应该是某个核心组件崩溃了,导致核心服务不可用。
出现这种可能的不少,最有可能的原因是上线新版本,开始没问题,升级了部分集群,结果新版本有 Bug,到了某个时刻直接挂了,老版本的压力一大也没扛住。然后紧急定位,回滚解决。
也有网友提出,此次事件与云服务商离不开干系:
云服务提供商提供的 CDN 出现意外之后,大量请求绕过 CDN 直接打到网关,网关收到大量请求,自动启动了容灾策略。
容灾策略启动服务降级。服务降级了但没完全降,CDN 挂了,网关也跟着挂了,服务雪崩,一直崩到整个环境。
在互联网历史上,“小破站”这样的宕机事件只能算是“洒洒水”,不信?我们来看看其他互联网大咖们是如何玩转宕机的。
7 小时不能上微信:2013 年 7 月 22 日,微信服务宕机,造成了将近 7 个小时的网络中断。据微信官方公布信息,由于上海一支施工队挖断了通信光缆,导致腾讯华东数据处理中心的业务请求纷纷转向华南和华北,进而导致了业务的全面瘫痪。
用支付宝“剁手”失败:2015 年 5 月 27 日下午,部分用户反映其支付宝出现网络故障,账号无法登录或支付。支付宝官方表示,故障是由于杭州市萧山区某地光纤被挖断导致,该事件造成部分用户无法使用支付宝。随后支付宝工程师紧急将用户请求切换至其他机房,受影响的用户开始逐步恢复。到了晚上 7 点 20 分,支付宝方面宣布用户服务已经完全恢复正常。
而在国外,网络宕机的事件更是屡见不鲜。
亚马逊云服务罢工:2015 年 9 月,亚马逊的云服务器因收到来自新上线的 DynamoDB 功能带来的大量数据请求,导致其因过载而宕机。于是,包括 Reddit、Tinder、Netflix 和 IMDB 在内的众多流行应用和网址直接罢工了数小时。
除了 Netflix,绝大多数亚马逊云服务的客户在此次“突击检查”中,都被发现毫无准备。而 Netflix 此前已经使用过一种名为“混沌工程”的技术来模拟类似服务中断事件的发生,使得这起事故对其影响降到了最小。
纳斯达克停摆:2013 年 8 月 22 日,由于纳斯达克交易所的备用服务器中出现了一个严重的 Bug,直接导致纳斯达克停摆了 3 个多小时。当其恢复运作时,已经引起了市场恐慌,大量交易员涌向交易窗口,出售交易所运营商纳斯达克 OMX 集团的股票,导致 OMX 集团的股价当日一度大跌逾 5%。
事后有人评估,由于纳斯达克停摆造成的经济损失可能达数亿美元。
全美大宕机:2016 年 10 月 21 日早晨,许多美国用户突然发现包括 Twitter、CNN、Spotify 等大型网站均无法登陆。这场网络瘫痪从美国东部开始,一路蔓延至全美区域。事后发现查明,原因是服务器遭受了黑客的 DDoS 攻击。
关于 B 站宕机事故,开源基础软件公司 Zilliz 的质量保障团队负责人乔燕良做了较为专业客观的分析:
现在的网站故障造成的原因主要可分为软件服务引起的故障和硬件服务引起的故障。
软件服务故障一般可理解为代码逻辑缺陷,常见的是新增或更新某个功能而引入缺陷导致整个服务中断,硬件服务故障一般是由于某些服务设备的损坏造成的服务中断,比如光纤被挖断了。
如果要降低宕机风险,就需要提高服务的高可用性。首先从架构上,建议采用云原生架构,实现自动容错机制和故障隔离,从而能够在服务出现故障时快速迁移或回滚。
其次为防止硬件故障类风险,需要有完善的灾备方案,同城双活或异地灾备目前都已经有比较成熟的方案,国内企业在这块投入相对比较“节约”。
关于 B 站的高可用架构可查看文章:《月均活跃用户达1.3亿,B站高可用架构实践》
Bilibili,下次一定!