浅谈数据中心运维自动化

## 1. 何为运维自动化

何为数据中心的 自动化运维？ 很多人把 DevOps与运维自动化紧绑，认为只有实现了容器化，只有实现了自动编排等等才算是实现了运维的自动化。且不说有多少企业可以完全实现这种IT转型，就概念本身而言，我觉得这也是一种不太合乎逻辑的思维。我们来看Gartner对运维自动化的理解“通过运维工具或平台，实现IT基础设施及业务应用日常任务处理和运维流程的自动化，从而提高效率和降低风险，促进运维组织的成熟和各种能力的升级”。从传统企业数据中心运维工程师角度来看，所谓自动化运维，即在最少的人工干预下，结合运用脚本与第三方工具，保证业务系统7*24小时高效稳定运行。所以，笔者认为最接地气的运维自动化即为在企业数据中心原有IT基础架构条件下，能够实现IT资源标准化定义，并且实现运维数据采集、加工、分析的自动化流程，最终能保障IT运维的及时性和效率化的建设体系。

2. 运维自动化框架

首先，我们先来从企业数据中心运维发展的历史阶段来分析运维自动化。从很多传统企业来看，尤其是金融企业的数据中心，大部分已经经历了三个阶段：

（1）复运维工作精简化的阶段，利用标准统一的工作流来避免重复的人力工作；

（2）局部运维工作自动化的阶段，在不同的系统上部署针对不同对象的脚本来收集处理运维数据；

（3）IT运维平台整合自动化的阶段，平台实现IT基础架构的半自动化运维。

总结以上历史阶段的发展过程，运维自动化的最初目的是为了提高效率和准确率的基础之上减少人力成本投入。从运维具体工作内容包括：日常监控任务中的日志配置、数据采集、报警过滤等；日常运维任务当中的 脚本执行、系统安装、配置备份、配置检查、配置变更、补丁分发 等； 作业调度 中的 应用发布流程、应用部署流程、变更流程、故障处理、灾备切换、资源交付等 。那么，要实现对以上所有工作内容的自动化整合需要经历以下三个步骤的建设：

首先，实现标准化是实现自动化的前提条件，因为自动化的工作流是必须要在标准化的基础之上才能实现识别、判断、处理等相关动作。标准化又包括资源定义的标准化、工作流程的标准化以及数据的标准化；然后，需要选择数据采集的工具和方式，因为所有的自动化动作都是基于数据判断的基础上采取的后续步骤；最后需要对采集来的数据进行加工处理以及最终的分析和决策，这里面包括常规性的决策、为后续采取动作需做的评估和预警、需要根据数据变化及时做出的动态调整等。

3. 数据标准化体系建设

3.1资源标准化

所谓资源的标准化，涉及到的资源主要包括设备、系统、软件等三类对象资源 。

针对物理设备的标准化，首先，我们需要做到对物理设备的资产定义标准化。例如：对设备的命名、地址、位置、配置、参数、管理等一系列属性信息的定义需要有统一个规划标准。不一定是一个标准，但是一定要建立一系列标准模板。其次，我们需要对物理设备的规划使用设置标准。例如：设备的网络配置、远程控制、存储配置等方面的配置使用标准。最后，我们需要对设备使用设置运维管理标准。例如：设备当中的硬件环境 的报警阀值规则定义。

针对系统层面的标准化，首先，与物理设备类似的资产定义标准化。例如：操作系统的主机名称、类型、版本等相关资产属性信息的标准化定义。其次，关于系统的标准化配置管理。例如：操作系统的初始化配置（地址、网关、掩码、DNS、NTP、内核参数调优、日志、存储使用、Agent）。最后，我们需要对操作系统设置运维监控标准。例如：CPU使用率、内存使用率、硬盘使用率、IO延时、网络状况、进程指标、运行时间等。一方面需要确定运维监控的指标，另外一方面需要确定每一个指标或者指标组合的阀值预警判定规则。

针对软件（主要是指系统上运行的数据库及应用中间件）层面的标准化，首先，我们需要对应用中间件的使用进行标准化管理。例如：数据库的类型和版本、同类中间件的类型和版本。其次，需要对所有软件的初始化以及配置使用进行标准化管理。例如：软件安装配置规范、配置文件规范、配置脚本规范、日志收集规范、端口监听规范等。最后，我们同样需要对软件的运维监控设定标准。也就是需要监控的软件服务指标体系，以此来判断软件提供的服务的正常与否以及性能如何。

3.2流程标准化

所谓流程标准化就是指在数据中心运维管理过程当中涉及到的日常工作流程的标准化管理。如果没有工作流程的标准化规范，那么所有的运维工作就会变成随机性流程，这样的流程是没有办法利用脚本或者软件工具来实现自动化的。具体说来，数据中心运维工作流程的标准化需要做到以下几个方面：

（1） 资源管理流程：包括软硬件资源的申请、审批、提供、销毁等；

（2） 资源初始化流程：包括操作系统、数据库、中间件、应用等方面的初始化配置工作；

（3） 资源动态管理流程：包括资源在使用过程中根据监控数据进行动态调整的各类流程；

（4） 事件处理流程：包括预警、报警、常规事件、常规故障的标准处理流程；

