2024年2月22日凌晨，美国运营商AT&T发生全国性断网，语音与数据业务瘫痪约12小时，旗下预付费品牌Cricket及多家虚拟运营商用户同样失联，多个城市报警系统受波及。官方结论令人错愕：不是黑客，不是硬件，而是网络扩容过程中一次不正确的“退出维护”操作，引发核心网设备连接批量释放与连锁雪崩。本文以AT&T官方说明与监管调查为轴，复盘这起教科书级的割接事故，并给出一套经过二十年一线验证的“割接军规”——变更管理、灰度滚动、回退死线与通报合规，供每一个维护核心网的工程师参考。
2024年2月22日，周四。美中时区凌晨三点前后，AT&T用户开始大量在社交媒体报告手机“无服务”：打不出电话、上不了网，iPhone信号栏干脆变成空白。投诉监测网站DownDetector上的报告量在几个小时内冲破7万条，创下该平台近年来移动运营商类目的峰值之一。
受影响的不只是AT&T自有用户。使用AT&T网络的预付费品牌Cricket同步瘫痪，部分租用AT&T网络的虚拟运营商用户同样失联；T-Mobile和Verizon的用户则发现自己拨打AT&T号码时听到的是忙音。也就是说，这不是一张网掉线，而是一块横贯美国的核心网疆域整体静默。
更麻烦的是应急通信。多个城市的911报警系统受到波及，一些地方警察局被迫在社交媒体上公布备用报警电话。对一家反复在广告里强调“网络可靠性”的运营商来说，这是最难堪的一幕。
当天上午，AT&T对外确认排除网络攻击，称正在逐步恢复业务；到下午，官方宣布服务基本恢复，从故障发生算起约12小时。据CNBC等媒体报道，AT&T事后向受影响用户提供了每账户约5美元的话费补偿。次日，部分用户又出现了间歇性的二次中断，据当时报道与恢复措施引发的连锁反应有关，随后被消除。
一次扩容，怎么就放倒了一张全国网？答案藏在AT&T一周后发布的官方说明里。
2月底，AT&T在官方新闻室（about.att.com）发布了根因说明，原文大意是：
运营商扩容网络、增减设备是常规动作。在这次操作中，我们对部分设备退出维护状态时使用了一个不正确的流程，导致这些设备向网络中的其他设备释放（released）连接、再重新建立（reacquired）连接，进而引发连锁反应，最终造成服务中断。整个过程没有任何恶意活动的迹象。
需要分清楚：以上是官方陈述的事实，AT&T没有披露更多技术细节——涉密的具体网元型号、错误流程到底错在哪一步、为什么灰度机制没有拦住它，均未公开。下面是笔者的解读，基于核心网的普遍架构逻辑，而非AT&T内部信息。
“退出维护”四个字，做过核心网的人都不陌生。设备维护状态的语义是“我暂时不干活了，邻居们别把业务派给我”。而“退出维护”是反向操作：设备宣布回归生产，要在短时间内完成状态同步、邻居关系重建、信令连接重连、路由重新收敛。这是一个对顺序和时序极其敏感的过程——错误流程相当于让一台“睡了一觉”的设备带着过期状态冲回生产网。
更糟的是这张网里有亿级在网用户。设备间的连接批量释放，会被邻居网元感知为“大面积故障”，触发重连风暴和信令风暴；保护机制为了自保再掐断关联资源，故障半径从几个网元滚雪球到核心网层面。这正是分布式系统里最经典的级联失效：单点的进程性失误，被系统的强耦合放大成全网事故。
恢复为什么慢？因为此时的网络已经不是“重启就好”的状态——大量网元间的连接关系被污染，恢复必须逐段重建、逐段验证，每一步都要防止触发二次雪崩。第二天出现的间歇性二次中断，很可能就是恢复期的余震（此为推断，官方未详述）。
后续监管层面，据当年多家媒体报道引述的FCC调查披露，此次断网影响超过1.25亿部手机，超过9500通911呼叫受到影响，且AT&T未在规则时限内及时向911相关方通报（该数据与通报认定细节，本文成稿环境未能在线二次核验，请以FCC原文为准）。
综合AT&T官方说明与当年公开报道，事件脉络如下（时间为美中时区，个别时刻为媒体约略口径）：
| 时间 | 事件 |
|---|---|
| 2月21日夜间至22日凌晨 | 扩容变更按计划实施，部分设备先后进入并退出维护状态 |
| 2月22日约03:00 | 用户投诉陡增，社交媒体集中爆发，业务大面积中断 |
| 02:00–06:00 | DownDetector报告量冲破7万条；多个城市911受影响，警方发布备用报警渠道 |
| 上午 | AT&T确认排除网络攻击，开始全网逐段恢复 |
| 约15:00 | 官方宣布服务恢复，故障历时约12小时 |
| 2月23日 | 部分用户出现间歇性二次中断，随后消除 |
| 2月底 | AT&T发布官方根因说明：错误的“退出维护”流程 |
| 2024年内 | FCC调查披露影响面（超1.25亿部手机、超9500通911）并追究通报迟延责任 |
用时间线图看更直观：
timeline
title AT&T 2024年2月22日断网大事记
2月21日深夜 : 扩容变更实施 : 设备退出维护
2月22日凌晨 : 连接批量释放 : 全国业务中断
2月22日上午 : 排除网络攻击 : 逐段重建恢复
2月22日下午 : 官宣业务恢复 : 历时约12小时
2月23日 : 二次间歇中断 : 恢复期余震
2月底 : 官方发布根因 : 错误退出流程
2024年内 : 监管调查披露 : 通报迟延追责
在一线干了十几年核心网，我常对新人说一句话：割接的风险不在你动的那台设备，而在所有“认识”它的设备。
核心网是一个典型的强耦合分布式系统。以4G/5G为例：接入网通过N2/N11挂到移动性管理网元，会话面通过GTP-C/PFCP互联，签约与鉴权依赖统一的数据网元，网元发现靠DNS，计费靠实时话单链路。任何一个环节的连接关系被破坏，故障会沿着依赖关系扩散——你拔掉一根线，疼的是半张网。
维护状态机制的本意，是给变更圈一个“防爆区”。但它天然有个脆弱点：进出维护区的瞬间，是全网状态一致性最脆弱的时刻。进入维护，邻居要把话务摘走，这相对好办；退出维护，设备要带着可能过期的状态重新融入一个“已经演化了几个小时”的网络——邻居表、路由、会话上下文、信令关联，任何一样对不上，都会引发抖动。AT&T这次事故，正是踩在了“出区”这个最脆弱的时点上。
再加上一个工程实践中的老问题：变更窗口叠加。如果核心网和承载网在同一个夜里都有变更，故障发生后的定界难度是指数级上升的——你永远在两个团队之间互相甩锅，而业务在持续流血。这也是老运维把“单层变更”写进军规的原因。
还有一点值得说透：割接事故的代价曲线是非线性的。平时一次失败割接，损失的是几小时的夜间话务；而核心网层面的失败割接，损失的是应急通信、企业生产、支付系统对全网用户的可用性，外加监管处罚和品牌损伤。AT&T这12小时，账面补偿只是零头，真正的成本在FCC的调查记录里、在911那9500多通没打通的电话里。
事故讲完，讲干货。以下是这些年沉淀下来的割接十条军规，配套常见翻车点，供对照自查：
| # | 军规 | 要点 | 常见翻车点 |
|---|---|---|---|
| 1 | 变更单三件套 | 方案、步骤、回退预案缺一不可，步骤可勾选、可打断 | 方案写得漂亮，步骤写到“重启网元”就没有了 |
| 2 | 双人复核 | 两人独立通读步骤，关键指令念口令后执行 | 复核人临时被抓来顶班，看都没看 |
| 3 | 灰度先行 | 先做边缘网元、单点、最低话务时段，观察后再推全网 | 把“测试环境通过”当成“生产灰度通过” |
| 4 | 回退死线 | 设定硬性时点（如割接后2小时未达预期即回退），回退预案必须演练过 | 回退预案停留在纸面，真回退时发现依赖丢失 |
| 5 | 单层变更 | 核心网与承载网、电源、传输不排同一窗口 | “反正都停机了，一起弄了”，出事后无法定界 |
| 6 | 池内滚动 | 摘一台、升一台、回一台，任何时刻冗余不被击穿 | 贪快，同池两台同时动，冗余清零 |
| 7 | 基线对照 | 升级前后KPI基线自动对比：注册成功率、寻呼成功率、接通率 | 只看告警不看KPI，慢性劣化无人察觉 |
| 8 | 通报写入SOP | 应急/监管通报的触发条件、时限、话术模板化 | 现场慌乱中没有人想得起来要通报 |
| 9 | 首夜观察 | 割接后24小时专人值守，窗口期内禁止叠加任何变更 | 主割人凌晨四点回家，二次故障无人值守 |
| 10 | 无指责复盘 | 事故复盘对事不对人，产出物是流程修订而不是处分 | 复盘会开成追责会，下次没人敢说真话 |
十条里，第4、5、9条是血的教训换来的最多。回退死线尤其值得展开：割接最大的心理陷阱是“再等十分钟就好了”。没有死线的割接，会在“马上就好”的自我暗示里滑向天亮。我所在的团队规定，割接开始前就把死线写进变更单——到点即回退，回退决策不需要请示，这是事前授权，不是事后追认。
第10条来自Google SRE方法论的公开出版物《SRE：Google运维解密》（免费在线版sre.google），其“无指责复盘（Postmortem Culture）”一章的核心观点是：事故的唯一价值是变成流程资产，惩罚个人只会让下次事故多瞒三天。AT&T这次FCC介入后的信息披露路径，恰好从反面说明了“敢说真话的复盘文化”有多值钱。
AT&T官方说明没有披露是否采用灰度，这一点不应臆测。但“一次错误流程、全网连接释放”这个结果本身，说明变更缺乏爆炸半径控制。而现代核心网架构恰恰提供了现成的解法——池化。
2G/3G时代的SGSN Pool、4G的MME Pool，到5G的AMF Set，设计初衷都是容灾，但副产品就是无损割接能力：一组网元互为备份，任何一台都可以被摘出来单独维护。以5G的AMF为例，标准做法是：
flowchart TD
A[变更审批与窗口确认] --> B[备份与KPI基线采集]
B --> C[目标网元权重调零]
C --> D[在网用户上下文迁移]
D --> E[网元摘离AMF池组]
E --> F[实施升级或割接]
F --> G{升级成功？}
G -->|否| H[执行回退预案]
H --> I[回退后回池观察]
G -->|是| J[KPI基线对比]
J --> K{指标达标？}
K -->|否| H
K -->|是| L[恢复权重回池]
L --> M[下一台网元滚动]
M --> C
L --> N[全网完成后首夜观察]
几个关键点展开说：
权重调零与上下文迁移。把待升级网元的权重置零后，新用户不再选它，老用户通过标准的移动性流程迁移到同组其他网元。割接开始时，这台网元上已经没有在网会话——你动的不是“正在服务一亿会话的设备”，而是一台空载设备。爆炸半径从全网缩到零。
数据面网元反着做。HSS/UDR/UDM这类签约数据网元没法“摘离”，正确姿势是：先扩容新副本、数据双写、抽单校验、切读、观察、最后才下线旧节点。千万不能“停旧起新”——一旦新节点数据有出入，全网鉴权都会抖。计费侧同理，割接窗口前后必须做话单对账，CDR断点续传能力要在测试环境验证过。
滚动即灰度。池内逐台滚动天然就是灰度发布：第一台升级后如果KPI异常，后续网元全部冻结，变更单直接终止。AT&T式的“错误流程批量作用全网”，在滚动模式下最多伤及第一台。
需要说明：以上是3GPP标准架构允许的通用能力，各厂家的具体实现方式、参数名称与默认行为存在差异，以各厂家官方文档为准。
这次事故里容易被技术人忽视、却让AT&T付出监管代价的，是通报。
美国FCC自2019年起施行911故障通报规则：运营商在得知影响911的故障后，须在30分钟内向FCC及相关应急通报方报告。据当年媒体报道，FCC的调查认定AT&T在2月22日的断网中未及时履行通报义务——这也是后续监管处理的重要抓手。一边是12小时断网，一边是9500多通受影响的报警电话，中间还隔着一条没走完的通报链路，这三件事叠加，才是监管眼中的完整事故。
国内同行对这一点同样不陌生。重大网络故障向行业主管部门的分级报告制度，要求故障发生后在规定时限内完成首报与续报。但现实中，“报告SOP”往往躺在制度文件里，真到出事时，现场在抢修、领导在要口径、口径还没对齐，时间就过去了。
我的做法是：把通报做成变更预案的一部分，而不是故障预案的一部分。每一次割接变更单里都附一页通报卡——什么算触发条件（如影响用户数阈值、应急业务受影响）、向谁通报、多长时间内首报、首报模板三行字（现象、范围、预计时长）。事故现场没有人有余力组织语言，模板就是给最慌乱的时刻准备的。应急预案的最高境界，是让慌乱中的人也能做对事。
回头看这次事故，最讽刺的是它的起因如此平凡：一次再普通不过的扩容、一个自认为熟悉的维护流程、一个深夜的变更窗口。没有黑客，没有地震，没有光缆被挖断——杀死这张全国网的，是一次没有安全网的日常操作。
这也是我写这篇的目的。故障复盘看多了会发现，摧毁一张网络很少需要一个天才级的攻击者，多数时候只需要一个自以为没问题的人、一条没被遵守的流程、一个没有回退方案的变更单。割接这门手艺，练到后期拼的从来不是手速，而是纪律：敢不敢给回退设死线，肯不肯多等一夜灰度，能不能在“马上就好”的诱惑面前按预案办事。
把“人不敢按的按钮”变成“流程不允许按的按钮”——这就是AT&T用1.25亿部手机的失联，替全行业交的一次学费。
注：本文成稿时在线核验通道受限，参考来源为官方站点与权威公开出版物的高确定性稳定入口；文中关键事实均有2024年公开报道与AT&T官方说明交叉印证，个别未能在线二次核验的数据已在正文标注，请以来源原文为准。
本文由「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 等场景全覆盖。