📚 课程目录第3章升级前资产与版本清点

3. 升级前资产与版本清点

在正式升级 EOS 之前，最容易被低估、却最容易在升级窗口里“翻车”的环节，就是资产与版本清点。很多团队以为“知道设备型号和版本”就够了，但真正决定升级能否顺利推进的，是能否在升级前拿到一份可核对、可对比、可回滚的基线清单：每台设备的型号、当前 EOS 版本、运行配置、硬件模块、序列号、管理地址、所属站点与角色，以及它们之间的对应关系。没有这份基线，升级就变成了“盲升”——升级后配置漂移、模块不识别、版本不兼容，都无从判断是升级引入的，还是原本就存在。

本节的核心任务，是用 eAPI、SNMP、CloudVision 或脚本，把分散在数百台交换机上的信息批量采集回来，形成一份结构化的升级基线清单。下面从采集对象、采集通道、字段设计、脚本实现和结果校验五个方面展开。

一、先明确要采集什么：基线清单的字段设计

基线清单不是“设备列表”，而是升级决策的数据底座。建议至少包含以下字段，并按“设备身份—软件版本—硬件构成—配置状态—管理属性”分组：

设备身份：主机名、序列号、管理 IP、站点/机房、设备角色（Spine/Leaf/Border）。
软件版本：当前 EOS 版本（如 4.29.2F）、镜像文件、启动配置中指定的镜像、是否启用 TerminAttr。
硬件构成：型号（如 DCS-7050SX3-48YC8）、线卡/子卡、电源、风扇、光模块数量与类型。
配置状态：运行配置的哈希值、配置大小、最近一次变更时间、是否有未保存配置。
管理属性：eAPI/SNMP 可达性、管理接口状态、NTP 同步状态、CloudVision 注册状态。

这些字段中，运行配置哈希和未保存配置标记最容易被忽略，却直接决定升级前是否需要先做配置备份或提交。若设备存在未保存配置，升级重启后配置会丢失，必须在清点阶段就标记出来。

二、采集通道的选择：eAPI、SNMP、CloudVision 与脚本

四种通道各有适用场景，实际项目中往往组合使用：

eAPI：基于 HTTP/HTTPS 的 JSON-RPC 接口，适合批量执行 show 命令并直接拿到结构化 JSON。例如 show version、show inventory、show running-config 都可以通过 eAPI 返回。它是最适合脚本化采集的通道。
SNMP：适合采集型号、序列号、接口状态等 MIB 对象，但配置全文和版本细节不如 eAPI 完整，通常作为补充或兜底。
CloudVision：如果设备已注册到 CVP，可直接从 CVP 的 inventory 和 compliance 视图导出设备清单、版本分布和配置合规状态，适合大规模、多站点的统一清点。
脚本：用 Python + requests 调用 eAPI，或使用 Ansible 的 eos_command 模块，把采集结果写入 CSV/JSON，形成基线文件。

选择原则是：能走 eAPI 就不走 SNMP，能走 CVP 就不逐台登录。eAPI 返回结构化数据，省去文本解析；CVP 提供全局视图，省去逐台汇总。

三、用 eAPI 批量采集的脚本示例

下面是一个最小可用的 Python 采集脚本，遍历设备列表，通过 eAPI 获取版本、硬件和配置信息，并写入 CSV。示例中的设备 IP、用户名和密码均为教学假设值，实际使用时替换为真实环境参数。

import requests, json, csv

DEVICES = [
    {"host": "10.0.1.11", "role": "spine"},
    {"host": "10.0.1.21", "role": "leaf"},
]
AUTH = ("admin", "Cv@2024Demo")
CMDS = ["show version", "show inventory", "show running-config"]

def eapi_run(host, cmds):
    url = f"https://{host}/command-api"
    payload = {
        "jsonrpc": "2.0", "method": "runCmds",
        "params": {"version": 1, "cmds": cmds, "format": "json"},
        "id": "1"
    }
    r = requests.post(url, data=json.dumps(payload),
                      auth=AUTH, verify=False, timeout=15)
    return r.json()["result"]

rows = []
for d in DEVICES:
    res = eapi_run(d["host"], CMDS)
    ver = res[0]
    inv = res[1]
    cfg = res[2]
    rows.append({
        "host": d["host"],
        "role": d["role"],
        "model": ver.get("modelName"),
        "eos_version": ver.get("version"),
        "serial": ver.get("serialNumber"),
        "config_hash": hash(json.dumps(cfg, sort_keys=True)),
        "inventory_items": len(inv.get("systemInformation", {}).get("components", []))
    })

with open("eos_baseline.csv", "w", newline="") as f:
    writer = csv.DictWriter(f, fieldnames=rows[0].keys())
    writer.writeheader()
    writer.writerows(rows)

脚本执行后，eos_baseline.csv 就是升级基线清单的雏形。注意 verify=False 仅用于实验环境，生产环境应配置 CA 证书或使用受信任的证书链。

四、采集结果的结构化与校验

采集回来的原始数据需要经过校验，才能成为可信基线。建议做三类校验：

完整性校验：设备总数是否与 CMDB 或 CVP 中的数量一致，是否有设备采集失败。
一致性校验：同一型号设备的 EOS 版本是否在预期范围内，是否存在“同角色不同版本”的异常分布。
配置校验：运行配置哈希是否与上一次基线一致，若不一致，说明升级前已有变更，需要先确认变更来源。

校验完成后，把清单按“站点—角色—型号—版本”分组，就能直观看到升级影响面。例如：某站点 12 台 Leaf 中，有 3 台仍运行 4.28.3F，其余为 4.29.2F，那么这 3 台就是本次升级的重点对象。

五、基线清单的交付形态

最终交付的基线清单，建议同时保留两种形态：CSV/Excel 用于人工核对和评审，JSON 用于后续自动化对比和回滚校验。清单中应明确标注“采集时间”和“采集通道”，因为不同时间点的版本和配置可能不同，基线必须带时间戳才有意义。

实践提示：如果设备已接入 CloudVision，优先从 CVP 导出 inventory 和 compliance 报告，再用 eAPI 对差异设备做二次确认。这样既保证覆盖面，又保证关键设备的细节准确。

注意：清点阶段不要修改任何设备配置。基线清单的价值在于“如实记录升级前状态”，任何采集过程中的配置变更都会污染基线，导致升级后无法判断差异来源。

把上述流程走完，你得到的不仅是一份设备清单，而是一份升级决策依据：哪些设备需要优先升级、哪些设备存在配置漂移、哪些设备硬件模块需要提前确认兼容性。下一阶段的升级窗口规划、镜像分发和回滚预案，都将以这份基线为起点。