【摘要】 自动化的建设如火如荼，智能化也在蓬勃发展，但自动化依然是一个基础核心的手段。在技术方面，合适的设计理念能够帮助自动化系统升级成为基础性的工作平台，而不仅仅是一个辅助工具。

1、背景

1.1 背景分析

随着银行业务的快速发展，支撑业务的IT基础设施的变化节奏也大大加快。运维团队担负着对IT基础设施运维的重要使命，核心任务是保障生产安全运营，并提高软硬件环境的交付质量。

运维管理规模的不断扩大，运维人员的不断扩充，使我们的日常运维工作面临更大的压力与风险。

在很长一段时间里，应用运维尝试通过脚本辅助来提升工作效率，但仍然面临着繁重的工作压力：

(1)管理工作繁重，所管理的资源类型和数量众多，但是缺乏一个准确的整体资源视图，每次当有用户申请资源时，难以快速地进行分配。

(2)生产操作以登录生产主机进行手工操作为主，在手工操作时可能存在一些有意或无意的违规操作，给生产环境造成操作风险。

(3)应用变更是以纸质的变更操作步骤为依据，由运维人员登陆生产系统后进行手动操作，操作过程中对变更前后的环境变化内容没有记录。

(4)巡检工作通过操作系统的定时任务用脚本完成了数据采集，仍需由专人负责应用系统相关的日报生成与发布。采集的数据项、定时任务没有统一的管理界面，不利于数据采集内容的修订与管理。对日报的查看与分析工作也依托于管理员自觉进行，即使出现问题也没有工作界面进行记录与跟踪。

(5)数据分析目前主要是通过运维人员的个人经验进行，业务量增长、交易变化等等都依赖于运维人员的个人能力。

1.2 运维痛点

在运维管理工作中的主要痛点可以归纳总结为以下几个主要问题：

(1)、手工操作的风险不可控：日常巡检、服务请求、问题查询都通过登录生产主机进行操作。

(2)、运维工作及时性差异：各运维人员管辖的应用系统、主机数量多，巡检工作都是手工进行，无法做到及时有效在系统开门前做全面巡检。

(3)、工作规范性不强：新员工对现有的工作制度、工作流程需要一个逐步适应和熟悉的过程。不同人员对应用系统的运维管理工作细致程度存在差异，缺少统一标准。

2、建设目标

应用自动化运维系统的建设初衷是希望能建设一个服务于运维人员的统一管理工作平台，完成日常的生产系统操作任务，隔离运维人员与生产系统的直接接触。

下图展示了应用自动化运维系统与流程管理工具、监控工具之间的关系，也描述了应用自动化运维系统的功能蓝图。

通过应用自动化运维系统的建设可以提供一种新的IT运维管理和工作模式。在这种模式下，我们的运维工作可以跟流程结合，提供自动化的运维管理手段。主要功能目标可以总结为三个方面：

（一）实现调度自动化

从以前依赖手工的实现转换到通过自动化的工具来实现变更与日常巡检。

（二）实现日常运维工作标准化、规范化

对现有的运维工作事项（包括变更、巡检等）进行梳理和优化，建立标准化的应用自动化运维工作项，以促进日常运维工作的规范化。

（三）实现生产配置统一视图

对全行的服务器、存储、软件资源进行集中管理，形成资源池，集中管理核心的配置信息和关系。

对资源池中各种资源的配置信息进行自动化采集和更新，随时掌握其可用状态。建立资源的整体视图，并通过可视化视图直观展现资源之间（如宿主机与之上运行的虚拟机）的依赖关系以及与业务的逻辑关系。

3、设计原则

运维狭义定义为对IT业务系统支撑环境的运行维护活动。维护的对象包括应用程序、基础软件、操作系统、主机设备、存储设备、网络设备、机房环境等各个层次的运行实体。

运维活动一般由运维人员进行实施，包括上线、更新、下线等。在应用自动化运维的建设中要解决的是运维人员实施的各项运维活动可以由机器替代实施。在日常的运维实践中，利用定时任务、批量脚本等方式做了很多简化人工操作实施的工作，但由于这些活动每次实施的对象/约束条件存在差异，仍然会有大量操作需要人工干预。

自动化平台建设应考虑平台的可重用性与易用性，在架构设计与实现中需遵循以下建设原则：

4、关键设计思路

