# 一行break放倒美国长途网：1990年AT&T「1·15」大断网复盘 **概述**：1990年1月15日下午2时25分（美东时间），美国长途电话霸主AT&T的全国长途网在几分钟内成片瘫痪，约9小时内一半长途呼叫无法接通，800号码（银行、航司、订票热线）成片失灵。根因不是黑客、不是光缆，而是1989年12月统一加载到114台4ESS交换机上的一段软件——故障恢复例程里的一处缺陷，让「一台交换机重启」变成了「全国交换机连环自杀」。本文以FCC调查报告与当年RISKS工程论坛记录为解读主轴（见文末参考来源），按时间线、根因、处置、追责四个维度复盘这起36年前的教科书级事故，并回答一个问题：为什么它预言了云时代几乎每一场连锁失效。 ## 目录 - 一、那个星期一下午：全美一半长途电话打不出去 - 二、九小时时间线：一台交换机如何点燃全网 - 三、根因解剖：缺陷、触发器与放大器 - 四、处置复盘：怀疑黑客的一小时，逐台隔离的八小时 - 五、账单与追责：6000万美元、FCC调查与可靠性治理的起点 - 六、36年后再看：它预言了云时代的每一场雪崩 ## 一、那个星期一下午：全美一半长途电话打不出去 1990年1月15日是马丁·路德·金纪念日，一个星期一。AT&T在1984年被拆分后度过了第六年，但长途电话市场的格局远没有今天这么多元：彼时AT&T仍承载全美约七成以上的长途话务，骨干网是114台4ESS数字程控汇接交换机织成的网——这是当时全球最先进的长途交换平台，负责把跨越州的电话一条条接续出去。 下午2时25分起，美国东海岸的用户最先发现不对劲：拨号听到的不是正常回铃，也不是普通忙音，而是「所有中继全忙」的快速催挂音。重拨、再重拨，结果一样。坏消息沿着时区向西蔓延：纽约打不出芝加哥，芝加哥打不出达拉斯，800 toll-free 号码重灾区——银行的信用卡授权、航司的订票热线、连锁酒店的预订中心，成片失灵。据当年报道，在9个小时的中断里，AT&T长途呼叫约有一半未能接通，受影响呼叫量以千万计；而MCI、Sprint两家对手的接入话务量肉眼可见地暴涨。 在AT&T位于新泽西州Bedminster的网管控制中心，大屏上的画面更瘆人：交换机不是「故障」，而是像多米诺骨牌一样**一台接一台地自行重启**。最初几分钟，控制中心里没人往软件缺陷上想——他们首先怀疑的是黑客。这不是被害妄想：1988年11月莫里斯蠕虫刚把早期互联网掀翻过去不到14个月，「病毒自我复制搞垮网络」是所有工程师脑子里现成的剧本。事实证明，这次连剧本都不用写——写进网络里的那段代码，自己演完了全场。 ## 二、九小时时间线：一台交换机如何点燃全网 把FCC调查结论与当年报道拼起来，这一天大致是这样的： | 美东时间 | 事件 | 网络状态 | |---|---|---| | 1989年12月 | 114台4ESS交换机统一加载新版软件（据FCC调查及当年报道） | 正常运行 | | 1月15日 14:25 | 纽约一台4ESS因一个普通小故障自动复位，复位后按设计向邻机广播恢复消息 | 局部异常 | | 14:25–14:45 | 恢复消息触发邻机软件缺陷，邻机崩溃、重启后再广播，连锁扩散 | 全国过半长途电路中断 | | 15:00前后 | 控制中心初判疑似黑客/病毒攻击，着手排查 | 全网深度孤立 | | 17:00前后 | 排除攻击，锁定12月升级的软件，缺陷在实验室被复现 | 持续中断 | | 20:00前后 | 工程师逐台摘机、屏蔽缺陷代码，分岛复机 | 逐步恢复 | | 23:30前后 | 最后一批交换机恢复，故障关闭 | 全网复原 | ```mermaid timeline title 1990年1月15日：九小时崩塌与复原 14时25分 : 纽约一台4ESS自复位并广播恢复消息 14时45分 : 连锁崩溃蔓延，过半长途电路中断 15时 : 控制中心一度怀疑黑客攻击 17时前后 : 排除攻击，锁定12月升级的软件缺陷 20时前后 : 逐台隔离回退，网络分岛复机 23时30分 : 全网恢复，故障关闭 ``` 值得注意的一个细节是传播速度：从纽约第一台交换机崩溃到全国成片瘫痪，据当年报道只用了不到半小时。长途电话网不是局域网——交换机之间靠共路信令网实时互通状态，任何一台的状态变化都会以准实时的方式广播出去。这个为「高可靠」设计的信令体系，在那天下午变成了故障的高速公路。 ## 三、根因解剖：缺陷、触发器与放大器 单看任何一层，这场事故都不该发生。把它拆成四层看，每一层都是独立的失误，叠在一起才是灾难。 **第一层：潜伏的缺陷（latent defect）。** 4ESS的软件里有一段处理「故障恢复」的例程：当一台交换机崩溃重启后，它会向邻居广播「我回来了」的恢复消息，邻居收到后要更新自己的路由数据结构。这段例程里藏着一条代码缺陷。FCC的调查报告将其定性为软件缺陷叠加测试覆盖不足；而在工程师社区流传最广的版本是——问题出在一行C语言的`break`语句上，它放错了位置，导致处理恢复消息的例程在特定条件下走错分支、进而崩溃整机。需要说明：**FCC报告认定的是缺陷与测试不足这个层面，「一行break」的微观细节主要来自工程师社区与后续软件工程著作的转述**（RISKS论坛当年连续多期的第一手讨论是其重要载体），本文按「工程界流传版本」对待，读者引用时建议以FCC原文为准。 **第二层：一个再普通不过的触发器（trigger）。** 点燃它的不是什么惊天动地的事件，而是纽约一台交换机的一次日常小故障自复位——这种复位在骨干网上每天都会发生若干次。如果这行缺陷代码从未被执行，它就会安静地随下一次版本升级被淘汰。日常小故障撞上潜伏缺陷，这才是事故的标准配方。 **第三层：同构网络的放大（amplifier）。** 114台交换机在12月被**同批**加载了同一版本软件——意味着全网交换机在这条代码路径上是同一个脑子。恢复消息广播到邻居，邻居执行同样的例程、踩中同样的缺陷、同样崩溃；崩溃的机器重启后再广播，再传染下一批。这是一个教科书级的共因失效（common cause failure）：冗余设计的前提是「冗余单元不同时坏」，而全网同版本软件让「互为备份」的114台机器共享同一条死路。 **第四层：缺失的保险丝（missing fuse）。** 收到一条状态异常的恢复消息，交换机的正确姿势应该是「丢弃可疑消息、告警、降级运行」，而不是忠实地执行到崩溃。当年的软件没有任何熔断、限速或隔离设计——信令面收到什么就执行什么。加上没有灰度（无法只让10%的机器先跑新版）、没有预案（没人想过「全部崩溃后怎么恢复」），四层失误严丝合缝地扣在了一起。 ```mermaid flowchart TD A["1989年12月
114台4ESS换装新软件"] --> B["1月15日14时25分
纽约一台4ESS自复位"] B --> C["沿信令链路
向邻居广播恢复消息"] C --> D["邻居执行恢复例程
踩中代码缺陷"] D --> E["例程崩溃
整机重启"] E --> F["重启机再次广播
恢复消息"] F --> D E --> G["连锁扩散
长途网裂成孤岛"] G --> H["控制中心逐台隔离
切断传染链"] H --> I["分岛回退恢复
深夜全网复原"] ``` 这里有一个所有运维都该刻在骨头上的细节：**缺陷不在主业务路径上，而在故障恢复路径上。** 12月那次升级，正常的呼叫接续功能千锤百炼、指标全绿；但「交换机崩溃之后发生什么」这条路径，几乎从没被真正测试过——因为它只在故障时才执行。36年后的Optus断网复盘（本栏目此前已有专文）里，栽跟头的防泄露保护机制同样是「设计了、上线了、但从没实测过」的恢复路径代码。这不是巧合，这是规律。 ## 四、处置复盘：怀疑黑客的一小时，逐台隔离的八小时 复盘处置过程，前松后紧，两段对比极其鲜明。 **怀疑黑客的阶段（约15时–17时）。** 控制中心的直觉是「被攻击了」——蠕虫的阴影太新。事后看，这两个小时的定性错误代价高昂：排查黑客与排查软件是完全不同的两条路，前者在找「谁进来了」，后者在找「我们12月改了什么」。直到工程师注意到崩溃按「信令邻接关系」而非「地理分布」扩散、且现象可以在实验室用特定消息序列复现，方向才掉头。今天SRE方法论里反复强调的「先分型：外部攻击、资源耗尽、还是最近变更」，就是从这类事故里一条条学费换来的。 **隔离恢复的阶段（约17时–23时30分）。** 工程师采取的办法朴素到近乎笨拙：把交换机一台一台摘出服务，屏蔽缺陷代码，确认稳定后再放回——手工、串行、以小时计。为什么不敢一键全网回退？因为全网是同一个版本，「修复动作本身」没有经过任何验证，急躁的全网操作完全可能触发第二波雪崩。这种克制后来被证明是对的：恢复期间网络分岛逐步重建，深夜全部复原，没有二次翻车。对照本栏目此前复盘过的Rogers恢复洪峰与AT&T 2024年恢复后的注册风暴——恢复阶段的「二次事故」在36年里反复上演，1990年这场克制而缓慢的复机，反而是少有的正面教材。 **对外沟通则是减分项。** 据当年报道，AT&T当晚对外口径模糊，次日才由高层公开道歉并给出软件缺陷的定性，舆论批评其披露迟缓。36年后，FCC在2024年2月22日AT&T全国断网事故中对「迟报」单独开出95万美元罚单（本栏目已有专文复盘）——事故定性会进步、软件工程会进步，但「出事先捂一捂」的冲动，是运维史上最顽固的bug。 ## 五、账单与追责：6000万美元、FCC调查与可靠性治理的起点 先算钱。据当年报道，AT&T估计此次事故的直接收入损失约6000万美元（另有口径称约7500万）；更贵的隐性账单是信任——企业客户从这次事故里看清了一件事：把全部长途话务押在一家运营商、一张同构网络上，等于把身家押在一段你读不到的代码上。此后几年，关键行业客户加速部署双运营商、多路由冗余，「多归属」从可选项变成金融、航司行业的标配。 再看监管。FCC随即立案调查，调查结论对AT&T的软件流程提出了系统性批评：缺陷代码随12月升级一并进入全网、测试未能覆盖该故障路径、全网同批加载缺乏灰度与拦截手段。以今天的标准看，AT&T没有被开出天价罚单——当年的监管工具箱远没有今天丰富；AT&T以公开承诺整改收场。但这次事故留下了一份更值钱的制度遗产：面对80年代末90年代初接连不断的网络中断（软件缺陷、光缆被挖、机房火灾），FCC在1992年组建了网络可靠性委员会（Network Reliability Council），也就是今天FCC网络可靠性顾问委员会（NRIC）体系的前身。运营商重大事故报告、根因公开、监管复核这套今天我们习以为常的流程，其制度化起点就可以追溯到1990年1月15日下午2点25分。 换句话说：2024年AT&T断网后FCC能在两周内出报告、精确定性、精准开罚，这套「快刀」的刀刃，是1990年这一跤磨出来的。 ## 六、36年后再看：它预言了云时代的每一场雪崩 把本栏目此前复盘过的几场大事故和1990年这起摆到一张表上，你会看到同一张脸： | 事故 | 年份 | 同构放大器 | 与「1·15」的共性 | |---|---|---|---| | AT&T长途网崩溃 | 1990 | 恢复消息经信令网广播传染 | 全网同版本软件，无熔断 | | docomo全国语音瘫痪 | 2021 | 割接缺陷引发跨网信令风暴 | 同构设备同版软件 | | Rogers全国断网 | 2022 | 核心路由失联叠加恢复洪峰 | 单点故障放大为全网 | | AT&T 2·22断网 | 2024 | 扩容配置失误叠加注册风暴 | 变更无灰度，恢复期二次事故 | | Xfinity内核恐慌 | 2025 | 一条配置变更触发全网内核崩溃 | 变更无熔断，靠小时级手工恢复 | 五场事故跨越36年、横跨电路交换与云原生，但失效链条惊人一致：**一个局部变更（或局部故障）→ 一个未被测试的路径被激活 → 同构系统批量放大 → 恢复动作本身成为新的风险源。** Google SRE手册里专门有一章讨论连锁失效（cascading failures）：过载引发重试、重试放大过载，系统一旦越过临界点就再也回不到稳态——今天我们叫它亚稳态失效（metastable failure），1990年那个下午的114台交换机，就是这个概念的最早标本之一。 对号入座地给出对策映射，是这篇文章真正想留下的东西： | 1990年的教训 | 今天的对策 | |---|---| | 全网同批加载同一版本 | 灰度发布、金丝雀、分批回滚 | | 恢复路径从未被测试 | 故障注入必须覆盖故障处理路径 | | 信令面收到什么执行什么 | 控制面限速、熔断、可疑消息丢弃 | | 恢复动作临场即兴 | 恢复预案化、演练化、自动化 | | 事故披露迟缓 | 事故报告制度化（如FCC DRS体系） | 最后说一点老兵观点（以下为作者看法，非任何官方结论）。36年里，交换机换成了云原生网元，共路信令换成了gRPC和消息队列，「114台同版本4ESS」变成了「几千个Pod跑同一个镜像」——舞台换了，剧本一字没改。我带过的团队里，几乎所有重大事故都能归结到同一种侥幸：「这段代码在故障时才执行，应该没事」。应该没事，就是出事的全部原因。**你最该担心的，永远不是那条天天在跑的主路径，而是那行只在故障发生时才执行的代码——因为它执行的那一天，恰恰是系统最脆弱、最输不起的一天。** 1990年1月15日下午2点25分，那行break被执行了；36年来，它换着名字、换着语言，一直在被执行。 ## 参考来源 1. [FCC EDOCS 官方文件库](https://www.fcc.gov/edocs) — 检索「Investigation of the January 15, 1990 Disruption of AT&T's Long Distance Network」可获取FCC对本次事故的调查报告全文；本文的根因定性、114台4ESS统一升级、测试覆盖不足等关键事实以此为准 2. [The Risks Digest（P. G. Neumann 主持的 comp.risks 论坛档案）](https://catless.ncl.ac.uk/Risks/) — 事故发生后工程师社区的第一手连续讨论，「break语句」微观细节流传的主要载体之一；属工程社区版本，非官方结论 3. [Google SRE: Addressing Cascading Failures](https://sre.google/sre-book/addressing-cascading-failures/) — 连锁失效与过载恢复的现代方法论，用于第六节的对策映射 4. [FCC: February 22, 2024 AT&T Mobility Network Outage Report（DOC-404150A1）](https://docs.fcc.gov/public/attachments/DOC-404150A1.pdf) — 用于第五、六节中36年监管对照与AT&T 2024年事故的根因引用 5. [IEEE Spectrum](https://spectrum.ieee.org/) — 1990年对事故的跟踪报道与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 等场景全覆盖。