小米米家 · 海量设备管理：OTA与批量运营
技术栈：小米 OTA（差分升级 / 灰度 / 回滚）+ 设备运营看板（以小米米家 / MiOT 为案例） 适用场景：固件如何安全批量升级、运营如何盯住十亿台设备
米家设备卖出去只是开始。固件有 bug 要修、功能要迭代——这些事不可能靠用户一个个手动升级。
对消费级 IoT 来说，OTA 不是锦上添花，而是生死线。一台工业网关可以派人现场刷机，一台米家灯泡只能靠用户无感升级。海量设备一旦因一次坏升级集体变砖，召回成本是灾难级的。所以米家 OTA 的核心不是「快」，而是「可控、可观测、可退」。
1.问题背景：OTA 为什么是生死线
- 规模巨大：十亿级设备，哪怕 1% 升级失败也是一千万台变砖，远超人肉挽回的极限
- 环境不可控：设备在千万家庭里，网络质量参差，升级中途断电、断网是常态
- 成本零容忍：不能派人上门，不能要求用户操作，必须全程静默
- 安全必须内建：固件签名、回滚保护、防降级攻击，每一环都缺不得
2.设计理念：差分 + 灰度 + 回滚三件套
| 机制 | 作用 | 米家做法 |
|---|---|---|
| 差分升级 | 只传差异部分，节省带宽和升级时间 | 差分包通常几百 KB，全量包可能几 MB |
| 灰度发布 | 先推 1% 设备验证，再逐步放量 | 按设备型号/固件版本/地域分批 |
| 自动回滚 | 升级失败自动退到上一个稳定版本 | 设备本地保留双分区，新固件写入备用分区 |
米家 OTA 大多走差分模式——服务器对比新旧固件生成 patch 包，设备下载后本地合成。对于 BLE Mesh 低功耗节点，OTA 走好友节点中继转发，避免每个节点各自连云端。
灰度流程：1% 内部设备 → 5% 公测 → 20% → 50% → 全量。每阶段观察 crash 率、功能异常率、用户投诉量，任一指标超阈值立即暂停。
设备本地保留两个固件分区。升级时新固件写入备用分区，重启后若新分区启动失败，硬件 watchdog 自动切回旧分区——整个过程用户无感，设备最多重启一次。
BLE Mesh 低功耗节点的 OTA 更特殊：它们平时深度休眠，不能直接接收云端推送。米家的做法是由好友节点（Friend Node）代收固件包并缓存，低功耗节点周期性唤醒时从好友节点拉取——这就是 BLE Mesh 的"分布式 OTA"。
3.实际应用：一次典型 OTA 流程
- 运营在后台创建升级任务，选择目标设备范围（型号/版本/地域）
- 系统按灰度比例推送升级通知
- 设备在闲置时段（如凌晨）自动下载差分包
- 下载完成后校验签名，写入备用分区
- 设备重启进入新分区，上报新版本号
- 运营看板实时监控升级成功率、失败原因分布
一个真实教训：某厂商曾把"全量 OTA"一次推到所有设备，结果 3% 的设备因固件与特定批次模组不兼容而变砖。召回成本超千万。此后米家 OTA 强制要求"灰度至少三阶段，任一阶段成功率低于 99.5% 自动暂停"——这是用流程兜住规模风险。
运营看板的另一面是"数据驱动产品迭代"。OTA 升级数据不仅反映技术指标，还暴露用户行为：某版本升级后某功能的使用率骤降，可能是交互改坏了；某地区升级率异常低，可能是 CDN 节点有问题。这些信号如果不看，就只是在"盲升"。
4.注意事项
- 不要在工作时段推送：设备被用户正在使用时升级会严重影响体验。OTA 应设定窗口期，默认凌晨执行。
- 固件签名是最后防线：一旦签名密钥泄露，攻击者可以推送恶意固件控制十亿台设备。密钥管理必须上 HSM。
- 运营看板要盯住三类指标：升级成功率（是否达标）、失败原因分布（是否有共性故障）、用户投诉量（是否有体验问题）。
5.小结
米家 OTA 的本质是把「养设备」变成一套有节奏、有闸口、有眼睛的运营系统。差分降带宽、灰度控风险、双分区保不死——三件套缺一不可。
下一篇（六），系列收官，讲最硬的两个要求：隐私安全与高可用。