首先，让我们假想一个场景：
由于业务发生变更，需要为一个 POD 里面的几十台交换机修改 QoS 配置。作为网络运维人员，应该怎样处理这项工作呢？
如果需要变更的对象是整个数据中心几百台甚至几千台交换机，又该怎样处理这项工作呢？
当下，互联网行业已经普遍采用 DevOps 的体系流程。靠人力去一台设备一台设备的更改配置，已经不再是正确的思维方式。原因不仅仅是浪费时间 —— 要知道，人如果要长时间保持注意力集中，大脑需要耗费大量的能量，很难保证不出现遗漏或者错误。而机器却不会。
因此，正确的方法是利用 DevOps 的流程，让机器来完成这项工作。例如采用基于 Python 的 SSH 库 Paramiko 或 Netmiko，以及 Ansible 或 SaltStack 等自动化工具编写运维脚本。
Netmiko 库和 Ansible 等运维工具虽然可以通过程序化的脚本对网络设备实现批量管理，但仍然需要运维工程师对网络设备的 CLI 很熟悉，预先在脚本中建立需要被执行的 Command 列表。 CLI
CLI 最大的问题就是在不同厂商的设备之间，甚至在不同版本之间存在较大差异。比如在某 C 厂商交换机上配置边缘端口，不同的 OS 版本命令并不相同：
而对于另一些厂商，配置命令则差异更大。例如在某 E 品牌 交换机上配置边缘端口的命令为：
这意味着：如果设备版本升级，就可能需要更改运维脚本的代码。为了避免厂商绑定，网络内通常也会同时存在多个厂商的设备，相应地，也可能需要准备多种运维脚本或者让运维脚本变得很复杂 —— 先判断设备型号和版本号，再运行相应的 Command-list。
所以 CLI 并不适合用来作为一种 API。虽然采用自动化工具处理 Commands 可以节省网络运维人员的工作量，但是技术门槛和维护成本都比较高。SNMP 似乎是一种更好的选择。 SNMP
▲ SNMP Overview
SNMP 的历史很悠久，第 1 个与之相关的 RFC 1065 发布于 1988 年，距今已有 30 年。在 SNMP 架构中，一个网络设备以守护进程的方式运行 SNMP Agent，而 NMS（网络管理系统）和网络运维人员所使用的各种 SNMP 管理工具则称为 SNMP Manager。SNMP Agent 能够响应来自 SNMP Manager 的各种请求信息。
SNMP Agent 会维护一个 MIB（管理信息库），里面保存着大量的 OID （对象标识符）。一个 OID 是一对唯一的 Key-Value，SNMP Manager 向 SNMP Agent 查询或修改若干 Key 所对应的 Value，就可以实现信息采集或者网络设备的配置修改。
▲ MIB-Example
上图是一个 MIB 示例，请注意标黄色的部分。OID 1.3.6.1.2.1.2.2.1.5 用来以 bps 为单位评估接口流量，它属于 RFC 1213 标准 MIB，名称为 ifSpeed，只读。因为这个 MIB 并不是我从正在运行的设备上取下来的，所以当前的 Value 为空。
需要注意的是，SNMP Manager 侧的 MIB 并不是必需的。如果使用数字 OID 1.3.6.1.2.1.2.2.1.5，SNMP Manager 可以直接从 SNMP Agent get 接口流量带宽，而不需要安装完整的 MIB。
现在 SNMP 在网络监控领域已经被广泛使用，利用 Zabbix、Nagios、Cacti 等开源的 SNMP 管理工具采集网络设备接口流量带宽和其他设备信息，同时也有大量的基于 Python 的 SNMP 库用来实现运维开发，例如 PySNMP、 EasySNMP、 Net-SNMP等等，并且它们都可以集成到 Ansible 和 SaltStack 等自动化运维工具上。
看上去还不错，但实际上 SNMP 仍然不是一个合适的 API，因为它存在几个问题： ○太古老，并发性能不好
○基于 UDP 协议传输，比较不可靠。虽然在应用层有 Response 机制保证丢包之后的重复 get/ set，但代价就是性能和运行时间都受到影响
○致命的问题是，各厂商都大量的使用私有 MIB，却不存在一个可以自动发现网络设备当前所采用的 MIB 的机制。网络运维人员必须分别向设备厂商索取网络设备的 MIB，耗费大量的时间整理自己需要的 OID，再手工导入到自动化运维平台或者脚本当中
所以 SNMP 仍然只适合用来做信息采集，提供告警和可视化报表，但自动化运维的 API 则需要考虑其他的选项。站在网络运维人员的角度，这个 API 应该满足以下要求： ○容易使用 —— Usability 是所有产品的核心价值
○需要能够清晰地区分“配置数据”，“设备运行状态数据”和“统计数据”
○需要能够分别从各个网络设备获取上述 3 种数据，并且可以方便地对比不同设备的数据 ○可以让网络运维人员统一地管理整个网络的所有设备，而不是一台一台的单独管理 ○对不同厂商的设备都能够使用同一种配置方法 ○配置变更对网络业务的影响要尽可能的小
○能够提供一个标准化的，对设备 Pulling 和 Pushing 配置文件的流程，以满足对设备配置的备份和恢复的业务需求
○能够很方便地，持续地，检查设备配置文件的一致性
○能够提供基于文本的配置方式，并且不会导致配置的乱序，例如不能搅乱 ACL 规则的顺序 能够满足这些要求的网络设备的北向 API 接口就是 Netconf。
Netconf
Netconf 是 IETF 发布的标准协议，它的全称是 Network Configuration Protocal。从名字就可以看出来，Netconf 的作用是基于网络来安装、操作和删除设备的配置。在 Netconf 的架构中，网络设备充当 Netconf Server 的角色，而运维人员的这一侧则是 Netconf Client。此外，和 OSI 标准模型一样，Netconf 也是分层结构。
▲ Netconf 4 Layers
它有 4 个层次，从下到上依次为： ? 安全传输层
安全传输层在 Netconf Client 和 Netconf Server 之间提供安全的端到端连接。与 SNMP 采用非面向连接的 UDP 协议不同，Netconf 采用面向连接的 TCP 协议，通常是 SSH 协议，保证连接的可靠性和安全性。 ? 消息层
消息层也称为 RPC（远程过程调用）层。Netconf Server（网络设备）上面部署了 Netconf 应用，Netconf Client 需要调用 Server 上的应用所提供的函数/方法，但由于 Client 和 Server 不在同一个内存空间，无法直接调用，所以需要通过网络来表达调用的语义，并传达调用的数据。这个过程，称为 RPC。它 提供了一个简单的，与安全传输层无关的机制来封装操作层和内容层的数据： ○RPC 调用：
? 操作层
操作层定义了如图所示的 9 种基础操作集，其中：
顾名思义，内容层就是用来表达配置数据和状态数据，网络运维人员只需要关注数据本身，而不需要去关注设备的相关命令。基础网络设备在内容层所采用的数据格式通常是 XML，但也有厂商的数据格式采用了 JSON。
虽然网络运维人员不再需要关注设备的相关命令了，但仍然无法直接使用 Netconf 配置设备，还需要考虑配置结构。
什么叫“配置结构”呢？
假如我们现在要将交换机的 10# 端口划入 VLAN 20。我们的交换机需要在物理端口模式下配置：
而某 H 品牌交换机却需要在 VLAN 逻辑端口模式下配置：
从上面两个配置示例可以发现我们的交换机和 H 品牌交换机的配置结构有明显差异，所以无法直接使用 XML 或者 JSON 修改它们的设备配置。
为了解决配置结构的问题，需要将 XML 和 JSON 数据格式抽象成一个统一的标准的模型，这就是 YANG。YANG 的全称是 Yet Another Next Generation，没有恰当的中文来翻译它。通俗的讲，YANG 是表达 Netconf 所操作的配置数据和状态数据的模板，它描述什么才是符合设备期望的数据。有了 YANG Model，配置结构就交给它去处理，网络运维人员就只需要做一个完形填空即可。
填空的题目大概是这样子的：
技术盛宴丨畅谈数据中心网络运维自动化 - 图文