结合前文所提出的设计原则，我们认为 做好自动化系统有以下几个关键点： 一是须有一个可用的、完善的配置信息库，引入面向对象编程思想构建合适的运维对象模型； 二是梳理出规范性的日常运维活动场景，将运维活动工具化，实现场景组合； 三是建立有效协同机制，推动自动化建设可行性与实用性。

自动化系统是以配置管理为基础的监管控一体化，利用与运维日常操作实际相关的应用系统配置信息管理为基础构建应用模型，将应用系统与模型、配置、监控、流程衔接，围绕生产系统运行的运维操作实现监管控一体化。

4.1 面向专业领域的配置库

配置管理是运维管理中一个恒古不变的话题。配置库对自动化系统建设的到底有什么影响，应该如何梳理两者之间的关系？

配置管理的重点是数据生产、处理及消费，同时要关注数据的质量。在此不对配置管理整体建设做赘述，只是提出几个关键点：一、配置数据应建立统一的配置项标准；二是配置信息不应是静态信息，需要利用自动化实现动态采集，尽可能减少人工维护的入口与实施；三是配置信息应充分被使用即消费，充分消费并合理维护，保障配置信息可用性。

在应用自动化建设中我们也认为必须要有合适的配置信息库。这里所需要的配置信息并不需要传统配置管理管控范畴那么庞杂。而在应用自动化建设过程中我们不需要如CPU个数、MAC地址等信息，更关注的是自动化操作所需要实施的对象，以及谁对这个对象有操作权限。

应用自动化作为配置信息的消费者，如果已经有合适的配置管理工具（即生产者）做好接口，充分运用数据，避免自己维护独立的配置数据。

4.2 面向对象思维建模

面向对象起源于编程语言，是一种建立在“对象”概念基础上的方法，是目前软件开发方法中的主流方法，把面向对象的思想应用于软件开发过程，指软件导开发活动。面向对象的主要特性包括封装性、继承性、多态性。运维对象也存在着同样的一些特性，在梳理定义运维事项时也可以采用这种方法，将运维事项中的活动和运行实体建立对应关系。

引入面向对象设计理念，解决不同业务系统采用不同的技术架构和同一个业务系统在不同环境下的部署结构差异；建立应用环境模型，将环境模型与组件模型组合，实现应用与环境的关联性解耦。通过解耦规避了包括应用发布、运维工具、系统巡检等功能在开发、测试、生产环境上的差异，并实现多个同类型应用服务的重用。快速高效响应了运维需求及应用部署，在多个数据中心和混合云模式之间实现简单配置应用部署并支持持续交付。

以应用系统为例说明，应用系统是一组应用程序功能组件，可以独立运行于操作系统之上，也可以运行在一些特定的中间件上，应用组件根据功能划分为不同的组件组，整体组成提供某一类业务的支撑服务，我们把应用系统定义为一个运维对象，包括该系统的程序、配置文件、数据文件等，这些可以理解为封装性。在不同的环境下（如，开发环境、测试环境、生产环境等），有不同的配置（如，数据库连接、操作系统用户、不同组件合并部署等），对这个对象主要的运维活动有程序更新、配置更新、数据文件修改、程序启动、程序停止等活动，这些形成了应用系统的多态性。

我们把应用系统的发布活动以面向对象的思想具象化后可以总结出如下图示：

应用系统的模型与运维活动多态性示例

应用模型是基于配置管理构建的，将IT环境中的物理设备全部抽象出来，把不同的东西看成统一的一种对象。利用配置项和它们的属性来体现IT环境中的对象，再用关系把它们在IT环境的关系表现出来，得到了一个简单有效的环境模型，可以用统一的方法来进行管理，利用以面向对象的技术提供通用数据模型，可视化管理，自定义建模型，快速继承，可再进行扩展,可在线调整模型。

合理的模型设计与应用场景结合是有效手段，对于模型设计的特点简单归纳如下：

• 开发、测试、运维协同按应用系统、按技术架构和部署架构进行分解；
• 将开发、测试、生产环境上的差异性配置信息进行参数化，通过不同环境绑定不同的参数实例值建立通用应用环境模型和部署环境模型，实现应用系统无关性和基础环境无关性的模型；
• 消除开发、测试、运维环境差异，消除应用系统之间差异，实现环境的一致性通用模型管理。

4.3 运维场景化

应用自动化运维的主要目标是要提升运维工作中的效率、规范和可靠问题。效率的提升直接体现是可并行实施的运维活动数量，对单个运维活动实施时的服务停机时长控制；而规范和可靠更多的是从不同人员在执行同一运维活动时所带来的效果和质量的一致性。

