IoT 系列第 6 篇。第 4 篇讲了设备影子，第 5 篇讲了给"穷设备"用的 CoAP/LwM2M。这一篇把视角从"一台设备"拉到"一万台设备"：当你有 1000 台设备散在全国，发现一个 bug，总不能一台台寄回来刷吧？
适用人群：已经理解单设备 OTA（建议看过07_固件升级与OTA专栏的 Bootloader/差分/签名那几篇）、现在想解决"规模化运维"的同学。
读完你能得到：
- 分清"单设备 OTA"和"设备管理（fleet management）"是两件不同难度的活；
- 一套能落地的批量 OTA 流程：分组、灰度、断点续传、回滚；
- 远程配置的思路——不改固件也能改设备行为；
- 设备从出厂到退役的完整生命周期，以及怎么监控成千上万台设备。
一、场景：bug 不是在一台上，是在一千台上
我在07_固件升级与OTA专栏里讲了怎么给一台设备做升级：Bootloader、A/B 双分区、差分包、签名校验。那是从固件本身的角度。
但真实世界里，麻烦的是规模：
- 卖出去 1000 台气象节点，固件里有个算错了温度的 bug。
- 你不可能让用户把设备寄回来，也不可能派人挨个去现场。
- 你甚至不知道哪 800 台在线、哪 200 台因为部署在地下室常年半死不活。
这就是**设备管理（设备运维 / fleet management）**要解决的问题：把"升级一台"升级成"安全地升级一万台，且任何一步出问题都能兜住"。
二、白话前置概念表
| 术语 | 白话解释 | 为什么你要在意 |
|---|---|---|
| 设备分组 | 按型号/地区/批次把设备归类 | 灰度、批量操作的基础单位 |
| 灰度发布 | 先放 1% 设备，没问题再 10%→100% | 防止一个 bug 一夜变砖一万台 |
| 差分 OTA | 只传新旧固件差异包 | 流量贵、NB-IoT 场景的救命稻草 |
| 断点续传 | 下载中断能从上次偏移接着下 | 弱网下不全车重来 |
| 设备生命周期 | 注册→激活→运行→禁用→退役 | 每台设备都要被管理到终点 |
| 影子/物模型 | 第 4 篇讲的云端状态副本 | 远程配置不改固件就靠它 |
三、单设备 OTA vs 设备管理
| 维度 | 单设备 OTA（07 专栏） | 设备管理（本篇） |
|---|---|---|
| 核心问题 | “固件怎么安全地烧进去” | “一万台怎么安全地一起动” |
| 关注点 | Bootloader、分区、签名、校验 | 分组、灰度、成功率、回滚、监控 |
| 失败代价 | 一台变砖 | 批量变砖、舆论事故 |
| 典型工具 | 自己写的 Bootloader | 云平台批量任务 / 自建任务调度 |
一句话：07 专栏保证"升级一台不会错"，本篇保证"升级一万台不会出事"。两者是上下层关系，不是替代。
四、批量 OTA 的完整流程
[上传固件] 带版本号 + 签名 + SHA256 校验和 │ ▼ [创建升级任务] 选目标分组（如"华东地区 v1.2 设备"） │ ▼ [灰度发布] 1% ──监控成功率/崩溃率──▶ 10% ──▶ 50% ──▶ 100% │ (任一阶段失败率超阈值 → 暂停并回滚) ▼ [逐台执行] 比对版本 → 下载(可断点) → 校验 → 写备份区 → 重启切分区 → 上报结果 │ ▼ [汇总看板] 在线率 / 升级成功率 / 各版本分布 / 异常设备灰度是关键中的关键。哪怕你对自己的固件再有信心，也永远先放 1%。因为有些 bug 只在特定批次的硬件、特定地区的网络、特定温度下出现——实验室测不出来。灰度的存在就是给这些"测不出来的 bug"留一道闸。
五、远程配置：不改固件也能改行为
有些"改动"根本不值得发一次固件。比如：
- 把采样周期从 30 秒改成 60 秒（省电）；
- 把告警阈值从 30°C 调到 35°C；
- 临时关闭某一路传感器。
这些用物模型属性下发（第 4 篇的desired）或一条自定义配置 Topic 就能搞定，设备收到后存到 Flash/NVS 里，下次启动也生效。好处是：秒级生效、零流量成本、可随时改回去。
⚠️ 远程配置和 OTA 的边界：配置改"参数和行为"，OTA 改"程序本身"。别为了改一个阈值就发固件，也别为了换程序去走配置通道。
六、设备生命周期：每台设备都要有终点
| 阶段 | 发生了什么 | 你要做什么 |
|---|---|---|
| 注册 | 出厂烧录/产线写入设备身份（见第 8 篇安全） | 一机一密，身份可溯源 |
| 激活 | 首次联网上线 | 绑定到用户/项目，标记"在用" |
| 运行 | 日常上报、接受控制 | 监控在线率、异常、版本 |
| 禁用 | 召回/安全事件/欠费 | 停用证书、拒绝对外服务 |
| 退役 | 报废/替换 | 清证书、释放资源、归档数据 |
最容易忘的是退役：设备拆了、丢了，它的证书还有效，就可能被冒用。安全角度（呼应第 8 篇）要求能"一键吊销"。
七、实战：用 MQTT + 版本广播自建一套批量 OTA
如果不用云平台，自己也能搭一套最小可用的（适合私有部署）：
平台 ──广播──▶ topic: fleet/{group}/ota/version payload: {"v":"1.3.0","url":"https://...","sha256":"...","sig":"..."} 设备(版本低于1.3.0): 1. 请求下载(带 offset 支持断点): GET url?range=bytes=offset- 2. 写 Flash 备份区 3. 校验 sha256 + 验签 4. 标记"待切换"，重启 5. 新固件启动成功 → 上报 result=success 6. 新固件启动失败(看门狗复位) → 自动回退旧分区 设备 ──上报──▶ topic: fleet/{id}/ota/result payload: {"v":"1.3.0","status":"success"|"fail"}平台侧要统计每个result，算成功率。成功率低于阈值（比如 95%）就立刻暂停灰度，人工介入。这比"全量一把梭"安全一万倍。
八、新手必踩的 5 个坑
| 坑 | 后果 | 正确做法 |
|---|---|---|
| 跳过灰度直接全量 | 一个隐藏 bug 一夜变砖一万台 | 1%→10%→50%→100%，每档看数据 |
| 版本号回退被拒（防回滚机制） | 想降级救场却刷不进去 | 保留"紧急回退版本"白名单 |
| 差分包机型/分区不匹配 | 校验失败，升级卡死 | 差分包绑定硬件型号+分区表版本 |
| 升级中途掉电 | 单分区变砖（无备份） | 必须 A/B 双分区 + 看门狗（见07_固件升级与OTA） |
| 统计口径错（只算"开始"不算"成功"） | 假成功率，实际一半失败 | 以"重启后上报 success"为准 |
九、动手练（含故意搞破坏）
- 用 EMQX（Docker 一键起）搭一个本地 broker，写个 Python 脚本模拟 10 台设备（各自独立 client_id）。
- 设计"版本广播 + ACK"机制：平台发
fleet/+/ota/version，设备比对后开始"下载"（脚本里用time.sleep模拟），结束上报result。 - 统计这 10 台的
result，打印成功率。 - 故意破坏：让其中 1 台"下载"过程抛异常不上报，看你的成功率统计会不会失真——想清楚该用"开始数"还是"成功数"做分母。
- 加一个"失败率 > 20% 自动暂停"的逻辑，验证能拦住批量事故。
十、小结
设备管理是 IoT 从"玩具"走向"产品"的门槛。它的核心不是某一项技术，而是一整套兜底思维：灰度拦 bug、断点续传抗弱网、回滚防变砖、监控早发现。当你能拍着胸脯说"我的一万台设备升级有 99% 成功率且出事能停"，你就具备了嵌入式工程师之外、更值钱的"运维思维"。
下一篇：《IoT 安全入门：设备认证、传输加密与固件防篡改》
