批量升级怎么做才不出错
几十台设备集中升级，靠人工作业必然出错，脚本化是唯一可行的路径。脚本的核心不是自动化本身，而是把流程固化成五步：传输文件、校验完整性、指定启动文件、保存配置、重启验证。其中校验环节最容易被省略，也最容易造成后果——命令失败后脚本继续往下执行，设备仍停在旧版本，而执行报告显示全部成功。分批策略同样重要：先试点一台，再同型号小批，最后按区域分批推进。
基本信息
| 适用场景 | 几十台到上百台设备的版本升级 |
|---|---|
| 五步流程 | 传输、校验、指向、保存、重启 |
| 华为命令 | tftp get、startup system-software、save force、reboot |
| 思科命令 | copy tftp:、verify /md5、boot system、copy run start、reload |
| H3C 命令 | tftp get、boot-loader file、save force、reboot |
典型使用场景
- 版本统一：全网设备批量升级到指定版本，消除版本碎片
- 安全补丁：应急漏洞修复时在限定窗口内完成大批量升级
- 新设备上线：到货设备批量刷到现网统一版本再部署
- 异地分支：按区域分批推进，避免一次性影响全部站点
- 回退演练：验证脚本的回退分支是否真的可用
脚本骨架（思路示意）
脚本骨架（思路示意）
for host in hosts:
run(host, 'tftp <srv> get <image> <image>') # 传输系统文件
check_size(host, image) # 校验文件大小
run(host, 'startup system-software <image>') # 或 boot-loader 指定启动
run(host, 'save force') # 保存配置
run(host, 'reboot')
wait_online(host) # 等待设备恢复在线
verify_version(host) # 回读版本，失败即告警三厂命令
三厂命令
! 华为 VRP
<Huawei> tftp 192.168.1.100 get NEW.cc NEW.cc
<Huawei> dir flash:/NEW.cc
<Huawei> startup system-software NEW.cc
<Huawei> save force
<Huawei> reboot
! 思科 IOS
SW-CORE-01# copy tftp://192.168.1.100/NEW.bin flash:NEW.bin
SW-CORE-01# verify /md5 flash:NEW.bin
SW-CORE-01(config)# boot system flash:NEW.bin
SW-CORE-01# copy running-config startup-config
! H3C Comware
<H3C> tftp 192.168.1.100 get NEW.ipe NEW.ipe
<H3C> boot-loader file flash:/NEW.ipe main
<H3C> save force分批策略与检查点
| 阶段 | 规模 | 放行条件 |
|---|---|---|
| 试点 | 单台非关键设备 | 版本回读一致且业务验证通过 |
| 小批 | 同型号若干台 | 批量脚本执行全绿、无异常告警 |
| 分批推广 | 按区域或业务分批 | 每批完成后业务验证再放行下一批 |
| 收尾核对 | 全网 | 版本统计一致、无遗漏设备 |
| 回退准备 | 全程 | 旧版本文件在设备或服务器上可用 |
避免所有设备齐步走。一台设备卡在升级中途会拖住整个维护窗口，分批推进可以保证即使出问题也只有一小部分受影响，回退范围也可控。
脚本必须有超时与回读校验。没有校验的脚本在命令失败后会继续执行后续步骤，最终报告显示成功、设备实际仍在旧版本，这类问题往往在后续故障时才会暴露。