以日常运维场景为基础，将运维手册中的操作以操作简单、可重用原则为基础进行原子化拆分，规范输入输出，由专业运维人员在平台中进行原子工具步骤实现，根据不同应用场景对原子操作进行组合，形成场景工具/流程交付给使用。

在系统设计方面将功能、服务、操作等进行原子化设计实现，上层设计场景组合模型，不同的场景组合通过自由定制原子服务即可完成场景服务的构建与应用。

如基于原子化的应用变更一键式发布场景，以应用模型组件为基础对发布活动拆分成细粒度的发布步骤，实现原子步骤在不同形态发布中的重用。利用应用组件实现步骤与环境的松耦合，通过参数化实现环境差异性支持；如基于原子化的自动化一键式验证组合工具，通过将原子工具进行自由组合完成定制，也可将已定制的组合工具作为一层原子工具进行组合，实现灵活的场景组合。

4.4 运维知识的工具化设计

项目建设中为了更好的实现大一线运维体系中知识的转移与运用，我们引进工具箱的设计理念，由三线、二线人员将专业知识固化为工具，系统将工具与监控告警实现自动匹配，通过关联自动展现给一线具体运用，实现监控告警信息的自动诊断与快速处理。

5、系统定位

应用自动化运维系统在实现运维工作自动化的同时，也需要考虑与流程管理、监控等工具实现有效对接，提升联动效率，实现流程即服务。

在系统功能上着重考虑与已有的配置管理、流程管理、应用监控等工具系统之间关联性：

一、与配置管理系统的关系

行内统一建设CMDB标准，自动化系统从CMDB获取各系统的设备信息，包含设备信息、管理员信息、配置参数等。

二、与流程管理系统的关系

所有ITIL流程都在流程管理系统中实现，自动化侧重于将目前应用管理员的生产操作进行集中管理，专业化工具做专业范畴的事。

三、与应用监控的关系

报警联动：告警出现后的自动系统检查与现场保存在监控项目中统一实现，自动化平台侧重于生产操作工具集的建设，这些工具可以通过脚本、或者菜单形式提供给一线团队。

6、技术方案

6.1 功能概述

在应用自动化运维系统建设思路上，以一个完善的生产配置库为基础，实现业务系统的服务请求处理、操作工具箱使用、应用投产、系统变更、日常巡检及性能数据分析。

应用自动化运维系统在功能上包含自动发布、自动巡检、运维工具等功能模块，实现应用发布、巡检自动化、运维工具箱的所能操作的基础设备的管理和相关的功能权限管理，通过运行数据分析对所有的操作进行整体监控。

整体功能架构图如下：

6.2 总体架构示意

系统总体架构可以划分为门户展现、流程调度引擎、操作调度引擎三层。门户是统一的web操作入口门户，为各类用户提供统一的B/S操作界面；流程调度引擎模块实现统一的操作流程串接，将原子化作业组合形成批量文件分发、脚本执行、合规检查、软件安装部署等运维活动场景的具体实现；操作调度引擎模块实现具体脚本命令在目标机上的执行。示意图如下：

6.3 物理架构示意

系统部署上应考虑多机房部署及多活部署，具备横向扩展能力，具备对各类基础环境的管理能力。示意图如下：

7、主要场景实践

7.1 发布自动化

在发布流程管理上需要协调开发、测试和运维三个部门之间的沟通、协作和集成。自动化发布流程由开发进行构建，测试进行验证，运维进行实施。制定核查任务清单，投产前核查逐一确认检查结果，确保参数、步骤、流程正确性。

在自动化系统部署上，考虑将开发、测试与生产环境独立部署与物理隔离，以规避开发测试环境对生产的误操作。

应用发布流程示意图

由于整个发布过程涉及开发、测试、运维等多个环节，在多环境差异的背景下，充分考虑平台的易用性、流程的可复用性，通过设计环境模型、组件模型解决开发、测试、生产不同环境的服务器差异，实现发布请求、环境、服务器的解耦；通过设计参数模型，解决服务器配置信息的差异，解耦发布步骤与目标服务器；通过发布流程迁移功能，实现发布请求、发布作业、发布参数经开发、测试、生产三个过程的自动化迁移，充分保证整个发布流程的可复用性与完整性，整个发布流程仅在开发阶段构建并测试完成后，即可整体迁移至生产环境，充分保证生产发布的正确性。

应用环境模型与参数实例示意图

