本文转自优维科技CEO王津银先生个人微信公众号——互联网运维杂谈（ID:waynewang_ops）,欢迎各位运维圈儿的大牛、小牛、菜鸟、童鞋们关注哦！
如果非要说CMDB是ITOM的核心元数据，那么服务树就是CMDB的核心数据。如果非要说应用CMDB最核心的精髓在哪儿，那么服务树必须是其一。
我在很早之前高效运维社区出版的《运维36计》中提到的应用CMDB的构建原则，其中原则4表达的就是这个概念。如下：
何为服务树？有些人（公司）把服务树称为系统树或者业务树等等。其实服务树是描述了一种服务侧应用系统能力域之间的水平划分和纵向层次关系。这个关系包含两个维度：水平划分出来的能力域以及纵向复杂系统的模块化划分，示例如下（二维表）：
首先一级系统之间的横向划分代表着业务能力域的划分规则，对于金融系统来说，分各种前端系统及核心银行系统（CBS），券商类系统也是如此，如表所示例分：手机证券、集中运营和核心交易系统；对于运营商系统来说，分B域、O域、E域等类型系统。
其次到某一个应用系统内部的纵向去看，其实表示的是复杂系统的模块划分规则，比如说手机证券系统底下包含三个子系统，每个子系统下面又包含了能够对外提供服务能力的应用程序或者组件。
在这么多客户的实施中，总结了一些服务树的构建原则供大家参考。原则细则如下：
第一、建立统一的服务树层级规范，不要超过四级，二级和三级混合使用最佳。超过四级从树的角度来看，太深不利于划分，造成结构混乱；三级用来构建复杂系统的层次树，二级是用来构建简单系统的层次划分。
第二、叶子节点必须是应用。有些公司称之为服务单元或者组件，总而言之是一组服务的聚合，这一层节点和直接的资源产生联系，比如说主机、服务实例等等。
第三、同样的子系统或者应用不应该属于多个上级节点。这是业务系统的天然划分规则，在系统设计之初就有唯一属主。但是有人会说我有一个公共系统被很多人访问怎么办？那是访问关系，服务树表达的是系统静态划分，而非动态访问关系。
第四、可以指定每个层级系统的服务代码规范，根据代码规范生成的服务代码可以用在外围系统的资源管理上，便于系统之间的关联唯一性管理。
第五、非业务属性的信息不要放到服务树上。典型的情况是，为了方便，大家把组织架构信息（如部门）放到服务树上，而部门只是业务系统的一个属性而已。
第六、服务树不要做读权限控制。最好封装成一个标准组件，外围平台任意使用。
我们都知道IaaS和PaaS资源存在的目的就是为上层应用所服务的，因此必须有个逻辑是服务树和资源之间有个服务关系。这个关系从应用/服务单元的角度来说，有两层业务含义：一种是部署资源，另外一种是服务资源，部署资源是安装态关联的资源，服务资源是运行态关联的资源。安装部署态资源从OS开始，依赖库、制品库、配置库等等；运行服务态资源保护依赖的各种外围服务，如负载均衡、DNS、存储、缓存服务等等。但这两类资源被管理起来之后，接下来应用场景非常广泛，从成本、收益和质量等多个维度体现这一管理思路的价值。
在多年实践的基础上，服务树的应用场景非常广泛，之前做过梳理总结：
第一、监控管理。服务树上的告警可以有默认继承规则，下级继承上级，这样大大的提升告警策略配置效率。同时在应用级别的告警策略，在资源发生变化的时候能够直接继承，不容易出现漏告警或者多告警。当然在监控的数据视图场景中，还可以基于服务树生成复杂的资源数据视图，比如说流量的汇总计算等等。
第二、自动化管理。常规的如巡检管理，系统之间的容灾切换等等。但我们今天用这个服务树来做部署编排，大大提升发布效率。
第三、环境管理。基于应用/服务单元来进行环境管理是最好的聚合单元，在该单元下分类出Dev、Test、预发布和生产等各类环境的配置定义，从部署资源到服务资源定义。基于部署资源的配置，可以直接打通DevOps交付流水线。
第四、DevOps管理。持续部署、自动化测试、持续反馈都可以以树为载体，加强数据的唯一性管理。
第五、各类IT资源对象管理。这种管理思维是前置思维，而非自动发现或者人工梳理来实现的。我发现很多客户都喜欢用系统的粒度或者无服务维度的去申请各类资源，导致这些资源最终没有业务属主。我建议你们在各类资源申请流程中前置关联关系，选择所属服务树，这样方便我们把资源和服务关联起来的，这种关联给后续的变更、事件、IT分析等场景提供准确的数据基础。CMP平台的底层资源管理，可以应用服务树来管理资源模板，其次在资源分配的时候，关联服务树，确保资源物有所主，这样就可以避免事后自动发现来建立关系
第六、ITSM流程管理支撑。这个在很多流程中，都能提供数据基础，特别是今天面向上层服务的事件管理、监控管理、发布与部署管理等等都需要结合这个数据。
第七、故障、变更与事件管理。打通上层应用系统和底层资源的关系图谱，这就等于给故障、变更提供了强有力的数据支撑，快速提供准确的数据支撑。
在AIOps的今天，这个服务树必须成为AIOps的标签库数据能力。我们一直所说的ITOA中有大量的场景使用到这个数据，比如说应用容量管理、应用性能管理、应用系统安全管理、应用的可用性分析等等，它们都是基于这个服务树积累的资源关系构建起来的。应用容量管理是基于服务树应用和主机状态资源的关系，建立容量模型构建起来的；应用性能管理，在应用这个层面上聚合了各类服务，方便我们识别每一个应用资源的瓶颈源，结合公司的业务情况（比如说活动）提前评估；应用安全管理，建立不同级别的系统安全性和重要性评估，集中优势资源聚焦在核心服务上；应用的可用性分析，从应用角度知道其API服务状态数据，然后计算应用可用性情况。
不过服务树的管理在传统企业是一笔糊涂账，原因是过去不重视应用架构管理导致的，在很多组织中，应用管理角色都是不存在的，那么其对应的数据质量怎么可能好呢？