4. 升级策略与流程设计：静默升级、强制升级、灰度发布、回滚机制设计

升级策略这东西，说白了就是「什么时候升、怎么升、升坏了怎么办」。我见过不少团队，OTA 功能做出来了，结果一上线就炸——要么用户嫌弹窗烦，要么升级到一半断网变砖。嗯，策略没设计好。

这一章，我把四种核心策略掰开揉碎讲清楚。每种策略都有适用场景，也有坑。我会结合自己踩过的雷，帮你把流程画明白。

4.1 四种升级策略的适用场景

先看一张总览表，后面再逐个细讲。

4.2 静默升级：让用户「无感」才是最高境界

静默升级，就是设备在后台偷偷把活干了。用户早上起来，发现设备还是那个设备，但 bug 没了，性能还快了。这才是好体验。

设计要点：

• 下载时机： 我习惯选在设备空闲且连接 Wi-Fi 时触发。比如凌晨 2-4 点，或者用户长时间不操作时。
• 安装时机： 非关键系统可以热替换（比如蓝牙协议栈），关键系统（如内核）需要下次重启时生效。
• 资源控制： 下载速度要限流，别把带宽吃满。我一般设 30% 带宽上限，避免影响用户正常使用。

伪代码示例：

// 静默升级调度逻辑
void silent_upgrade_check() {
    if (is_idle() && is_wifi_connected() && is_battery_above(30%)) {
        start_download_with_throttle(30%);  // 限速30%
        if (download_complete && verify_checksum()) {
            schedule_install_at_next_reboot();
        } else {
            retry_count++;
            if (retry_count > 3) {
                report_to_cloud("SILENT_FAILURE");
                switch_to_manual_mode();
            }
        }
    }
}

4.3 强制升级：该强硬时别手软

有些场景，你不能给用户选择权。比如发现了一个远程代码执行漏洞，或者新协议和老版本不兼容。这时候必须强制升级。

设计要点：

• 倒计时机制： 弹窗提示「系统将在 60 秒后升级」，用户可推迟 3 次，但最终必须执行。
• 断点续传： 强制升级如果下载中断，恢复后继续下载，别从头来。我在项目中遇到过用户网络差，一个 100MB 的包断了 8 次，没断点续传的话用户会疯。
• 降级保护： 强制升级后，旧版本必须被标记为「不可用」，防止用户手动降级回去。

4.4 灰度发布：小步快跑，别一把梭

灰度发布，说白了就是「先让一小部分人试，没问题再全量推」。我个人的习惯是：1% → 5% → 20% → 100%，每阶段观察 24 小时。

常见灰度策略对比：

灰度发布流程图：

4.5 回滚机制：最后一道防线

回滚不是「后悔药」，而是「安全绳」。我见过太多团队只做升级不做回滚，结果出问题只能让用户返厂。嗯，那画面太美我不敢看。

回滚策略设计：

• A/B 分区方案： 设备保留两个系统分区（active 和 inactive）。升级时写入 inactive 分区，下次启动切换。如果启动失败，自动回退到 active 分区。
• 版本号管理： 每个固件包携带兼容性矩阵。比如「版本 4.2 可以回滚到 4.1，但不能回滚到 3.x」。
• 回滚触发条件：
  • 自动回滚：设备连续重启 3 次、关键服务启动超时、心跳丢失。
  • 手动回滚：运维后台一键下发回滚指令。

4.6 策略组合：实际项目怎么搭？

实际项目中，很少只用一种策略。我分享一个典型的组合方案：

1. 安全补丁： 静默升级 + 自动回滚。用户无感，出问题自动恢复。
2. 功能大版本： 灰度发布（1%→5%→20%→100%）+ 强制升级（最后一批）。灰度阶段发现问题就回滚，全量阶段用强制升级保证一致性。
3. 紧急漏洞： 强制升级 + 倒计时 30 秒 + 回滚保留旧版本 7 天。万一新版本有兼容问题，还能切回去。

好了，四种策略讲完了。你想想看，你的项目适合哪种组合？别急着全量推，先画好流程图，把回滚路径想清楚。这才是架构师该干的事。