网络自动化与 NetConf/YANG：设备可编程与配置即代码

登录交换机敲命令的时代正在终结。大规模网络的真实需求是「确定性」：同样的变更，1000 台设备结果必须一致，且要可回滚、可审计、可评审。网络自动化就是把设备配置从「手工敲击」变成「代码制品」的工程化过程，而 NetConf/YANG 正是让设备拥有「结构化可编程接口」的底座。

一、为什么需要网络自动化

1.1 手工配置的痛点

手工配置的典型问题：
1. 一致性差：两台设备配置「看起来一样」，细节不同
2. 效率低：批量变更逐台敲，晚班只能通宵
3. 审计难：谁改了哪台设备的哪一行，没有记录
4. 回滚难：变更出错，只能手工「改回去」
5. 与云/DevOps 脱节：代码可以 CI/CD，网络却靠人

一句话：网络自动化的本质是「把网络的最终状态声明为代码，让设备向目标状态收敛」。

1.2 自动化技术栈全景

网络自动化四层：
┌──────────────────────────────────────────────┐
│ 编排层：Ansible / Terraform / Nornir / Salt  │
├──────────────────────────────────────────────┤
│ 交互层：NetConf / RESTCONF / gNMI / 专用API  │
├──────────────────────────────────────────────┤
│ 数据建模：YANG（设备配置与状态的「Schema」）  │
├──────────────────────────────────────────────┤
│ 底座层：设备/云网元（可编程接口 + 事务化能力） │
└──────────────────────────────────────────────┘

二、YANG 数据建模

2.1 YANG 是什么

YANG（RFC 7950）是描述网络配置与状态的数据建模语言，类似网络界的「JSON Schema + IDL」：

YANG 模块示例（一个接口模块）：
module example-interfaces {
  yang-version 1.1;
  namespace "urn:example:interfaces";
  prefix if;

  container interfaces {
    list interface {
      key "name";
      leaf name   { type string; }
      leaf mtu    { type uint16; }
      leaf speed  { type enumeration {
                      enum auto; enum 1g; enum 10g; } }
      leaf enabled { type boolean; }
    }
  }
}

2.2 建模与实现分离

YANG 的核心价值是「模型标准化，实现各不同」：

建模（厂商无关）：
  标准模型：IETF / OpenConfig 定义的通用模型
  扩展模型：厂商私有模型补充特性

实现（厂商相关）：
  每个设备把 YANG 树映射到自己的配置存储
  对外暴露一致接口 → 上层工具不依赖具体厂商

OpenConfig 的意义：
  一套模型管多云/多厂商
  让「读状态、改配置」与厂商解耦

一句话：YANG 让网络设备从「私有方言」走向「公共语言」，自动化工具只需学会一门语言。

三、NETCONF 协议

3.1 NETCONF 基础

NETCONF（RFC 6241）基于 SSH 传输，操作被组织成 RPC：

NETCONF 传输栈：
  SSH ──► NETCONF（Hello → 能力协商 → 操作）

核心操作：
  <get-config>        读配置
  <edit-config>       修改配置（merge/replace/delete）
  <copy-config>       整体替换配置库
  <commit>            提交候选配置
  <lock>/<unlock>     锁配置库（防并发冲突）
  <validate>          校验配置
  <get>               读运行状态（含统计数据）

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target><running/></target>
    <config>
      <interfaces xmlns="urn:example:interfaces">
        <interface>
          <name>eth0</name>
          <mtu>9000</mtu>
        </interface>
      </interfaces>
    </config>
  </edit-config>
</rpc>

3.2 候选库与事务化

NETCONF 支持「候选配置库 + commit」，实现类事务变更：

事务流程：
  edit-config（写入 candidate）
  validate（校验语法与语义）
  commit（原子提交：要么全成功，要么全失败）
  discard-changes（放弃候选库）

对比传统 CLI：
  敲完一半才发现错了 → 无法原子回滚
  NETCONF 的 candidate + commit 从协议层面解决

NETCONF 会话要点：
  - 基于 SSH，端口 830
  - 每个 RPC 有 message-id，响应严格配对
  - 支持 <notification>：订阅设备事件（接口 Up/Down）
  - 良好适用于「低频、结构化、事务化」配置变更

四、RESTCONF 与 gNMI

4.1 RESTCONF：HTTP 化的配置接口

RESTCONF（RFC 8040）把 YANG 树映射为 REST 资源：

RESTCONF 映射：
  GET  /restconf/data/interfaces/interface=eth0    读
  PUT  /restconf/data/interfaces/interface=eth0    整体写
  PATCH /restconf/data/interfaces/interface=eth0   局部更新
  DELETE /restconf/data/interfaces/interface=eth0  删除

  HEADER：Accept: application/yang-data+json
  → 与 YANG 一一对应的 JSON 视图

curl -u admin:secret \
  -H 'Accept: application/yang-data+json' \
  http://192.0.2.1:443/restconf/data/interfaces/interface=eth0

4.2 gNMI：云原生的网络接口

gNMI（gRPC Network Management Interface）是云原生时代的首选：

gNMI 四大 RPC：
  Capabilities   查询设备能力（支持的模型）
  Get            读配置/状态（paths 指定子树）
  Set            修改（replace/update/delete）
  Subscribe      订阅路径，持续推送状态变化

