去工具化/脚本化理解，自动化运维落地最佳实践之业务/架构/模型/方法

声明：本文来自于我的这些年运维创业服务经验，基于EasyOps自动化运维平台的经验总结，与大家分享。

近年来后端IT也呈现更复杂的形态，底层IT架构逐渐开放平台化、云化，上层应用微服务化等等，虚拟化、云平台、容器PaaS和云原生框架都进入到IT运行环境中，而传统业务依然运行在传统IT架构之上，系统封闭，交付周期慢，巨石架构等等，由业务驱动的双态IT特点日益突出。另外一方面，由于IT的形态日益复杂化，引入的运维平台和工具越来越多，这些复杂的工具场景如何实现能力互通，实现自动化、数据化高效运维，是运维侧的挑战。

在过去以ITIL为核心理念的运维体系设计，强调流程、规范、合规，让很多运维事务代价变得更高。今天运维领域逐渐接受DevOps的理念，以自动化为核心，强调敏捷效率、标准化和平台化等，带来降本增效的价值。但我们在自动化运维体系中，必须兼顾ITIL和DevOps，兼顾在业务上的安全合规规范与自动化敏捷等诉求。

自动化运维是一个复杂的体系，它是对日常运维工作场景化、平台化的实现。而日常的自动化运维场景非常多，不同IT资源、角色、服务、流程就构成了自动化运维场景。

1. 关键术语

1.1 CMDB，配置管理

CMDB(Configuration Management Database)即面向应用的配置管理数据库，通过识别、控制、维护，检查企业的IT资源，从而高效控制与管理不断变化的IT基础架构与IT服务，并为其它IT服务管理流程、DevOps、智能监控、自动化运维等运维周边系统提供准确的应用视角的配置管理信息。应用CMDB是IT运维管理系统的核心，提供监控、自动化、流程相关IT系统配置信息进行记录、连接、更新等操作。为整个IT运维系统高效整合打下了基础。

1.2 IT资源

自动化运维是IT资源对象上的一个或者组合变更动作，核心依赖或者作用的是IT资源对象，如网络、防火墙、主机、应用、集群等等。重点阐述一下应用术语，系统实现见【IT资源】模块中的【应用】功能。

Ø 应用（又称应用程序）

应用程序是集群的集合，而集群又是服务器组的集合。应用程序是代表一组或者一个能够独立部署、运行、并对外提供服务的集合，在某些公司应用程序可以理解成组件。

Ø 集群

集群（又称环境）是一组相同的服务器资源的结合，比如说开发、测试、生产或者被集群。

1.3 原子工具库

是作业执行能力的原子化封装，表现为一种工具库的能力，实现一种单一的变更服务能力，如添加用户，在vmware中创建虚拟机。原子化封装和语言无关，通常以shell、python、powershell、bat等主要语言。系统实现见【基础库】中的【工具库】

1.4 流程库

是一种基于某个服务场景，对一连串原子事务工作的复杂编排。系统实现见【基础库】中的【流程库】，典型流程库的概念包括：子流程、串行、并行、输入参数、输出参数等等。

1.5 通道

当一个作业执行过程中，执行指令要作用于相应的IT资源目标，此时需要相应的通道到达目标资源，典型的通道有SSH通道、ansible、自有agent通道以及其他API通道等等。某种程度上，通道会限制上层的作业指令的封装方式，比如ansible通道依赖的上层指令是ansible playbook封装、API通道是需要封装成目标对象所需要的格式。通道是对上层屏蔽的，在构建一个工具库的时候，就基本上确定了通道。

1.6 制品

用以管理源代码编译后的构建产物，支持 Docker、Maven、Helm、npm 包等常见制品库类型，制品库可以跟源代码协同进行版本化控制，可以与本地各构建工具和云上的持续集成，持续部署无缝结合，为自动化运维工具提供的构建物管理服务，把控构建物质量。

2. 自动化运维架构介绍

2.1 架构概览

Ø操作界面

系统所有交互操作的入口，以React作为核心前端技术栈

Ø配置库CMDB

统一的IT资源管理数据库，里面纳管了IaaS、PaaS及上层应用相关的一切资源

Ø自动化操作库

自动化工具、流程及操作流水等相关的信息存储

Ø消息总线

分布式数据采集及指令数据下发通道，满足高可用要求

ØProxy代理

基于某些特殊的场景及权限管理控制需要，利用proxy隔离多数据中心或者网络隔离下的权限控制要求

