企业应用级自动化运维建设实践.docx

《企业应用级自动化运维建设实践.docx》由会员分享，可在线阅读，更多相关《企业应用级自动化运维建设实践.docx（17页珍藏版）》请在优知文库上搜索。

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

2、之一就是IT运堆.从初期的几台服务器发展到庞大的数据中心，单靠人工已经无法满足在技术、业务、管理等方面的要求，那么标准化、自动化、架构优化、过程优化等降低IT服务成本的因素越来越被人们所正视.其中，自动化最开始作为代替人工操作为出发点的诉求被广泛研究和应用。所谓自动化运维是指通过将日常IT运维中大量的电豆性工作（小到简单的日常检直、配置变更和软件安装，大到整个变更流程的组织调度）由过去的手工执行陡为标准化、流程化和自动化操作.自动化运维通过制定IT运维工作的规范规则，辅助技术手段，促进IT运维工作尤其是应用运堆的规范化、流程化和自动化，提高工作效率，降低运行风险.宏观能通过图表流程等直观友好方

3、式向普通运维人员和管理人员展示运维进程和运维成果，微观能给后台技术人员提供尽量详细实时的运行情况和事后分析记录.目前，自动化运维基本上都是以计凭机主机、操作系统为对象的系统层面的操作，我称为基于系统层面的自动化运维.本文试图从应用蜃面探讨自动化运维的实现思路，系统运维实质性是对操作系统本身运行维护的一种特殊应用运维，业务作为一种或者多种应用系统的功能，通过业务-应用关联实现业务的应用遍历声询,通过与流程审批管理、服务管理等系统对接实现业务维护的自动化，从而实现全方位多角度的自动化运维平台.应用岷面的自动化运维己在某银行做了很多落地实践，效果很理想.由于是探索式开发，有些方面还有待完善,本文既是

4、对以往工作的总结，也想从理论上做更深入全面的研究，供自动化运维平台建设和开发的专家们参考.2 .概述2.1 相关名词业务:指各行业中需要处理的事务，但是通常偏向指俏管的事务.在IT中，指按某一共同的目标，通过信息交换实现的一系列过程。在银行IT系统中，业务大多不是独立的系统，或多或少在有多个应用系统中交流.IT运维的最终目的为各式各样的业务服务，很多IT运维事件也是源于业务问题.业务问题实质上是应用系统功能不完善或者程序实现缺陷，业务问题的运维麋作实质上是对应用系统的功能修补或者是一种特殊的业务交易，原则上都可通过应用系统的优化升级根除该类操作.系统软件：指控制和协调计算机及其外部设备,支持应

5、用软件开发和运行的系统，是无需要用户干预的各种程序的集合.我们一股指操作系统、数据库以及中间件等辅助的成熟的软件.应用系统：指专门为满足不同领域、不同问题的应用需求而编制的软件，分为应用软件包和用户程序,譬如：银行的核心系统、前笆系统、中间业务系统、财务系统等等。博维：运维是一个非常广泛的定义，在不同的公司不同的阶段有着不同的职责与定位，最基本的职责是保证业务瑁定运行.大型的公司对于运维工作要求越来越高，分工也越来越细，从大的方向可分为网站运维、系统运维、应用运维、网络运维、数据库运维、安全运维等等.CMDB:CMDBConfigurationManagementDatabase配置管理数据库

6、。CMDB存储与管理企业IT架构中设备的各种配置信息，它与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性.2.2 相互关系业务、应用、系统、数据、运维等之间从定义和目标方面是各有侧重点又案密联系的，大致关系如下图：从上图中分析，业务、应用.服务器之间都存在一对多的关系，自动化运维控制的基本单位是应用系统所需的各服务器,服务器及其网络等系统运维方面的管理要素相对统一简单，因此自动化运维基于服务器资源的系统运维是比较成熟广泛的.应用层面处于整个运维环节的中心位2S,与业务和资源关系最密切，因此，基于应用层面建设自动化运维将大大扩展自