优势：
  - 基于 gRPC/Protobuf，效率高、支持流式
  - Subscribe 天然支撑 Telemetry（遥测）
  - 与 Kubernetes/控制器生态集成容易

gnmic --address 192.0.2.1:6030 \
  --username admin --password secret \
  subscribe \
  --path /interfaces/interface/state/counters \
  --stream-mode sample --sample-interval 1s

一句话：NETCONF 胜在事务化配置，gNMI 胜在高频遥测与流式订阅——前者管「改」，后者管「看」。

五、配置即代码：Ansible 与工具链

5.1 Ansible 网络自动化

Ansible 的 network 生态用 YAML 描述期望状态：

---
- name: Configure NTP on network devices
  hosts: cisco_switches
  gather_facts: false
  vars:
    ntp_servers:
      - 203.0.113.10
      - 203.0.113.11
  tasks:
    - name: Set NTP servers via CLI
      cisco.ios.ios_ntp:
        server: "{{ item }}"
        vrf: default
      loop: "{{ ntp_servers }}"
    - name: Ensure NTP is enabled
      cisco.ios.ios_ntp:
        state: present

Ansible 三种执行模式：
  1. 基于 CLI 的模块：解析命令输出（简单但脆弱）
  2. 基于 NetConf/RESTCONF 的模块：结构化（推荐）
  3. 基于 gNMI 的模块：云原生设备

Inventory 用 YAML/INI，或从 Nautobot/NetBox 动态拉取

5.2 模板与 J2

配置即代码的另一个关键工具是模板引擎（Jinja2）：

模板复用场景：
  同一园区网，100 台交换机「同构不同参」：
  用变量抽离：机架号、VLAN 段、上游端口
  模板渲染 → 每台设备得到唯一且一致的配置

{% for vlan in vlans %}
vlan {{ vlan.id }}
  name {{ vlan.name }}
{% endfor %}
interface Vlan{{ vlan.id }}
  ip address {{ vlan.gateway }} {{ vlan.mask }}

5.3 配置备份与漂移检测

漂移（Drift）检测：设备实际配置 ≠ 声明配置
常用手段：
  - 定期拉取 running-config 与期望配置对比
  - 用 Oxidized 等工具自动备份 + Git 版本管理
  - 漂移告警：发现手工变更即通知
最佳实践：
  把「所有网络设备配置」当代码提交进 Git
  每次变更 = 一次提交，可 diff、可回滚

六、Nautobot / NetBox：网络数据源

6.1 为什么需要 CMDB

自动化需要一个「可信的设备与拓扑真相」（Source of Truth）：

没有 CMDB 的痛点：
  设备清单靠 Excel，谁负责哪台不清晰
  自动化脚本里硬编码 IP 与角色，改一次改一片

Nautobot/NetBox 提供：
  设备/机架/IP/前缀/拓扑的模型化管理
  API + 插件，作为自动化的单一数据源

6.2 与自动化工具链集成

Nautobot 集成模式：
  Ansible inventory 从 Nautobot 动态拉取
  Job/Webhook 触发变更后自动更新 IPAM
  与 CI/CD 联动：变更前先到 Nautobot 查变更影响面

示例流程：
  新设备上架 → 录入 Nautobot → 动态 inventory 自动出现
  → 跑 playbook 下发基线 → 状态回写 Nautobot

七、网络 CI/CD

7.1 网络变更的流水线

网络 CI/CD 与代码 CI/CD 同构，但多一层「变更风险控制」：

阶段一：变更请求（Tickets → 变更单）
阶段二：评审（PR/MR 评审配置差异）
阶段三：预检（diff、连通性预检、授权校验）
阶段四：执行（灰度分批 + 维护窗口）
阶段五：验证（事后探测、遥测确认）
阶段六：回滚（失败自动回滚到上一版本）

CI 校验项（变更合入前）：
  - YAML/模板语法校验
  - YANG 模型 validate（如有模型校验能力）
  - 配置差异 diff 评审
  - 静态检查：VLAN 冲突、IP 冲突、环路风险

7.2 灰度与回滚

灰度策略：
  1. 先改一台「代表设备」，跑验证 playbook
  2. 扩到分区域（先分支后核心）
  3. 全量，但保留维护窗口与回滚预案

回滚设计：
  每次变更前自动备份运行配置
  失败时自动 load 备份 + 验证连通性
  对 NetConf 设备：用 commit 回滚（candidate 未确认则 revert）

7.3 变更后的验证

验证自动化（post-change validation）：
  网络探测：ping / TCP 端口 / DNS 解析
  协议健康：BGP 邻居、OSPF 邻接、路由表核对
  遥测对比：变更前后关键指标基线对比
  业务冒烟：关键应用连通性测试

把「验证」写进流水线，而不是靠人回头再看

八、总结

网络自动化是一场「用软件工程纪律改造网络运维」的运动：YANG 提供可编程的数据模型，NETCONF/gNMI 提供标准化的交互协议，Ansible/Nautobot 提供编排与数据源，CI/CD 提供变更的纪律与安全网。对后端与网络工程师而言，掌握这条技术栈意味着网络不再是「黑盒运维」，而是可以像代码一样评审、测试与回滚的基础设施。方向清晰，剩下的就是「先把一台设备自动化，再逐步铺开」。