定义
Device Grouping（设备分组）按区域、项目、产品类型等业务维度组织设备，支持 Static Group（静态分组）与 Dynamic Group（动态分组）。分组与 OTA、配置下发、告警规则、RBAC 深度集成。
分组类型与层级
Static Group 静态分组由用户手动添加设备，成员固定；Dynamic Group 动态分组按规则（如 Device Tagging 标签、产品、固件版本）自动筛选，成员随设备属性变化。分组可支持层级结构（如区域—站点—设备），便于权限继承与批量操作。同一设备可属于多个分组，满足不同业务视角。分组与 Device Tagging 设备标签互补：分组侧重批量操作的目标集合，标签侧重灵活的多维分类。
与 DMP 的集成
设备管理平台在 OTA 任务、配置下发、告警规则、RBAC 数据权限等场景使用分组作为目标或范围。选择分组后，操作应用于组内所有设备；RBAC 可基于分组实现数据隔离，用户仅能访问其分组内的设备。分组支持与 Report Analytics 报表分析、Device Monitoring 设备监控联动，按分组聚合展示指标。与 Remote Maintenance 远程维护配合，支持对分组批量执行升级、配置、诊断等操作。
应用场景
适用于按区域、项目、客户管理设备；批量 OTA 时选择目标分组；按分组统计运维指标；多租户场景下的数据隔离。设备分组是规模化设备管理的基础能力。
手工名单和规则名单不能混用
设备分组的技术含义，是把一批终端收成一个可被升级、配置、授权和统计引用的集合。静态分组的成员是人逐台或批量放进去的，只有再次编辑才会变。动态分组的成员由规则在计算时得出，设备属性一变，集合就可能变。两者都可以叫分组，但任务绑定的是哪一种，决定了执行那一刻的目标还是不是创建任务时看见的那一批。需要留档的升级名单应使用静态分组或当时的成员快照；需要“以后新满足条件的设备也算进去”的日常策略，才用动态分组。
使用分组之前，要先定分组回答的业务问题：是项目边界、权限边界，还是一次操作的目标。一个分组同时承担三种角色，改成员会连带改权限和统计口径。层级分组里，父组的操作是否包含子组必须写明。同一台设备可以属于多个组，所以组是视角而不是物理位置。与标签配合时，标签是输入，分组是给批量动作用的结果。把空中升级直接绑在一张会随版本变化的规则组上，升级过程中成员会进进出出，任务范围就不再可解释。
一机多组把操作放大
容易出错的是忘记设备可以同时在多个组里。对甲组下发一套参数、对乙组下发另一套，交集里的设备会先后被写两次，最后生效的是后到达的那一次，而不是“更合适”的那一次。权限按组授予时，把人加进一个很宽的父组，等于把子组全部开放。动态规则写错一个条件，例如把“等于”写成“不等于”，组成员会突然变成几乎全部设备，批量操作随之放大。空组也要警惕：筛选条件过严时组是空的，任务显示成功，实际没有任何设备执行。
手工组和规则组同名或被人当成同一份名单，是另一类事故。看名称无法知道成员会不会自己变化。统计在线情况时，多组重复计算同一台设备，会把总数加爆。应允许按组看名单，也要能看出一台设备还在哪些组里。设备监控按组过滤时，应使用执行查询那一刻的成员，并注明是快照还是实时规则。调整组成员不应追溯改写已经完成的历史任务范围，历史任务要保留当时的目标清单。
父组授权为什么会放大
分组一旦做成层级，父组上的一次授权或一次下发就会落到所有子组。把一个人加进很宽的父组，等于把下面每个项目都开放给他，即使他只是去处理其中一个站点。操作界面若只显示父组名称，执行人看不到将要触及的设备数量，确认就失去意义。下发前应展开成具体名单或至少给出台数，并允许看出其中有哪些设备同时还属于其他组。多组交集上的设备会被各组的配置轮流写到，最后生效的是后到达的那一次，不是名称看起来更匹配的那一组。这种覆盖要能在设备上查到最近几次写入来自哪一组。
空组同样危险。条件过严时成员为零，任务显示完成，现场没有任何变化，人会以为配置已经生效。动态规则和手工名单若共用一个含糊的组名，几天之后没人记得这份名单会不会自己变化。统计时把多组简单相加，同一台设备会被计算多次，总数会大于实际档案。已经结束的任务必须保留执行当时的目标清单，事后调整组成员不能改写那次任务的范围。否则审计看到的是现在的组，不是当晚真正被操作的设备。