业务组与资源归属
业务组是权限边界：规则、对象、仪表盘都归属某个业务组，成员关系决定谁能看、谁能改。
业务组是夜莺里唯一的权限边界。理解它，权限相关的困惑基本就没了。
它同时是两件事
一是分组。告警规则、屏蔽规则、订阅规则、自愈脚本、机器、仪表盘， 创建时都要选一个业务组。不然所有东西堆在一张表里，几百条规则之后就没法看了。
二是授权。业务组的成员是团队（不是单个用户），每个团队带一个读写标记：
只读：能看到这个组下的东西，不能改；读写：能改。
一个用户能不能改某条告警规则，取决于：他在哪些团队里 → 这些团队在这条规则所属的业务组里有没有读写权限。
命名带层级
业务组在数据库里是扁平的列表，但界面按名字里的分隔符渲染成树。所以这样命名：
DBA/MySQL
DBA/Postgres
K8S/cluster-a
K8S/cluster-b
界面上会显示成：
DBA
├── MySQL
└── Postgres
K8S
├── cluster-a
└── cluster-b
分隔符可以在 系统配置 → 站点设置 里改，推荐用 /。
这只是显示层的事——重命名一个组不会影响它下面的东西。
机器要手动归组
装完 categraf 的机器会自动注册上来，但落在「未归组」里。 管理员需要把它分到某个业务组，那个组的人才能看到它、才能给它配规则。
这一步经常被忘记，症状是「机器列表里明明有，业务组的同事却说看不到」。
怎么划分
按谁负责划，不是按技术类型划。判断标准是：这个组里的东西出问题，是同一拨人处理吗？
- 一个业务线一个组，是常见做法；
- 基础设施按团队分（DBA、网络、K8s 平台），也常见；
- 按机房或环境分，通常不如按人分好用——因为值班的人不是按机房排的。
组划得太细，配规则时要来回切；太粗，权限就形同虚设。