（5） 监控管理流程：包括监控数据收集、加工、报送、分析、处理等各环节的处理方法及步骤；

（6） 应急处理流程：预定义的系列应急处理流程，例如：流量限制、容灾切换。

3.3数据标准化

很多做运维平台的厂家到了客户现场进行调研的时候都会发现一个非常头痛的问题 。 客户实际环境当中的软件、硬件、应用等各方面的日志数据会呈现出很多形态。既有加密日志（日志表现形式为代码，需要根据代码查询日志解释说明才能定位问题的日志）也有非加密日志；既有字段形式表示的也有不加任何分割的文字串表示的，而且内容表示的方式也是各有千秋；既有文本文件也有压缩包或者其他非文本文件形式；既有保存在数据库的又有保存在目录当中的。总而言之，运维数据从形态、内容、载体等各个方面都没有经过标准化规范，最终导致运维平台可做的工作非常有限。

要实现运维自动化，数据是前提条件，没有数据的支撑就不会有后续的预警、报警以及与之相匹配的自动化运维处理过程。因此在系统、中间件、应用上线之前的设计阶段， IT运维的标准化规范就应该输入到规划设计当中。

4. 数据收集手段和工具的使用

4.1脚本工具

很多人觉得谈脚本有点落伍，应该谈一些高大上的自动化运维集成工具或者产品。其实看到本质上，任何自动化运维平台底层都是靠一些脚本去完成具体工作的，只不过是选取的脚本根据不同的运维任务在类型、定义、执行方式等方面会有所区别。抛开上层管理集成平台，聚焦到脚本本身来看的话，脚本工具在自动化运维过程当中应该在以下几个方面发挥作用：

（1） 数据收集：从很多企业的运维来看，大家都会部署一些脚本来收集硬件、系统、软件等各维度的运维信息，有些是基于实时执行结果的收集，有些是基于一定周期内的日志文件内容；

（2） 数据加工：面对大量的原始日志信息，相信依靠人力去完成价值信息的提炼是比较耗费时间的，这个时候就需要脚本基于已经收集的原始日志信息进行重复加工，最终提炼价值信息。

（ 3 ）任务流程处理：所谓任务处理就是要根据预定义的一些需求输入数据，串联或者并联一些工作步骤，从而完成一个完整的运维任务工作流程，例如：系统初始化、软件安装、资源扩展；

4.2工具使用

首先，多数实现运维自动化的思维是选择一个大而全的产品，然后让这个产品渗透到运维工作的各个维度，从而实现整体的自动化。但是结果往往差强人意，你选择的产品最终没有办法与你现有的环境非常融洽的相处，所谓的自动化只是一个局部而已。所以，笔者认为真正落地的思路是先选择设计好运维工作每一个角落的脚本工具，然后再考虑上层的管理整合。

其次，当我们在聚焦于某一个数据采集环节或者某一个运维工作任务的工具的时候，要考虑到工具本身的扩展性以及交互性。比如 Shell和Python，大多数数据采集的工具都是用Shell实现的，无论从效率上还是从与系统的融洽度角度来考虑，它都是最佳选择。但是某些需要人机交互的自动化任务就只能靠Python了，比如输入登录信息这个操作。

再次，从运维管理整体的集成角度，我们需要考虑到顶层运维工作和底层运维任务的整合逻辑。完整的运维工作解耦分解之后就是一个个聚焦到有限动作的运维任务，但是这些运维任务要组成一个完整的运维工作流是需要严密的判断逻辑和控制机制的。

5. 运维数据分析及自动化决策

运维自动化与监控自动化最大的区别就在于是否有后续的动作 。 当我们把所有的运维数据都采集完成并且按照既定逻辑进行加工处理之后，就下来就是价值信息的提取和有效动作的实施。

什么是价值信息的提取呢？举个例子：比如我们想看存储设备的负载是否正常，是否需要调整资源配置？传统模式下，工程师需要收集存储上的各种性能日志（端口性能、存储控制器 CPU及缓存、存储卷的IO性能、吞吐量等等 ），而且是需要收集一定周期内的均值和峰值数据。然后综合判断之后，决策需要调整资源或者无需调整。如果是自动化运维，我们就需要把工程师如何分析和判断的逻辑以及经验设计到脚本当中。逻辑可以提炼成算法，经验可以提炼为历史数据的概率算法。

什么是有效动作的实施呢？举个例子：比如大多数金融企业都会面临的购物刷卡的特殊节日或者时间段，如果是可预知的情况，很多相关的工程师会提前值守，应用工程师实时观察应用处理业务的情况， IT工程师观察计算、网络、存储等各类资源的使用情况，一旦监控出现异常情况，IT工程师会把提前准备好的相关服务器资源安装配置好应用之后丢进资源池，这是通常的应急处理方法。 如果是自动化运维，我们就需要把工程师对应用、系统、网络等各方面实时监控到的信息进行判断的逻辑进行标准固化，同时需要将准备资源、初始化资源、分配资源以及对外提供服务的一系列操作进行脚本化。

6. 结语

总结而言，运维自动化是企业 IT运维追求的重要目标。 实现运维自动化的前提条件在于标准化，保障运维自动化质量的关键在于运维数据的利用，落地运维自动化项目的思路在于从下往上的设计思路。