Facebook 史上最严重宕机:互联网企业是时候重新审视架构了?

本文涉及的产品
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
简介: 刚被指责“利用放大仇恨言论的算法谋取利益”没多久,Facebook 再次陷入危机。

作者:核子可乐、褚杏娟
美国东部时间 10 月 4 日上午 11 点 39 分左右,美国社交媒体 Facebook、Instagram 和即时通讯软件 WhatsApp 出现大规模宕机,此次宕机长达近 7 个小时,刷新了 Facebook 自 2008 年以来的最长宕机时长。

美国互联网监控网站 DownDectors 的监控情况显示,Facebook 在欧洲、美洲、大洋洲几乎是完全下线,在亚洲的日本、韩国、印度等国也无法访问。据悉,WhatsApp 和 Facebook Messenger 两款“微信”类即时通信产品,分别在全球范围拥有 20 亿用户和 13 亿用户,社交平台 Instagram 用户数也达到了 10 亿用户。

除了让数十亿用户陷入困境之外, Facebook 服务中断还使其员工无法使用内部工具相互交流。Facebook 的电子邮件和工具都是企业内部管理的,Facebook 很多员工也无法正常工作。

100e8ad14861221ff45438cb24e90604.png


Facebook 首席技术官 Mike Schroepfer 在推特上道歉

一条指令引发的“血案”

Facebook 表示,这次故障的根本原因是例行维护工作发出了一条糟糕的指令,结果导致其 DNS 服务器不可使用,切断了 Facebook 整个骨干网络与数据中心之间的连接。

所谓骨干网,是 Facebook 为一切计算设施构建而成的全局连接网络,由长达数万英里的光纤线缆组成,跨越全球并将各地的数据中心连接了起来。Facebook 基础设施副总裁 Santosh Janardhan 在文章中解释道,数据中心主要有两种形式,一种是存放着数百万台数据存储与高强度计算负载运行设备的“巨大的建筑”,另一种则属于小型设备,通过骨干网络接入整体互联网并构建起 Facebook 社交平台的方方面面。

当用户打开应用并加载摘要或消息时,应用提出的数据请求会由当前设备传输至最近的设施,之后再直接通过骨干网络与更大的数据中心进行通信。应用所需要的信息将在这些数据中心内进行检索与处理,再把结果通过网络发送回用户手机上。

维护基础设施的日常工作非常繁重。工程师们还经常需要让部分骨干网络离线以实施维护——包括修复光纤线路、扩大容量或者更新路由器自身软件等等。而这也是此次宕机事件的原因所在。

Janardhan 表示,在一项日常维护工作中,工程师们发出一条用于评估全球骨干网容量可用性的指令,但意外切断了骨干网络中的所有连接,这实质上就是断开了 Facebook 全球数据中心之间的连接。不幸的是,Facebook 的系统在设计上能够审查此类指令以防止出现错误,但其功能只是发出错误提示,并不能真正阻止指令执行。

这次意外,导致 Facebook 的数据中心与互联网之间的服务器连接完全断开,由此带来了一系列连锁效应让情况进一步恶化。

在此次宕机事件中,由于整个骨干网都已陷入瘫痪,因此各 DNS 服务器位置均上报连接状态问题并撤回边界网关协议(BGP)通告。最终结果是,Facebook 的 DNS 服务器虽然仍在运行但却无法正常访问,导致其他互联网用户也无法正常接入其服务器。

响应 DNS 查询是小型设施执行的一项重要任务。DNS 可以称之为互联网的地址簿,能够将用户在浏览器中输入的简单网络名称转换为特定的服务器 IP 地址。这些转换查询由 Facebook 的权威名称服务器给出应答,而这些服务器本身就占用着最众所周知的 IP 地址。接下来,这些服务器再通过边界网关协议(BGP)向互联网的其余部分发布通告。为了确保运行可靠性,如果 DNS 服务器自身无法与数据中心通信,则所有 BGP 通告都将被禁用,表示当前网络连接状态不正确。

