要说业务组这个概念，可能要先聊聊机器分组的设计，之前为此专门写过一篇公众号文章《设计篇-监控系统机器分组设计，你是我的知音么？》，建议感兴趣的朋友读一读。反正最终，以现在的认知来看，用标签来做机器分组是最合适的，虽然标签没有那么直观，但是足够灵活，再佐以业务组这个设计，做相关筛选的时候，先用业务组做第一层筛选，后面再用标签来筛，标签不够直观这个缺点可以被大大的规避。

再说各种规则，比如告警规则、屏蔽规则、订阅规则，这些规则如果没有一种归组管理方式，就是全公司的规则都平铺到一个表格里，会显得非常混乱。比如我是某个业务线的研发人员，我肯定就关心自己业务线的那些规则，才不想看到别的业务线的规则呢。所以我们需要一个规则分组机制，类似一个namespace的东西，来对这些规则分个组。

再就是权限，这些告警规则、监控对象、自愈脚本等，谁可以修改维护？总得关联到具体的一些人上。对于某个产品的相关规则、监控对象等，是由一批相同的人来维护的，所以抽象一个业务组这样的概念，把这些资产都归到这个业务组里，也方便配置权限。另外就是告警自愈以及机器上跑脚本，这个动作比较危险，要好好控制权限，机器隶属业务组，业务组有管理人员，这种管理模式相对比较简单清晰。

综上，我们设计了业务组这个概念，夜莺中的各种实体大都是归到业务组的，比如监控对象、各类规则、自愈脚本等，业务组一般是一个自闭环的组织，他们自己管理自己的机器设备，自己管理自己的告警规则，跟其他的业务组没什么交集。举个例子，比如公司的DBA团队，管理了公司的所有mysql数据库以及相关的机器，这种就可以单独建立一个业务组；再比如基础网络的同学，管理了公司所有的网络设备，跟其他业务线关系不大，就可以建立一个专门的业务组，放置网络设备监控对象，以及相关的告警规则。

当然了，公司也可能有个统一的运维团队，管理所有的告警规则，普通研发人员都不会去创建告警规则，这种情况，这个统一的运维团队可以创建一个业务组，比如叫infra，放置公司所有的监控对象，配置告警规则。其他各个团队，可以创建自己的业务组，然后订阅infra的告警规则（订阅可以跨业务组订阅），每个业务团队创建的业务组里只有订阅规则，与其他业务组隔离，比较清晰较为容易管理。

对于监控对象，只要有监控数据上报，n9e-server就会自动从监控对象中解析到ident标签，取其值当做监控对象，注册到mysql监控对象这个表里。刚注册上来的监控对象是未归组的，此时应该由Admin角色的人去把这些监控对象做分配，分配给不同的业务组，分完之后，各个业务组的人就自己玩自己的就好了。

业务组的人，对于刚刚分配过来的监控对象设备，建议首先做的事情，就是打上一个bg的标签，比如bg=cloud表示相关的监控对象都隶属cloud这个Business Group。未来这些监控对象告警了，告警事件中会自动带上bg=cloud这个标签，收报警的人就可以立刻知道这是哪个bg的监控对象。