# 凌晨割核心网：5GC升级解剖 ## 概述 割接升级是电信运维手里的高危动作：干得好，用户无感；干砸了，就是登上新闻头条的全网故障。本文以一次典型的5G核心网AMF池滚动升级为主线，拆解从T-14天预检、凌晨冻结、半池灰度、门限观察、回退决策到出窗后72小时观察的完整流程，用3GPP TS 23.501/23.502定义的池化与上下文迁移机制说明“用户无感”的技术原理，并用谷歌SRE的变更故障统计与Cloudflare 2020年7月27分钟全球故障的官方复盘，回答一个核心问题：为什么绝大多数重大故障都源于变更，以及割接纪律如何把这件事的风险摁到最低。 ## 目录 - 一、变更，是运维手里最锋利的刀 - 二、T-14天到T-0：仗在割接前就打完了 - 三、五小时时间线：从冻结到出窗 - 四、用户为什么无感：三个技术支柱 - 五、最难的一步：按下回退 - 六、出窗之后的72小时 - 七、结语 ## 一、变更，是运维手里最锋利的刀 谷歌SRE（站点可靠性工程）团队在《SRE》一书“复盘文化”章节里给出过一个常被引用的内部统计：**大约70%的故障源于对在线系统的变更**。这不是互联网行业独有的现象——Uptime Institute历年发布的《年度故障分析》反复指向同一个结论：相当比例的宕机事故背后都有变更操作或人为因素的影子。 电信行业的应对方式是把变更关进“割接窗口”的笼子里：只在话务低谷的深夜操作、提前N天报变更单、跨部门电话会评审、出窗前必须恢复业务验证。这套纪律看起来繁琐，是几代运维用事故换来的。做了十几年核心网，我的体会是：割接方案评审会上吵得越凶，割接当夜反而越平静；会上全场点头、无人质疑的方案，才最让人心里发毛。 5G核心网（5GC）全面云化之后，割接这件事发生了本质变化： | 维度 | 传统EPC/软交换割接 | 云化5GC割接 | |---|---|---| | 最小操作单元 | 板卡/整机框 | 容器/Pod实例 | | 升级方式 | 停机换版，主备倒换 | 滚动升级，逐个替换 | | 灰度粒度 | 池级或局级 | 节点级（一次一个或一批Pod） | | 用户影响 | 倒换瞬间有闪断风险 | 设计目标为零感知 | | 回退手段 | 换回旧板、回导配置 | 回滚镜像+数据兼容回退 | | 典型窗口 | 数小时到通宵 | 半池观察后数小时完成 | 变化很大，但不变的是那句老话：**割接的风险不在升级动作本身，而在你没预演过的那条路径上**。Cloudflare的案例（见第四节）证明，连全球最大的边缘网络也会栽在“部署流程本身的bug”上。 ## 二、T-14天到T-0：仗在割接前就打完了 一次规范的5GC割接，从变更单提交到正式出窗，周期通常是两周。这两周里做的事，按时间排开： | 时间点 | 动作 | 要害 | |---|---|---| | T-14天 | 变更单提交，附升级方案、影响面分析 | 影响面要写到"哪些地市的哪些用户、多少话务" | | T-10天 | 跨部门评审会：无线、传输、IT、客服、市场全部到场 | 客服要提前备好话术，市场要确认无重大营销活动 | | T-7天 | 兼容矩阵核对：新旧版本NF间的接口兼容性、license容量、虚拟化平台版本 | 版本兼容矩阵错一行，当夜就是事故 | | T-5天 | 备份三件套：NF配置、数据库全量+增量、虚拟机快照 | 备份做了不等于备份能用 | | T-3天 | 回退演练：在容灾环境把回退脚本真实跑一遍并计时 | 回退超窗是割接最常见的翻车方式 | | T-1天 | 全要素预检：资源余量、告警清零、话务基线截图 | 基线不提前留，当夜没有对照物 | | T-0 凌晨 | 冻结窗口内执行 | — | 三条经验值得单独说。 **第一，备份要演练恢复，不能只演练备份。** 数据库全备文件躺在存储里，不等于它能恢复出来。回退演练的核心是“计时”：如果回退需要150分钟，而你的窗口只剩90分钟，这个方案在纸面上就该被否掉。 **第二，警惕数据不可逆。** 5GC的NF升级经常伴随数据库schema变更。一旦新版本对用户面上下文、会话数据做了结构迁移，回退到旧版本就可能读不回去。负责任的升级方案会在设计上要求新版本对旧schema保持一个版本的兼容期，或者采用双写过渡。这一点标准并不强制，各厂家实现思路不同，具体行为以所购版本的官方升级文档为准——割接评审时必须把这个问题当面问穿：**“回退时数据怎么办？”**答不上来的方案不能过会。 **第三，灰度方案要在纸面上推演到Pod级。** 一个AMF池里有几十个实例，升多少、怎么分组、组间观察多久、每组的流量权重怎么调，都要写进方案，而不是当夜现场发挥。 ## 三、五小时时间线：从冻结到出窗 以一次典型的AMF池滚动升级为例（下列时间为示例值，各局实际情况随规模不同），当夜的节奏大致是： ```mermaid flowchart TD A["割接开始"] --> B["冻结变更窗口"] B --> C["全量备份"] C --> D{"备份校验通过"} D -->|否| E["终止割接"] D -->|是| F["升级半池节点"] F --> G["观察30分钟"] G --> H{"KPI过门限"} H -->|否| I["执行回退"] H -->|是| J["升级剩余节点"] J --> K["全量拨测"] K --> L["出窗持续观察"] I --> M["复盘归因归档"] E --> M ``` 对应的观察指标与回退门限，一般在方案里白纸黑字写死（下表为示例基线，实际以本局7天历史基线为准）： | 观察指标 | 示例告警线 | 示例回退评估线 | 为什么看它 | |---|---|---|---| | AMF注册成功率 | 较基线劣化0.2个百分点 | 劣化0.5个百分点且持续10分钟 | 终端能否附上网络的门槛 | | PDU会话建立成功率 | 劣化0.2个百分点 | 劣化0.5个百分点且持续10分钟 | 用户"有信号没数据"的直接来源 | | N2接口建立/丢包 | 出现非计划闪断 | 同一对偶连闪断≥3次 | 新旧版本实例间信令互通是否正常 | | 寻呼成功率 | 劣化0.3个百分点 | 劣化0.5个百分点 | 上下文迁移是否完整 | | NF实例CPU/内存 | 持续高于85% | OOM或实例重启 | 新版本资源画像是否与容量规划一致 | | 端到端拨测 | 任一项失败 | 拨测失败率>1% | 最后一步：KPI好看不等于用户真能用 | 几个当夜才有的细节，方案里写不出来，只有站过凌晨机房的的人才懂： - **凌晨两点的话务低谷是你的朋友，但别迷信它。** 低谷期注册量只有白天峰值的两三成，可一旦你们省有大规模物联网卡在夜里跑心跳，注册量曲线会突然抬头。预检时看清楚月末/周末物联网话务特征。 - **观察期不是等待，是盯曲线。** 半池升级完的30分钟里，眼睛要盯在注册成功率的分钟级曲线上，同时开着信令监测回放，随机抽新版本实例上的注册流程逐条看：N2建立、鉴权、安全模式、注册完成，一步都不能缺。 - **电话会保持静默是对的。** 割接当夜的跨专业电话会，规矩是没事不说话。谁在观察期里开口汇报一条正常指标，反而说明他在紧张——正常的曲线不需要汇报。 ## 四、用户为什么无感：三个技术支柱 滚动升级敢在话务低谷“带电作业”，靠的不是胆子，是3GPP和云原生两套机制叠出来的冗余。 **支柱一：池化与容量权重。** 5GC的AMF天然以资源池方式组网，多个AMF对外呈现为一组GUAMI。(R)AN为终端选择AMF时，会考虑各AMF的容量权重（weight factor）——这正是TS 23.501中定义的AMF选择机制的一部分。割接时把待升级实例的权重调低甚至归零，新进流量自然流向池内其他实例，等于给升级中的节点“腾干捞湿”。 **支柱二：上下文迁移与重注册兜底。** 已经注册在待升级AMF上的用户怎么办？3GPP在TS 23.502中定义了完整的AMF间移动与上下文迁移流程：AMF重分配时，旧AMF把UE上下文交给新AMF，N2/N1信令随之切换。对于负载重平衡场景，TS 23.501还定义了AMF负载重平衡机制：AMF可以通知部分终端重新注册，把它们有序引导到池内其他AMF上。终端侧的兜底能力同样关键——即便上下文迁移失败，UE发现信令链路异常后会发起重注册，对用户来说就是多等一两秒信号条。**“无感”从来不是零切换，而是把切换藏进终端自愈能力里。** **支柱三：云原生的滚动升级。** 5GC的NF如今大多是CNF（云原生网络功能），Kubernetes的滚动升级参数直接决定割接平滑度：maxSurge控制“先多起几个新Pod再杀旧的”，maxUnavailable保证服务能力不打折，readinessProbe探针不通过的新Pod不会接入流量，PodDisruptionBudget约束驱逐时的最低可用副本数。这些参数本质上是把电信行业“N+1冗余”的老智慧翻译成了配置文件。 反过来看一个不守灰度纪律的代价。2020年7月17日，Cloudflare发生了一场持续27分钟的全球性故障，其官方复盘《Details of the Cloudflare outage on July 17, 2020》写得很坦诚：工程师部署防火墙规则功能的新配置时，其中一条含多重`.*`的正则在特定输入下触发超线性耗时，把边缘服务器CPU打满；更糟的是，部署工具中途出了bug自行停摆，坏配置已经铺到了约89%的边缘节点，全网处于新旧配置混杂的“半吊子”状态，既没有全部生效、也没能整体熔断，恢复只能靠人工逐点清理。复盘列出的整改里，最重要的几条全是流程而非技术：给全局配置部署加“熔断开关”，坏配置一旦露头可一秒全停；把部署批次切得更细；强化回滚。这个案例我常在割接评审会上讲，就为说明一句话——**灰度不是走形式，分批推进中每一批的“暂停点”必须真的能停**。Cloudflare的批次不是没有，坏就坏在批次间的异常处理和全局急停能力上。 ## 五、最难的一步：按下回退 割接当夜最难的决策不是升级，是回退。回退意味着：两小时白干、下周重新约窗口、复盘会上要解释。于是人会本能地想“再观察五分钟”——这是所有割接事故复盘里出现频率最高的心理陷阱：沉没成本压倒了门限纪律。 对策只有一条：**门限和决策权在会前就写死。** 方案里写明“指标触及回退评估线且持续N分钟，现场值班负责人有权直接下令回退，无需再上会请示”，并且把这个授权当着所有相关方的面确认过。回退不是失败，把回退拖成事故才是失败。凌晨四点回退，天亮前业务照常；熬到六点不忍心回退，早高峰一句“有信号上不了网”，性质就完全变了。 回退预案本身也要满足两个条件：一是真实演练过并计过时（见第二节）；二是回退后的验证路径完整——回退完同样要全量拨测，因为回退动作本身也是一次变更。 ## 六、出窗之后的72小时 出窗不等于结束。升级后72小时是隐形观察期： - **KPI天级回看。** 当夜的分钟级曲线正常，不代表没问题。注册成功率、掉线率、寻呼成功率要连续回看三天，和升级前的周基线对比。有些问题（比如某个边缘MLC/UPF池的话务迁移不均）要等话务高峰回来才显形。 - **投诉工单监控。** 升级后三天内，客服侧对涉及升级区域的网络类投诉打上标记。用户感知有时领先于网管KPI——个别厂商终端的兼容性问题上KPI根本看不见，只会在投诉里出现。 - **复盘沉淀。** 无论当夜顺不顺，一周内出复盘：实际耗时与计划的偏差、预检漏项、脚本报错、门限设定是否合理。复盘文档进变更知识库，下次割接的检查清单从这里面长出来。这就是谷歌SRE倡导的复盘文化的核心：**对事不对人，每一次割接都要让组织比上一次更熟练。** ## 七、结语 割接是运维工作的年度大考，考的从来不是当夜那五个小时，而是此前两周的推演、演练和把丑话说在前面的纪律。谷歌SRE那句“70%的故障源于变更”反过来读也是一把尺子：**变更做好了，就消灭了七成的故障**。5GC云化把滚动升级、池化冗余、上下文迁移这些漂亮机制交到我们手里，但Cloudflare用27分钟的全球故障提醒所有人：机制再好，流程纪律缺一块，照样翻车。 凌晨两点，机房里只剩风扇的声音，曲线稳稳地贴着基线走。那种平静，是提前十四天挣来的。 ## 参考来源 1. [Postmortem Culture: Learning from Failure — Google SRE Book](https://sre.google/sre-book/postmortem-culture/) — 谷歌SRE官方免费书籍，“约70%的故障源于对在线系统的变更”统计数据的出处 2. [Details of the Cloudflare outage on July 17, 2020 — Cloudflare Blog](https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-17-2020/) — Cloudflare官方复盘：27分钟全球故障的完整根因、89%边缘节点波及与部署流程整改 3. [3GPP TS 23.501: System architecture for the 5G System](https://www.3gpp.org/dynareport/23501.htm) — AMF池化、容量权重、负载重平衡等机制的标准定义 4. [3GPP TS 23.502: Procedures for the 5G System](https://www.3gpp.org/dynareport/23502.htm) — AMF间上下文迁移与重分配流程的标准定义 5. [Uptime Institute: Research and Reports](https://uptimeinstitute.com/resources/research-and-reports) — 历年《年度故障分析》报告，持续揭示变更与人为因素在宕机中的占比 --- > 本文由「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 等场景全覆盖。