运维体系标准化建设的思考

思考问题：

运维在做什么？自己所做的工作在运维体系里面属于什么位置？
工具化和平台选型之前，应该做什么？
自动化的前提和方向是什么？
CMDB该如何建设？
……

观点

在微服务的架构模式下，我们的运维视角一定转到应用这个核心概念上来，一切要从应用的角度来分析和看待问题。

概念

应用：可独立部署和运行，并提供对应的业务能力。

应用来源

微服务架构一般都是从单体架构或分层架构演进过来的。软件架构服务化的过程，就是我们根据业务模型进行细化的过程，在这个过程中切分出一个个具备不同职责的业务逻辑模块，然后每个微服务模块都会提供相对应业务逻辑的服务化接口。

应用模型及关系模型的建立

上面我们定义出来的一个个应用，都是从业务角度入手进行拆分细化出来的业务逻辑单元。它虽然可以独立部署和运行，但是每一个应用都只具备相对单一的业务职能。如果要完成整体的业务流程和目标，就需要和周边其它的服务化应用交互。同时，这个过程中还需要依赖各种与业务无直接关系、相对独立的基础设施和组件，比如机器资源、域名、DB、缓存、消息队列等等。
所以，除了应用这个实体之外，还会存在其他各类基础组件实体。同时，在应用运行过程中，还需要不断地与它们产生和建立各种各样复杂的关联关系，这也为我们后续的运维带来很多困难。
那接下来，我们要做的就是应用模型以及各种关系模型的梳理和建立，因为只有模型和关系梳理清楚了，才能为我们后面一系列的运维自动化、持续交付以及稳定性保障打下一个良好的基础。

应用业务模型

BPM的流程业务模型，其中有一个流程迁移功能模块，里面有流程迁移服务，以api暴漏给外
应用业务模型
这个业务模型通常都是业务架构师在进行业务需求分析和拆解时进行设计，更多的是聚焦在业务逻辑上，运维角度来看，这块的了解有利于问题排查。

应用管理模型

应用管理模型，也就是应用自身的各种属性，如应用名、应用功能信息、责任人、Git 地址、部署结构（代码路径、日志路径以及各类配置文件路径等）、启停方式、健康检测方式等等。

应用运行时所依赖的基础设施和组件

资源层面：应用运行所必需的资源载体有物理机、虚拟机或容器等，如果对外提供 HTTP 服务，就需要域名、DNS、SLB、IP等服务；
基础组件：这一部分其实就是我们所说的中间件体系，DB、缓存、消息队列等。

从这里我们可以抽象出一个重要结论，那就是这些基础设施和组件都是为上层的一个个业务应用所服务的。也正是因为业务和应用上的需求，才开启了它们各自的生命周期。如果脱离了这些业务应用，它们自己并没有单纯存在的意义。所以，从始至终基础设施和组件都跟应用这个概念保持着紧密的联系。

理清这个思路，再来梳理他们之间关系，分为两步：

建立各个基础设施和组件的数据模型。
识别出的基础设施及组件与应用建立关联关系的属性，或者在基础组件的数据模型中增加所属应用字段。
通过上面的梳理，可以建立类似下图这样以应用为核心的应用模型和关联关系模型了。

如何建立应用标准化体系和模型

标准化的过程实际上就是对运维对象的识别和建模过程。

标准化步骤

第一步，识别对象；
第二步，识别对象属性；
第三步，识别对象关系；
第四步，识别对象场景。

基础设施层面的标准化

基础设施层面的运维对象应该不难识别，因为都是一个个物理存在的实体，我们可以进行如下分析。

第一步，识别实体对象，主要有服务器、网络、IDC、机柜、存储、配件等。
第二步，识别对象的属性，比如服务器就会有 SN 序列号、IP 地址、厂商、硬件配置（如 CPU、内存、硬盘、网卡、PCIE、BIOS）、维保信息等；网络设备如交换机也会有厂商、型号、带宽等信息。
第三步，识别对象之间的关联关系，比如服务器所在的机柜，虚拟机所在的宿主机、机柜所在 IDC 等简单关系；复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系等，这些相对复杂一些，也就是我们常说的网络拓扑关系。
把以上信息梳理清楚，通过 ER 建模工具进行数据建模，再将以上的信息固化到 DB 中，一个资源层面的信息管理平台就基本成型了。
以服务器为例简单展示一下，我们的视角就是下面这样的：

但是，信息固化不是目的，也没有价值，只有信息动态流转起来才有价值。接下来我们需要做的事情，就是识别出针对运维对象所实施的日常运维操作有哪些，也就是识别出运维场景是什么。

第四步，识别运维场景。还是以服务器为例，我们针对服务器的日常操作有采购、入库、安装、配置、上线、下线、维修等等。另外，可能还会有可视化和查询的场景，如拓扑关系的可视化和动态展示，交换机与服务器之间的级联关系、状态（正常 or 故障）的展示等，这样可以很直观地关注到资源节点的状态。

应用层面的标准化

下面我们再一起看运维的核心：应用。对这个逻辑对象的建模会相对复杂一些，不过我们依然可以按照上面的套路来。

第一步，识别对象。
这个识别过程是在做微服务架构设计或拆分的时候就确定下来的。所以严格地讲，它不应该是运维阶段才被识别出来的，而是在之前设计阶段就被识别和确认下来，然后延伸到运维这里才对。
第二步，识别对象属性。
一个应用是业务的抽象逻辑，所以会有业务和运维两个维度的属性。业务属性在业务架构时确定，这主要是需要业务架构师去识别的，但是它的运维属性就应该由运维来识别了。
梳理一下一个应用应该具备哪些基本的运维属性。
应用的元数据属性，也就是简单直接地描述一个应用的信息，如应用名、应用 Owner、所属业务、是否核心链路应用以及应用功能说明等，这里的关键是应用名；
应用代码属性，主要是编程语言及版本（决定了后续的构建方式），GitLab 地址；
应用部署模式，涉及到基础软件包，如语言包 Java、C++、Go 等；容器如 Tomcat、JBoss 等；
应用目录信息，如运维脚本目录、日志目录、应用包目录、临时目录等；
应用运行脚本，如启停脚本、健康监测脚本；
应用运行时的参数配置，如运行端口、Java 的 JVM 参数 GC 方式、新生代、老生代、永生代的堆内存大小配置等。
从应用属性的视角，应该是下面这样一个视图：
第三步，识别对象关系。
也就是应用与外部的关系，概括起来有三大类：
第一类是应用与基础设施的关系，包括应用与资源、应用与BLB、应用与DNS 等等的关系；
第二类是平行层面的应用与应用之间的关系，这里再细分下去就是应用服务或 API 与其它应用服务和 API 的依赖关系。这里应该会联想到全链路这样的工具平台（skywalking）了，没错，这样的平台就是用来处理应用间关系管理的。
第三类是应用与各类基础组件之间的关系，比如应用与缓存，应用与消息、应用与DB 等等之间的关系。
第四步，识别应用的运维场景。
这个就会比较多了，比如应用创建、持续集成、持续发布、扩容、缩容、监控等；再复杂点的比如容量评估、限流降级等。