7、动化运维的使用范围和使用效果.CMDB,几乎是每个运维人都绕不过去的字眼，但又是很多运维人的痛，因为CMDB很少有成功的，因此我也把它称之为运维人的耻辱.其中失败原因大都可归结到CMDB很难做到与实际工作同步变更，造成信息的过时或错i吴，最终失去使用价值.如果从应用层面建设自动化运维系统，再丰富服务器网络等底层资源信息和管理控制，丰富业务层次的关联信息，这些实际上已极大地满足了CMDB的信息要求,只要增加同步CMDB数据库机制，或者按照CMDB数据规范直接直找自动化运维数据库展示各种配置信息，就可以同步建设好CMDB。面向应用的运维能力才是真正直接作用于用户的。面向用户的价值流梳理对应的就是应

8、用交付流的识别.里面有几个核心的场景：应用上线场空、应用维护升级场景、应用迁移场景、应用下线场景等等，贯穿了整个应用交付的生命周期管理.3 .应用运维的模型研究应用系统规模大小不一，支撑的基础软件与硬件也不定相同，随着互联网与通信技术的发展，单纯的前后台一体的应用系统很少，大都是基于前台浏览器或截信等手机app的瘦客户端，控制管理和数据都在后台服务器.本文研究系统也都默认是后台系统.应用系统总的拓扑架构如下:应用指一个应用系统，主要记录其管理属性，鳌如分类码、开发公司、负责人、维护AB角等.子应用指应用系统中相对独立的有其共同操作属性的子系统，主要记录其操作属性，譬如：部署的操作系统用户名、主

9、工作目录等。一个应用可能包括多个子应用，每个子应用可能部署在多台服务器中，多个应用或者子应用也可能部署在同一个服务器中.为了模型的统一，我们将没有明显的多个子应用也规定一个子应用，对于复杂的多子应用的划分，尤其是使用广泛的UniX类后台应用我们原则上以应用部署的麋作系统用户作为划分子应用的标准.建议应用系统不要以操作系统的超级用户部署，将超级用户翦给系统运维.我们在实际工作中发现少数以超级用户部署的应用系统,实际并不需要这么高的权限.有些（子）应用存在双机或多机负载均衡或备机情况这就是一个子应用对应多服务器情况.我们也可将不同维护人不同系统类型的系统运维以子应用方式将多服务器归属管理维护,我们

10、在服务器中记录其包括地点等资源属性。运维即运行维护，包括运行和维护两个方面。软件工程的理论和各种论坛文章大都是站在开发角度的开发维护论述.实际中作为运维主角的甲方，不一定能很好掌握应用的开发文档和代码.下面我将从甲方角度详述运行和维护的相关内容，即使不悔开发，我们也能较好地做应用运维，管控所需应用软件，当然懂开发我们就能做得更好，甚至能比只懂开发的开发人员更好。3.1 应用的运行工作要点这里的应用实际上是上述的关注操作属性的子应用.我们将应用系统的各种开发特性剔除，当作一个黑盒，根据我多年的开发维护经验，应用系统实际上有着很多一致的运行关注要点，并开发了一些相应的通用运堆操作程序，丰畜和简化了

11、日常运维，也能轻易地使用到应用层面的自动化运维中。资源状况：包括CPU、内存、存阵空间、数据空间等常规资源状态.这也是很多系统岷面自动化运维的主要内容，这方面很容易通用化.但应用层面可做得更精准些.服务进程：每个应用或子应用都有一个或多个服务进程和子进程，该进程应与其部署的操作系统用户相关.常见的机房监控系统很多也可监控各服务器中进程.但大都未考虑用户与应用的相关问题，对于服务器存在多个应用的相似进程名不能区分，导致漏报或误报.文件清理:应用的长久运行，为了开发维护的追踪查找，必然产生大量日志和临时文件，如果长期不清理，必然会导致磁盘空间紧张，运行缓慢甚至失败.因在开发测试基本不存在该问题,导

