概述：2018年12月6日13时34分起，软银（SoftBank）移动网发生日本通信史上罕见的大规模故障：全国约3086万手机用户语音、短信、数据业务中断，主流业务耗时约39小时才恢复，连固定电话都遭殃。本文以软银第三方委员会调查报告与日本总务省通报为主轴，完整复盘这起“硬件故障—备用切换失败—数据回滚—认证序列号错位”四连环事故：一个藏在SIM卡里的计数器，如何让三千万部手机集体“失忆”，以及给核心网工程师留下的教训。
2018年12月6日，周四。东京时间13时34分前后，软银位于东京的核心网机房内，一台正在做更换作业的用户管理类核心设备突发硬件故障。故障没有按剧本停留在“局部”，而是在几分钟内演变成全国性事件：软银移动网（含共用同一张网的Y!mobile品牌）的手机用户陆续发现——电话打不出去也打不进来，短信发不出，4G数据断了，手机信号格直接消失或停在“无服务”。
这是日本移动通信史上影响面最大的单一运营商故障之一。据第三方委员会事后公布的数据，受影响移动用户约3086万，故障从6日下午持续到8日凌晨，主流业务恢复累计耗时约39小时。更麻烦的是两类次生影响：一是大量从其他运营商打往软银号码的呼叫也以失败告终——故障影响的不是“软银的手机”，而是“通往软银的整条路”；二是软银旗下约46万“软银光电话”（SoftBank光电话）固定语音用户同样断话，因为这套固话业务跑在移动网核心之上，皮之不存，毛将焉附。
在社交媒体尚且如此发达的2018年，这场故障的传播速度可想而知：车站里人们围着公用电话排队（对，日本当时还有大量公用电话，那一天它们重新变成了硬通货），企业呼叫中心瘫痪，依赖移动网络的物联网设备——快递柜、数字标牌、车队管理终端——批量离线。据日媒报道，部分110、119紧急呼叫也出现无法接通的情况，这也是事后官方问责的重点之一。
先把关键时间线整理成表（依据软银第三方委员会中期报告及NHK、日本经济新闻等媒体报道综合）：
| 时间（当地时间） | 事件 |
|---|---|
| 12月6日 13:34前后 | 东京核心网机房设备更换作业中发生硬件故障，全国移动业务陆续中断 |
| 12月6日 下午至晚间 | 故障确认影响全国，语音、短信、数据全面受损；总务省要求运营商说明并提交报告 |
| 12月6日 深夜至7日 | 网络侧完成用户数据恢复与对策调整，部分3G终端开始陆续恢复注册 |
| 12月7日 全天 | VoLTE终端仍是重灾区，软银通过短信、官网引导用户重启手机 |
| 12月8日 凌晨 | 主流业务恢复完毕，官方口径累计约39小时 |
| 12月26日 | 第三方委员会公布中期报告，还原故障链条；总务省提出行政指导 |
| 2019年初 | 最终报告发布，软银提交再发防止对策 |
运营商网络在设计时就假设“设备会坏”：现用系统坏了切备用，备用不行恢复数据，数据不对终端自己会重试。这套纵深防御在12月6日那天，被逐层击穿。整条故障传播链可以画成一张图：
flowchart TD
A["机房内设备更换作业"] --> B["现用核心设备硬件故障"]
B --> C["倒向备用系统失败"]
C --> D["用旧备份恢复用户数据"]
D --> E["认证序列号整体回退"]
E --> F["认证失败 无法重新注册"]
F --> G["全国语音数据业务中断"]
第一道失守的是冗余。 按第三方委员会中期报告的还原，故障发生在核心网用户管理设备的更新维护作业期间，现用系统硬件故障后，切换到备用系统的动作没有按预期完成——也就是说，故障发生时这张网实际上处于“现用异常、备用不可用”的双输状态。冗余配置写在图纸上是一回事，在真实故障时刻能不能接得住是另一回事。很多运营商的冗余切换演练，做的是“计划性倒换”：提前挑好窗口、降低负荷、工程师盯着仪表一步一步切。而真实故障从不挑窗口，也从不提前降负荷。
第二道失守的是数据恢复。 备用系统接不住，退而求其次：从备份里恢复用户数据。问题恰恰出在这里——恢复所用的是故障发生前的备份数据，而用户数据里有一类特殊的字段：与每张SIM卡一一对应、只增不减的认证序列号（SQN）。备份里的SQN是“过去时”，而全国三千万张SIM卡里记录的SQN是“现在时”。数据恢复的瞬间，全网的“网络侧账本”被整体拨回到了几个小时之前。
第三道失守的是终端自愈。 按照3GPP认证体系的设计，账本错位本应能自愈——SIM卡检测到网络侧序列号异常后，会走一条专门的“重同步”流程把计数器对齐（下一节详细讲）。但这次面对的是三千万部终端在同一时段的集中冲击，加上VoLTE终端的注册链路远比3G复杂，自愈机制没有形成雪崩式收敛，反而演变成持续数十小时的拉锯。据委员会报告和媒体报道，3G终端大多在次日陆续恢复，而VoLTE终端大量需要重启手机、甚至反复重启才恢复——这也是软银后来通过短信和官引导用户“重启手机”的原因：网络侧能做的补救都做完之后，最后一公里必须靠终端自己重新发起注册。
先说明：本节关于认证机制的描述属于3GPP标准背景知识（参见TS 33.102、TS 33.401中的认证与密钥协商AKA框架），并非委员会报告原文；委员会报告的结论是——用户数据恢复导致网络与终端间认证序列号不一致，终端认证失败无法重新注册。
移动网络的认证要防一种攻击：攻击者截获网络发给手机的一条认证消息，原样重放，冒充网络骗取手机响应。防御的核心就是SQN——一个由网络和SIM卡各自维护、单调递增的计数器。网络每次发起认证，生成一个比历史值更新的SQN放进认证令牌里；SIM卡收到后核对自己卡内记录，只有“新值合理地大于旧值”才放行。一旦发现网络给的值反而更旧，SIM卡就判定：这可能是一次重放攻击，拒绝认证。
正常流程与错位后的流程，差别在这张图里：
sequenceDiagram
participant T as 手机与SIM卡
participant M as 核心网MME
participant H as 用户数据库HSS
Note over T,H: 正常情况 网络侧SQN不低于卡内值
M->>H: 请求认证向量
H-->>M: 下发随机数与认证令牌
M->>T: 发起认证请求
T-->>M: 校验通过 返回响应
Note over T,H: 数据回滚后 HSS被写成旧SQN
M->>T: 携带旧SQN发起认证
T->>T: 比对卡内计数 判定异常
T-->>M: 返回AUTS 同步失败
M->>H: 触发SQN重同步流程
标准里本来就准备了“账本对不上”的出路：SIM卡返回的AUTS消息携带卡内的计数信息，网络据此把HSS侧的SQN重新对齐，下一次认证即可通过。这本是一条成熟的救赎通道——这也是为什么3G终端相对恢复得快。
但救赎通道有三个前提，这次全都不成立：
第一，重同步需要网络侧数据是“健康的”。 这次的问题不是简单的计数器落后，而是整套用户数据被回写成了备份时点的状态。 restored数据与三千万张卡的卡内状态之间出现了大规模、持续性的偏差，重同步要一个终端一个终端地对账，而故障期间网络自身的处理能力又是残血的。
第二，终端不会无限重试。 手机发起注册被拒后，会按照协议和厂家策略进入退避状态——等一段时间再试，或者干脆要求用户干预。数千万部终端的退避节奏各不相同，冲击不是一次性的，而是持续数小时的波次冲击，网络刚缓过来一口气，下一波注册请求又压上来。这和后来2022年KDDI故障中“恢复即风暴”的现象如出一辙：把网修好只是上半场，让几千万终端有序地回来是下半场。
第三，VoLTE的链路更长。 3G时代语音走电路域，注册路径相对短；VoLTE终端要完成EPC附着、IMS注册两级认证，任何一环卡住，电话就打不出去。恢复期间“数据通了一部分、语音还不行”的割裂状态，让用户感知比实际恢复进度更糟。
用一张表对比两类终端在这次故障中的表现（综合委员会报告结论与媒体报道）：
| 对比项 | 3G终端 | VoLTE终端 |
|---|---|---|
| 注册链路 | 电路域注册，路径短 | EPC附着+IMS注册，路径长 |
| 认证失败的连锁反应 | 相对可控 | 任一环失败则语音全断 |
| 恢复方式 | 多数自动重试即恢复 | 大量需重启终端，部分反复多次 |
| 恢复节奏 | 7日起陆续恢复 | 拖至8日凌晨才基本收尾 |
这里有一个值得所有核心网工程师记住的推论：用户数据库的“备份恢复”不等于“业务恢复”。传统数据库灾备演练关注的是RPO（能丢多少数据）和RTO（多久能恢复服务），但SQN这类只增不减的计数器提出了第三种要求——恢复出的数据必须与全网终端侧状态“对得上账”。账本回拨几小时，代价是三千万终端逐个重新对账。
复盘处置过程，软银的排障路径大致是：隔离故障设备、尝试备用系统、失败后恢复备份数据、发现终端认证失败、定位到序列号错位、在网络上实施针对性对策、最后分波引导终端回归。每一步在技术上都有理由，但串起来就是39个小时。慢，慢在三个地方。
慢在故障定性。 硬件坏了换硬件，这是运维的本能反应。真正的难关在于识别出“修好设备之后网还是不通”，并把原因归结到认证层面。从硬件故障到认证错位，中间隔着“数据恢复”这个看似无害的动作——排障者面对的是两层故障的叠加，第二层还是第一层的“修复动作”引入的。这类“医源性损伤”在重大事故里格外常见，也格外难缠。
慢在恢复的物理规模。 对三千万用户的数据逐段校验、修正，再让数千万终端分波重新注册，每一步都是亿级操作。软银在恢复期间采取了网络侧的针对性调整来放开认证失败终端的重试，并通过短信和官网呼吁用户重启手机——短信为什么管用？重启会强制终端走一遍完整的附着流程，以全新的认证对话重新对账，绕开了故障期间终端内部已经积累的异常状态。
慢在次生受害者。 约46万光电话用户的存在提醒我们：核心网故障的影响面从来不由“故障设备”决定，而由“谁挂在这张核心网上”决定。固话、物联网、企业专线、对其他运营商的互联互通——故障边界要按业务拓扑画，不能按设备清单画。
处置层面还有一个隐性课题：对公众的沟通。故障发生于午后，总务省当晚即要求说明，此后每天的开发布会、官方推特更新成为用户获取恢复进度的主要渠道。对持续数十小时的故障，与其给出“很快恢复”的乐观预期然后反复跳票，不如给出明确的分阶段恢复口径——这是这次事故中软银做得相对及格的一环。
量化这次事故的影响，大致是四笔账。
用户账：约3086万移动用户业务中断，平均中断时长以十小时计；约46万固话用户连带断话；从其他网络拨打软银号码的呼叫同样失败，实际波及人群远超软银自身用户数。
社会账：紧急呼叫受阻是最重的一条。据日媒报道，部分110、119呼叫无法接通，官方在后续问责中对此重点关注。此外，企业客服、物流配送、自动售货机、快递柜等依赖移动网的民生与商业设施大面积停摆——这发生在12月上旬，正值日本年末商务与物流高峰。
监管账：总务省依据电气通信事业法的相关规定介入，要求提交事故报告，并在中期报告公布时提出行政指导。第三方委员会（外部专家参与的独立调查体）先后发布中期与最终报告，把问题归纳为设备冗余与数据管理机制的缺陷，要求落实再发防止对策。日本由此掀起一轮运营商自查：NTT docomo、KDDI均被要求检视同类风险——两年后KDDI发生更大规模的通信故障时，这份教训清单被再次翻了出来。
企业账：据日媒报道，软银向受影响用户发放了500日元优惠券作为补偿，并承担了品牌与商誉损失——故障发生在软银上市关键期前后，资本市场对此给出了直接反应。对运营商而言，一次全国性故障的显性成本是赔偿，隐性成本是此后数年监管强度与舆情审视的抬升。
最后把这次事故压成六条可以带走的清单，按价值排序：
1. 灾备演练必须包含“数据一致性”科目。 恢复出的用户数据，要能回答“与全网终端侧状态是否对账”这个问题。凡涉及单调计数器、密钥序号、防重放状态的数据恢复，都要单独设计校验与修复预案。RPO/RTO之外，建议再立一个指标：恢复后首小时的认证成功率。
2. 冗余切换要按真实故障演练，不要只做计划性倒换。 在维护窗口、低负荷、工程师围观的条件下切一次备用，证明不了故障时刻它接得住。至少要定期做带业务负荷的强制倒换，并验证“现用故障瞬间”的接管路径。
3. 警惕“修复动作”引入的第二层故障。 硬件故障后的数据回写、参数重载、批量放号，每一个修复动作本身都是一次变更。重大故障处置时，对修复动作要执行与割接同级别的评审——这次事故里，正是“恢复数据”这个动作把39小时写进了剧本。
4. 不要对终端行为做理想假设。 数千万终端的退避策略、重试节奏、对失败原因码的处理各不相同，恢复期必须设计分波放号与限流，把“终端回归”当成一场有指挥的潮汐来管理，而不是等它自然收敛。
5. 故障边界按业务拓扑画。 盘点哪些业务挂在同一张核心网上——固话、物联网、专线、互联路由——提前想清楚“这张核心网瘫痪时，账单上还有谁”。光电话断话这件事，本可以在风险清单上被提前看见。
6. 紧急呼叫保障要有独立预案。 全国性故障时110/119的可达性是监管与社会舆论的第一焦点，网内网间的紧急呼叫路由、故障期间的替代接入通道，都应在预案里落到具体设备和参数，而不是停留在“高优先级”四个字上。
回看这起事故，最令人感慨的是它的“平凡”：一次例行的设备更换、一套按设计执行的备份恢复、一群按标准协议拒绝可疑认证的SIM卡——每个环节单看都没有做错，连起来却是三千万人的39小时。通信网络的可靠性从来不取决于最强的那一环，而取决于最意外的那条链路。你的SIM卡里，此刻正躺着一个这样的计数器，安静地数着每一次认证。愿它永远不需要证明自己存在的意义。
本文由「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 等场景全覆盖。