# 业务组与资源归属

业务组是权限边界：规则、对象、仪表盘都归属某个业务组，成员关系决定谁能看、谁能改。

最后校对于 2026-10-10

业务组是夜莺里**唯一的权限边界**。理解它，权限相关的困惑基本就没了。

## 它同时是两件事[​](#它同时是两件事 "它同时是两件事的直接链接")

**一是分组**。告警规则、屏蔽规则、订阅规则、自愈脚本、机器、仪表盘， 创建时都要选一个业务组。不然所有东西堆在一张表里，几百条规则之后就没法看了。

**二是授权**。业务组的成员是**团队**（不是单个用户），每个团队带一个读写标记：

* `只读`：能看到这个组下的东西，不能改；
* `读写`：能改。

一个用户能不能改某条告警规则，取决于：他在哪些团队里 → 这些团队在这条规则所属的业务组里有没有读写权限。

## 命名带层级[​](#命名带层级 "命名带层级的直接链接")

业务组在数据库里是**扁平的列表**，但界面按名字里的分隔符渲染成树。所以这样命名：

```
DBA/MySQL

DBA/Postgres

K8S/cluster-a

K8S/cluster-b
```

界面上会显示成：

```
DBA

├── MySQL

└── Postgres

K8S

├── cluster-a

└── cluster-b
```

分隔符可以在 **系统配置 → 站点设置** 里改，推荐用 `/`。 这只是显示层的事——重命名一个组不会影响它下面的东西。

## 机器要手动归组[​](#机器要手动归组 "机器要手动归组的直接链接")

装完 categraf 的机器会自动注册上来，但**落在「未归组」里**。 管理员需要把它分到某个业务组，那个组的人才能看到它、才能给它配规则。

这一步经常被忘记，症状是「机器列表里明明有，业务组的同事却说看不到」。

## 怎么划分[​](#怎么划分 "怎么划分的直接链接")

按**谁负责**划，不是按技术类型划。判断标准是：**这个组里的东西出问题，是同一拨人处理吗？**

* 一个业务线一个组，是常见做法；
* 基础设施按团队分（DBA、网络、K8s 平台），也常见；
* 按机房或环境分，通常不如按人分好用——因为值班的人不是按机房排的。

组划得太细，配规则时要来回切；太粗，权限就形同虚设。

## 相关[​](#相关 "相关的直接链接")

* [业务组授权](https://n9e.github.io/zh/docs/security/business-groups.md)
* [角色与权限矩阵](https://n9e.github.io/zh/docs/security/roles.md)
* [认证、Token 与 RBAC 模型](https://n9e.github.io/zh/docs/concepts/auth-rbac.md)