远程升级的三个难点
一是下发通道本身不可靠，弱网与断电会让升级中断；二是设备状态不一致，部分已升级、部分未升级的中间状态必须能安全运行；三是回滚，新版本异常时往往没有人员到场。因此升级流程要设计成可重试、可回滚、可灰度的。
基本信息
| 版本管理 | 固件与配置分别编号，设备主动上报当前版本 |
|---|---|
| 分发方式 | 按批次或标签灰度，先小范围验证再逐步扩大 |
| 传输要求 | 支持断点续传与完整性校验 |
| 回滚通道 | 保留上一版本，异常时自动或人工回滚 |
| 升级窗口 | 避开业务高峰，必要时限定在设备空闲时段 |
典型流程
典型流程
# 下发：平台下发版本信息，设备确认当前状态可升级
# 下载：分块下载并校验完整性，中断后从已确认位置续传
# 应用：写入备份分区或双分区切换，避免中途断电变砖
# 校验：设备重启后上报新版本号与自检结果
# 回滚：自检失败或平台未确认时切回上一版本典型使用场景
- 批量固件升级：分批推送并观察批次成功率
- 参数批量下发：配置与固件分开管理，避免每次调参都升级固件
- 紧急修复：出现安全问题时按批次快速推送补丁
- 现场回滚：新版本在现场出现不兼容时快速恢复
升级要能暂停与中止：发现异常时先停止扩散，比事后逐台回滚便宜得多。平台侧应能实时查看各批次的成功与失败分布。
一次性全量推送是风险最高的做法：新版本一旦有问题，全部设备同时不可用，恢复手段极其有限。
状态可见性
升级期间平台应能查到每台设备当前的版本与所处阶段：缺少这份可见性，批量操作就变成盲操作，失败设备只能靠现场巡检才发现。