运维平台中的业务树初版设计
这是学习笔记的第 1807篇文章
之前简单讨论过一版业务树的内容，随着讨论的深入，业务树的建设思路也越来越清晰。
对此我设计了一个初版的业务树建设思路，会把整个业务树分为四层。
分别对应的是资源服务，系统服务，业务服务和通用服务。
资源服务的一个基本单元是服务器，可以是虚拟机，物理机，也可以是docker等。这是最底层的资源服务。
系统服务包括系统应用服务，比如上面部署的nginx等，还有数据库服务，它们都是在系统资源服务为载体。
业务服务就是应用层面关注的服务，可能包含业务层运维的服务，数据平台的服务，或者某个项目的产品服务等。
通用服务是基于客服体系建设的服务，它的粒度最粗，但是对于业务的理解和把握最为直接，有效。
在这个基础上，我们提炼出了一个核心的概念，那就是标签系统。我们可以基于分层的思想来给各层打标签，通过标签的组合来实现业务的串联。
这里会解决一个很头疼的问题，比如这里有一台服务器，上面部署了MySQL的服务，但是这个服务归属于哪个业务，其实对于我们来说，我们没法得到最贴切的信息，因为业务的分类规则和角度不同，通过组织架构来分类也可以，通过产品线规则来分类也可以，这个粒度到底是怎么样，其实这个是我们不能直接决定的，同时我们维护的应用信息和业务方是割裂开来的，彼此互不通晓。
以数据库为例，数据库层面我们对接业务的单元是实例，即IP和端口的组合，可以基于这个基本维度来和上下层之间关联起来。
这里需要明确的一点是属性和标签是有区别的，比如对于数据库来说，数据库里的数据库角色是一个状态值，它可能会发生变化，那么这个属性作为一个标签就不是很合适了，但是它作为元数据的属性是很贴切的。所以标签系统是一个通用的入口，标签之间的关系可以通过元数据接口来打通。实现了上下的串联，就可以让标签的信息成为一个层次设计很清晰的数据。
整个标签系统的设计中，对于不同维度的标签管理是有一些差别的，因为维度和视角不同，所以添加标签的demo会有一些差别。
但是总体来说，标签的管理还是一个相对层次化的管理，比如对某一类服务添加标签，添加的过程中就应该能够查看到已有的标签，然后在这个基础上进行细化。
同理，添加数据库标签的时候也是类似，我们可以看到系统层的基础标签，这些标签是不能随意改变的，每个层面根据自己的特色去定义标签，需要关联一来的标签应该是互相充分沟通的前提下添加的对等标签。
在完成了基础标签的定义之后，比如完成了资源服务和系统服务的标签，这个时候我们就可以对接业务来实现共同关系的业务维度的标签配置。