Ø制品库

存储某些文件、容器、配置文件、补丁等镜像文件，提供版本化控制

2.2 功能框架

核心功能概述如下：

Ø服务门户层

随着客户的IT管理平台越来越复杂，所需要支撑的平台越来越多，而在平台内支撑的场景也越来越多。一个复杂的统一IT管理平台，里面覆盖了各类角色日常的管理需要，但这些场景综合起来包括：事务处理、信息决策、获取相应的产品与服务目录。

Ø服务受理层

基于ITSM流程服务体系构建的统一服务入口，任何变更、服务请求都需要通过ITSM流程发起。同时部分服务流程也要考虑与后面的自动化流程对接。它建立起了服务通道，确保以统一标准的形式提供服务。

Ø服务开通层

ITSM是面向管理者的服务流程，是服务过程管理的体现，而真正的服务执行与落地需要通过底层自动化和数据化平台来实现。就拿一个变更来说，ITSM有相应的变更流程，而变更的动作执行则需要通过自动化运维场景编排流程来实现。

Ø基础数据层

CMDB的统一的IT资源管理层，所有自动化和数据化的资源对象元数据都是来自于CMDB平台的定义和管理。

ØIT资源层

分IaaS、PaaS和SaaS等各类物理资源对象

2.3 系统架构

核心组件职责概述

ØConsole-w前端页面层

前端统一用户前端操作层，基于UI的操作入口封装；

ØAPI-Gateway网关

统一的接入网关，实现对所有API和路由的统一接入；

Ø自动化API

自动化层统一API操作，基于流程服务编排的实现；

Ø原子作业API

原子化事务作业的API，基于工具库的能力实现封装；

Ø配置管理API

CMDB统一管理的API，基于CRUD的统一资源管理，对各类资源对象的管理；

ØNotify

CMDB数据增量更新之后，由Notify同步到消息队列中，基于消息队列的订阅发布到其他周边系统；

ØRabbitMQ

增量数据变更之后，数据同步到RabbitMQ中，分channel对外增量数据订阅发布；

ØNotifyWorker

编写数据处理逻辑引擎，在数据增量更新之后，做协议转换、事务处理等等；

ØEasy_command任务调度器

命令下发执行先被Easy_Command接受，做统一的命令下发、执行管理的等等；

Ø链接网关GateWay

命令下发到数据中心，特别是对于大规模数据中心或者网络权限隔离要求比较高的资源对象，首先是下发到GateWay，让它做请求的转发；

ØAgent

机器上的执行代理，负责任务的本地化执行、数据执行结果的上报、数据采集等等；

ØEasyCore

CMDB的核心图数据库存储，负责对一切元数据的定义和存储；

ØMongoDB

记录CMDB和自动化的变更操作流水；

3. 自动化运维的设计与实现框架

3.1 自动化运维能力框架

运维自动化包括了IT资源管理、资源交付、应用交付以及生产运行等领域范围，覆盖了IT资源生命周期管理的全过程，是一套体系化的方法论、实践和标准的集合。当我们去实现运维自动化的能力时，可以参照该过程框架，落实具体的场景化自动化运维需求。

3.2 底层实现框架

Ø流程GUI编排层

面向场景，提供统一的流程编排能力，详细见【运维自动化工具】；

Ø流程引擎层

提供高性能流程引擎，该引擎要支持子流程、串并行、人工审核等流程化能力；

Ø工具服务层

原子工具库的封装和流程的封装，包括各类语言封装的工具库；

Ø工具执行层

不同的执行工具，到不同的端执行

4. 自动化运维数据模型设计与管理

4.1 图数据库设计的总流程图

一个自动化运维的业务需求确定之后，数据架构要遵循从概念设计、逻辑设计到物理设计的一个过程。由于平台使用的是图数据库存储，图数据库的核心概念都是来自于关系数据库的，但是到具体的物理实现上对关系的表达，在图数据库中有单独的关系实体来表达，而不是关系数据库的外键、关联表等各种不同的表达手段。

4.2 概念与逻辑模型设计

4.2.1 概念模型

概念模型：就是从现实世界到信息世界的第一层抽象，确定领域实体属性关系等，使用E-R图表示，E-R图主要是由实体、属性和关系三个要素构成的。类似如下：

4.2.2 逻辑模型

将概念模型转化为具体的数据模型的过程，即按照概念结构设计阶段建立的基本E-R图，按图数据库支持的数据模型（属性、关系、面向对象），转换成相应的逻辑模型，这种转换要符合图数据模型的原则。这个部分是对一个具体的实体模型及其关系的设计，类似如下：

