一次固件在实验室成功升级，只证明“这台设备在这次条件下写入并启动了新镜像”。它没有证明车队里不同硬件修订、运营商网络、剩余电量、存储磨损、现场外设和长时间离线设备都能安全升级。真正的 IoT OTA 系统不是文件分发器，而是一套限制故障半径、判断是否继续扩张、并把未知状态收敛回可运营状态的发布控制面。
灰度也不是简单把 1%、10%、100% 写进三个按钮。若第一批 1% 全在同一办公室、同一硬件批次和同一网络，它只能验证一个故障域；若每个环没有进入条件、观察窗口、停止信号和恢复路径，“分批”只是把同一事故延迟发生。安全 OTA 的核心单位不是百分比，而是可解释的故障域与可验证的发布合同。
本文讨论车队级控制面：如何分环、哪些设备能够进入、用什么证据判定健康、何时停止扩张、回滚为什么必须先验证可达，以及离线设备如何在数周后仍服从已更新的发布策略。已有的固件、模型与配置版本管理文章回答“更新对象如何拆分”；这里回答“一个发布如何穿过真实车队并安全结束”。
1. 先写失败预算，再决定第一环有多大
发布设计应从“最坏情况下允许损失什么”开始，而不是从平台默认比例开始。冷库网关重启五分钟可能导致本地缓存积压；门禁控制器失联可能触发人工值守；电池传感器反复下载则会消耗数月续航。它们不能共享同一套 canary 比例与停止门槛。
先把失败后果拆成四类。第一类是可自动恢复的短暂中断，例如重启后遥测补传；第二类是需要远程干预但业务仍可运行的降级，例如新功能关闭；第三类需要现场服务，例如启动链损坏或外设驱动不兼容；第四类会影响安全、资产或法规义务，必须把发布窗口、双人审批和本地旁路写进变更控制。每类都应有最大受影响设备数、最长不可见时间和恢复 Owner。
这会改变“1%”的含义。十万台低风险传感器的 1% 是一千台，可能远超现场团队的恢复能力；二十台关键网关的 1% 不到一台，又没有统计意义。第一环更合理的上限是：在不超过现场与远程恢复容量的前提下，覆盖所有高风险故障域所需的最小设备集合。
建议为每次发布建立 release_id 与不可变 manifest。manifest 至少绑定镜像摘要、签名、目标硬件/bootloader 范围、允许的前置版本、分区需求、配置迁移版本、回滚目标和截止时间。设备收到的不是“最新版本”，而是一个明确 release 的 job。工作区既有的 Device Job 分层方案也把 OTA 归入可跟踪、可暂停、可重试和可回滚的远程任务，而不是即时命令通道；这正是控制面能够对每台设备保留执行状态的基础。
2. 用故障域组成环，不要随机抽样后祈祷
设备分组需要同时表达业务重要性与技术差异。至少考虑 hardware_revision、bootloader 版本、当前固件、地区、网络类型、供电方式、存储容量、外设组合、客户/SLA、维护窗口和本地恢复能力。不要把这些标签只用于报表；发布服务要在创建 job 时固化目标快照，避免成员在发布过程中静默变化。
一个可用的环形设计通常包含四层，但名称可以自定义：
| 发布环 | 目标 | 典型成员 | 进入下一环的必要证据 |
|---|---|---|---|
| 工程环 | 验证包、签名、迁移和基础遥测 | 可物理接触的内部设备，每个硬件修订至少一台 | 安装、首启、回滚演练均完成 |
| 风险覆盖环 | 暴露故障域差异 | 弱网、低电量边界、不同运营商、不同外设与旧 bootloader | 每个关键故障域都有完整观察窗口 |
| 业务 canary | 验证真实负载和流程 | 低关键度站点，但运行真实任务 | 业务信号、告警和人工反馈无退化 |
| 扩张环 | 受控增加覆盖 | 按区域/客户/维护窗口分批 | 前环 SLO、最小样本与观察时间同时满足 |
这里最容易犯的错是只看总成功率。假设 200 台中 196 台成功，98% 看似很好；但四台失败都来自同一硬件修订，就已经证明该故障域不应扩张。每个环的报告必须能够按 cohort 切片，且稀有但高后果的失败要用规则而非平均值覆盖。
Azure Device Update 的设备组由设备标签形成，部署会作用于组；其部署具有动态性质，新加入或更改组成员的设备可能在活动部署下自动收到更新。这说明“组”不是静态名单时，平台必须明确成员变化的语义。对于高风险发布，我们更倾向固化目标快照；需要持续部署的场景，则把新成员放入单独的准入队列，而不是让它跳过 canary。
3. 每台设备都要通过准入合同
发布环解决“先更新谁”，设备准入合同解决“这台设备现在能不能更新”。准入检查应在云端筛选和设备本地复核两次执行，因为平台库存可能过期，而设备知道即时电量、存储和运行状态。
云端检查目标型号、硬件修订、当前版本、证书状态、最近在线时间、所属站点、维护窗口和是否存在互斥 job。设备本地再检查镜像签名、下载空间、写入空间、电源稳定性、温度、bootloader 能力、回滚分区、配置迁移前置条件，以及关键业务能否暂时停止。结果不能只有 FAILED；建议至少区分 REJECTED_INCOMPATIBLE、DEFERRED_POWER、DEFERRED_WINDOW、FAILED_DOWNLOAD、FAILED_VERIFY、FAILED_INSTALL 和 FAILED_HEALTH，因为这些状态对应完全不同的处理策略。
下载也属于发布风险。大规模设备同时拉取镜像会冲击 CDN、蜂窝网络和电池。应按站点与运营商限速、支持断点续传和内容摘要校验，并让设备在重试前退避。AWS IoT Jobs 支持固定或指数 rollout rate，也能按已通知或成功数量提高速率；但速率增长条件不等于健康条件。控制面仍需把安装结果、首启验证和业务信号纳入“允许进入下一环”的自定义判定。
最后，准入失败不是垃圾数据。若大量设备因 bootloader 太旧而拒绝，说明前置迁移计划缺失；若低电量设备持续延期，说明发布截止时间与电池策略冲突；若存储不足集中于某批硬件，发布清单或设备库存需要纠正。cohort_admission_contract 应保留原因、观测时间、下一次评估和 Owner，使“未升级”成为可运营队列。
4. 成功必须穿过四层健康证据
“下载完成”距离成功很远，“设备重新上线”也不够。建议把每台执行的证据拆成四层，并只在全部满足后确认镜像。
第一层是安装完整性：签名与摘要正确，写入目标分区成功，配置迁移有校验结果。第二层是启动完整性：bootloader 选择新镜像，系统未进入重启循环，watchdog、存储和关键驱动初始化正常。第三层是功能健康：设备能够认证、上报、接收 Device Job、访问必须的外设，并在本地控制逻辑上产生合理结果。第四层是业务健康：冷链温度采样没有断层、网关缓存能够排空、告警没有异常激增、现场流程未被阻塞。
这四层需要不同时间尺度。启动检查可能在几分钟内结束；内存泄漏、连接抖动或采样漂移可能需要数小时或一个完整业务周期才能暴露。观察窗口应按风险设定，同时规定“至少完成多少台/多少故障域”和“至少观察多久”。没有最小样本就使用百分比，会在小 canary 中产生误导；只等时间而没有执行量，也会让大量离线设备制造虚假安全。
ESP-IDF 的回滚机制很好地展示了设备侧确认语义：启用回滚时，新应用首次启动处于待验证状态，应用需要在自检通过后调用确认函数，否则重启时可回退。云端平台应把这种本地确认作为可信证据，而不是看到 MQTT 重连就宣布成功。不同 RTOS/bootloader 实现会不同，但原则一致：新镜像必须经过 probation，并由新镜像之外的启动链保留最后已知良好版本。
flowchart LR
A("Signed release candidate"):::blue --> B{"Cohort admission"}:::orange
B -->|Rejected| X("Hold and record reason"):::red
B -->|Admitted| C("Download and verify"):::cyan
C --> D("Install to inactive slot"):::slate
D --> E("First boot probation"):::violet
E --> F{"Health window"}:::orange
F -->|Pass| G("Confirm image"):::green
F -->|Degrade| H("Stop expansion"):::red
H --> I("Rollback or local recovery"):::red
I --> J("Reconcile device state"):::slate
G --> K{"Next ring allowed?"}:::orange
K -->|Yes| B
K -->|No| H
classDef blue fill:#EAF4FF,stroke:#3B82F6,color:#16324F,stroke-width:2px;
classDef cyan fill:#E9FBF8,stroke:#14B8A6,color:#134E4A,stroke-width:2px;
classDef slate fill:#F8FAFC,stroke:#64748B,color:#1F2937,stroke-width:2px;
classDef violet fill:#F4EDFF,stroke:#8B5CF6,color:#4C1D95,stroke-width:2px;
classDef orange fill:#FFF3E8,stroke:#F08A24,color:#7C3F00,stroke-width:2px;
classDef green fill:#ECFDF3,stroke:#22C55E,color:#14532D,stroke-width:2px;
classDef red fill:#FEF2F2,stroke:#EF4444,color:#7F1D1D,stroke-width:2px;
图里的 Confirm image 必须晚于健康窗口；否则 A/B 分区虽然存在，最后已知良好镜像却会被过早覆盖。Stop expansion 也不等于立即强杀所有 IN_PROGRESS 设备：正在写 flash 的设备可能因强制取消而更危险。平台需要分别定义停止新派发、取消排队任务、让在途任务完成，以及触发设备侧回滚的语义。
5. 中止规则要在发布前可执行
事故中临时讨论“失败多少算多”会放大确认偏差。创建 release 时就应保存中止策略，并让自动规则与人工权限都可审计。AWS IoT Jobs 的 AbortConfig 可以按 FAILED、REJECTED、TIMED_OUT 等类型设置最小执行数量和失败百分比；Azure Device Update 也支持用失败百分比和最小失败设备数触发自动回滚。这些机制给出了正确形状：阈值必须同时包含分母成熟度与故障比例。
但生产规则不应只有一个总失败率。可以组合以下信号：
- 任一安全或数据损坏事件立即停止，不等待统计阈值；
- 特定硬件/地区 cohort 的安装失败超过其预算时停止该 cohort；
- 首启回滚、重启循环、认证失败或遥测断流超过基线时停止扩张；
- 下载失败激增但设备仍健康时暂停速率并调查 CDN/网络，不自动回滚已成功设备；
- 业务指标退化而技术指标正常时，仍应停止，因为新固件可能“在线但做错事”；
- 人工现场报告出现不可遥测的异常时，必须有一键 hold 与变更记录。
一份实用的 abort_recovery_ledger 至少保存触发信号、首个受影响 cohort、当前各状态数量、停止动作、回滚目标、决定人、时间、证据链接和下一次复核。这样团队才能回答：停止之后哪些设备还在写入，哪些已确认新版本，哪些会自动回滚，哪些需要人工服务。只有一个 release 总状态，无法支持现场恢复。
重试策略也要按失败类型区分。网络超时可指数退避；签名失败、硬件不兼容和分区不足不应盲目重试；首启健康失败应优先回滚；业务信号异常则先冻结扩张并保全日志。把所有失败都设成三次 retry，会耗电、占带宽，还可能反复触发一个确定性缺陷。
6. 回滚能力必须在发布前证明可达
“平台有 rollback 按钮”不代表设备能回去。真正的回滚链路包括：旧镜像仍在可启动分区、bootloader 能判断新镜像失败、配置和数据格式向后兼容、设备在故障后仍能接收命令，或能在无云连接时自动恢复。如果新版本已经不可联网，依赖云端下发回滚命令就形成循环依赖。
因此每个硬件修订在工程环至少演练三种失败：镜像验证失败、首启自检失败、运行一段时间后触发健康退化。演练要记录最终启动分区、配置版本、云端 job 状态、遥测恢复时间和是否需要物理访问。升级前还要验证旧版本能读取迁移后的必要数据；不可逆数据库/文件格式变更应采用 expand-migrate-contract，或把迁移推迟到新镜像确认之后。
对于只有单分区、空间不足或 bootloader 不可更新的存量设备，必须承认它们没有等价的自动回滚能力。可选策略包括小得多的环、只在现场维护窗口升级、保留串口/USB/恢复卡路径、先发布引导链升级，或将设备排除在高风险功能之外。风险不能通过给一个字段写 rollback_supported: true 消失。
现场恢复图提醒一个常被忽略的成本：每台砖化设备都对应人员、行程、停机和访问许可。发布前应从设备库存中计算“自动回滚可达”“远程 recovery 可达”“必须现场”的数量，并让 canary 上限不超过真实服务能力。
7. 离线与迟到设备决定发布能否真正结束
IoT 车队不会在同一小时在线。季节设备、移动资产、弱网站点可能在 release 创建数周后才出现。若平台把 “95% 完成”直接当作结束，剩余 5% 会在未来带着旧漏洞或跳过已经发现问题的 release 上线。
每个 release 需要明确生命周期：ACTIVE 接受符合条件的设备，HELD 停止新派发但保留现场状态，SUPERSEDED 被新 release 替代，EXPIRED 不再允许安装，CLOSED 表示所有目标已经进入终态或进入有 Owner 的例外队列。迟到设备连接时，先重新执行准入，而不是继续使用数周前缓存的 job；若原 release 已中止或过期，应取消任务并重新解析当前允许路径。
还要处理“下载一半后离线”“安装后未回报”“云端认为失败但设备实际成功”这些不确定状态。设备应持久化 release_id、阶段、镜像摘要和最近错误；云端通过幂等状态上报与版本读回做 reconciliation。对长时间 IN_PROGRESS 的设备，不要自动假设失败并重复安装，而应在重连后询问本地分区和运行版本，再决定继续、确认或回滚。
发布完成率因此应拆成：已确认成功、已自动回滚、明确拒绝、延期待条件、不可见待对账、需要现场服务和已从范围移除。只有这些分桶都有 Owner 与处置规则，release 才能关闭。一个绿色圆环图无法代替这张责任账。
8. 从小系统开始，但保留控制面的骨架
车队只有几十台时，不一定需要采购完整 OTA 平台。可以用对象存储/CDN、签名服务、Device Job 表、设备状态表和一个发布 worker 实现最小闭环，但不要省掉核心语义：不可变 manifest、目标快照、设备准入、状态机、分环速率、中止规则、健康证据、回滚目标和审计日志。
实施顺序可以分四步。第一步只在工程设备上实现签名校验、断点下载、A/B 分区和首启确认；第二步加入 cohort 标签、发布环与逐设备 job 状态；第三步接入业务健康指标、中止策略和恢复台账；第四步才自动扩环，并通过故障注入验证弱网、断电、磁盘满、坏签名、驱动初始化失败和云端超时。自动化应建立在恢复演练之后。
上线前最值得问的不是“OTA 按钮能不能工作”，而是这五个问题：第一批设备是否覆盖最危险故障域？扩张决定使用了哪些成熟证据？停止之后在途设备会发生什么？设备失去云连接时还能否回到最后良好版本？三周后上线的迟到设备会服从哪一个 release？若答案能从 manifest、状态机和恢复台账中直接查到，系统才具备规模化发布的基础。
参考资料与证据边界
- AWS IoT Jobs：rollout、scheduling、abort、timeout 与 retry
- AWS IoT Jobs API：rollout 与 AbortConfig 参数
- Azure Device Update：deployment lifecycle 与 automatic rollback
- Azure Device Update：device groups
- ESP-IDF OTA：首启确认与 rollback
本文的工作区证据来自 Device Job 分层与既有 Edge AI OTA 架构资产，证明了任务状态、暂停、重试和版本拆分的工程边界；它不是本轮客户量产数据。文中的阈值形状与实施方法可以复用，具体比例、观察窗口、维护容量和 SLO 必须在目标硬件、网络、现场流程和故障预算上重新校准。