发布自动化模块主要包括发布请求构建、发布作业构建、发布流程迁移等功能。自动化发布通过构建发布作业，创建应用发布步骤，完成发布过程请求的构建，然后进行发布请求排期、授权、执行来完成整个应用发布过程，实现应用发布规范化、流程化管理。

请求构建可为大部分常规应用系统发布提供标准请求模板，各应用系统通过选择请求模板和简单定义可快速制定发布请求流程，流程可以最大程度复用模板内容，不需要重复定义。同时也提供离线的Excel导入构建发布请求的功能，实现简单、快速定制发布请求流程。

发布请求定义对单机多实例、多机单实例等负载均衡模式提供支持，不需要分别定义每个实例、机器的发布步骤，可以通过资源组指定实现请求步骤执行；单个步骤支持跨服务器功能的调用；请求定义与服务器资源定义分离，方便同一请求在投产验证环境和生产环境的实施。

发布作业构建功能提供自动化发布作业的新建、查询、修改、删除功能，在构建作业时，用户只需指定系统等条件并上传自动化发布脚本，整个自动化发布作业的构建过程都有平台后台程序自动创建，大大降低用户构建作业的复杂度，提升用户的体验。

发布流程迁移提供包括发布请求、发布作业、发布参数等的迁移功能，可将构建的发布流程等信息经开发、测试环境无缝迁移至生产环境，实现由开发进行一次构建，测试进行验证，运维进行实施的整个过程。在降低构建复杂度、提供工作效率的基础上，充分保证生产发布的正确性。

发布请求审批授权功能实现自动化发布流程启动执行前的审批授权功能。自动化发布作业构建完成后，需要构建发布请求，流程中的步骤关联自动化发布作业，实现自动化发布。

7.2 巡检自动化

以前的巡检工作，尤其是应用巡检，各个系统没有一个统一的规范、标准，导致巡检的范围和深度都存在一定的局限性，并且是基于人工的手工统计工作，导致工作效率比较低，同时耗费较大的人力资源。

巡检自动化的建设通过制定标准、规范，制定统一的巡检指标、巡检方式、基本巡检频度等，保证巡检标准化、巡检范围、巡检深度；通过设计巡检作业、数据采集方式、自动化作业调度等实现日常巡检的自动化，代替手工工作，提高效率的同时，解放管理人员，释放管理人员更多的精力，使更多的精力处理更重要的事项。

对于应用自动化巡检的巡检方式、巡检内容、巡检规则、巡检任务、巡检报告、巡检结果处理等。

巡检频度、巡检指标项、巡检分类都是需要事先约束定义的内容。如，巡检可分为日常检查、重保检查、临时检查等。巡检项应包括交易量、平均响应时间、Weblogic线程数、JDBC连接池数等，我们对巡检项定义了多级分类，便于统一标准。

巡检任务配置可以灵活定制，指定巡检任务运行时的目标服务器，支持同时指定一个或者多个服务器。

巡检任务执行可根据需要设置不同维度的作业运行时间表进行调度。结果可以通过邮件等方式发送。巡检结果要求运维人员确认处理。

7.3 运维工具箱

生产系统在发生故障或告警情况下，可以通过运维工具箱进行初步的诊断分析，同时可以进行一些经过预授权的应急操作，如应用服务重启、生产参数修改等紧急操作。各个系统事先预定的应急预案操作流程定制在系统中，一线运维人员或管理员在紧急情况下可以通过平台进行应急操作，不需要登录生产系统进行手工操作。

监控告警联动功能将统一监控平台主动推送的告警信息进行展示，可通过不同的条件组合进行告警信息的查询。同时提供告警忽略功能，由一线人员判断告警信息，无用的告警可通过忽略告警功能进行忽略屏蔽，忽略后可以不针对此告警信息进行故障诊断、分析、处置等一系列操作。

监控告警诊断、分析、处置功能通过告警页面单击告警信息后跳转至当前页面，当前页面提供诊断、忽略、完成处理、取消、业务影响分析等功能。经诊断功能可查询出关联的运维工具箱，通过执行一系列的工具进行告警的诊断、分析、处置，最终完成告警的处理工作，并录入处理结果。

8、结束语

自动化的建设如火如荼，智能化也在蓬勃发展，但自动化依然是一个基础核心的手段。自动化运维非一蹴而就，需要循序渐进，在安全可控的基础上逐步扩展。这是一种新的运维工作模式，有效的组织模式也是自动化项目成功实施的关键。

在技术方面，合适的设计理念能够帮助自动化系统升级成为基础性的工作平台，而不仅仅是一个辅助工具。