简单来说,Facebook 拿走了告诉世界计算机如何找到其各种在线资产的地图。结果,当在 Web 浏览器中键入 Facebook.com 时,浏览器不知道在哪里可以找到 Facebook.com,因此返回到了错误页面。

为什么无法及时修复

为什么这次故障持续了近 7 个小时之久呢?

Janardhan 表示,工程师们在修复这一故障时,面临着两个巨大的障碍:首先,Facebook 的工程师们无法通过正常方式访问自己的 Facebook 数据中心,因为这时候骨干网已经出现了故障;其次,DNS 没有响应致使 Facebook 无法使用调查及解决宕机问题的常规内部工具。

骨干网与带外网络访问均出现故障,这意味着工程师只能亲自前往现场进行调试并尝试重启系统。但这需要时间,因为各处设施都遵循高水平的物理与系统安全保护政策。

错误的更新阻止了 Facebook 员工(其中大多数是远程工作)恢复和更改系统。与此同时,那些可以物理访问 Facebook 大楼的人无法访问 Facebook 的内部工具。

“任何人员都很难进入,而且一旦进入并获得物理访问能力,这些硬件与路由器的设计也很难得到修改。因此,需要更多的时间将工程师们引导进机房,并为他们提供在服务器上工作所需要的安全访问协议。只有这样,我们才能确认问题并让骨干网重新上线。”Janardhan 写道。

834b69bc4af3aefccd42b96f25c1da41.png

有专家估计,Facebook、Instagram、WhatsApp 全球服务中断一小时将给全球经济造成 1.6 亿美元的损失。同时,Facebook 当日股价盘中暴跌 6%,扎克伯格个人财富一日蒸发逾 60 亿美元。

屋漏偏逢连夜雨。在 Facebook 全球网络服务中断期间,据称在黑客论坛上有超过 15 亿 Facebook 用户的数据被出售。但 Facebook 方面否认了这次用户数据泄露与服务中断有关。

“我们要明确表示,这次宕机背后没有恶意活动,其根本原因是我们端的错误配置更改。我们也没有证据表明用户数据因此次停机而受到损害。”Janardhan说道。

架构缺陷

美国东部时间下午 6 点 33 分,Facebook 发推文称其应用程序和服务已开始恢复运行。随着各数据中心区域中的骨干网连接的恢复,一切都随之复原。但问题还没有真正结束。

一次性对所有服务全部重启会带来新的隐患,因为流量激增很可能导致新一轮崩溃。个别数据中心还上报称宕机导致设施耗电量下降了几十兆瓦,而突然上线带来的用电量暴增很可能给电气系统、缓存等各类装置带来意外冲击。

Janardhan 表示,虽然 Facebook 一直在做“风暴”演习,对服务、数据中心乃至整个区域进行脱机,并针对一切相关基础设施与软件开展压力测试以模拟主要系统故障,但并未演练过全球骨干网络脱机的状况,后续会找可行性方法作出应对。

据监测互联网流量和故障的思科 ThousandEyes 的产品营销主管 Angelique Medina 表示,这起事件暴露了 Facebook 架构的一个缺点:如果本身出现 DNS 故障,又没有后备 DNS,就可能会出现长时间的故障,“所以我认为,这件事带来的一大经验教训就是要有冗余 DNS。”

Medina 表示,一套更稳健的架构将拥有双 DNS 服务,那样一个 DNS 服务可以支援另一个。据 Medina 声称,比如说,亚马逊(其 AWS 提供 DNS 服务)为其 DNS 使用两项外部服务:Dyn 和 UltraDNS。

同时,这次宕机事件也让身处反垄断调查的 Facebook 雪上加霜。

美国国会众议院成员 Alexandria Ocasio-Cortez 表示,Facebook 爆发大规模宕机事故,这凸显出该公司在全球通信和其他服务领域的垄断地位。其在推特上表示,Facebook 周一发生的大规模宕机事故是对该公司垄断全球通讯和其他服务的一次提醒,再次表明 Facebook 应该被分拆。

