运维体系建设:运维基础平台体系建设(2)

运维体系建设:运维基础平台体系建设(2)

（本文共1532字，大约需要阅读4分钟）

标准化体系

CMDB是传统运维中面向资源的管理，而应用配置是面向应用的管理，这者在梳理逻辑上本质上是一样的，在识别到应用对象后，也进行属性识别、关系梳理。需要说明的是，CMDB的管理和应用配置管理并不冲突，如果一个运维项目即有传统机房又有分布式架构应用（比如业务系统上云，但有自运维的灾备机房），则面向资源和面向应用的管理都是必须的。

一、应用对象识别

1、应用拆分

（1）应用拆分原则

应用的对象是微服务架构设计或业务拆分的时候确定下来的，架构师一般会在搭建平台时将这部分工作完成，业务的拆分过程如下图所示。

图 96应用拆分

（2）应用对象拆分

业务架构决定技术架构，而技术架构又决定研发团队的组织架构，所以应用管理的拆分和标识思路是“产品线”－“业务团队”－“应用”的三层结构。

图 97应用对象拆分

（3）应用名规范

拆分出来的对象名应该固化，并且固化起名规范，比如可以遵循以下原则：

必须以大小写英文字母以及下划线组合而成，且以英文字母开头。 长度有最长16个字符，最短8个字符，要简单易懂名字中不允许出现物理位置和依赖的资源信息

2、服务树

应用对象被识别后，下一步是要用服务树建立应用之间的关系。

服务树：有效组织和管理应用的方式，就是把应用组织成一个树形的层次结构。应用对象服务树的层次关系为：产品线－业务团队－应用－集群服务分组－资源。

集群服务分组一般用于区别多环境、多IDC、多服务分组等应用场景。

多环境应用场景：应用环境通常会有开发测试环境、项目测试环境、集成测试环境、预发环境、金丝雀环境、线上环境等等。 多IDC应用场景：多IDC机房部署中，通过应用代码相同但应用配置不同。多服务分组应用场景分为静态分组和动态分组。静态分组可划分为核心应用和非核心应用，凡是会引起大量业务中断的应用都是核心应用。动态分组可按场景因素划分，如对瞬间访问量大的业务或有突发流量的业务要从资源层隔离，上层的应用要建立独立的应用集群分组。

下图是一个服务树的示例：

图98 应用对象服务树

二、应用属性识别

我们在持续交付体系—>应用配置管理->软件配置管理中聊过，软件配置管理分为代码配置和应用配置两部分，相对应的应用的属性分为应用业务模型属性和应用管理模型属性。属性的折分在持续交付体系中已经仔细说明，以下我们主要从多应用的角度和和CMDB相结合的角度将软件配置管理的软件配置管理整合进来。

应用业务（应用服务）模型：即每个应用对外提供的业务服务能力，并以API的方式暴露给外部。由业务架构师进行整体规划。这些API（应用接口）是对应用功能方法接口的两次封装，可以分为监控接口、程序接口、网管接口等。其中网管接口用于实现访问控制、链路依赖、开关策略、限流降级、功能预案等。

应用管理（应用配置）模型：即应用自身的各种属性，如应用名、功能信息、责任人、访问地址、目录信息（运维脚本、代码路径、日志路径以及各种配置文件路径、安装软件包路径、应用包目录、临时文件目录等）、代码属性（如编程语言及版本）、运行端口、启停方式、运行参数、监控检测参数、监控频率。要建立应用唯一标示符，如应用名。

三、应用关系识别

应用关系识别与持续交付应用配置管理的环境配置管理相同。在资源层面，我们知道应用依赖的资源关系有物理机（IP、维保信息、交换机信息、机柜信息）、虚拟机、容器、虚IP服务、域名服务等。在基础组件层面，我们知识应用依赖的基础组件有数据库、数据库中间件、缓存、消息队列、存储系统等。

最终我们会梳理出应用的属性和关系，形成下图所示的结构。

图 99应用属性识别和应用关系识别

应用配置管理就聊到这里，最终我们会形成下图所示的梳理结构。

图 94运维对象标准化