1.前言

银行等信息化程度高的行业,随着业务的持续发展和不断创新，IT系统不断壮大，IT运维已经成为IT服务内涵中重要的组成部分。面对越来越复杂的业务，面对越来越多样化的用户需求，数据中心基础设施规模随之不断扩大，服务器、存储、数据库、网络资源等需求愈加旺盛，系统架构日趋复杂；在互联网和智慧化建设背景下，包括智能营销和精准获客在内的新需求大量涌现，促使应用架构呈现多元化发展趋势；监管要求日趋严格，现场监管和非现场监管、内部审计和外部审计相结合的方式，对运维标准化、规范化、合规性提出了更高的要求。

不断扩展的IT应用需要越来越合理的模式来保障IT服务能灵活便捷、安全稳定地持续保障，这种模式中的保障因素之一就是IT运维。从初期的几台服务器发展到庞大的数据中心，单靠人工已经无法满足在技术、业务、管理等方面的要求，那么标准化、自动化、架构优化、过程优化等降低IT服务成本的因素越来越被人们所重视。其中，自动化最开始作为代替人工操作为出发点的诉求被广泛研究和应用。

所谓自动化运维是指通过将日常IT运维中大量的重复性工作（小到简单的日常检查、配置变更和软件安装，大到整个变更流程的组织调度）由过去的手工执行转为标准化、流程化和自动化操作。

自动化运维通过制定IT运维工作的规范规则，辅助技术手段，促进IT运维工作尤其是应用运维的规范化、流程化和自动化, 提高工作效率，降低运行风险。宏观能通过图表流程等直观友好方式向普通运维人员和管理人员展示运维进程和运维成果, 微观能给后台技术人员提供尽量详细实时的运行情况和事后分析记录。

目前，自动化运维基本上都是以计算机主机、操作系统为对象的系统层面的操作，我称为基于系统层面的自动化运维。本文试图从应用层面探讨自动化运维的实现思路，系统运维实质性是对操作系统本身运行维护的一种特殊应用运维，业务作为一种或者多种应用系统的功能，通过业务--应用关联实现业务的应用遍历查询，通过与流程审批管理、服务管理等系统对接实现业务维护的自动化， 从而实现全方位多角度的自动化运维平台。

应用层面的自动化运维已在我工作银行做了很多落地实践，效果很理想。由于是探索式开发，有些方面还有待完善，本文既是对以往工作的总结，也想从理论上做更深入全面的研究，供自动化运维平台建设和开发的专家们参考。

2.概述

2.1 相关名词

业务:

指各行业中需要处理的事务，但是通常偏向指销售的事务。在IT中，指按某一共同的目标，通过信息交换实现的一系列过程。在银行IT系统中，业务大多不是独立的系统，或多或少在有多个应用系统中交流。

IT运维的最终目的为各式各样的业务服务，很多IT运维事件也是源于业务问题。业务问题实质上是应用系统功能不完善或者程序实现缺陷，业务问题的运维操作实质上是对应用系统的功能修补或者是一种特殊的业务交易，原则上都可通过应用系统的优化升级根除该类操作。

系统软件：

指控制和协调计算机及其外部设备，支持应用软件开发和运行的系统，是无需要用户干预的各种程序的集合。我们一般指操作系统、数据库以及中间件等辅助的成熟的软件。

应用系统：

指专门为满足不同领域、不同问题的应用需求而编制的软件, 分为应用软件包和用户程序。譬如：银行的核心系统、前置系统、中间业务系统、财务系统等等。

运维：

运维是一个非常广泛的定义，在不同的公司不同的阶段有着不同的职责与定位，最基本的职责是保证业务稳定运行。大型的公司对于运维工作要求越来越高，分工也越来越细，从大的方向可分为网站运维、系统运维、应用运维、网络运维、数据库运维、安全运维等等。

CMDB：

CMDB——Configuration Management Database 配置管理数据库。

CMDB存储与管理企业IT架构中设备的各种配置信息，它与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。

2.2 相互关系

业务、应用、系统、数据、运维等之间从定义和目标方面是各有侧重点又紧密联系的，大致关系如下图：

从上图中分析，业务、应用、服务器之间都存在一对多的关系, 自动化运维控制的基本单位是应用系统所需的各服务器。 服务器及其网络等系统运维方面的管理要素相对统一简单，因此自动化运维基于服务器资源的系统运维是比较成熟广泛的。

应用层面处于整个运维环节的中心位置，与业务和资源关系最密切，因此，基于应用层面建设自动化运维将大大扩展自动化运维的使用范围和使用效果。

