你有没有想过，一个拥有几百万用户、几万基站的移动网络，日常运维是什么体验？
想象一座城市里有10000盏红绿灯，每盏都需要一个交通警察手动拨动开关。白天调时序、晚上查故障、刮风下雨还要紧急处理——这就是传统通信网络运维的真实写照。每台路由器、每个网元，都需要工程师一条一条敲CLI命令去配置。一个新业务上线，可能要协调几十个团队、改几百台设备，周期以"月"计算。
而今天，行业正在经历一场从"手动驾驶"到"自动驾驶"的革命。这场革命的核心，就是网络编排与自动化。
2G时代，一个基站就是一个基站，配置几个参数就能工作。但到了5G时代，事情完全不同了：
| 维度 | 2G/3G时代 | 4G时代 | 5G时代 |
|---|---|---|---|
| 网元类型 | 3-4种 | 6-8种 | 15+种（虚拟化+容器化） |
| 配置参数 | 几十个 | 几百个 | 几千个（含切片参数） |
| 业务类型 | 语音+短信 | 语音+数据 | eMBB/URLLC/mMTC三大场景 |
| 部署周期 | 数月 | 数周 | 按需实时 |
| 运维模式 | 人工CLI | 半自动脚本 | 意图驱动自动编排 |
一个5G核心网，可能包含AMF、SMF、UPF、PCF、UDM、NRF、NSSF、AUSF、NEF、AF等十几个网络功能，每个都需要独立配置，又要协同工作。如果全靠人工，出错率极高——据统计，超过60%的网络故障是人为配置错误导致的。
运营商的信息系统分为两大阵营：
图表 1
BSS（Business Support System） 面向客户和业务：你办理一个5G套餐，从选套餐、下订单、到出账单，都归BSS管。
OSS（Operations Support System） 面向网络和运维：基站宕了、网元挂了、流量异常了，OSS负责发现和处置。
传统的问题在于：
这就像一个公司有10个部门，每个部门只说自己的方言，互相听不懂，老板想传达一个指令，得分别找10个翻译。
2012年，ETSI（欧洲电信标准化协会）提出了一个划时代的概念——NFV（Network Functions Virtualization，网络功能虚拟化）。
核心思想非常简单：把原来跑在专用硬件上的网络功能，变成跑在通用服务器上的软件。
想象一下：以前你买一台专用防火墙设备，花50万，功能固定，扩容还得再买一台。现在，防火墙变成一个软件包，需要多少就启动多少实例，跑在普通的x86服务器上，像装App一样简单。
$$\text{网络功能成本} = \text{专用硬件成本} + \text{软件许可} + \text{运维成本}$$
NFV之后：
$$\text{网络功能成本} = \text{通用服务器分摊} + \text{软件许可} + \text{大幅降低的运维成本}$$
有了虚拟化能力，几百个VNF（虚拟网络功能）在数据中心里跑着，谁来管它们？谁来决定哪个VNF部署在哪台服务器上？谁来负责扩容缩容？故障了谁来重启？
这就是MANO（Management and Orchestration，管理与编排） 的职责——它是NFV体系的"总调度中心"。
图表 2
三个核心组件各司其职：
| 组件 | 全称 | 职责类比 |
|---|---|---|
| NFVO | NFV Orchestrator | 公司CEO——决定"做什么"，统筹全局资源 |
| VNFM | VNF Manager | 项目经理——管理每个VNF的一生（创建、运行、扩容、终止） |
| VIM | Virtual Infrastructure Manager | 后勤主管——管理服务器、存储、网络等底层资源 |
一个实际的工作流程：
整个过程全自动，从原来的数周缩短到分钟级。
VNF是虚拟机级别的虚拟化——每个VNF跑在一台虚拟机里。但虚拟机太"重"了，启动慢、资源开销大（一个虚拟机自身就要占1-2GB内存）。
于是行业转向了CNF（Cloud-Native Function，云原生网络功能）——用容器（Container）替代虚拟机。5G核心网中的AMF、SMF、UPF等，正在全面容器化。
| 维度 | VNF（虚拟机） | CNF（容器） |
|---|---|---|
| 启动时间 | 分钟级 | 秒级 |
| 资源占用 | 高（需完整OS） | 低（共享宿主OS） |
| 粒度 | 整个网元一个VM | 微服务拆分，每个进程一个容器 |
| 弹性伸缩 | 慢（需启动新VM） | 快（K8s HPA自动扩缩） |
| 管理工具 | OpenStack | Kubernetes |
传统的网络配置是命令式（Imperative）的——你告诉网络每一步怎么做：
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
interface GigabitEthernet0/0
ip address 10.0.1.1 255.255.255.0
no shutdown
你需要知道每台设备的型号、每个接口的名字、每个参数的取值。稍有差错，网络就可能瘫痪。
意图驱动网络（Intent-Driven Networking，IBN） 则是声明式（Declarative）的——你只告诉网络你想要什么结果：
"保障A分部到总部的视频会议延迟低于50ms，可用性99.99%。"
至于怎么配置路由策略、怎么选路径、怎么调QoS参数——编排器自动搞定。
图表 3
第1层——意图表达：这是面向用户的入口。可能是一个Web Portal上的表单，也可能是自然语言接口。TM Forum定义了标准化的Intent API，让意图可以跨厂商传递。
第2层——意图翻译：这是IBN的核心难点。把"视频会议延迟低于50ms"这个业务意图，翻译成： - 路由策略（选低延迟路径） - QoS策略（优先转发视频流量的包） - 资源预留（确保带宽充足） - 监控指标（设置50ms阈值的告警）
翻译过程依赖策略引擎和AI模型。策略引擎中预定义了大量规则，AI模型则通过历史数据学习最优策略。
第3层——自动执行：翻译出的配置方案通过SDN控制器下发到网络设备。南向接口从传统的CLI/SNMP，演进到了NETCONF/YANG（结构化配置）和gNMI/gRPC（流式遥测）。
第4层——持续保障：这是IBN区别于传统自动化的关键。传统自动化是"配完就完"，IBN是"配完还要持续盯"——通过实时遥测，持续验证网络行为是否符合意图声明，一旦发现偏差，自动触发修复。
闭环（Closed-Loop）是网络自动化的核心机制。它的工作原理可以用一个公式概括：
$$\text{Closed-Loop} = \text{Monitor} \rightarrow \text{Analyze} \rightarrow \text{Plan} \rightarrow \text{Execute} \rightarrow \text{Verify}$$
这就是著名的MAPE-K循环（Monitor-Analyze-Plan-Execute with Knowledge）。
图表 4
一个真实场景：某企业客户的5G专网突然出现视频卡顿。
整个过程从发现到修复，不超过2分钟，无需人工介入。传统方式下，这个故障可能要1-2小时才能定位和解决。
ONAP（Open Network Automation Platform，开放网络自动化平台） 是Linux基金会旗下的开源项目，由AT&T的ECOMP和中国移动的OPEN-O合并而来。它是目前电信行业最全面的自动化编排平台。
ONAP的目标是：提供一个统一的平台，实现网络服务的全生命周期自动化——从设计、创建、部署到监控、修复、优化。
ONAP的架构分为两大阶段：
| 阶段 | 功能 | 类比 |
|---|---|---|
| 设计时（Design-Time） | 定义网络服务模板、策略规则、闭环逻辑 | 建筑师画图纸 |
| 运行时（Run-Time） | 实例化服务、监控运行、闭环自愈 | 施工队按图纸盖楼并维护 |
设计时的关键组件： - SDC（Service Design & Creation）：服务设计工具，拖拽式定义网络服务拓扑 - Policy Engine：策略引擎，定义什么条件下触发什么动作
运行时的关键组件： - SO（Service Orchestrator）：服务编排器，端到端的网络服务生命周期管理 - AAI（Active & Available Inventory）：资源清单，记录网络中所有资源和它们的关系 - DCAE（Data Collection Analytics & Events）：数据采集与分析，AI/ML的"眼睛" - VID（Virtual Integration Deployment）：部署执行接口 - APPC（Application Controller）：应用控制器，对VNF进行配置和操作
ONAP的典型工作流：
O-RAN（Open RAN）引入了一个新组件——SMO（Service Management and Orchestration，服务管理与编排），专门负责O-RAN无线接入网的管理。
SMO的功能与ONAP有重叠但也有区别：
| 维度 | ONAP | O-RAN SMO |
|---|---|---|
| 管理范围 | 端到端（核心网+传输+云） | 无线接入网（O-CU/O-DU/O-RU） |
| 接口 | TMF Open API / REST | O1/O2/A1接口 |
| AI/ML | DCAE（数据分析） | Non-RT RIC（非实时RIC） |
| 定位 | 全局编排器 | RAN域编排器 |
在实际部署中，SMO可以作为ONAP的子组件或通过API与ONAP协同。ONAP负责全局编排，SMO负责RAN域的精细化管控。
TM Forum（电信管理论坛）长期以来定义了运营商的标准流程框架——eTOM（enhanced Telecom Operations Map）。eTOM定义了运营商"应该做哪些事"：客户管理、计费、网络运维、供应链管理等。
但eTOM只是流程框架，没有告诉运营商"怎么做"。于是TM Forum推出了ODA（Open Digital Architecture，开放数字架构）——它提供了从流程到实现的技术蓝图。
ODA的核心理念是可组合性（Composability）——把庞大的单体OSS/BSS系统，拆解为一组可独立部署、可组合的微服务组件，通过标准Open API互联互通。
传统模式：
┌─────────────────────────────────────┐
│ 单体BSS系统 │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │CRM │ │计费 │ │订单 │ │产品 │ │
│ │ │ │ │ │管理 │ │目录 │ │
│ └─────┘ └─────┘ └─────┘ └─────┘ │
│ 紧耦合，改一个牵动全部 │
└─────────────────────────────────────┘
ODA模式：
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│CRM │ │计费 │ │订单 │ │产品 │
│微服务│ │微服务│ │微服务│ │微服务│
└──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘
└───────┴────┬───┴───────┘
Open API
松耦合，独立升级
ODA定义了解耦组件清单——每个组件对应一个TMF Open API。运营商可以"混搭"不同供应商的组件：A厂商的计费、B厂商的CRM、C厂商的订单管理，通过标准API连接。
如果你是运维工程师或系统集成工程师，ODA意味着：
O-RAN架构引入了RIC（RAN Intelligent Controller，无线智能控制器），把AI能力注入无线接入网：
| 组件 | 实时性 | 部署位置 | 功能 |
|---|---|---|---|
| Non-RT RIC | >1秒 | SMO内 | 制定无线策略、训练AI模型 |
| Near-RT RIC | 10ms-1秒 | 部署在边缘 | 实时无线资源优化 |
Non-RT RIC上运行rApp（策略应用），Near-RT RIC上运行xApp（实时控制应用）。它们通过A1接口交互：Non-RT RIC下发策略，Near-RT RIC根据策略实时控制。
典型的应用场景： - xApp：负载均衡——实时检测各小区负载，将用户从拥挤小区引导到空闲小区 - rApp：SLA保障——根据历史流量模式训练模型，预测拥塞并提前制定策略
场景1：VNF实例化失败
在MANO环境中，VNF实例化可能失败。排查思路： 1. 查看VNFM日志——是镜像拉取失败、资源不足还是配置错误？ 2. 查看VIM资源池——是否还有足够的CPU/内存/存储？ 3. 查看网络连通性——VNF需要的虚拟网络是否已创建？
场景2：闭环未触发
定义了"CPU>80%自动扩容"的策略，但实际没有触发： 1. 检查遥测数据——是否正确采集到了CPU指标？ 2. 检查策略引擎——阈值配置是否正确？策略是否激活？ 3. 检查编排器——是否收到了策略触发指令？执行是否成功？
场景3：意图不收敛
声明了"延迟<50ms"的意图，但系统反复修复又反复违反： 1. 可能是资源确实不足——当前容量无法满足需求 2. 可能是意图冲突——有其他意图占用了相同资源 3. 需要人工介入调整意图或扩容基础设施
| 误解 | 实际 |
|---|---|
| "自动化会取代所有运维工程师" | 自动化取代的是重复性操作，工程师需要转型为策略定义者和异常处理者 |
| "意图驱动就是自然语言配置" | 当前主要是结构化的声明式API，自然语言只是前端交互方式之一 |
| "ONAP部署了就实现自动化了" | ONAP只是平台，还需要大量的服务蓝图设计、策略定义、数据训练 |
| "闭环等于无人值守" | 闭环处理已知场景，未知异常仍需人工干预 |
| "NFV=软件化" | NFV不只是软件化，关键是编排能力和弹性伸缩能力 |
Q: ONAP和OSM有什么区别，运营商该选哪个？
A: ONAP和OSM都是开源MANO实现。ONAP由Linux基金会主导（AT&T、中国移动等参与），功能全面但复杂度高，适合大型运营商。OSM由ETSI主导，轻量级，适合中小型运营商或特定场景。实际上很多运营商并非二选一——核心编排可能用ONAP，特定域管理可能用OSM，通过API协同。
Q: 意图驱动网络和SDN是什么关系？
A: SDN是基础设施层面的技术——把网络的控制平面和数据平面分离，提供集中控制能力。意图驱动网络是更高层次的理念——它可能利用SDN作为执行手段之一，但还涉及AI翻译、策略引擎、持续验证等SDN不具备的能力。简单说：SDN是"手"，IBN是"大脑"。
Q: 闭环自动化的"闭环"到底是什么意思？
A: "闭环"是指从监控到执行再到验证形成一个自我反馈的循环——系统能自动发现问题、分析原因、执行修复、验证结果。与之对应的是"开环"——系统只负责检测和告警，修复动作需要人工执行。闭环的关键是验证环节——修复后要确认效果，如果没修复就继续调整。
Q: 5G网络切片的编排与传统VPN业务开通有什么本质区别？
A: 传统VPN是静态的——开通后配置固定，除非手动修改。5G网络切片是动态的——切片的资源配额、QoS参数、甚至拓扑结构都可以根据实时需求动态调整。这需要MANO具备实时感知和动态编排能力，远超传统业务开通的复杂度。
Q: 普通工程师如何入门网络自动化？
A: 建议路径：①学习Python和网络编程基础（NETCONF/RESTCONF/YANG）；②了解NFV/MANO概念和ETSI架构；③动手实践——部署一个OSM或轻量级ONAP环境；④学习TM Forum Open API标准；⑤关注O-RAN RIC和xApp/rApp开发。YANG模型和REST API是两个最核心的技术基础。
本文由「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 等场景全覆盖。