4.3 自动化运维物理模型的管理

物理模型就是某个特定存储下的具体设计实现。在该自动化平台中，物理模型管理统一是放在CMDB中，对实体和实体关系的描述，都统一有CMDB的模型管理模块进行管理，其中包括实体属性管理、实体关系管理、模型版本、模型视图管理、模型的全文检索管理、模型继承等等：

5. 自动化运维场景开发流程

5.1 自动化运维场景开发框架

Ø 需求分析

对自动运维的场景需求分析，包括背景、场景目标、业务流、开发任务、文档编写等等；

Ø 设计

针对自动化运维场景，结合系统平台的技术实现，给出相应的实现方案，包括工具设计、数据模型设计、流程编排设计等等，最重要的是这些设计文档要同步输出；

Ø 实现

基于之前的设计实现相应的能力，特殊的一个地方是数据库的实现是在CMDB中建模完成的；

Ø 测试

基于之前业务需求和流程分析，对其做功能验收测试，确保上线后的高质量交付；

Ø 上线

上线可以设置成两个阶段，试运行阶段和正式发布阶段。试运行阶段是属于灰度运行阶段，正式交付是需要做相应的培训之后才能变成正式运行态。

5.2 自动化运维场景【需求分析】关键点

Ø 背景

l 阐述该领域遇到的挑战和问题

l 初步概要性提出问题的解决思路

Ø 场景目标

l 强调需求实现的业务目标

l 强调需求实现带来的业务价值

Ø 业务流程

l 初步分析需求实现的场景功能点是哪些

l 初步分析每个功能点的业务流是什么样的

Ø 开发任务

l 根据需要开发的功能和业务流程情况，分解开发任务

l 细化开发任务到开发的不同阶段：设计、开发、测试与上线

l 对每一个不同的阶段，细化具体的能力要求

5.3 自动化运维场景【设计】关键点

Ø 工具设计

l 请严格细化原子工具层面上的设计要求，不耦合设计

l 设计工具的输入和输出及用途

Ø 数据模型设计

l 重点关注数据模型对象的属性和关系分解

l 重点关注数据的生成和变更机制，如自动采集、手动更新、流程更新等等

Ø 流程编排设计

l 请严格设计场景流程的输入和输出以及相应的目标

l 提供相应的场景编排方案，见【需求分析】的业务流设计

l 并做好自动化执行流程与ITSM对接流程的方案设计

5.4 自动化运维场景【实现】关键点

Ø 工具实现

l 请严格遵循相应的语言规范进行工具库代码的实现

l 请严格执行原子工具库的沙盒测试工作，确保流程集成后的正常，相对于代码的单元测试

Ø 数据模型建模

l 请注意模型建模CI属性的类型

l 请注意模型建模CI关系的定义，如数量、约束等等

5.5 自动化运维场景【测试】关键点

自动化运维场景的测试是以功能测试为主，其中包括工具库的功能测试、流程库的功能测试以及场景化端到端流程功能性测试，该测试框架与自动化【4.2底层实现框架】原理一致，分：功能层、场景编排层、服务流程层（包括ITSM流程）。请关注：

l 功能测试

l 场景编排流程的功能测试

l ITSM与自动化流程的端到端功能测试

5.6 自动化运维场景【上线】关键点

自动化运维场景发布到生产环境需要在质量验证完全OK的情况下进行，建议过程分成两个阶段：灰度试运行阶段（小范围）和正式发布阶段。具体为：

Ø 灰度试运行阶段

l 少量的用户可以执行，权限不要大面积分发

l 部分服务请求可以工具执行，灰度部分该场景服务请求或变更进行

l 服务流程和自动化运维作业流程分离，确保自动化运维作业流程可以人为控制

l 试运行阶段之后，出具相应的试运行报告

Ø 正式发布阶段

l 经历严格的服务培训，从产品设计、平台、操作等多个方面进行培训

l 无权限限制，可以发布给更多用户使用

l 无服务请求限制

l 服务流程和自动化运维作业流程完全对接

l 周期性输出正式的运行报告

总结：自动化运维是一个复杂体系，涉及从开始的需求分析、设计到落地以及后续的运营整个过程。本文更多的是从技术的角度探讨自动化运维的落地过程。以上方法，都已经在多客户环境得到验证，是创业服务客户的经验。