📚 课程目录第3章配置采集与版本化

3. 配置采集与版本化

网络配置合规与变更自动化的第一步，是把设备上“真实生效的配置”稳定、可重复地取回到一个可信的存储位置。没有可靠的配置采集，后续的合规比对、变更审计、回滚和差异追踪都无从谈起。本节围绕四类采集协议（SSH、NETCONF、RESTCONF、SNMP）与 Git 版本管理，说明如何构建一条从设备到仓库的配置数据链路。

一、四类采集协议的能力边界

选择采集协议，本质是在“兼容性、结构化程度、实时性、可写性”之间做权衡。SSH 兼容性最好，几乎所有网络设备都支持，通过 CLI 抓取 show running-config 一类命令的文本输出，得到的是非结构化配置；NETCONF 基于 SSH 传输，使用 XML 编码，支持 <get-config> 获取候选库或运行库配置，返回结构化数据，便于程序解析；RESTCONF 把同样的数据模型暴露为 HTTP/JSON 接口，适合与 Web 生态集成；SNMP 则以 OID 为单位读取指标和部分配置对象，适合采集状态、接口计数、CPU 等运行数据，但通常不适合完整配置的版本化。

一个常见的工程组合是：用 SSH 采集“配置文本快照”作为兜底与审计依据，用 NETCONF/RESTCONF 采集“结构化配置”用于字段级比对，用 SNMP 采集运行状态作为变更后的健康校验。三者互补，而不是互相替代。

二、采集脚本的关键实现

以 SSH 采集为例，使用 Python 的 netmiko 库可以快速建立连接并执行命令。下面是一个最小可用的采集片段，示例参数为教学假设值：

from netmiko import ConnectHandler
import hashlib, datetime, os

device = {
    "device_type": "cisco_ios",
    "host": "10.0.0.1",
    "username": "netops",
    "password": "******",
    "timeout": 30,
}

with ConnectHandler(**device) as conn:
    config = conn.send_command("show running-config")
    digest = hashlib.sha256(config.encode()).hexdigest()[:12]
    ts = datetime.datetime.now().strftime("%Y%m%d-%H%M%S")
    path = f"configs/10.0.0.1/{ts}-{digest}.cfg"
    os.makedirs(os.path.dirname(path), exist_ok=True)
    with open(path, "w", encoding="utf-8") as f:
        f.write(config)
    print(f"采集完成: {path}, 摘要: {digest}")

这段代码做了三件事：连接设备、抓取运行配置、按“时间戳+内容摘要”命名落盘。内容摘要（SHA-256 前 12 位）的作用是快速判断配置是否发生变化——如果两次采集的摘要相同，说明配置未变，可以跳过后续的 Git 提交，减少仓库噪音。

NETCONF 采集则使用 ncclient，通过 <get-config> 获取运行库配置。与 SSH 的文本抓取不同，NETCONF 返回的是带命名空间的 XML，需要按数据模型路径解析。例如获取接口配置时，可以指定 source=running 和 filter 子树，只取 interfaces 节点，避免全量拉取。RESTCONF 的调用方式更接近普通 HTTP 请求，使用 GET /restconf/data/ietf-interfaces:interfaces，请求头声明 Accept: application/yang-data+json，返回 JSON 后可直接用字典方式访问字段。

三、Git 版本化与差异追踪

把配置纳入 Git 管理，核心价值在于“每一次变更都有迹可循”。推荐的做法是：每台设备一个目录，目录下按时间戳存放配置快照，或者只保留一个“当前配置”文件，由 Git 记录历史版本。前者便于直接查看任意时刻的原始文件，后者便于用 git diff 比较相邻版本。两种方式可以结合：保留当前文件用于 diff，同时把历史快照作为附件或单独分支。

一个典型的提交与差异追踪流程如下：

采集器抓取配置，计算摘要，与上一次摘要比较。
若摘要不同，将新配置写入工作区，执行 git add 与 git commit，提交信息包含设备名、时间、采集协议和摘要。
使用 git diff HEAD~1 HEAD -- configs/10.0.0.1/ 查看本次变更的具体行。
将 diff 结果推送到审计系统或工单系统，作为变更凭证。

提交信息建议采用结构化格式，例如：[10.0.0.1] 2025-03-18T10:22:31 ssh sha256:a1b2c3d4e5f6。这样在 git log --oneline 中就能快速定位某台设备在某时刻的配置状态。对于 NETCONF/RESTCONF 采集的结构化数据，可以按 JSON 格式化后提交，Git 的 diff 同样能逐行展示字段变化，比纯文本配置更易读。

实践建议：采集频率不宜过高。对于稳定运行的设备，每日一次或变更后触发即可；对于频繁变更的核心设备，可缩短到每小时一次。过高的频率会让 Git 历史迅速膨胀，也会给设备带来不必要的连接压力。

四、采集失败的常见原因与处理

采集失败通常集中在四类：认证失败（用户名、密码、密钥或权限不足）、网络不可达（路由、ACL、防火墙策略）、协议不匹配（设备不支持 NETCONF，或未开启相关服务）、返回内容异常（配置被分页截断、命令回显包含错误信息）。处理方式包括：在采集器中加入重试与退避、对返回内容做关键字校验（如检测 % Invalid input）、对超时和认证失败分别记录日志并触发告警。采集器还应避免并发过高，建议对同一台设备串行采集，不同设备之间控制并发数。

注意：不要把设备密码硬编码在脚本中。应使用环境变量、密钥管理服务或专用凭据库，并在 Git 仓库中排除任何包含明文凭据的文件。

五、从采集到合规的衔接

采集与版本化完成后，配置数据就具备了“可比较”的基础。下一步的合规检查，本质上就是把当前配置与基线配置做差异比对，判断差异是否在允许范围内。Git 提供的 diff 能力可以直接复用：将基线配置放在一个分支或标签中，将当前采集结果放在工作区，执行差异比较，再对差异行做规则匹配。这样，采集、版本化、差异追踪和合规判断就形成了一条完整的数据链路，而不是彼此割裂的独立步骤。

在实际工程中，建议把采集器设计成幂等操作：同一时刻重复执行，结果一致；配置未变化时不产生新的提交。这样既能保证数据可信，也能让 Git 历史保持干净，便于后续审计和回溯。