Facebook 旗下应用出现网络故障，可能是什么原因导致的，将会带来哪些影响？
可能导致 Facebook 旗下应用出现网络故障的原因，可以从几个主要维度进行剖析：
1. 基础设施层面的问题：
数据中心故障（Data Center Outages）： Meta 拥有遍布全球的庞大服务器集群，负责存储和处理海量用户数据。任何一个关键数据中心的硬件故障（如服务器宕机、网络设备损坏、供电中断等），如果存在单点故障而没有完善的冗余备份和快速切换机制，都可能导致区域性的甚至全球性的服务中断。想象一下，如果一个承载了欧洲大部分用户流量的数据中心突然“熄火”，那么整个欧洲区域的用户体验将立刻受到影响。
网络骨干网问题（Network Backbone Issues）： 连接全球数据中心和用户设备的，是错综复杂且容量巨大的网络基础设施。无论是内部网络还是依赖的外部互联网服务提供商（ISP）的网络，任何一个环节的拥堵、路由错误、或者物理线路的损坏（例如海底光缆中断），都可能成为“卡脖子”的环节，阻碍数据正常传输。这就好比城市交通的“大动脉”被堵死，所有车辆都无法通行。
软件更新或部署失误（Software Update/Deployment Errors）： 为了不断优化功能和修复bug，Meta 会周期性地进行软件更新和系统部署。如果在这个过程中出现了设计缺陷、编码错误，或者部署流程出现了问题（例如一次性向所有服务器推送了存在问题的代码），那么可能导致整个系统崩溃。这种情况有点像给一栋大楼升级操作系统，结果新系统本身就存在致命bug，导致整栋楼的“电脑”都罢工了。
配置错误（Configuration Errors）： 在大规模分布式系统中，管理成千上万的服务器和网络设备的配置是一项极其精细的工作。一个微小的配置错误，比如一个错误的IP地址设置、一个不正确的访问权限，都可能引发连锁反应，导致服务无法正常访问。这就好像你在家给路由器设置了密码，结果自己输错了密码，怎么也连不上网了。
2. 安全层面的挑战：
大规模网络攻击（LargeScale Cyberattacks）： 分布式拒绝服务攻击（DDoS）是一种常见的攻击手段，攻击者通过大量无效请求淹没服务器，使其无法响应正常用户的访问。如果 Meta 的防御系统未能及时有效应对，大规模的 DDoS 攻击完全可能导致其应用宕机。这种情况下，Facebook 就像一个生意火爆的商店，突然被成千上万的“假顾客”围堵，真正的顾客根本进不来。
内部系统安全漏洞（Internal System Vulnerabilities）： 如果 Meta 的内部系统存在未被发现的安全漏洞，并且被攻击者利用，可能会导致敏感信息泄露、系统被恶意控制，进而引发服务中断。虽然 Meta 会投入巨资保障安全，但科技世界的安全博弈从来没有止境。
3. 突发性事件：
意外的硬件故障（Unforeseen Hardware Failures）： 即使有冗余和备份，但一些极端情况下的硬件故障，比如电源突发性过载、冷却系统失效导致服务器过热等等，也可能在短时间内造成大范围影响。
自然灾害或第三方服务中断（Natural Disasters or ThirdParty Service Disruptions）： 虽然 Meta 有全球布局的数据中心，但如果一个关键区域遭遇自然灾害（如地震、洪水）影响了数据中心的运行，或者依赖的第三方云服务提供商（尽管 Meta 大部分是自建，但某些辅助服务可能依赖第三方）出现问题，也可能间接导致其应用故障。
网络故障将带来的影响是多方面且深远的：
1. 用户层面：
社交联系中断： 对于许多用户而言，Facebook、Instagram、WhatsApp 是他们与家人、朋友保持联系的主要渠道。服务中断意味着无法发送消息、分享动态、查看朋友的更新，导致“失联感”和社交隔离。尤其是在家庭成员分散各地，或者有紧急事情需要沟通时，这种影响会更加显著。
信息获取受阻： Facebook 和 Instagram 也是许多人获取新闻、了解时事的重要平台。故障期间，用户无法获取最新的信息和关注事件的进展。
个人生活节奏被打乱： 许多人习惯于在通勤、休息时间刷刷社交媒体，故障会打断他们的日常习惯，带来无聊感或焦虑感。
2. 商业层面：
广告业务停滞： Facebook 及其旗下应用的绝大部分收入来自广告。当平台瘫痪时，广告投放活动将无法进行，企业广告主的广告预算将白白浪费，直接导致 Meta 广告收入的巨额损失。这对于那些高度依赖 Facebook 进行营销和销售的中小企业来说，更是致命打击。
电商和营销活动受阻： 许多企业通过 Facebook 和 Instagram 进行产品推广、客户互动和销售转化。故障会导致他们的营销活动暂停，客户咨询无法响应，订单处理受阻，直接影响销售额和品牌声誉。例如，一些品牌正在进行的促销活动，可能因为平台宕机而错失良机。
品牌声誉受损： 频繁或长时间的服务故障，会严重损害用户对 Meta 平台的信任度。用户可能会开始寻找替代性的社交工具，导致用户流失和品牌忠诚度下降。
对其他关联业务的影响： Meta 也在大力发展虚拟现实（VR）和元宇宙（Metaverse）等新业务，这些业务的很多入口和互动也依赖于其现有的社交网络和基础设施。整体平台的不稳定，也会对其新业务的推广和用户体验造成负面影响。
依赖 Meta 平台的内容创作者和网红经济受损： 大量内容创作者和网红通过 Facebook 和 Instagram 变现。平台故障期间，他们无法发布内容，无法与粉丝互动，广告收入和品牌合作收入都会受到直接影响。
3. 经济和社会层面：
影响信息传播和舆论： 在一些重要时刻，社交媒体是信息传播的关键渠道。大规模故障可能导致重要信息传播不畅，甚至影响公众对事件的认知和判断。
可能引发“多米诺骨牌效应”： 如果 Meta 平台出现严重安全事件导致数据泄露等后果，可能会引发连锁反应，影响整个互联网行业的信心和安全标准。
总而言之，Facebook 旗下应用的每一次大规模网络故障，都像是在我们高度数字化的生活中，突然按下了“暂停键”。它不仅仅是技术层面的事件，更是对我们生活方式、商业模式乃至社会运行逻辑的一次深刻考验。每一次故障的背后，都牵动着数亿人的神经，也促使着像 Meta 这样的科技巨头不断反思和加固其庞大的技术堡垒。
网友意见
10月4日15:39 UTC - 21:20 UTC，Facebook发生重大安全事故, 全球宕机六个小时。脸书股票暴跌，高管通过twitter道歉。
事故的原因是15:39 UTC，Facebook的路由器 通过BGP协议撤销了 185.89.218.0/23 和 129.134.30.0/23 两段明细路由。而facebook 的四台授权域名服务器工作在这两段明细路由，BGP路由问题，导致Facebook的域名服务器从互联网上消失，期间Facebook, WhatsApp, Instagram 和 Messenger（Facebook 的即时通讯工具，也用于facebook内部通讯，域名 m.me)的相关域名无法解析，所有服务无法访问。
一些教训：
1、DNS这个关键服务设计不合理，虽然设计了四台授权域名服务器，但是都位于两段/23地址，都是使用AS32934自治号发布的，网络接入的多样性不够，导致四台域名服务器同时出问题；
2、Facebook 这样的公司，网络运维都是自动化运维（DevOPs)，加上变更管理没有严格审查，两条小小的路由发布，导致了整个事故发生；
3、恢复过程为什么耗时将近六个小时，原因是门禁系统、即时通讯工具、监控、运维等DEVOP工具都依赖域名服务，出问题的时候，无法使用正常流程恢复。据说脸书的员工由于门禁问题无法进入办公地点和机房，后来是用切割机暴力破解才解决问题的；
4、新冠疫情，员工都是在家在线办公，没法及时响应；
5、现场工作人员只能处理简单的问题。
就像评论里面江浔提到的，对于关键路径的依赖，还是要梳理清楚，在紧急情况发生的时候，如何有逃生通道？比如
- 对重要网络设备，采用带外管理（OOB）
- 监控、DEVOP等工具假设在第三方的平台上
- 门禁、监控、DEVOP等工具使用主服务不一样的域名
- DNS服务器的网络接入的多样性
这是一条理论上非常简单的命令，越简单的命令，越容易翻车，就像某条命令多打一个空格，你盘就没了一样。
FB作为全球互联网核心服务的重要组成部分，拥有大量自用数据中心，以及自己买断的不少IP前缀，包括在自己几大AS自治系统下面。
facebook自己的骨干网，使用BGP协议向与自治系统对接的运营商骨干网广播自己拥有的IP前缀的路由信息，以此将路由信息广播到全球，声明这些IP前缀下属的IP，可以通过这些网络最终路由到自己的骨干网最终进入数据中心。
我看了下bgp信息，fb直接能查到的有三个AS，最大的AS32934有417个前缀，共计14万余IP地址。
这么大的系统，人工管理是很费劲的，一定有各种半自动甚至全自动的运维系统，对BGP广播的路由信息进行维护、优化，也有专门的批量化工具进行更新。
翻车的时候，由于敲错一个命令，导致原本用来评估网络状态的命令，变成了清空路由表的命令。
这个操作等效于FB自有的所有前缀直接人间蒸发，全球所有的运营商骨干网都不知道目的地为这些前缀的IP该往哪里转发，于是只能走默认路由转圈圈，直到TTL归零丢包。
按理来说FB这么大的系统，设计应该很完善，命令都有审计工具，这种命令不会被放行。
但不巧，正好审计工具有bug，放行了这条命令。
FB的所有域名服务器，设计上会在服务器自己连不上数据中心对应IP的情况下，停止DNS解析。原本的设计意图是如果这个IP不可达，那么网络存在问题，解析出来也没用，这样可以把用户请求解析到仍然好用的其他IP上。
可能很多人对域名服务器的工作原理还没有清晰的认识，以为都在美国，或者几大基础设施服务商手上。这是冷战宣传导致的非常幼稚的认识。
实际上，根域名服务器以及其镜像，只负责顶级域名以及一些重要的NS记录，像FB的域名服务器，就使用这些NS记录，把互联网上运营商以及散户的DNS解析请求指向自己，之后的解析，靠运营商DNS系统的缓存就可以负担了。
但BGP这么一把骚操作，直接把FB的整套自有域名服务干掉了，于是即使FB其他服务器都在线，没有DNS指路，业务也无法完成，并且等到运营商缓存超时后，FB所有业务也人间蒸发。
而且由于FB是互联网流量大头，失败的业务请求在其他运营商骨干网大量空转，也顺带压垮了不少其他基础设施，某些地区不仅断FB，甚至断网了。
以及不少第三方服务依赖FB的SSO运作，FB一挂，大家一起登录失败。
曾经有消息指出，之所以花了整整六小时才复原，除了整个基础架构都翻车，导致沟通、协调、分析以及远程排故困难外，在数据中心驻场的工程师也无法接触到服务器，因为数据中心有各种安全设计，用来防止各种虚拟或者物理的数据盗窃、服务器硬件盗窃等，结果导致工程师自己也上不去了。
早先的报道说是找了锯子把门锯开才进去，后来辟谣说没上锯子，不过的确存在“物理”障碍需要克服。
以及修复之后，第一次上线还又崩了，因为一台台恢复，先上线的那台顶不住网上已经存在的巨大空转流量，又崩了，后来先拔网线，把集群全都恢复起来再插上才没崩。
设计的时候都反复强调不要让单点故障搞崩整套系统，道理都懂，但真做起来总是这个那个没想到。
比如没想到BGP删前缀，有可能把这些前缀从所有边界路由全都删掉。
比如没想到会有一整个前缀在所有自营数据中心边界都不可达的情况，于是想当然的就把域名服务器放在了这个前缀里。
比如数据中心有了OOB管理和门禁，但仍然假定其他区域的基础设施可以使用，OOB管理与门禁用了可能会坏的基础设施来认证，然后就产生了打开门才能修好基础设施，但要修好基础设施才能打开门的死锁情况。
这种错误复盘的时候都觉得很蠢，但一开始架构规划的时候就死活想不到。
缘起
看了facebook此次的事故，是有个多个因素一起促成的一个大事故。而其中的任何单一事故，都不算特别严重，在各个互联网公司里也时常发生。但就是这些小事故集合在一起时，才完成了这个震惊业界的大炮仗。
先回溯一下问题过程。运维工程师对WAN配置做变更，一处配置错误导致了一个网段在互联网上消失了。单这一步，就足以影响facebook的多种服务了，但不是全部服务。但facebook的全部4个DNS服务器IP也在这个网段里。导致了facebook旗下所有服务的域名解析失败。后续就是运维层面的内部困难了，比如机房门禁系统也需要依赖域名访问内部服务做认证。
产生如此事故最初的原因是运维工程师的WAN配置失误。现实的WAN配置是很复杂的，对大型互联网公司来说，几乎无法依靠人工来完成设置。WAN配置是对互联网上的路由器进行规则配置。当数据包到达时，根据规则判定要将其转发到其他路由器。对计算机网络来说，根据目标地址设置转发目的地需要个映射，几种典型的映射：
- 域名->IP映射：通过DNS系统完成
- IP->Mac映射：通过ARP协议查询，交换机广播寻找实现
- Mac->网线端口映射：根据历史数据包交换做记录
BGP
而在互联网这个级别，各个路由器之间就是通过BGP协议实现的。其通过广播的方式，向相邻的其他路由器声称自己可以负责转发某些子网的数据包。其他路由器收到该信息后，就会自动记录下来，并在之后自动将对应子网的数据包转发到这台路由器。BGP设计的较早，早期设计缺乏安全性考虑，也导致过一些事故。比如2008年巴基斯坦就通过BGP劫持了全世界的Youtube流量，导致Youtube下线两小时。
由此可见，BGP是负责各个路由器之间声明子网映射的协议。其他路由器都是默认信任其广播信息的。此次facebook事故也是源于错误的BGP配置，将自己持有的子网AS32943声明丢失了。于是所有需要发送到该子网的数据包就全部没了目的地，在网络中消失了。这其中就包含很多对facebook旗下各种服务的DNS查询请求。
路由器配置的挑战
路由器配置对运维工程师来说是很有挑战的。一条路由器规则由3个部分组成：入口条件，路由选择，出口条件。路由表的配置由很多条这样的规则组成，互相之间还有顺序依赖，比如入口条件为子集的放在后面就不会命中，而是在前面就转发走了。同时各种路由器制造商，在规则语句的执行上也有少许区别，导致相同的配置在不同厂商，不同型号的路由器上可能得到完全不同的结果。甚至在多个路由器的环境里，配置到达路由器的先后顺序也可能导致事故。这些问题使得配置大型互联网公司的路由表变得难上加难。
正是因为手工配置路由器困难重重，于是也有一些开源软件来辅助，用来自动检查路由器配置，以及生成的网络拓扑图。比如batfish就是其中较为著名的一个。但batfish功能较少，比如没有区分路由器制造商的检查功能，以及路由失败时错误配置的显示。但在搜索中，发现了阿里巴巴的运维部为了解决互联网路由器配置，开发了一套更加强大的工具，HOYAN。通过HOYAN，可以通过读取路由器配置，自动检查是否有哪些规则被屏蔽，分析网络的拓扑结构，寻找网络不可达的情况，以及失败配置时的拓扑。使得路由器配置编写好以后，实际生效之前能够得到完善的检查，避免facebook这样的运维事故。
HOYAN，一种新的解法
论文的标题和摘要如下：
论文全文下载：
路由配置的检查面临诸多困难。为此HOYAN对阿里巴巴所使用的路由器进行了路由器行为建模，以确保路由配置可以针对不同品牌型号路由器产生针对性的仿真结果，并生成网络拓扑。进而在基于网络拓扑来分析各个子网之间的连通性。尤其是针对大型网络，连通性靠人来分析已经非常不显示了。而依靠对网络拓扑图的有向图遍历，则可以分析出来网络不可达的情况。即此次facebook错误配置中的问题。
中国的互联网企业在发展过程中，往往面临着巨大的流量压力，和复杂很多的网络状况。比如阿里巴巴在全世界有数十个数据中心，比Google和facebook的数据中心更多，进而导致了网络配置的复杂性更高。这也督促着运维工程师更早的引入自动化工具来辅助工作流程，比如此次完全有机会预先发现路由配置错误的HOYAN系统。通过这些自动化系统，不仅使得工作的可靠性提高，也使得很多工作基于规则自动完成，而避免依靠人在紧急状况下的判断，避免了事故隐患。
总结
facebook此次事故的教训，依旧是老生常谈的那几点，注重上线前检查，建立规范而带有审计的上线流程等等。但HOYAN系统的例子，也使得我们更应该注意整个信息基础架构中的自动化系统，毕竟这玩意真的可以避免事故，保住自己的年终奖。
类似的话题
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有