CMDB，几乎是每个运维人都绕不过去的字眼，但又是很多运维人的痛，因为CMDB很少有成功的，因此我也把它称之为运维人的耻辱。其中失败原因大都可归结到CMDB很难做到与实际工作同步变更，造成信息的过时或错误，最终失去使用价值。

如果从应用层面建设自动化运维系统，再丰富服务器网络等底层资源信息和管理控制，丰富业务层次的关联信息，这些实际上已极大地满足了CMDB的信息要求，只要增加同步CMDB数据库机制，或者按照CMDB数据规范直接查找自动化运维数据库展示各种配置信息，就可以同步建设好CMDB。

面向应用的运维能力才是真正直接作用于用户的。面向用户的价值流梳理对应的就是应用交付流的识别。里面有几个核心的场景：应用上线场景、应用维护升级场景、应用迁移场景、应用下线场景等等，贯穿了整个应用交付的生命周期管理。

3.应用运维的模型研究

应用系统规模大小不一，支撑的基础软件与硬件也不定相同，随着互联网与通信技术的发展，单纯的前后台一体的应用系统很少，大都是基于前台浏览器或微信等手机app的瘦客户端，控制管理和数据都在后台服务器。本文研究系统也都默认是后台系统。应用系统总的拓扑架构如下:

应用指一个应用系统，主要记录其管理属性，譬如分类码、开发公司、负责人、维护AB角等。

子应用指应用系统中相对独立的有其共同操作属性的子系统，主要记录其操作属性，譬如: 部署的操作系统用户名、主工作目录等。

一个应用可能包括多个子应用，每个子应用可能部署在多台服务器中，多个应用或者子应用也可能部署在同一个服务器中。为了模型的统一，我们将没有明显的多个子应用也规定一个子应用，对于复杂的多子应用的划分，尤其是使用广泛的unix类后台应用，我们原则上以应用部署的操作系统用户作为划分子应用的标准。建议应用系统不要以操作系统的超级用户部署，将超级用户留给系统运维。我们在实际工作中发现少数以超级用户部署的应用系统,实际并不需要这么高的权限。

有些(子)应用存在双机或多机负载均衡或备机情况，这就是一个子应用对应多服务器情况。我们也可将不同维护人不同系统类型的系统运维以子应用方式将多服务器归属管理维护。我们在服务器中记录其包括地点等资源属性。

运维即运行维护，包括运行和维护两个方面。软件工程的理论和各种论坛文章大都是站在开发角度的开发维护论述。实际中作为运维主角的甲方，不一定能很好掌握应用的开发文档和代码。下面我将从甲方角度详述运行和维护的相关内容，即使不懂开发，我们也能较好地做应用运维，管控所需应用软件，当然懂开发我们就能做得更好，甚至能比只懂开发的开发人员更好。

3.1 应用的运行工作要点

这里的应用实际上是上述的关注操作属性的子应用。我们将应用系统的各种开发特性剔除，当作一个黑盒，根据我多年的开发维护经验，应用系统实际上有着很多一致的运行关注要点，并开发了一些相应的通用运维操作程序，丰富和简化了日常运维，也能轻易地使用到应用层面的自动化运维中。

①资源状况: 包括CPU、内存、存储空间、数据空间等常规资源状态。这也是很多系统层面自动化运维的主要内容，这方面很容易通用化。但应用层面可做得更精准些。

②服务进程: 每个应用或子应用都有一个或多个服务进程和子进程，该进程应与其部署的操作系统用户相关。常见的机房监控系统很多也可监控各服务器中进程，但大都未考虑用户与应用的相关问题，对于服务器存在多个应用的相似进程名不能区分，导致漏报或误报。

③文件清理:应用的长久运行，为了开发维护的追踪查找，必然产生大量日志和临时文件，如果长期不清理，必然会导致磁盘空间紧张，运行缓慢甚至失败。因在开发测试基本不存在该问题，导致文件清理常常被开发忽视或者清理不彻底。文件清理可分为两种模式:第一种:备份后清理; 第二种: 直接清理。运维人员要根据文件的保存必要性加以区别，最好做成定时任务自动定时清理,防患于未然，也是主动运维的核心所在。

④数据清理: 数据即数据库记录表也存在与上述的文件同样的问题。数据清理可分二种方式:第一种:当前表转移至历史表; 第二种:当前表或历史表导出备份后清理。

⑤通信状态:通信状态包括本应用的服务端口、外联的IP地址和端口，出于安全运行考虑很多外联IP只能在本应用部署的服务器才能访问，有些甚至未开放ping只开放了指定端口。这些情况，常规的集中式的数据中心监控是不能做的，通过面向应用的自动化运维让该应用状态的监控成为现实。