目录
相关文章
|
23天前
|
运维 供应链 安全
SD-WAN分布式组网:构建高效、灵活的企业网络架构
本文介绍了SD-WAN(软件定义广域网)在企业分布式组网中的应用,强调其智能化流量管理、简化的网络部署、弹性扩展能力和增强的安全性等核心优势,以及在跨国企业、多云环境、零售连锁和制造业中的典型应用场景。通过合理设计网络架构、选择合适的网络连接类型、优化应用流量优先级和定期评估网络性能等最佳实践,SD-WAN助力企业实现高效、稳定的业务连接,加速数字化转型。
SD-WAN分布式组网:构建高效、灵活的企业网络架构
|
9天前
|
Kubernetes Cloud Native 云计算
云原生技术深度解析:重塑企业IT架构的未来####
本文深入探讨了云原生技术的核心理念、关键技术组件及其对企业IT架构转型的深远影响。通过剖析Kubernetes、微服务、容器化等核心技术,本文揭示了云原生如何提升应用的灵活性、可扩展性和可维护性,助力企业在数字化转型中保持领先地位。 ####
|
9天前
|
运维 Cloud Native Devops
云原生架构:重塑企业IT的未来####
随着数字化转型浪潮的汹涌,云原生架构凭借其高度灵活、可扩展和高效的特性,正逐步成为企业IT系统的核心。本文将深入探讨云原生架构的核心要素、技术优势以及如何引领企业实现业务创新与敏捷交付。 ####
|
1月前
|
存储 人工智能 算法
精通RAG架构:从0到1,基于LLM+RAG构建生产级企业知识库
为了帮助更多人掌握大模型技术,尼恩和他的团队编写了《LLM大模型学习圣经》系列文档,包括《从0到1吃透Transformer技术底座》、《从0到1精通RAG架构,基于LLM+RAG构建生产级企业知识库》和《从0到1吃透大模型的顶级架构》。这些文档不仅系统地讲解了大模型的核心技术,还提供了实战案例和配套视频,帮助读者快速上手。
精通RAG架构:从0到1,基于LLM+RAG构建生产级企业知识库
|
23天前
|
Cloud Native Devops 持续交付
云原生架构:重塑企业IT的无形之手####
本文旨在探讨云原生架构如何成为推动企业数字化转型的核心动力,它不仅是一种技术升级,更是业务与开发模式的深刻变革。通过剖析云原生的核心要素——微服务、容器化、持续集成/持续部署(CI/CD)、以及DevOps文化,本文揭示了这一架构如何提升系统的弹性、可扩展性和敏捷性,为企业在竞争激烈的市场环境中赋予快速响应和创新的能力。不同于传统综述,本文将以一个虚构案例贯穿始终,直观展示云原生架构从理论到实践的转化过程,为读者提供一幅生动的技术蓝图。 --- ###
|
1月前
|
运维 Cloud Native 持续交付
探索云原生架构:企业数字化转型的新引擎
在当今数字化浪潮中,云原生架构以其独特的优势成为企业转型的关键。它通过容器化、微服务、DevOps和持续交付等技术,使企业能够快速响应市场变化,实现应用的高效开发、部署和运维。本文将深入探讨云原生的概念、核心技术及其在现代IT环境中的重要性。
|
1月前
|
运维 Kubernetes Cloud Native
探索云原生架构:企业数字化转型的新引擎
【10月更文挑战第9天】 在当今数字化浪潮中,云原生架构以其独特的优势成为企业实现高效运营和快速创新的关键。本文将深入探讨云原生的核心概念、关键技术以及实际应用案例,揭示其如何助力企业加速数字化转型步伐。通过对云原生技术的剖析,我们将看到这一新兴架构是如何重新定义软件开发、部署和运维模式的,进而推动企业在激烈的市场竞争中脱颖而出。
|
5天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
4天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
4天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
15 1
服务架构的演进:从单体到微服务的探索之旅