2022年7月2日凌晨1点35分，日本运营商KDDI在给全国传送网一台路由器做例行维护时，写错了一行路由配置。位置更新信令被丢弃，几千万台终端的重发定时器同时被点燃，信令风暴经全国传送网层层放大，au网络瘫痪61小时25分钟，涉及用户超3091万。本文以KDDI官方事后报告与总务省报送材料为主线，完整拆解这次割接作业从失控到恢复的全过程，并给出从T-7天到T+1天的割接剧本与回滚红线设计——回答一个问题：一行配置为什么能挂掉一张全国网，以及怎样让下一次割接不再赌运气。
先对齐一个词。本文说的“割接”，泛指一切在运行网络上实施的变更作业：核心网软件升级、承载网路由调整、HLR/HSS搬迁、板卡更换、参数批量下发。共同特征只有一个——手术对象是一张正在承载用户的活网。
割接选在凌晨，是全行业用几十年事故换来的共识。理由有三层：第一，凌晨是话务低谷，低谷时段的话务量常常不足忙时的一半（具体比例因网而异），同样一次误操作，忙时炸出来的影响面可能是凌晨的十倍；第二，凌晨开工天然自带一整夜的处置余量，万一翻车，还有几个小时可以抢救，早高峰是挂在墙上的死线；第三，凌晨变更对用户感知的扰动最小，投诉热线不容易被打爆。
但低谷窗口不是护身符。凌晨的另一面是：观测手段薄，值守人力少，设备商后台支持响应慢，出了事往往就是几个人对着一张大屏硬扛。KDDI那次作业选的就是教科书级窗口——周六凌晨1点半，一周话务最低的时段之一。窗口选择没有任何问题，出问题的是窗口里的每一步预案。
先把官方口径的时间线摆出来，数据来自KDDI官网事故专页及其向日本总务省报送的材料：
| 时间（日本标准时） | 事件 |
|---|---|
| 7月2日 01:35 | 多摩站点全国传送网路由器维护作业中路由配置写错，位置更新信令被丢弃，故障开始 |
| 7月2日 凌晨起 | 终端重发风暴形成，多摩VoLTE节点过载，并经全国传送网向其他站点扩散 |
| 7月2日 03:00至下午 | 据事后披露的处置时间线，先后在无线侧与核心网侧实施限流 |
| 7月2日（确切时点官方未披露） | 限流未见效，将全国18台VoLTE节点中的6台从网隔离 |
| 7月3日 | 社长高桥诚出面召开记者会致歉（据读卖新闻报道） |
| 7月4日 15:00 | 话务恢复至前一周同期水平，故障结束 |
| 合计 | 61小时25分钟，全国范围 |
再看根因链条，KDDI官方专页交代得很诚实，可以逐环拆开：
第一步，维护作业对象是全国传送网在多摩的路由器，作业中路由配置写错。直接后果是：经过该路由器的位置更新类注册信令被丢弃——注意，不是被拒绝，是被黑洞掉。
这个区别是整个事故的引信。被拒绝的信令，终端拿到明确答复就安静了；被丢弃的信令，终端什么都收不到，NAS层的重发定时器到点就重发，重发还是黑洞，再重发。几百万台手机在同一时刻进入“我必须注册上网”的执念状态。
第二步，多摩的VoLTE节点先被信令洪峰压垮。而KDDI核心网节点之间通过全国传送网做分布式处理、互为备份——这套高可用设计在平时是优点，此刻成了放大器：多摩消化不了的洪峰顺着承载网灌向其他站点，把全国18台VoLTE节点一个接一个拖下水。
第三步，VoLTE节点和PGW每处理一次请求都要到签约数据库做认证查询，重发让查库次数成倍上涨，签约DB成为第二个饱和点。数据库一慢，响应更慢，终端重发更凶，正反馈闭环。
第四步，KDDI先上limiter限流，压不住——因为重发源头是几千万台终端，网内限流挡不住终端里的定时器。最后的手法相当粗暴：把全国18台VoLTE节点中的6台直接从网断开，让这部分区域的终端彻底收不到任何响应、重发源消失，签约DB的压力才真正回落。
影响面，官方口径：语音（VoLTE）约2278万人、数据（4G/5G）765万人以上，KDDI单体统计；合并报送总务省的口径为3091万以上用户。au、UQ mobile、povo全线波及。企业侧的连带伤害清单很有时代感：物流的配送状态回传、车联网服务、水表数据采集、银行ATM、机场无线对讲、公交IC卡——这就是一张移动网瘫痪的散射半径。
flowchart TD
A["多摩传送网路由器维护"] --> B["路由配置写错"]
B --> C["位置更新信令被丢弃"]
C -->|终端收不到响应| D["定时器到点重发"]
D --> E["多摩VoLTE节点过载"]
E --> F["经全国传送网扩散"]
F --> G["各站点VoLTE节点过载"]
G --> H["认证查库请求暴涨"]
H --> I["签约数据库过载"]
I --> J["网内限流无效"]
J --> K["隔离6台VoLTE节点"]
K --> L["重发源消失，压力回落"]
KDDI在给总务省的材料里，把原因剥成了三层。这个分法本身就值得抄进每本运维手册，因为它对应的不是三个技术缺陷，而是三种组织能力的缺失。
第一层：作业层。路由配置写错是表象，KDDI的自评是“作业准备不足——管理规则、确认项、审批方式都有缺口”。翻译成一线语言：这一行配置没有第二双眼睛复核，没有逐条核对清单，没有作业前的推演。割接作业里最危险的从来不是复杂操作，而是“随手一改”的简单操作——简单意味着没人觉得需要设防。
第二层：放大层。KDDI承认，对不规则网络状态下拥塞控制的考虑不充分。这句话信息量极大。常规拥塞预案是为“可预测的高峰”设计的：跨年、演唱会、灾难避险通话——请求多，但路径是通的，扩容、限流、排队都能起作用。而路由黑洞是另一种物种：信令不是在排队，是在消失。对付排队可以削峰，对付消失只能靠终端退避。预案库里没有这一页，等于在凌晨两点面对一个预案手册之外的故障。
第三层：恢复层。KDDI原话大意是：从未建立从复杂拥塞状态恢复的作业程序。于是恢复动作只能边做边发明，而现场发明的动作常常互相打架——重新接入的节点带来流量的再集中，二次拥塞又把前面压下去的信令重新顶起来。恢复一路拖到周一15:00。61小时里，真正花在“闯祸”上的只有凌晨那几个小时，剩下的大部分时间，都花在“怎么收场”上。
这是整起事故里最贵的一课：恢复是被设计出来的，不是被现场发明出来的。
把KDDI的学费代进去，一套完整的割接剧本长什么样？下表是从方案评审到复盘归档的最小完整流程：
| 阶段 | 关键动作 | 放行判据（Go/No-Go） |
|---|---|---|
| T-7天 | 方案评审：影响面分析、爆炸半径推演、回滚方案、干系人通报 | 评审签字，回滚步骤能在纸面完整走通 |
| T-1天 | 配置与信令路由全量备份；预检时钟、license、容量、告警基线；冻结期内禁止叠加其他变更 | 预检全绿，回滚点验证可用 |
| T0 作业中 | 分段实施，单点灰度先行，每一步做完立即拨测验证再放大 | 每步退出判据逐条核对，不跳步 |
| T+观察窗 | 盯注册成功率、接通率、位置更新成功率、DB负荷与信令重发率 | 任何一项跌破事先写死的红线，立即回滚 |
| T+1天 | 复盘归档，预案库更新，解除变更冻结 | 复盘记录入库，整改项有责任人与期限 |
这张表里最值钱的是最后一列。所谓回滚红线，就是数值化的Go/No-Go判据：注册成功率低于多少、持续多久、信令重发率超过多少，必须回滚——阈值具体取值各网不同，但共同要求是：在评审会上定死，写进方案，作业现场只执行、不讨论。
为什么必须事先写死？因为回滚永远要与“再修一下”的诱惑对抗。故障现场的心理曲线是可以预测的：刚翻车时没人愿意承认失败，总觉得自己离修复只差一步。KDDI用61小时证明，临场发明恢复方案的代价，远大于提前回滚的“丢脸”。回滚是预案，不是失败——这句话要刻在每个割接总负责人的脑子里。
flowchart TD
A["T-7天：方案评审"] --> B["T-1天：备份与预检"]
B --> C{"预检全绿"}
C -->|否| D["冻结变更另择窗口"]
C -->|是| E["T0：分段实施"]
E --> F["单点灰度先行"]
F --> G["逐段放量观察"]
G --> H{"KPI达标"}
H -->|否| I["触发回滚红线"]
H -->|是| G
I --> J["回退至备份点"]
J --> K["T+1天复盘归档"]
割接夜最脆的地方不是转发面，是控制面。原因在信令的天性：终端发出的注册、鉴权类请求，天然自带重发机制——终端无法确认网络是否收到，只能靠定时器兜底。这个机制在正常网络里是可靠性保障，一旦网络侧“沉默”（丢包、黑洞、无响应），它瞬间变成正反馈引擎：定时器驱动全体终端齐步走，重发成倍放大，直到把响应能力剩余不多的网元彻底淹没。
3GPP其实早给过工具箱。NAS层有退避定时器：网络在拒绝或释放消息中可以下发退避值（如EPC与5GC通用的T3346，见TS 24.301与TS 24.501），终端收到后在定时器超时前不得再发起同类请求——把“齐步走”打散成“错峰走”。空口侧，NR引入了统一接入控制UAC（TS 38.331），按接入类别配置概率性禁止，从源头削峰。核心网侧，网元之间可对过载方向的查询请求做节流，优先保住数据库这个最深的瓶颈。这些都写进了标准，各设备商的具体实现方式以官方文档为准。
但工具箱有一个前提，恰好被KDDI案例精准击穿：信令必须先“能到”网络侧，才能被网络管理。退避指令也好、准入禁止也好，都得由某个网元告诉终端。路由黑洞场景下，被丢弃的信令永远到不了那个能对它说“退避”的网元——终端只知道自己被沉默，于是按协议最大努力重发。这就是KDDI限流失效的理论解释，也是为什么最后只能物理断开6台节点：对失控的重发源，唯一有效的管理是让它消失。
对一线的实际推论有两条。第一，割接后的观察窗口里，首要指标不是话务量，而是位置更新成功率、信令重发率这类“网络有没有在沉默”的指标——它们比话务曲线早几个小时报警。第二，拥塞控制参数要按最坏状态设计：常规扩容预案对齐“可预测的高峰”，割接预案必须对齐“不可预测的畸形状态”——黑洞、环路、单点放大。两套阈值不该共用一套参数。
传统核心网的割接是“整网换版本”：深夜窗口、全停或半停、小时级的回滚。5GC云原生化之后，这门手艺正在换代。SBA架构把控制面拆成微服务，无状态的计算层与数据层分离（如UDM与UDR分离部署），升级粒度从“整网”缩到“逐pod、逐站点”：滚动升级让新旧版本短时共存，金丝雀实例先吃流量，蓝绿切换保留瞬时回退能力。ETSI NFV的MANO框架对VNF软件升级流程也有标准化描述；标准允许多种实现，具体行为以各厂家官方文档为准。效果是实打实的：回滚动作从“整网回退”变成“摘除新版本实例”，时间从小时级压到分钟级。
但别把换代误解为免死。KDDI案例里有一个细节值得所有云原生架构师记住：最先饱和的是签约数据库。控制面可以无状态、可以滚动、可以金丝雀，可签约数据是全局单点逻辑，是有状态的地基——18台VoLTE节点砍掉6台，保的正是它。无论架构怎么演进，数据层的迁移与扩容依然要按最传统的割接纪律来：备份、灰度、红线，一个都不能省。无状态化解决的是“升级时业务不中断”，从来不承诺“配错了也没事”。
变更前在孪生环境里把配置预推一遍，正在成为大网标配，这能把一部分“写错”拦在真网之前——但孪生网覆盖的是已知场景，预案深度的上限，永远取决于人对未知场景的想象力。KDDI缺的那一页预案，孪生网里同样不会有，除非有人先把它想出来。
把61小时压成五条，每条都对应这次事故里的一处伤口：
割接这门手艺的本质，是在一张正在运行的网上做手术。凌晨的窗口、写死的红线、逐条的核对清单，这些看起来笨的流程，是61小时替全行业交的学费。技术会从深夜割接演进到滚动升级，但“控制爆炸半径、敬畏信令风暴、把恢复设计成流程”这三件事，不会过时。
本文由「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 等场景全覆盖。