12、致文件清理常常被开发忽视或者清理不彻底。文件清理可分为两种模式:第一种:备份后清理；第二种：亘接清理.运维人员要根据文件的保存必要性加以区别，最好做成定时任务自动定时清理,防崽于未然，也是主动运维的核心所在。数据清理：数据即数据由记录表也存在与上述的文件同样的问题.数据清理可分二种方式:第一种:当前表转移至历史表；第二种:当前表或历史表导出备份后清理.通信状态:通信状态包括本应用的服务端口、外联的IP地址和端口，出于安全运行考虑很多外联IP只能在本应用部署的服务器才能访问，有些甚至未开放Ping只开放了指定端口.这些情况，常规的集中式的数据中心监控是不能做的，通过面向应用的自动化运维让该应用状

13、态的监控成为现实。服务启停等常用维护操作:该操作也是很多自动化运维提到的操作，这对于应用厩面的自动化运维是很自然的麋作.服务日志：应用日志在银行等单位的很多应用系统中很丰富和庞大，尤其是一些交易量大的交易服务日志.采用打包在自动化运维平台中下投查看是不现实的.这就需要采用实时的远程部分直阅模式或者专门的日志管理分析系统。对账情况：对账只针对部分应用系统，一般用于与第三方等其它应用系统联网交易日终处理场里.有些系统有专用的对账平台或对账交易，但原理上应该都可用脚本查询到，并通过较通用模式展示.服务交易情况：交易情况分为统计情况和明细情况，统计情况可用图示展示.服务交易查询大致有以下几种方式:数据

14、库流水表记录型:通过交易流水数据库记录查询统计，优点是查询统计方便灵活;缺点是因为不是关键交易无相应流水表或数据库事务机制等原因导致可能有部分交易未写记录或写入失败的记录.监控记录文件型：部分功能较完善的应用系统可能存在该类文件，文件记录可解决无相应流水表或事务失败回滚的记录问题，能更全面地记录各类交易状态.缺点是很难直接进行较复杂灵活的查询统计.日志信息抽取型：分析日志信息生成各类交易记录.该类型适用于日志较丰富但无交易数据记录或交易监控文件记录情况，可更全面地记录各类服务交易.缺点是依赖于日志记录的丰常，且分析抽取困难并可能不准确.3.2 应用的维护工作要点维护可分开发方维护和使用方维护.

15、下面主要论述使用方维护工作技术要点，不讨论维护工作的合规性等管理要求.相关文档资料：我们要尽鼠掌握了解应用的设计架构、数据库结构、维护手册等维护文档，如能进一步了解源代码会更好。这无疑是最快最好地进行维护的方式，但现实是很多应用这方面文档不全甚至没有，即使有，也不易全部深入掌握.相关目录结构：主要目录包括启停脚本或服务命令的可执行程序目录、日志目录、配置信息目录和临时文件目录等.相关日志结构：运行中出现的问题,我们往往需要在相关日志中查找问题点，然后据此分析找到优化修正方法.相关表索引：索引使用不当，能显著地影响执行效率，是导致很多交易超时的主要因素之一，这方面因开发测试数据量不多，不容易发现

16、，往往运行数月甚至数年后才能呈现。叁看常用表尤其是记录数多的表是否有主键、索引，有关日期的流水记录类表是否有以日期为首关键字的索引或主键,最好还能了解分析数据库运行记录或开发代码中的相关大表查询条件是否有效地使用了索引.多年的维护工作中发现：大表没索引、索引关堆字顺序不当、索引过多存在点兔性的无效索引等问题是很常见的。应用层面自动化运维也可以在这方面做一些记录和管理分析工作.3.3 发版流程控制：系统层面的自动化运维中大都只有静默方式的软件安装升级功能，这适应于需要大批量更新较单纯软件或者应用，如互联网应用的多服务负载均衡部署.对于很多隼机或者少量机运行的应用系统，安装升级过程不完善又需要经常版本发布并不适用,因此，我们将软件一步式的静默安装升级方式，通过规范引导，设计成多步的发版流程，以便实时