⑥服务启停等常用维护操作:该操作也是很多自动化运维提到的操作，这对于应用层面的自动化运维是很自然的操作。

⑦服务日志: 应用日志在银行等单位的很多应用系统中很丰富和庞大，尤其是一些交易量大的交易服务日志。采用打包在自动化运维平台中下载查看是不现实的，这就需要采用实时的远程部分查阅模式或者专门的日志管理分析系统。

⑧对账情况: 对账只针对部分应用系统，一般用于与第三方等其它应用系统联网交易日终处理场景。有些系统有专用的对账平台或对账交易，但原理上应该都可用脚本查询到，并通过较通用模式展示。

⑨服务交易情况: 交易情况分为统计情况和明细情况，统计情况可用图示展示。服务交易查询大致有以下几种方式:

3.2 应用的维护工作要点

维护可分开发方维护和使用方维护。下面主要论述使用方维护工作技术要点，不讨论维护工作的合规性等管理要求。

①相关文挡资料: 我们要尽量掌握了解应用的设计架构、数据库结构、维护手册等维护文档，如能进一步了解源代码会更好。这无疑是最快最好地进行维护的方式，但现实是很多应用这方面文档不全甚至没有，即使有，也不易全部深入掌握。

②相关目录结构: 主要目录包括启停脚本或服务命令的可执行程序目录、日志目录、配置信息目录和临时文件目录等。

③相关日志结构: 运行中出现的问题，我们往往需要在相关日志中查找问题点，然后据此分析找到优化修正方法。

④相关表索引: 索引使用不当，能显著地影响执行效率，是导致很多交易超时的主要因素之一，这方面因开发测试数据量不多，不容易发现，往往运行数月甚至数年后才能呈现。查看常用表尤其是记录数多的表是否有主键、索引，有关日期的流水记录类表是否有以日期为首关键字的索引或主键，最好还能了解分析数据库运行记录或开发代码中的相关大表查询条件是否有效地使用了索引。多年的维护工作中发现: 大表没索引、索引关键字顺序不当、索引过多存在重复性的无效索引等问题是很常见的。

应用层面自动化运维也可以在这方面作一些记录和管理分析工作。

3.3 发版流程控制:

系统层面的自动化运维中大都只有静默方式的软件安装升级功能，这适应于需要大批量更新较单纯软件或者应用，如互联网应用的多服务负载均衡部署。对于很多单机或者少量机运行的应用系统, 安装升级过程不完善又需要经常版本发布并不适用。因此，我们将软件一步式的静默安装升级方式，通过规范引导，设计成多步的发版流程，以便实时监控发版进程和运行日志。规范化流程化发版已在我行推广至二十多个应用系统，取得了很好的效果。

该模式也能根据需要改为静默大批量软件安装升级模式。

通用的发版流程如下：

发版大屏监视：

3.4 应用运维与系统运维的区别

4.自动化运维平台的开发设计

自动化运维平台作为管理众多应用系统和服务器等的数据中心的主要的运维管理平台，我认为要优先致力于各类运维规范标准的建设、根据规范标准建设完善平台自身功能和标准的推广应用。平台要让要应用运维人员或者普遍服务台人员操作,除了平台本身权限控制外，还要在服务器的操作系统用户层面针对不同的功能作操作安全权限控制，总之操作记录跟踪和安全权限要作为建设重点，以便控制风险并有据可查，满足严格的监管要求。

制造自动化、办公自动化除了技术升级改造外还有关键的规范化标准化工序或元件，要实现自动化运维也同样离不开运维操作和流程的规范化标准化，自动化运维平台建设必须与运维规范标准化相辅相成。

4.1 体系架构

应用层面的自动化运维功能首选操作对象是应用，然后通过应用自动选择其最终操作的服务器和对应的基本操作设定, 从而达到应用层面的运维目的。

4.2 代理选型和接口的设计

自动化运维的实现原理是通过自动化运维服务器控制数据中心的其它服务器等应用系统资源设备。要控制服务器有2种模式：代理模式和非代理模式。非代理模式如果不远程登录则只能做测试通信等有限的功能，如登录，则需要记录用户密码，在修改用户密码后需要同步，或者使用ssh的互信免密设置(ssh实际也类似于代理程序)，同时登录也会耗时影响效率。因此，目前基本都是采用代理模式。代理一旦选定推广，不易修改。

代理的选型网上有很多文章，这里不加阐述。但是我们应该可以通过编写接口函数隐藏代理细节，实现更灵活的可自由选型的自动化运维。

