定义
Gray Release（灰度发布）在 OTA 升级时先对部分设备推送新版本，验证稳定后再全量发布，降低升级风险。可基于 Device Grouping 或比例选择灰度设备。
灰度策略
常见策略包括：按设备分组（Static Group 静态组、Dynamic Group 动态组）选择试点设备；按比例随机抽取（如 5%、10%、50% 分批）；按区域、型号、批次等维度定向推送。平台支持多阶段灰度：第一阶段小范围验证，观察成功率与告警；通过后扩大范围，最终全量发布。
监控与回滚
灰度期间需监控升级成功率、设备上线率、故障告警等指标。若灰度设备出现异常（如批量离线、故障率上升），可立即暂停推送并触发 Rollback 回滚，将已升级设备恢复至旧版本。平台应支持灰度任务暂停、恢复、扩大范围等操作，实现可控的渐进式发布。
最佳实践
建议先对内部测试设备或低风险分组灰度；设置灰度观察期（如 24～72 小时）；定义明确的灰度通过标准（成功率阈值、无严重告警等）；与 Changelog 变更日志结合，便于评估升级影响与决策。
分批验证和一次全量推送
灰度发布的含义是把同一次版本变更拆成可停止的几步：先让一小批设备跑上新版本，观察它们是否还能保持连接、完成关键业务并按预期上报，再决定是否扩大。它不是把设备名单随机打乱就结束，也不是“先发测试环境”的另一种说法。测试环境里的设备往往供电稳定、网络人工保证；灰度要面对的是即将接收全量的那一类现场设备。每一批都应有明确的进入条件和停住条件，例如观察期内没有出现新的大面积离线、没有出现该版本特有的启动失败。批次之间不要重叠写同一分区，避免前一批还在确认、后一批已经覆盖。任务记录要能回答当前批次是哪些设备、它们从哪个版本来、停在哪一步。固件空中升级提供的是换映像的动作，灰度提供的是这个动作允许扩大的门闩。
下一批可以打开的观察条件
打开下一批之前，上一批应已经越过重启并完成至少一次业务所需的上报，而不是仅仅显示下载进度结束。观察窗口要盖住设备真实的工作循环：只在夜间通信的设备，白天就宣布通过，等于没有观察。样本里应包含这次全量会遇到的硬件修订、网络类型和供电方式，只挑实验台或单一客户现场，不能代表其余设备。若版本同时改了协议或点表，观察项里要有“平台是否还能解析新上报”，不能只看在线灯。发现异常时，未开始的批次应能停住，已经写上新映像的设备应能按维护窗口或立即策略回到旧版本，两种节奏不要在同一个开关里含糊过去。通过与否要留下人可阅读的依据，而不是只留一个被点过的按钮。
样本盖不住即将全量的设备
按百分比抽取却不看分布，样本可能全落在同一型号、同一机房，其余型号的启动失败要到全量才出现。用“最近在线”当抽样条件，会把长期休眠、链路最差的设备排除在观察之外，而它们往往最容易在升级时超时。观察期只统计下载成功率，不看重启后的业务报文，程序起不来也被当成通过。扩大范围时沿用了上一批的旧任务编号，失败重试把已经确认的设备又升了一次。停批只停止了新的下发，已经下载完但还没重启的设备仍会在下次上电时自己切换。回退包没有随灰度任务一起准备，真要退时才发现旧版本的包已被清理。不同批次使用了不同的签名密钥，前一批能验、后一批不能验，现象被误判成网络问题。每一批的名单、开始观察的时刻和停批原因都应留在任务上，事后才能说明为什么没有继续放大。观察指标要在开批前写明，不能等结果出来再挑选好看的曲线。停批之后不应再有设备悄悄进入下一批，除非重新指定观察范围并记下原因。