## 概述 2024年2月22日凌晨，美国运营商AT&T发生全国性断网，语音与数据业务瘫痪约12小时，旗下预付费品牌Cricket及多家虚拟运营商用户同样失联，多个城市报警系统受波及。官方结论令人错愕：不是黑客，不是硬件，而是网络扩容过程中一次**不正确的“退出维护”操作**，引发核心网设备连接批量释放与连锁雪崩。本文以AT&T官方说明与监管调查为轴，复盘这起教科书级的割接事故，并给出一套经过二十年一线验证的“割接军规”——变更管理、灰度滚动、回退死线与通报合规，供每一个维护核心网的工程师参考。 ## 目录 - 一次退出维护，放倒一张全国网 - 官方说明拆解：雪崩从哪里开始 - 时间线：从凌晨三点到下午三点 - 割接为什么危险：强耦合的核心网 - 割接军规：把风险关进流程 - 池化时代：滚动升级与无损割接 - 通报合规：911的那三十分钟 - 结语：割接靠的不是胆子，是纪律 ## 一次退出维护，放倒一张全国网 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）并追究通报迟延责任 | 用时间线图看更直观： ```mermaid 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为例，标准做法是： ```mermaid 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标准架构允许的通用能力，各厂家的具体实现方式、参数名称与默认行为存在差异，以各厂家官方文档为准。 ## 通报合规：911的那三十分钟 这次事故里容易被技术人忽视、却让AT&T付出监管代价的，是**通报**。 美国FCC自2019年起施行911故障通报规则：运营商在得知影响911的故障后，须在**30分钟内**向FCC及相关应急通报方报告。据当年媒体报道，FCC的调查认定AT&T在2月22日的断网中未及时履行通报义务——这也是后续监管处理的重要抓手。一边是12小时断网，一边是9500多通受影响的报警电话，中间还隔着一条没走完的通报链路，这三件事叠加，才是监管眼中的完整事故。 国内同行对这一点同样不陌生。重大网络故障向行业主管部门的分级报告制度，要求故障发生后在规定时限内完成首报与续报。但现实中，“报告SOP”往往躺在制度文件里，真到出事时，现场在抢修、领导在要口径、口径还没对齐，时间就过去了。 我的做法是：**把通报做成变更预案的一部分，而不是故障预案的一部分**。每一次割接变更单里都附一页通报卡——什么算触发条件（如影响用户数阈值、应急业务受影响）、向谁通报、多长时间内首报、首报模板三行字（现象、范围、预计时长）。事故现场没有人有余力组织语言，模板就是给最慌乱的时刻准备的。应急预案的最高境界，是让慌乱中的人也能做对事。 ## 结语：割接靠的不是胆子，是纪律 回头看这次事故，最讽刺的是它的起因如此平凡：一次再普通不过的扩容、一个自认为熟悉的维护流程、一个深夜的变更窗口。没有黑客，没有地震，没有光缆被挖断——**杀死这张全国网的，是一次没有安全网的日常操作**。 这也是我写这篇的目的。故障复盘看多了会发现，摧毁一张网络很少需要一个天才级的攻击者，多数时候只需要一个自以为没问题的人、一条没被遵守的流程、一个没有回退方案的变更单。割接这门手艺，练到后期拼的从来不是手速，而是纪律：敢不敢给回退设死线，肯不肯多等一夜灰度，能不能在“马上就好”的诱惑面前按预案办事。 把“人不敢按的按钮”变成“流程不允许按的按钮”——这就是AT&T用1.25亿部手机的失联，替全行业交的一次学费。 --- **注**：本文成稿时在线核验通道受限，参考来源为官方站点与权威公开出版物的高确定性稳定入口；文中关键事实均有2024年公开报道与AT&T官方说明交叉印证，个别未能在线二次核验的数据已在正文标注，请以来源原文为准。 ## 参考来源 1. [AT&T官方新闻室（about.att.com）](https://about.att.com/) — 2024年2月底发布的断网根因官方说明：扩容中“不正确的退出维护流程”导致设备连接释放与重连，排除网络攻击 2. [2024 AT&T outage — Wikipedia](https://en.wikipedia.org/wiki/2024_AT%26T_outage) — 事件时间线、影响面与各方回应的聚合条目 3. [Google SRE Book: Postmortem Culture](https://sre.google/sre-book/postmortem-culture/) — 无指责复盘文化的权威工程实践出处 4. [Google SRE Book: Managing Incidents](https://sre.google/sre-book/managing-incidents/) — 应急管理与通报职责的事故指挥体系（ICS）方法论 5. [FCC官网](https://www.fcc.gov/) — 911故障通报规则与本次事件监管调查的发布主体，认定细节以FCC原文为准 --- > 本文由「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 等场景全覆盖。