2024年2月22日（美东时间，下同）凌晨4时前后，美国第二大移动运营商AT&T爆发全国性语音与数据中断，大量手机从满格信号直接跌进“无服务”，持续约12小时才全部恢复。Downdetector平台峰值报告约7.4万次，FCC事后通报口径显示上亿部设备受影响、400余通911紧急呼叫未能接通。官方定因令人错愕：不是网络攻击，而是网络扩容过程中一次“应用错误+错误流程被执行”。2024年12月，FCC就911故障环节对AT&T开出95万美元罚单。本文以FCC通报与AT&T官方声明为主轴，复盘这起“一次变更打瘫一张全国网”的完整链条：时间线、根因、影响、处置与整改，最后给核心网运维留下几条能直接落地的军规。
2024年2月22日是周四。美国中部时间凌晨3时前后，AT&T网内手机开始成规模掉线。很多人是被闹钟叫醒后才发现问题的：信号栏空空如也，iPhone顶部赫然显示"SOS"——这个细节很关键，说明终端认得出“这不是我的网”，却怎么也注册不回去。据美联社、路透社等媒体报道，故障从凌晨持续到午后，社交媒体上的吐槽在早上7点前后达到高潮：Downdetector峰值报告约7.4万次，是当年最尖的一根“故障刺”。
受影响的远不止聊天刷视频。移动支付刷不开、网约车叫不到、双因子验证码收不到，门禁和物流终端跟着遭殃；更严重的是多个城市的用户反映911打不通——这是后来FCC介入的导火索。AT&T旗下的预付费子品牌Cricket Wireless同步瘫痪，这是一个重要线索：子品牌与主品牌共享核心网，故障点大概率在“共享层”而不是某个区域的无线接入侧。与此同时，Verizon和T-Mobile的用户基本正常，只有少量跨网呼叫AT&T号码失败的报告——互联互通层面被牵连的“回声”，而不是他们自己的网出了事。
还有一个被大量用户复现的怪现象：网络恢复后，相当一部分手机仍停在“无服务”状态，必须重启或开关飞行模式才缓过来。终端状态机被网络拒绝后卡死在坏状态，这个细节在后面推导根因时会再次出现。
先看时间线（各节点时间综合AT&T官方声明与美联社、路透社报道口径，均为美东时间概数）：
timeline
title 2024年2月22日AT&T断网时间线
凌晨4时前后 : 终端大规模失去服务，报告开始涌入
上午7时前后 : 故障报告达峰，单平台超7万次
上午时段 : 官方确认全国性故障，启动应急处置
午后时段 : 网络分批恢复，用户陆续重新注册
下午3时前后 : 宣布全部恢复，历时约12小时
当天晚间 : 官方定调变更错误，排除网络攻击
| 美东时间 | 事件 | 信息口径 |
|---|---|---|
| 约04:00 | 中部时间3时前后故障显现，用户开始失联 | 媒体报道+用户报告 |
| 约07:00 | Downdetector峰值约7.4万次报告 | 平台公开数据 |
| 上午 | AT&T确认全国性语音数据中断，表示正排查、暂无定论 | AT&T官方声明 |
| 午后 | 网络分批恢复，部分终端需手动重启才恢复注册 | 媒体报道 |
| 约15:00-15:10 | AT&T宣布受影响用户全部恢复 | AT&T官方声明 |
| 当天稍晚 | 定因：扩容中应用错误+错误流程被执行，排除网络攻击 | AT&T官方声明 |
| 2024年12月 | FCC就911故障环节达成95万美元和解 | FCC官方通报 |
12个小时，对一张全国网来说是“深度昏迷”——不是局部抽搐，是整张网的控制面持续失能。这个时长本身就排除了“单点硬件坏”的剧本：硬件坏一个池子，顶多掉一片用户，不会让全网12小时起不来。
AT&T在事发当天的官方声明里给出的定性是：故障由“扩容网络时使用的应用错误和一段被错误执行的流程”引起，与网络攻击无关。这句话的官方版本原文可在AT&T新闻室（about.att.com）查证，路透社当天即做了转述报道。
把这句话翻译成运维语言，它其实交代了三个要素：
第一，场景是扩容。 不是日常的参数调整，而是一个给网络“增肥”的工程项目——新网元上线、新容量接入。这类项目周期长、自动化程度高，通常靠脚本和应用系统批量下发指令。
第二，错的是“应用+流程”的组合。 应用本身有错，或者应用没过错但流程把它用错了——比如作用域选错、环境隔离没做干净，本该落在新网元上的指令，打到了在役网元头上。
第三，在役设备被“动了”。 这是全网瘫痪的物理前提：正在承载用户的核心网元被误下线或误置为异常状态。
据此可以把故障传播链工程化地重构如下（注意：AT&T并未披露网元级细节，以下链路是结合官方表述、公开报道与核心网常识做出的推断，特此声明）：
flowchart TD
A["扩容项目：新网元上线"] --> B["错误流程被执行，应用误发指令"]
B --> C["在役核心网元被误下线"]
C --> D["鉴权与注册能力受损"]
D --> E["全网终端反复发起注册"]
E --> F["信令洪峰挤占容量，恢复更慢"]
C --> G["紧急呼叫路由依赖同一核心网"]
G --> H["400余通911呼叫失败"]
D --> I["终端状态机卡死，需重启恢复"]
这张图解释了现场的三个反常现象。为什么全网一起挂？ 因为现代核心网的控制面高度集中——集中鉴权、集中用户数据库，爆炸半径等于部署面，一错就是全国。为什么911也挂？ 因为紧急呼叫的建立同样依赖注册与位置管理流程，正常路径断了，降级路径没有兜住。为什么恢复这么慢？ 两个放大器：一是终端状态机卡死，用户重启才恢复；二是恢复期全网终端在同一时间窗内扑上来重新注册，信令洪峰反过来挤占刚恢复的容量——这个机理与KDDI、NTT docomo历史上的大断网如出一辙，是注册类故障的通用续集。
还有一个耐人寻味的细节：部分用户的Wi-Fi通话可用、部分不可用。VoWiFi的注册鉴权路径与网络侧核心网仍有交叠，可用与否取决于故障的具体落点——这反过来佐证故障在鉴权/注册层面，而不是纯粹的无线侧。另外据AT&T官方说法，其承建的公共安全专网FirstNet采用独立组网、未受波及，但事后也有公共安全用户提出了异议。独立核心网能抗多大的故障，取决于“独立”到底独立到哪一层。
规模口径。 据路透社转述的FCC事后通报，这次故障影响了约1.25亿部联网设备，超过400通911呼叫未能接通。这是FCC口径下美国近年来影响面最大的运营商断网事故之一。要说明的是：规模大，但性质清楚——这是可用性事故，不是安全事件，没有证据表明用户数据泄露或遭遇攻击。
911是本次事故的“定罪项”。 语音数据中断是服务质量问题，911打不通则是公共安全问题，FCC对两者的容忍度完全不同。400多通电话背后，可能是400多个正在流血、着火或心梗的现场。这也是为什么最终罚单金额不大（95万美元），但监管动作落点精准——只针对911故障环节立案。
商业影响反而有限。 AT&T事后给受影响用户发放了约合5美元的话费补偿（媒体口径，大约相当于一天服务费），按其近亿的用户规模计算是笔可观的支出，但对一家年收入千亿美元量级的运营商，这只是零头。真正贵的两样东西没上账本：一是品牌信任，二是后续每一个新项目都要接受的更严审查。顺带一提，同一年晚些时候AT&T还因历史数据上云泄露被FCC另案罚款1300万美元——可用性和安全性是两条独立战线，哪条失守都要单独买单。
对行业的溢出影响。 2024年12月，FCC在就911故障环节与AT&T达成95万美元和解（官方通报见fcc.gov/enforcement）的同时，还推动了新规落地：要求无线运营商在发生影响911的故障时，必须及时通知911接警中心。换句话说，这次事故改写了全行业的合规基线——以后再出事，不仅要修网，还要第一时间让接警中心知道“你的辖区里有手机打不通911了”。
从公开信息看，AT&T当天的处置链条大致是：监控发现异常 → 确认影响面（从“部分用户”到承认全国性故障，对外口径有一个升级过程）→ 冻结并回溯变更 → 修复 → 分批恢复 → 官宣全部恢复 → 当天晚间给出初步定因。值得肯定的是定因速度：当天就排除了网络攻击并锁定变更错误，这说明变更审计链路是通的——谁在什么时间、用哪个账号、对哪些设备执行了什么，能查得回来。这是后面军规之一的基础。
按FCC规则，影响911的故障属于必须快速上报的范畴（NORS体系），运营商要在规定时限内提交故障报告。AT&T这次显然没能在故障发生时就把911环节兜住，但在报告义务上是走了流程的——FCC的调查正是基于这些报告展开。
2024年12月的和解协议里，除了95万美元民事罚金，此类同意令通常还附带合规整改承诺：变更管理、911可靠性、故障上报流程的强化与定期评估（具体条款以FCC官方文本为准）。对运营商来说，罚金是账单，整改承诺才是真正的紧箍咒——它意味着未来相当长一段时间里，每一次关键变更都在监管的放大镜下。
从运维视角看，这次处置最值得复盘的不是修复本身，而是修复的“形状”。 12小时的恢复曲线不是一条直线：先分批恢复、再对付注册洪峰、再处理状态机卡死的终端。如果恢复时把全部容量一次性放出去，信令风暴很可能让网络二次瘫倒——分批放号、限流准入，这些平时写在预案里的动作，在2月22日那天真正派上了用场。
把AT&T放进近几年的重大断网序列里看，病根的分布很有规律：
| 时间 | 运营商/国家 | 影响面 | 持续时长 | 根因关键词 | 后续处置 |
|---|---|---|---|---|---|
| 2024-02-22 | AT&T/美国 | 约1.25亿部设备，400余通911失败 | 约12小时 | 扩容中应用错误+错误流程被执行 | FCC和解，95万美元 |
| 2024-09-30 | Verizon/美国 | 全国性，平台报告超10万次 | 约10小时 | 软件问题（官方未披露细节） | 向FCC提交说明 |
| 2023-11-08 | Optus/澳大利亚 | 约千万级用户+4000余企业 | 约14小时 | 核心网例行升级中路由信息变更引发级联故障 | 监管调查与整改承诺 |
| 2020-06-15 | T-Mobile/美国 | 全国语音与911受影响 | 约12小时 | 第三方互联电路故障引发路由震荡与注册风暴 | FCC发布技术复盘报告 |
三种病根一目了然：变更错误（AT&T、Optus）、软件与路由缺陷（Verizon、T-Mobile）、外部攻击（另案讨论）。最扎心的是共同点：绝大多数全国级瘫痪，引爆点都不在“天灾”里，而在“控制面×变更”的交汇处——人、脚本、流程，三者之一在错误的时刻按错了按钮。硬件冗余、多活机房这些花大钱的东西，防的都是小概率的物理故障；而一次变更错误能绕过所有这些冗余，因为冗余设备之间共享同一条变更流水线。
这条军规清单是写给所有要在生产网上动刀的人的，条条都有AT&T的影子：
第一条，扩容脚本必须“作用域白名单+环境硬隔离”。 目标网元清单要显式枚举、双人复核，不允许用规则推导“应该作用到哪些设备”；开发、测试、生产三套环境之间，指令通道要物理隔离。这次事故的本质就是指令越界——本该落在新设备上的命令打到了在役设备头上。
第二条，变更分批就是爆炸半径控制。 任何核心网变更不得同时触碰全部冗余单元：先1%，观察，再10%，再全量。标准允许多种实现方式，具体分批粒度以各厂家官方文档和自家网络架构为准，但“一次变更不同时打掉N+1”这条底线没有商量余地。
第三条，紧急呼叫的降级路径要设计、要演练，不能只写预案。 注册失败的场景下911能不能呼出、走哪条路由、接警中心如何被通知，每个季度都要实打实演练一次——包括和接警中心的联动通报流程。FCC新规之后，“通知911中心”本身就是合规动作，不练就是裸奔。
第四条，把信令风暴防护做成常态配置。 准入控制、退避策略、恢复期分批放号，这三件事要在每次大变更前检查到位。全网瘫痪后的恢复时刻是最危险的时刻——上亿部手机不会礼貌地排队重新注册，它们会同一秒扑上来。
第五条，监控和应急通信必须带外。 监控通道不能和业务网同路径，否则故障时刻你是在盲飞；内部IM、会议桥、语音 会议要有“网络全挂”的备份方案。当天能快速定因的前提，是应急团队在网瘫着的时候还能开得成会、查得成日志。
第六条，变更记录是第一现场，审计链路要能回放。 时间戳、执行账号、脚本版本、下发指令全文，一个都不能少。AT&T能在事发当天锁定根因、排除攻击，靠的就是这条链路。做不到“任何人任何操作可回放”，你连复盘的材料都没有。
复盘完这12小时，最让人后背发凉的不是故障有多大，而是根因有多小：一个应用、一段流程、一次执行错位，就干掉了1.25亿部设备的连接和400多通呼救。这不是AT&T一家的病——Optus的级联故障、Verizon的软件问题、T-Mobile的注册风暴，剧本高度相似：冗余防得住硬件坏，防不住一条错误的指令被忠实地执行。
所以成熟的运维体系，从来不假设人不犯错，而是把“人犯错的概率”当成一个工程量来设计：用白名单收窄指令的作用域，用分批限制错误的爆炸半径，用带外监控保住故障时的观察力，用演练让最坏场景变成肌肉记忆。网络不怕出故障，怕的是一个按钮按错之后，全网的刹车一起失灵。下次在割接窗口敲下回车之前，不妨想想2月22日凌晨那些显示"SOS"的手机——那一刻，全网只有变更记录是诚实的。
注：以上链接为各来源机构官方站点入口，原文可按所附标题与日期检索核对；正文已明确区分官方通报口径、媒体报道口径与作者工程推断。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。