从“运维之困”到“模型驱动”：新一代网络管理的必然演进

对于许多网络运维工程师而言，这样的一幕或许并不陌生：面对成百上千台多厂商设备，一边在命令行中重复着繁琐的配置脚本，一边在监控屏幕上审视着分钟级延迟的流量图表，心中始终萦绕着一个疑问——在云原生与自动化浪潮席卷IT的今天，网络运维为何依然如此“手工”与“滞后”？
这种普遍的“运维之困”，其根源在于我们长期依赖的两大传统支柱：CLI（命令行接口）与 SNMP（简单网络管理协议）。

• CLI是精确而直接的点对点控制工具，但在规模面前，极易因人为失误导致配置漂移。
• SNMP曾开创了集中监控的先河，但其基于静态MIB库与轮询（Pull）的架构，使其在监控精度、实时性以及业务导向的配置灵活性上力不从心。它们本质上都是面向设备参数，而非面向业务意图的管理方式。

业务的敏捷性要求网络能够快速响应、动态调整。为此，IETF推出了 YANG（Yet Another Next Generation） 数据建模语言。YANG的出现，标志着网络管理思维的根本转变：它不再关注如何对单一设备“下命令”，而是关注如何用结构化的数据模型，清晰定义整个网络的“期望状态”。YANG模型层次化地描述了设备的配置、状态乃至可执行的操作，成为机器可读、可编程的“网络单一事实来源”。

YANG模型：为业务意图提供标准化“语言”（基于 YANG 模型的几种主流管理协议）

YANG模型的核心价值在于，它将运维人员的业务意图（如“为某业务创建隔离通道”）与设备的具体配置指令解耦。工程师只需根据标准或厂商提供的YANG模型，撰写描述最终状态的XML或JSON文件（即数据实例），而由NETCONF、RESTCONF或gNMI等协议负责将其安全、可靠地下发至设备。

设备的配置管理

以下是使用 NETCONF 在星融元园区交换机的eth1上创建静态ARP的示例。

<config><top> <interfaces> <interface> <name>Ethernet1</name> <ipv4> <address operation="create"> <ip-prefix>20.1.1.1/20</ip-prefix> </address> <address operation="create"> <ip-prefix>30.1.1.1/20</ip-prefix> </address> <neighbor operation="create"> <ip>20.1.1.2</ip> <mac-address>00:0e:c6:56:9d:35</mac-address> </neighbor> <neighbor operation="create"> <ip>30.1.1.2</ip> <mac-address>00:0e:c6:56:9d:35</mac-address> </neighbor> </ipv4> </interface> </interfaces> </top></config>

设备的运行状态

设备供应商使用 YANG 模型描述设备上当前运行的各种接口和协议的所有运行状态，这些信息可以通过以下两种方式获取。

• 使用 NETCONF 的 GET RPC （远程过程调用）和或供应商支持的其他管理接口的 RPC，与 SNMP 非常相似
• 使用网络遥测技术（Telemetry）来定义需要监控的字段，并将遥测信息发送到指定的收集器，采集精度可达纳秒级

可见， YANG 数据模型适用于各种现代化的网络管理场景，包括但不限于：

• 网络配置管理：自动配置和同步网络配置，减少人为错误，提高运营效率
• 网络状态监控：利用 YANG 模型对网络状态进行实时监控和验证，从而实现主动管理和故障排除
• 网络服务编排：支持 NFV 和 SDN 架构中的复杂服务定义和编排，从而实现动态的、按需的网络服务

NETCONF

提供基于会话的完整事务机制（提交、确认、回滚），确保核心网络配置变更的绝对准确性。（以下是一个典型的数据中心带外管理网拓扑：）

在带外管理网络内部部署一台管理服务器，使其能与所有交换机进行网络通信，即可对所有交换机进行集中管理，例如配置变更和状态检查。

NETCONF 和 YANG 提供了相对统一的操作接口来管理跨厂商的设备，同时具备强大的配置事务机制，配置失败时可以自动回滚。尽管不同厂商的设备支持的YANG模型可能不同，但管理应用可以建立在相同的底座上对所有设备执行相同的操作（如<edit-config>）。当具体的操作数据不同，可能需要网络管理员针对不同厂商设备编写不同的配置数据模板，而配置数据的语法又是相同的。

RESTCONF

RESTCONF 是 NETCONF 面向 RESTful API 的“简化版”，2017年融合了 NETCONF 和 HTTP 协议的 RESTCONF 悄然诞生，为用户提供高效开发 Web 化运维工具的能力，提供的编程接口符合IT业界流行RESTful风格，与现代云原生应用和 DevOps 工具链（如 Ansible, Python脚本）集成度极高，学习成本低。使用标准的HTTP动词（GET/POST/PUT/DELETE），让网络配置能无缝嵌入Ansible、Python等DevOps流水线，实现基础设施即代码。

gNMI（基于gRPC）

利用HTTP/2长连接和Protocol Buffers编码，原生支持配置与流式遥测（Streaming Telemetry）。运维人员可以像订阅新闻一样，持续、实时地接收设备状态更新，精度可达纳秒级，彻底告别低效轮询。

在常规的状态查询和配置修改方面，gNMI 和 NETCONF 的能力相差无几；但对于大型数据中心、云网络、5G 核心网等需要海量、实时监控数据和高频配置的场景，gNMI 性能卓越，通过单一协议解决了配置与监控需求，并且原生支持流式遥测，推送模式效率远高于轮询，是云原生/可编程网络的首选。

以下是一个典型的数据中心云网场景组网拓扑，使用遥测方式对网络进行监控：

通过连接数据中心网络交换机提供的额外 10G 接口并辅以隔离性配置，监控服务器可在不干扰业务流量的情况下对所有设备发起gNMI订阅请求，持续高频获取网络设备的各类信息，只要是设备支持的YANG模型有建模的数据均可。

gNMI 可采集的数据十分丰富，可用于监控设备状态、监控流量计数，配合 Prometheus 和 Grafana 等可视化工具，以上时序数据可被转化为直观的统计图表，并进一步实现系统异常告警、流量分析等功能。

以统一模型驱动全场景网络

星融元自2025年底起，运行最新版本AsterNOS的交换机（涵盖数据中心核心、园区接入及边缘网关）中，全面内置了对标准YANG模型及上述三大协议的支持。这意味着，无论网络设备身处何地，运维团队都能使用同一套模型化的方法进行管理：

• 在数据中心：通过gNMI订阅，实时可视化微突发流量与设备内部状态，结合Prometheus+Grafana实现预警式运维。
• 在园区网：通过RESTCONF接口，与自动化平台集成，实现新业务网络的分钟级开通。
• 在边缘：通过NETCONF可靠地下发复杂路由策略，确保配置的严格一致性。

迈向自驱型网络

YANG模型的价值远不止于替代CLI或SNMP。它奠定了模型驱动网络（Model-Driven Networking）的基石，使得网络真正成为可被软件定义、验证和闭环控制的智能实体。未来，结合AI算法，网络管理系统能够基于YANG模型实时验证网络状态是否符合业务意图，并自动执行优化或修复动作。
我们通过全面拥抱YANG及新一代管理协议，正助力用户跨越传统的运维鸿沟，驶向更自动化、更智能的网络未来。

【参考资料】

https://datatracker.ietf.org/doc/html/rfc6020

https://zhuanlan.zhihu.com/p/139500393
https://medium.com/@k.okasha/yang-and-road-to-a-model-driven-network-e9e52d47148d https://blog.csdn.net/puhaiyang/article/details/137432500