4、升级流程设计：升级触发条件、下载阶段、校验阶段、激活阶段、回滚阶段
基站固件升级这事儿，看着简单，做起来坑特别多。我这些年经手过不下百次升级，有半夜三点成功的，也有把整片区域打瘫了的。说白了，升级流程就是一场「手术」，每个阶段都得有预案。
今天我把升级拆成五个阶段来讲：触发、下载、校验、激活、回滚。每个阶段我都会说说我踩过的坑。
4.1 升级触发条件
什么时候该升级？不是拍脑袋决定的。我个人习惯把触发条件分成三类：
| 触发类型 | 典型场景 | 优先级 |
|---|---|---|
| 安全补丁 | 发现CVE漏洞、加密算法过期 | 最高 |
| 功能迭代 | 新增特性、优化算法 | 中 |
| 运维需求 | 配置变更、日志格式调整 | 低 |
这里有个细节：触发条件必须可量化。比如「信号质量下降超过15%且持续30分钟」才算触发，而不是「感觉信号不好」。我在项目中遇到过运维人员凭感觉手动触发升级，结果把正常运行的基站给升挂了。
4.2 下载阶段
下载阶段看起来简单——把固件包从服务器拉到基站本地。但这里有个关键问题：断点续传。
基站网络环境不稳定，尤其是偏远地区的宏站。我建议下载流程这样设计：
- 分片下载：把固件包切成1MB的块，每块独立校验
- 进度记录：每下载完一块，在本地Flash记录进度
- 并发控制：最多同时下载4片，避免占满带宽
- 超时重试：单块下载超时30秒，重试3次
嗯，这里要注意：下载过程中如果断电，重启后要从上次记录的位置继续，而不是从头开始。我曾经有个项目没做断点续传，结果每次升级都要2小时，运维人员直接骂娘。
// 伪代码：下载阶段核心逻辑
typedef struct {
uint32_t block_id;
uint32_t block_size;
uint32_t crc32;
uint8_t data[1024 * 1024]; // 1MB
} DownloadBlock;
bool download_firmware() {
for (int i = last_completed_block; i < total_blocks; i++) {
DownloadBlock block = fetch_block(i);
if (!verify_block_crc(block)) {
retry_count++;
if (retry_count > 3) return false;
i--; // 重试当前块
continue;
}
save_to_flash(block);
save_progress(i);
}
return true;
}
4.3 校验阶段
校验阶段是升级流程的「守门员」。我见过太多升级失败是因为校验没做好。
校验必须做三层：
- 完整性校验：对整个固件包做SHA256哈希，确保下载没丢数据
- 签名校验：用公钥验证固件包的数字签名，防止被篡改
- 兼容性校验：检查固件版本是否与当前硬件匹配
我的经验： 兼容性校验最容易出问题。有一次我升级一款老基站，新固件里用了新的硬件寄存器，但老硬件根本没有。结果校验通过了，激活后直接死机。从那以后，我要求固件包里必须包含硬件兼容性列表，校验时逐项比对。
校验失败怎么办？直接回滚到下载前的状态，不要尝试修复。我曾经犯过傻，想着「就差一点点，手动改一下固件包里的版本号就行」，结果...嗯，不提了，都是泪。
4.4 激活阶段
激活阶段是升级流程里最危险的环节。说白了，就是把新固件从「备用区」搬到「运行区」。
我推荐使用双分区方案：
| 分区 | 用途 | 状态 |
|---|---|---|
| Active分区 | 当前运行的固件 | 只读 |
| Standby分区 | 新下载的固件 | 可写 |
激活流程：
- 将Standby分区标记为「待激活」
- 执行软重启，Bootloader检查标记
- Bootloader将Standby分区切换为Active
- 新固件启动，执行自检
- 自检通过后，标记升级成功
你想想看，为什么不用原地覆盖？因为万一写到一半断电，两个分区都坏了，基站就成砖了。双分区方案保证任何时候至少有一个可用的固件。
4.5 回滚阶段
回滚是升级流程的「安全网」。不是所有升级都能成功，你得准备好退路。
触发回滚的条件：
- 新固件启动后，心跳检测超时（30秒无响应）
- 关键业务指标下降超过阈值（比如掉线率上升5%）
- 用户手动触发回滚（运维人员发现异常）
回滚流程：
- Bootloader检测到Active分区异常
- 自动切换到Standby分区（旧固件）
- 旧固件启动，执行自检
- 自检通过后，标记回滚成功
- 记录回滚原因到日志
还有一个坑：回滚次数限制。我见过一个基站反复回滚，每次启动都失败，然后回滚，再失败，再回滚...成了死循环。解决方案是设置最大回滚次数（比如3次），超过后进入「安全模式」，只保留基础通信功能，等待人工介入。
最后说一句：升级流程设计好了，能省90%的运维精力。我这些年最大的感悟就是——别把升级当小事，它可能是你系统最脆弱的时候。每个阶段都做好预案，出了问题才能从容应对。