综观了一些代理的介绍和我们应用过的Puppet+mcollective和Control-M等自动化代理软件。虽然代理工具有很多辅助的控制调用功能，但是真正能广泛使用的只是常用的几种调用，可能基于自动化等考虑，代理软件都屏蔽了标准输入，不能实时标准输出必须等命令执行完毕才能将得到整个标准输出，这就意味着我们与应用连最简单的交互都不能直接做，对运行长久的命令不能及时了解执行进展。这对于一些运维场景不是很合适或者需要做一些技术处理。

原理上自动化运维平台可做数据中心的全面监控，但是基于代理软件的资源开销比较大，而监控尤其是基础设备监控往往频繁又要求实时，建议安装轻量级的监控专用代理,只使用自动化运维平台中的基本关系数据。

4.3 应用运维的扩展

根据应用运维的模型设计，应用运维如同一个功能容器，我们可以根据不同类型的用户在上面作不同的功能整合，扩展为系统运维、数据库运维、网络运维和安全运维等专家职能运维。数据库运维主要指数据库管理员职能操作，我们可在数据库服务器上建立专属的数据库应用，将常用功能在专属的应用容器封装。网络运维指对路由器等网络设备的运维，通常我们都是通过可访问的电脑联网访问维护，我们可在专用服务器安装自动化代理建立专属的网络应用，或者直接在自动化平台服务器中虚拟一个专属的网络应用，将常用功能在专属的应用容器中封装。

应用层面的自动化运维，因与业务层面关系密切，可较容易地与面向业务或管理方向的ITIL类系统对接，实现业务层面的自动化运维。详见下文的日常维护。

4.4 巡检监控的扩展--指标监控分析

通常监控平台都是将采集和分析显示包揽起来，完成纳管服务器等设备的所有工作。这就造成了监控功能的局限性，同时让监控管理人员疲于应付。

我们可以转换思路，将采集数据做成开放式的，监控平台主做分析显示的功能。开放的监控数据我称为指标，定义各类指标规范，让各应用系统各服务器运维人员将想监控的指标按规范发送监控服务器集中分析显示。如此，充分体现让专业人做专业事以及主动运维的思想。指标监控能轻易地实现网络监控、应用监控、业务监控等。

譬如：定义数据模型: 指标编码, 类别, 时间, 笔数, 数值, 状态(成功,失败), 简要说明。

监控平台能实时选择类别(包括全部), 图示按时间(时间段可为分钟, 时间段可动态调整)的指标笔数, 数值总额,指标失败率, 如果连续一定时间失败率超高, 报警(可通过颜色声音短信等), 并可查询指定时间段的明细数据.

4.5 日常维护

日常维护主要是指自定义脚本维护数据表少量记录、修改某一个参数，启停某一个服务等一次性的维护操作,与例行维护不同的是不需要也不允许多次执行。很多自动化平台缺乏该功能，过分强调自动化运维的批量性和自动化。

该功能是与场景化运维、业务运维对接的关键。前面已提到：业务运维实质上是交易功能缺陷或者交易程序缺陷的快速解决方案，常规的人工维护存在不规范、监管困难等诸多不足，通过该功能可较完美地解决这些不足，如果进一步与面向业务的服务管理系统等ITIL类系统对接，将一些常见的较规范的业务问题场景通过业务场景和运维操作的模板化流程化实现规范化标准化运作，从而实现业务层面的自动化运维。譬如:新增机构，由于应用系统众多，有些应用系统没自维护功能或难以同步维护，往往需要各自后台维护。通过将各应用系统增加机构做成模板规范化标准化，然后在增加机构的业务场景中流程化，实现业务的审批合规检查并自动完成整个的应用运维的实例化操作。

4.6 查看监视

这里的查看监视不是指查看自动化平台本身的文件内容，而是其纳管的应用系统-服务器中的文件内容。由于服务器所使用字符集的多样性，应该支持多种字符集文件的正确显示。

该功能可以在统一平台查看监视各个应用系统的日志等文本文件，分析出现的问题，解决日志采集保存需要存储量大、不易查看、实时性差等问题。该功能也能在统一界面监控业务记录,是对一些应用系统无业务监控或者监控不友好的解决方案。

5.总结

应用层面的自动化运维思路，以应用为基本运维对象，整合CMDB，为我们打开了广阔的开发思路和应用场景，部分功能的探索式落地实践也取得了良好的效果。相信深入挖掘，可以很大程度上真正实现统一的全方位的数据中心自动化运维，并有助于解决各种运维系统或者工具彼此独立整合困难的问题。