在通信行业的教科书里，很少讲这样一个细节：上世纪70年代的贝尔系统里，如果客户要开通一部新电话，营业系统的操作员需要把客户信息抄在工单上，然后转个身，在另一台交换机管理系统的终端上把同样的信息重新敲一遍。这两套系统之间没有任何接口，全靠人当“人肉网线”。业界的行话很形象——转椅集成（Swivel Chair Integration）：人坐在转椅上，在两个系统之间转来转去。
这个故事之所以值得讲，是因为它揭示了网络管理最底层的矛盾：网络规模在指数增长，而人的精力是常数。上世纪70年代一部程控交换机就够忙活，今天的5G网络里，一个省级运营商要管理的虚拟机、容器、物理设备动辄以十万计。靠人转椅子？椅子会先转冒烟。
于是整个行业在过去五十年里做的事情，本质上只有一件：把“人管设备”逐步替换成“系统管系统”。理解了这条主线，你就能理解 OSS/BSS、TMN 分层、NFV 编排、闭环自动化、意图驱动网络这些看起来眼花缭乱的概念——它们不是五个技术，而是同一场演进的五个阶段。
把运营商想象成一家大医院：
两者合称 OSS/BSS，是运营商的“数字神经系统”。病人（客户）在前台挂号（下单），前台把医嘱传给设备科（OSS），设备科操作医疗器械（网元）完成检查，检查结果再变成账单回到收费处——这条信息流在现代化的运营商网络里，理论上全程无纸、全自动。
上世纪90年代，ITU-T 提出了 TMN（电信管理网）模型，把 OSS 内部切成四层。这个分层不是拍脑袋，而是计算机科学的老办法：当一件事复杂到没法整体理解时，就切层，让每层只跟相邻层打交道。
graph TB
subgraph BSS["BSS 业务支撑系统（面向客户与钱）"]
CRM["客户关系管理"]
ORDER["订单管理"]
BILL["计费账务"]
end
subgraph OSS["OSS 运营支撑系统（面向网络与服务）"]
BML["业务管理层<br/>产品设计与业务规划"]
SML["服务管理层<br/>服务开通·保障·计费协同"]
NML["网络管理层<br/>端到端网络拓扑与性能"]
EML["网元管理层<br/>设备配置·告警·软件版本"]
end
NE["网元层<br/>基站 / 核心网 / 路由器 / 服务器"]
ORDER --> BML
BML --> SML
SML --> NML
NML --> EML
EML --> NE
NE -. "话单/性能数据回流" .-> BILL
四层各自的“语言”完全不同：业务管理层说的是“推出一个融合套餐”，服务管理层说的是“给用户X开通一条专线”，网络管理层说的是“调整A城到B城的流量路径”，网元管理层说的是“给这台设备下发这行配置”。层与层之间的翻译，就是自动化的第一性原理——只要这个翻译还靠人，自动化就没开始。
分层解决“从上到下怎么传指令”，FCAPS 模型解决“每一层横着要管哪几摊事”。它把运维职责正交分解成五个互不重叠的域：
| 域 | 英文 | 管什么 | 工程师熟悉的例子 |
|---|---|---|---|
| 故障 | Fault | 发现、定位、修复异常 | 告警、事件、诊断测试 |
| 配置 | Configuration | 设备参数的下发与回滚 | 配置模板、版本升级、开通 |
| 计费 | Accounting | 资源使用的计量 | 话单采集、流量统计 |
| 性能 | Performance | 运行质量的测量与优化 | KPI 采集、性能门限、报表 |
| 安全 | Security | 访问控制与数据保护 | 账号权限、日志审计 |
后来 TM Forum 又在这套体系上发展出 eTOM 业务流程框架和 SID 共享信息模型，再演进为今天的开放数字架构（ODA）。名字换了一茬又一茬，骨架没变：分层 + 分域，把“管理一个网络”拆成可编程的小方块。
传统网管有个天花板：设备的形态不可编程。一台专用硬件设备，软件和硬件焊死在一起，管理动作只能是“下发配置、重启、更换”，颗粒度粗得像用锤子做外科手术。
两场革命改变了地基：
第一场是 NFV（网络功能虚拟化）。2012年10月，一批运营商在德国达姆施塔特的会议上发布白皮书，随后在 ETSI 成立了 NFV 工作组。核心思想简单粗暴：把跑在专用硬件上的网元（防火墙、负载均衡器、核心网网元……）变成跑在通用 x86 服务器上的软件——虚拟网元（VNF）。软硬件解耦之后，网元的“开通”从“申请预算、到货、上架、加电、调试”（以月计）变成“从镜像库里拉起一个虚拟机”（以分钟计）。
第二场是 SDN（软件定义网络）。它把设备内部的控制平面和转发平面拆开：转发还留在交换机里傻快地搬包，但“往哪转”的大脑被抽出来集中放到控制器里。2012年谷歌在广域网骨干 B4 上的规模化部署，证明了这套玩法在超大规模网络中可行。
这两场革命合起来的效果是：整个网络第一次变成了纯软件可以定义的东西。当网元只是虚拟机、链路只是虚拟交换机的配置项时，“管理网络”就彻底变成了“管理数据”——而管理数据，恰恰是计算机最擅长的事。
网元变软了，谁来管这群软件？ETSI 给出的答案就是 NFV-MANO 框架。它由三个角色组成，理解它们最好的方式是想象一个装修工地：
graph TB
OSSBSS["OSS/BSS<br/>（业主办公室）"]
NFVO["NFVO 网络业务编排器<br/>总包项目经理<br/>管端到端服务的组装与生命周期"]
VNFM1["VNFM ①<br/>水电工头<br/>管单个VNF的启停/升级/自愈"]
VNFM2["VNFM ②<br/>瓦工工头<br/>管另一类VNF"]
VIM["VIM 虚拟化基础设施管理器<br/>建材仓库 + 工地管家<br/>管计算/存储/网络资源池"]
NFVI["NFVI 基础设施层<br/>通用服务器 + 虚拟化层"]
VNF1["VNF 防火墙"]
VNF2["VNF 负载均衡"]
PNF["PNF 传统物理网元"]
OSSBSS -- "北向接口（RESTful）" --> NFVO
NFVO -- "Or-Vnfm 接口" --> VNFM1
NFVO -- "Or-Vnfm 接口" --> VNFM2
NFVO -- "Or-Vi 接口" --> VIM
VNFM1 -- "Ve-Vnfm 接口" --> VNF1
VIM -- "资源分配与回收" --> NFVI
NFVI --- VNF1
NFVI --- VNF2
VNF1 -- "业务链串接" --> VNF2 -- "混合组网" --> PNF
| 组件 | 全称 | 一句话职责 | 装修类比 | 典型开源实现 |
|---|---|---|---|---|
| NFVO | 编排器 | 管理网络服务（NS）全生命周期：把多个VNF按业务链组装、实例化、扩缩、终结 | 总包项目经理：只看图纸和进度，不亲手砌砖 | OSM、ONAP |
| VNFM | VNF管理器 | 管理单个虚拟网元的生命周期：创建、监控、修复、升级 | 各工种工头：水电出了问题找水电工头 | 可与NFVO合一部署 |
| VIM | 基础设施管理器 | 管理底层资源池：虚拟机、存储卷、虚拟网络的分配与监控 | 建材仓库管理员：工头要多少砖，他从库里发 | OpenStack；容器场景下是Kubernetes |
这个三分法的精妙之处在于职责正交：
MANO 体系里最容易被初学者忽略、却最见功力的设计是描述符（Descriptor）机制。部署一个网络服务前，工程师要先写好两份“图纸”：
描述符可以基于 TOSCA（基于YAML模板）或 YANG 数据模型来写。这背后是软件工程里一次深刻的范式转移：从命令式到声明式。
声明式的好处除了省事，更重要的是可校验、可复用、可版本化。图纸可以拿去仿真推演，可以进代码仓库做变更管理，出问题可以回滚到上一版——这些在“人肉敲命令”时代是不可想象的。
MANO 解决的是“怎么把服务开起来”，但服务开起来之后呢？流量会涨、链路会断、虚拟机会崩。如果每次都要等告警弹出、人工研判、手工处理，那前面的自动化只省了开通的钱，省不掉运维的命。
闭环自动化（Closed-Loop Automation）就是为此而生。ETSI 在2017年12月成立 ZSM（零接触网络与服务管理）工作组，其目标白皮书里写得很清楚：终极目标是让网络在高层策略和规则的驱动下，实现自配置、自监测、自愈合、自优化，无需人工干预。
原理并不神秘——你家空调早就实现了。设定26度（意图），温度传感器实时采样（感知），控制器比较偏差（分析），压缩机启停（执行），如此循环。把它搬到网络上：
flowchart TD
subgraph LOOP["自动化闭环 Closed Loop"]
A["① 感知 Monitor<br/>采集KPI·告警·日志·话单"] --> B["② 分析 Analyze<br/>异常检测·根因定位·预测"]
B --> C["③ 决策 Decide<br/>策略匹配·方案生成·风险评估"]
C --> D["④ 执行 Act<br/>扩缩容·流量调度·故障自愈"]
D -- "网络状态已改变，继续观测" --> A
end
ENG["运维工程师"] -. "人在环上：只监督与调策略，不亲手操作" .-> C
这个四拍循环（业界常称为 MAPE 模型，源自IBM 2001年提出的自治计算理念）有个关键设计哲学：人在环上（human-on-the-loop），而非人在环中（human-in-the-loop）。人不再亲手执行每一步，而是站在环路外面监督，只在系统拿不准的决策点介入。
闭环为什么能显著提升可用性？可以用可用性公式算一笔账：
$$A = \frac{MTBF}{MTBF + MTTR}$$
其中 MTBF 是平均无故障时间，MTTR 是平均修复时间。假设某业务年故障10次、每次纯故障持续2分钟，但人工定位加处理平均要50分钟：
行业常说的“五个9”意味着一年不可用时间只有：
$$525600 \text{ 分钟} \times 0.00001 \approx 5.26 \text{ 分钟}$$
这个数字用人工根本做不到——人还没看到告警，5分钟已经过去了。这就是闭环自动化的数学必然性，而不是营销话术。
闭环自动化还有一个软肋：闭环的“目标值”还得人来定。扩容门限定多少？时延红线画在哪？这些参数在今天的大量现网系统里，仍然是工程师在策略文件里手工写死的。网络规模继续膨胀、业务切片越来越个性化之后，写策略本身也会成为新的瓶颈。
于是演进的下一级台阶是意图驱动网络（Intent-Based Networking, IBN）：人只说“要什么结果”，系统自己翻译成“该怎么做”。最贴切的类比是点菜——客人说“来一份不太辣、做得快的海鲜”（意图），厨房自己决定选什么鱼、用什么火候、哪个灶眼优先（实现）。客人从不需要理解后厨。
一条意图的完整生命周期是一条流水线：
flowchart TD
I["意图输入<br/>『华南区视频类业务<br/>端到端时延低于20ms』"] --> T["翻译 Translate<br/>分解为策略·配置·资源需求"]
T --> V["验证 Verify<br/>仿真推演·冲突检查·可行性确认"]
V --> D["部署 Deploy<br/>下发给编排器与控制器执行"]
D --> O["保障 Assure<br/>持续监测·偏差检测"]
O -- "实测不达标 → 触发重新优化" --> T
O -- "持续达标" --> O
两个环节尤其值得注意：
顺带一提，网络自治程度业内常类比自动驾驶搞了 L0 到 L5 的分级（L0纯人工，L5完全自治）——注意这类分级是业界自发的沟通工具，并非强制标准，各厂家口径也不完全一致，看资料时要留意上下文。
| 维度 | 传统人工运维 | 编排自动化（MANO） | 意图驱动自治（IBN/闭环） |
|---|---|---|---|
| 操作的基本单位 | 单台设备、单条命令 | 端到端网络服务（描述符驱动） | 业务意图与目标 |
| 人的角色 | 执行者（敲命令的人） | 设计者（写图纸的人） | 决策者（提目标的人） |
| 一次变更的典型耗时 | 天～周 | 分钟～小时 | 秒～分钟（闭环内自动完成） |
| 典型故障来源 | 手工翻译出错、敲错命令 | 描述符模板缺陷 | 意图描述有歧义、策略冲突 |
| 故障恢复方式 | 人工告警研判＋手工处理 | 预定义自愈脚本/策略 | 系统自主决策，人只复核 |
这张表也回答了一个职业焦虑问题：自动化淘汰的不是工程师，是“执行者”这个角色分工。转椅时代需要的“复制粘贴工”确实在消失，但写描述符、设计闭环策略、给意图系统划定安全边界——这些活更难了，也更值钱。
1. 工单卡住了，先查“翻译链”。 现网开通一个切片或专线的标准路径是：BSS下单 → OSS 编排 → NFVO → VNFM → VIM。如果客户经理说“单子下了一小时没通”，正确的排查姿势是沿着这条链逐级看状态和接口返回——北向接口通常是标准 RESTful API，看返回码就能定位卡在哪一层，而不是登到某台设备上瞎翻。
2. 警惕“幽灵重启”。 闭环自愈上线后，你会遇到一种怪现象：某虚拟机半夜重启了，日志里查无此人，变更平台也没有工单。别急着报安全事件——很可能是 VNFM 的自愈策略检测到进程无响应后自动重建了它。闭环做的每一个动作都会留下自己的痕迹，查问题前先搞清楚现场有哪些闭环在运行，这是云化网络排障与传统排障最大的区别。
3. 描述符里最贵的两个字母：反亲和（anti-affinity）。 一个经典事故模式：VNFD 里忘了给互为主备的两个 VNFC 写反亲和约束，编排器为省资源把它们调度到了同一台物理机上。平时一切正常，某天那台机器一宕机，主备同时消失，服务全断。可用性不是靠备份组件的数量保证的，而是靠备份组件“不在同一个爆炸半径里”保证的——这句话值得写在工位上。
4. 资源超分的性能陷阱。 VIM 层为了提升利用率常做资源超分（overcommit），多台虚拟机共享超额的物理CPU。跑普通业务没事，但虚拟交换机（vSwitch）这类转发密集组件一被“超”，VNF吞吐立刻劣化且抖动异常。遇到“虚拟网元物理机没满载但转发性能上不去”的问题，往超分和 vSwitch 配置上查，往往有惊喜。
5. 闭环震荡：空调为什么一开一停？ 把制冷门限定在26度、制热门限定在25.9度，空调就会疯狂启停直到烧坏——这叫缺乏滞回（hysteresis）。网络闭环同理：扩容门限和缩容门限贴得太近，虚拟机就会反复扩了缩、缩了扩，不仅浪费资源，频繁的生命周期操作本身还会冲击业务。调闭环参数时，先看有没有滞回带，再看动作冷却时间，这是策略调优的第一课。
6. 两个闭环打架。 容量闭环看 CPU 高就扩容，节能闭环看负载低就缩容——如果它们的数据源延迟不同、看到的网络状态有时间差，就可能陷入“你扩我缩”的死循环。成熟的编排系统要求闭环之间有优先级仲裁和共享状态视图，这在多厂商组网里恰恰是最容易缺位的。
Q: OSS 和 BSS 到底怎么区分？为什么总写在一起？ A: 一句话——BSS 管“钱和客户”，OSS 管“网络和服务”。客户下单、计费出账走 BSS；网络开通、故障处理、性能监控走 OSS。但业务流程天然贯穿两者（一个订单最终要落到网络配置上），系统集成时永远绑在一起，所以行业习惯合称 OSS/BSS 或 B/OSS。
Q: 编排器和传统网管（NMS/EMS）的本质区别是什么？ A: 传统网管是命令式的：它帮你把配置下发到设备，但“做什么、什么顺序”由人规划。编排器是声明式 + 生命周期的：你提交一份描述“我要的服务长什么样”的描述符，它负责推导全部实施步骤，并持续管着这个服务的生老病死——包括故障自愈和动态扩缩。网管管设备，编排器管服务。
Q: NFV 和 SDN 是一回事吗？ A: 不是，但它们是天然搭档。NFV 解决“网元跑在哪”——把网元软件化，搬到通用服务器上；SDN 解决“链路怎么连”——把转发行为的控制权集中到软件控制器。打个比方：NFV 是把固定电话机换成了装着电话APP的智能手机，SDN 是把小区门口固定死的岗亭换成了可远程调度的保安系统。现网里通常配合使用：VIM 用 SDN 控制器来铺设连接各 VNF 的虚拟网络。
Q: “零接触（Zero-touch）”是说以后完全不需要网络工程师了吗？ A: 不是。ZSM 的“零接触”指的是常规的、重复性的运维操作不再需要人碰——开通、扩缩容、常见故障自愈。但意图怎么定义、闭环的安全边界怎么划、异常场景的兜底方案怎么设计、自动化系统自己出故障了怎么救，全都需要更高水平的工程师。自动化改变的是工作的“型”，不是消灭工作本身。
Q: 容器化（CNF）和虚拟机化（VNF）对编排有什么影响？ A: VNF 跑在虚拟机里，编排粒度是“台”，启动以分钟计；CNF（云原生网络功能）跑在容器里，编排粒度细到进程，启动以秒计，天然适合更快的闭环和灰度升级。大约从2018年起业界加速向 CNF 迁移，ETSI 也相应扩展了 MANO 框架，增加了容器基础设施服务管理（CISM）等角色——但三件套的分层哲学没有变，只是 VIM 的地位在容器场景下越来越多地由 Kubernetes 这类系统承担。
本文由「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 等场景全覆盖。