2024年起，核心网上云从概念变成工程：西班牙电信德国公司与诺基亚合作，把存量5G核心网迁上AWS，首阶段迁移100万用户；而在日本，乐天移动2020年开网第一天就把整张网架在Kubernetes上。核心网从专用黑盒设备变成云上负载之后，运维最核心的动作——割接升级——正在被重写：从“凌晨停机、一夜全换”，变成“实例级灰度、分钟级回退”。本文结合公开案例与一线割接经验，讲清两代割接的本质区别、灰度升级的落地步骤、回退预案怎么写才不是废纸，以及乐天两次断网换来的教训。
传统核心网割接是一场仪式感极强的集体行动。提前三周提交割接申请，附上组网图、步骤表、回退预案；变更评审会上，无线、传输、IT各部门挨个签字画押；割接当晚，机房里坐着运营商现场组、厂商工程师、监理三方，网管后台还挂着远程接入的TAC支持席位。凌晨零点，先停业务——或者降级承压；第一步永远是备份，配置文件拷两份存进两台笔记本；然后加载版本包、重启进程、主备倒换，任何一个步骤卡壳，剩下的时间就开始倒扣。凌晨四点是死线：业务必须恢复，拨测必须通过。
这套流程的要害在于：网元是黑盒。HLR、MME里的用户数据和会话状态锁死在设备内部，想只升级一半？做不到。所以只能整停、整换、整回退。回退预案往往写在方案最后一页，却是最难执行的段落——窗口过半才发现问题，回退本身也要四十分钟，很多人选择硬着头皮往前走。2022年7月KDDI那场拖了86个小时的全国断网，起点就是一次语音交换设备的更换作业；2021年9月乐天移动的大范围故障同样出在维护作业的高压地带，日本总务省事后对两家都动了行政指导。行业里流传一句老话：割接失败不可怕，可怕的是回退预案是纸糊的。
5G SA核心网天生是云原生的：AMF、SMF、UPF是一组组微服务，跑在Kubernetes集群的容器里；用户签约数据外置在UDM/UDR，会话状态有UDSF兜底。SBA服务化架构下，网元之间是HTTP/2服务调用，“网元”这个概念本身已经被拆散成一个个可独立升级的服务实例。
这改变了升级的物理含义。过去升级单位是“一套网元”——整机重启、全网让路；现在升级单位是“一个容器实例”——控制器滚动替换Pod，旧实例先摘流量、停进程，新版本起来、通过就绪探针、重新接入流量，全程业务基本无感。版本共存成了常态：新旧两版AMF在同一张网里并行跑上几天，是云原生核心网的日常，而不是事故。
乐天移动官方对自家网络架构的描述很有代表性：网络全面虚拟化、云原生化，5G能力的引入“本质上只需要更新核心网和无线接入网的软件”（见乐天移动官网技术页）。2020年开网时，它是全球第一家从第一天起就把整张移动网架在Kubernetes容器栈上的运营商——据Fierce Network 2026年1月的报道，其网络完全托管在容器化软件栈上，连海量移动数据都放在对象存储上管理。
大运营商走的是另一条路：存量迁移。据telecoms.com报道，西班牙电信德国公司2024年与诺基亚签署里程碑式协议，将5G核心网迁往AWS，首阶段迁移100万用户，是大型运营商最早的存量（brownfield）云化5G核心案例之一；2025年MWC期间，西班牙电信又联合AWS、诺基亚打通了欧洲首个混合云5G SA呼叫——DU跑在马德里总部的EC2（Graviton ARM芯片）上，CU跑在AWS阿拉贡区域的数据中心。2026年5月，沃达丰宣布与诺基亚、AWS完成试验，把IMS语音和物联网核心应用跑上了AWS公有云（见沃达丰官网新闻稿）。方向已经清楚：核心网上云不再是PPT，是排期表。
三家代表性玩家，三条路径：
| 运营商 | 路径 | 关键事实 |
|---|---|---|
| 乐天移动（日本） | 全新建网，全栈容器化 | 2020年开网，核心网与RAN全面跑在K8s上，升级靠更新软件 |
| 西班牙电信德国 | 存量迁移（brownfield） | 2024年起与诺基亚合作迁上AWS，首阶段100万用户 |
| 沃达丰+诺基亚 | 公有云试点 | 2026年5月宣布IMS语音与物联网核心应用AWS试验完成 |
但别忘了另一半故事。乐天的云原生网络不是没出过事，而且出事的方式颇有“新时代”的意味。
2021年9月底，乐天移动发生大范围通信故障，大量用户长时间无法正常拨入电话。日本总务省将其认定为《电气通信事业法》意义上的“重大事故”，并于当年12月下达行政指导（据Communications Today转引共同社报道）；直到12月24日内阁会议后的记者会上，总务大臣仍在追问整改进度——乐天报告称，iPhone用户的来电故障拖到2021年底才基本解决。一年后剧本重演：2022年9月4日（周日），乐天再次发生全网性系统故障，约两个半小时后才恢复（见路透社报道），总务省12月9日对其发出严厉警告和书面行政指导，白纸黑字要求防止类似事故重演（总务省新闻稿）。
这说明了什么？云原生解决了“怎么快”，没有自动解决“快得对不对”。容器化把发布速度提升一个数量级，也把流程纪律的短板同步放大一个数量级。快速建网、快速迭代是乐天的护城河，但“全云原生”的成色到底几何，业内也并非没有疑问——STL Partners的拆解文章标题就把这个问号摆在了台面上。对一线割接老手来说，这个案例的教训非常朴素：工具越快，闸门越要结实。变更评审、灰度比例、回退触发线这些“慢动作”，恰恰是快工具时代最不能省的环节。
云原生核心网的升级配方，行内已经跑出了相对固定的套路，核心思想一句话：把“一夜全换”拆成“分批换血”，每一批都有独立的观察窗和刹车线。
流量怎么切？行内常见的手法有几类：按网元池权重——新版本实例先放进AMF资源池，服务发现按权重少分流量；按地域——新版本先上一个小城市的UPF；按用户维度——测试号段或企业专线用户先行。无论哪种，第一梯队规模控制在1%上下，观察窗30到60分钟，盯住四个硬指标：注册成功率、PDU会话建立成功率、VoNR接通率、切换成功率，全部与升级前基线自动比对，偏离超阈值直接触发回滚。两代割接的差别，一张表说清：
| 维度 | 传统网元割接 | 云原生灰度升级 |
|---|---|---|
| 升级单位 | 整套网元，整机重启 | 单个容器实例 |
| 停机窗口 | 凌晨0点—4点，业务中断或降级 | 无需窗口，滚动替换 |
| 影响范围 | 全网或整大区用户 | 1%—5%灰度用户 |
| 回退方式 | 回退版本包加重启，30—60分钟 | 镜像标签回滚，分钟级 |
| 验证手段 | 人工拨测加告警巡查 | KPI自动基线比对加拨测机器人 |
| 版本共存 | 不存在，一夜全换 | 新旧版本并存数天 |
| 主要风险 | 割接失败拖长停机 | 探针误判、版本兼容、配置漂移 |
但云原生也带来几个新坑，每个都值得单独立卡防范。
一是探针误判。就绪探针只证明进程活着，不证明业务逻辑对——版本里一个字段的编解码错误，探针全绿，用户全挂。所以拨测机器人不能撤，要用真实终端按小时打一轮注册、呼叫、上传。
二是信令风暴。滚动更新如果限速没配好，几百个实例同时重启，同一时刻扑向UDM取签约数据，等于自己对自己发起洪水。重启节奏必须错峰限速——这和老时代“重启网元要一台一台来”是同一个道理，只是对象从板卡变成了Pod。
三是双版本兼容。新旧版本并存的每一天，SBA接口必须向后兼容，这是铁律，谁破坏谁全网翻车。共存期拉得越长，兼容性测试矩阵越大，所以共存期要设上限，不能无限期“暂存”。
四是配置漂移。灰度升级最怕的不是版本，是有人顺手在生产环境手改了一个参数。声明式配置加GitOps是正解：集群状态全部由代码库定义，任何手改都会被自动纠正并告警——配置的“唯一真相”只允许存在一份。
整套动作走下来，长这样：
flowchart TD
A["升级申请与评审"] --> B["预生产环境验证"]
B --> C{"预验通过？"}
C -->|否| D["退回研发修复"]
D --> B
C -->|是| E["备份：镜像/配置/数据"]
E --> F["灰度1%实例"]
F --> G["观察窗30分钟"]
G --> H{"KPI达标？"}
H -->|否| I["自动回滚镜像"]
I --> J["复盘归档"]
H -->|是| K["扩到25%"]
K --> L{"KPI达标？"}
L -->|否| I
L -->|是| M["扩到100%"]
M --> N["撤旧版本<br/>保留24小时"]
N --> O["变更关闭"]
传统割接的回退预案经常是纸糊的，云原生把回退做成了真功夫，但前提是功课做在前面。
第一，快照要全。升级前快照四件套：容器镜像版本清单、Helm values全量参数、配置库导出、数据库备份。镜像回滚是分钟级的，但数据和配置的回滚做不到分钟级——所以状态数据必须外置到UDR/UDSF，绝不能锁死在实例内部，这是回退速度的物理前提。
第二，触发线要量化。给一组一线经验参考值：注册成功率跌破基线0.5个百分点且持续5分钟、VoNR接通率跌破99%、拨测机器人连续两轮失败——满足任一条，自动回滚，不等人工决策。凌晨三点的电话会议做不出好决策，这是无数个通宵换来的共识。
第三，回退要演练。每季度拿预生产环境真刀真枪滚一遍回滚流程。没演练过的回退预案，等于没有预案——这句话在云原生时代同样成立，甚至更成立，因为回滚按钮越自动化，平时越容易忘了它到底能不能按下去。
第四，冻结期照旧。灰度不是免死金牌：月末出账日、重大节假日保障期，变更窗口照样关闭。2022年9月乐天那次故障发生在周日下午，业务全开的状态下系统照样瘫了两个半小时——日期和时机从来不是技术问题的遮羞布，该守的闸门一个都不能少。
从程控交换机到Kubernetes，割接这门手艺的内核没变过：备份、分批、可观察、可回退。变的是工具链——过去靠MML命令行和两部对讲机，现在靠CI/CD流水线、声明式配置和KPI自动基线。乐天用两张行政指导书换来的教训、西班牙电信用100万用户趟出来的路，说的其实是同一件事：核心网上云之后，割接单确实要重写，但重写的只是格式，敬畏之心一行都不能删。
本文由「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 等场景全覆盖。