企业应用级自动化运维的建设思路.docx

《企业应用级自动化运维的建设思路.docx》由会员分享，可在线阅读，更多相关《企业应用级自动化运维的建设思路.docx（16页珍藏版）》请在三一办公上搜索。

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

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

3、式向普通运维人员和管理人员展示运维进程和运维成果，微观能给后台技术人员提供尽量详细实时的运行情况和事后分析记录.实质上是对应用系统的功能修补或者是一种特殊的业务交易，原则上都可通过应用系统的优化升级根除该类操作.系统软件：指控制和协调计算机及其外部设备，支持应用软件开发和运行的系统，是无需要用户干预的各种程序的集合.我们一般指操作系统、数据库以及中间件等辅助的成熟的软件.应用系统：指专门为满足不同领域、不同问题的应用需求而编制的软件，分为应用软件包和用户程序.餐如：银行的核心系统、前置系统、中间业务系统、财务系统等等.运维：运维是一个非常广泛的定义，在不同的公司不同的阶段有着不同的职责与定位，

4、最基本的职责是保证业务鬼定运行.大型的公司对于运维工作要求越来越高，分工也越来越细，从大的方向可分为网站运维、系统运维、应用运维、网络运维、数据库运维、安全运维等等.CMDB:CMDBConfigurationManagementDatabase配置管理数据面.CMDB存储与管理企业IT架构中设备的各种配置信息，它与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配出信息的价值,同时依赖于相关流程保证数据的准确性.2.2相互关系业务、应用、系统、数据、运维等之间从定义和目标方面是各有侧函点又紧密联系的，大致关系如下图：从上图中分析，业务、应用、服务器之间都存在一对多的关系，自动化

5、运维控制的基本单位是应用系统所需的各服务器.服务器及其网络等系统运维方面的管理要素相对统一简单，因此自动化运维基于服务器资源的系统运维是比较成熟广泛的.应用层面处于整个运维环节的中心位笆，与业务和资源关系最密切，因此，基于应用层面建设自动化运维将大大扩展自动化运维的使用范围和使用效果.CMDB,几乎是每个运维人都绕不过去的字眼，但又是很多运维人的痛.因为CMDB很少有成功的，因此我也把它称之为运维人的耻辱。其中失败原因大都可归结到CMDB很难做到与实际工作同步变更，造成信息的过时或错误,最终失去使用价值.如果从应用层面建设自动化运维系统，再丰富服务器网络等底层资源信息和管理控制，丰畜业务层次的

6、关联信息，这些实际上已极大地满足了CMDB的信息要求,只要增加同步CMDB数据库机制，或者按照CMDB数据规范直接查找自动化运维数据库展示各种配营信息，就可以同步建设好CMDB.面向应用的运维能力才是真正直接作用于用户的。面向用户的价值流梳理对应的就是应用交付流的识别.里面有几个核心的场景：应用上线场毋、应用维护升级场品、应用迁移场景、应用下线场景等等，贯穿了整个应用交付的生命周期管理.3 .应用运维的模型研究应用系统规模大小不一，支撑的基础软件与硬件也不定相同，随着互联网与通信技术的发展，单纯的前后台一体的应用系统很少，大都是基于前台浏览器或微信等手机app的瘦客户端，控制管理和数据都在后台

7、服务器.本文研究系统也都默认是后台系统.应用系统总的拓扑架构如下：应用指一个应用系统，主要记录其管理属性，瞽如分类码、开发公司、负责人、维护AB角等.子应用指应用系统中相对独立的有其共同操作属性的子系统，主要记录其操作属性，譬如：部署的操作系统用户名、主工作目录等。一个应用可能包括多个子应用，每个子应用可能部署在多台服务器中，多个应用或者子应用也可能部署在同一个服务器中.为了模型的统一，我们将没有明显的多个子应用也规定一个子应用，对于复杂的多子应用的划分，尤其是使用广泛的unix类后台应用我们原则上以应用部署的麋作系统用户作为划分子应用的标准.建议应用系统不要以操作系统的超级用户部若，将超级用

8、户雷给系统运维.我们在实际工作中发现少数以超级用户部署的应用系统,实际并不需要这么高的权限.有些（子）应用存在双机或多机负载均衡或备机情况这就是一个子应用对应多服务器情况.我们也可将不同维护人不同系统类型的系统运维以子应用方式将多服务器归属管理维护.我们在服务器中记录其包括地点等资源属性。运维即运行维护，包括运行和维护两个方面.软件工程的理论和各种论坛文章大都是站在开发角度的开发维护论述,实际中作为运维主角的甲方，不一定能很好掌握应用的开发文档和代码.下面我将从甲方角度详述运行和维护的相关内容，即使不懂开发，我们也能较好地做应用运维，管控所需应用软件，当然懂开发我们就能做得更好，甚至能比只懂开

9、发的开发人员更好.3.1 应用的运行工作要点这里的应用实际上是上述的关注操作属性的子应用.我们将应用系统的各种开发特性剔除，当作一个黑窟，根据我多年的开发维护经验，应用系统实际上有着很多一致的运行关注要点，并开发了一些相应的通用运维操作程序，丰富和简化了日常运维，也能轻易地使用到应用层面的自动化运维中。资源状况：包括CPU、内存、存楮空间、数据空间等常规资源状杰.这也是很多系统层面自动化运维的主要内容，这方面很容易通用化。但应用层面可做得更精准些.服务进程：每个应用或子应用都有一个或多个服务进程和子进程，该进程应与其部署的操作系统用户相关.需见的机房监控系统很多也可监控各服务器中进程.但大都未

10、考虑用户与应用的相关问题，对于服务器存在多个应用的相似进程名不能区分，导致漏报或误报.文件清理:应用的长久运行，为了开发维护的追踪查找，必然产生大量日志和临时文件，如果长期不清理，必然会导致磁盘空间紧张，运行缓慢甚至失败.因在开发测试基本不存在该问题,导致文件清理常常被开发忽视或者清理不彻底。文件清理可分为两种模式:第一种:备份后清理；第二种：苴接清理.运维人员要根据文件的保存必要性加以区别，最好做成定时任务自动定时清理,防患于未然，也是主动运维的核心所在.数据清理：数据即数据库记录表也存在与上述的文件同样的问题.数据清理可分二种方式:第一种:当前表转移至历史表；第二种:当前表或历史表导出备份

11、后清理.通信状态:通信状态包括本应用的服务端口、外联的IP地址和端口，出于安全运行考虑很多外联IP只能在本应用部署的服务器才能访问，有些甚至未开放Ping只开放了指定端口.这些情况，常规的集中式的数据中心监控是不能做的，通过面向应用的自动化运维让该应用状态的监控成为现实.服务启停等常用维护麋作:该操作也是很多自动化运维提到的操作，这对于应用层面的自动化运维是很自然的操作.服务日志：应用日志在银行等单位的很多应用系统中很丰富和庞大，尤其是一些交易量大的交易服务日志.采用打包在自动化运维平台中下载直看是不现实的.这就需要采用实时的远程部分查阅模式或者专门的日志管理分析系统.对账情况：对账只针对部分

12、应用系统，一般用于与第三方等其它应用系统联网交易日终处理场里.有些系统有专用的对账平台或对账交易，但原理上应该都可用脚本查询到，并通过较通用模式展示.服务交易情况：交易情况分为统计情况和明细情况，统计情况可用图示展示.服务交易查询大致有以下几种方式：数据库流水表记录型:通过交易流水数据库记录直询统计，优点是查询统计方便灵活;缺点是因为不是关穗交易无相应流水表或数据库事务机制等原因导致可能有部分交易未写记录或写入失败的记录.监控记录文件型：部分功能蛟完善的应用系统可能存在该类文件，文件记录可解决无相应流水表或事务失败回滚的记录问题，能更全面地记录各类交易状态.缺点是很难直接进行较红杂灵活的查询统

13、计.日志信息抽取型：分析日志信息生成各类交易记录.该类型适用于日志较丰富但无交易数据记录或交易监控文件记录情况，可更全面地记录各类服务交易.缺点是依赖于日志记录的丰常，且分析抽取困难并可能不准确.3.2 应用的维护工作要点维护可分开发方维护和使用方维护.下面主要论述使用方维护工作技术要点，不讨论维护工作的合规性等管理要求.相关文档资料：我们要尽最掌握了解应用的设计架构、数据库结构、维护手册等维护文档，如能迸一步了解源代码会更好.这无疑是最快最好地进行维护的方式，但现实是很多应用这方面文档不全甚至没有，即使有，也不易全部深入掌握.相关目录结构：主要目录包括启停脚本或服务命令的可执行程序目录、日志

14、目录、配置信息目录和临时文件目录等.相关日志结构：运行中出现的问题，我们往往需要在相关日志中查找问题点，然后据此分析找到优化修正方法.相关表索引：索引使用不当，能显著地影响执行效率，是导致很多交易超时的主要因素之一，这方面因开发测试数据量不多，不容易发现，往往运行数月甚至数年后才能呈现.直看常用表尤其是记录数多的表是否有主键、索引，有关日期的流水记录类表是否有以日期为首关健字的索引或主键，展好还能了解分析数据府运行记录或开发代码中的相关大表直询条件是否有效地使用了索引.多年的维护工作中发现：大表没索引、索引关键字顺序不当、索引过多存在里且性的无效索引等问题是很常见的.应用层面自动化运维也可以在

15、这方面做一些记录和管理分析工作.3.3 发版流程控制：系统层面的自动化运维中大都只有静默方式的软件安装升级功能，这适应于需要大批事更新较单纯软件或者应用，如互联网应用的多服务负载均衡部署.对于很多单机或者少量机运行的应用系统，安装升级过程不完善又需要经常版本发布并不话用.因此，我们将软件一步式的静默安装升级方式，通过规范引导，设计成多步的发版流程，以便实时监控发版进程和运行日志.规范化流程化发版已在我行推广至二十多个应用系统，取得了很好的效果.该模式也能根据需要改为号默大批量软件安装升级模式。通用的发版流程如下:发版大屏监视:3.4应用运维与系统运维的区别从用房It杀绩运It宝雄对象应用茶姣J

16、务执行用户（发作东姣层次）生产用户或4婚护用户超圾用或看也校用户这堆命令或者网岐夏汆.大多与刖户环境相关.您要个性化纪.不话宜全部模板方式集中存.但是可用APP发布式萼方式共享.“筒单.遏宜极攻方式集中存放运雄任务（座椅境护.tf）任务大多一但是执行情况可建政复奈.常要超根.因纥,适宜任务单航分石执行任务黄薇但是可多任务多税务办执行,事后言阅关注要H坦务状充题务迸理正常.响应及时交8状专文8记录正常,*SMI况相关情况.关皎通信正常,对慰正常设备欢克5.存储等使用率检作系统安全事定蚊件安装中间件裤访源使用率4 .自动化运维平台的开发设计自动化运维平台作为管理众多应用系统和服务器等的数据中心的主

17、要的运维管理平台，我认为要优先致力于各类运维规范标准的建设、根据规范标准建设完善平台自身功能和标准的推广应用.平台要让要应用运维人员或者普遍服务台人员探作,除了平台本身权限控制外，还要在服务器的操作系疣用户层面针对不同的功能作操作安全权限控制，总之操作记录跟踪和安全权限要作为建设点点，以便控制风险并有据可查，满足严格的监管要求。制造自动化、办公自动化除了技术升级改造外还有关键的规范化标准化工序或元件，要实现自动化运维也同样离不开运维操作和流程的规范化标准化，自动化运维平台建设必须与运维规范标准化相辅相成.通过St设自动化运生修理平台将日常IT运生中大的复性工作(软件维妒.例行生妒.运饱检.JS

18、用自动化发布.IT信息收集.流&管理等)由过去的手工执行转为自动化Ji作.通过标理.制定IT运缰工作的规范，以技术手段作为麻江t三ia运缰工作尤其是应用运维的规范化.渝程化和自动化摄离工作效率，降低运1钢蜕台设流程控制跟踪安全权限定制化、可视化规范化、标准化安全化、易用化各系统推广应用典型系统应用推广应用TMN、平台化规苑化、标准化运维防议用户认证授权验证审批基础层代理层自动化接口协议处理CMDB自动化代理(Agent)操作系统用户级控制应用层面的自动化运维功能首选麋作对象是应用，然后通过应用自动选择其最终操作的服务器和对应的基本操作设定，从而达到应用层面的运维目的.4.2 代理选型和接口的设

19、计自动化运维的实现原理是通过自动化运维服务器控制数据中心的其它服务器等应用系统资源设备.要控制服务器有2种模式：代理模式和非代理模式,非代理模式如果不远程登录则只能做测试通信等有限的功能，如登录，则需要记录用户密码，在修改用户密码后需要同步，或者使用ssh的互信免密设置（SSh实际也类似于代理程序），同时登录也会耗时影响效率.因此，目前基本都是采用代理模式.代理一旦选定推广，不易修改.代理的选型网上有很多文章，这里不加阐述。但是我们应该可以通过编写接口函数想藏代理细节，实现更灵活的可自由选型的自动化运维.综观了一些代理的介绍和我们应用过的Puppet+mcollective和Control-M

20、等自动化代理软件.虽然代理工具有很多辅助的控制调用功能，但是真正能广泛使用的只是常用的几种调用，可能基于自动化等考虑，代理软件都屏蔽了标准输入，不能实时标准输出必须等命令执行完毕才能将得到整个标准输出,这就意味着我们与应用连最简单的交互都不能直接做，对运行长久的命令不能及时了解执行进展.这对于一些运维场景不是很合适或者需要做一些技术处理。原理上自动化运维平台可做数据中心的全面监控，但是基于代理软件的资源开销比较大，而监控尤其是基础设备监控往往频繁又要求实时，建议安装轻量级的监控专用代理,只使用自动化运维平台中的基本关系数据.4.3 应用运维的扩展根据应用运维的模型设计，应用运维如同一个功能容器

21、，我们可以根据不同类型的用户在上面做不同的功能整合，扩展为系统运维、数据库运维、网络运维和安全运维等专家职能运维.数据库运维主要指数据库管理员职能操作，我们可在数据库服务器上建立专属的数据库应用，将常用功能在专属的应用容器封装.网络运维指对路由器等网络设备的运维，通常我们都是通过可访问的电脑联网访问维护，我们可在专用服务器安装自动化代理建立专属的网络应用，或者直接在自动化平台服务器中虚拟一个专属的网络应用，将常用功能在专属的应用容器中封装.应用层面的自动化运维，因与业务层面关系密切，可较容易地与面向业务或管理方向的ITR.类系统对接，实现业务层面的自动化运维.详见下文的日常维护。系统运网络运维

22、安全运Vj维4.4巡检监控的扩展-指标监控分析通常监控平台都是将采集和分析显示包揽起来，完成纳管服务器等设备的所有工应用运维鬣务破性行场景-业务运维数据库运维作,这就造成了监控功能的局限性，同时让监控管理人员疲于应付.我们可以转换思路，将采集数据做成开放式的，监控平台主做分析显示的功能.开放的监控数据我称为指标，定义各类指标规范，让各应用系统各服务器运维人员将想监控的指标按规范发送监控服务器集中分析显示。如此，充分体现让专业人做专业事以及主动运维的思想.指标监控能轻易地实现网络监控、应用监控、业务监控等.警如：定义数据模型：指标编码，类别，时间，笔数，数值，状态（成功,失败），简要说明。监控平

23、台能实时选择类别（包括全部），图示按时间（时间段可为分钟，时间段可动态调整）的指标笔数，数值总额,指标失败率，如果连续一定时间失败率超高，报警（可通过颜色声音短信等），并可查询指定时间段的明细数据.4.5 日常维护日常维护主要是指自定义豳本维护数据表少量记录、修改某一个参数，启停某一个服务等一次性的维护操作,与例行维护不同的是不需要也不允许多次执行,很多自动化平台缺乏该功能，过分强调自动化运维的批量性和自动化.该功能是与场景化运维、业务运维对接的关键.前面已提到：业务运维实质上是交易功能缺陷或者交易程序缺陷的快速解决方案，常规的人工维护存在不规范、监管困难等诸多不足，通过该功能可较完美地解决这

24、些不足，如果进一步与面向业务的服务管理系统等ITI1.类系统对接，将一些常见的较规范的业务问题场景通过业务场里和运维麋作的模板化流程化实现规范化标准化运作，从而实现业务屈面的自动化运维.磐如:新增机构，由于应用系统众多，有些应用系统没自维护功能或难以同步维护，往往需要各自后台维护。通过将各应用系统增加机构做成模板规范化标准化，然后在增加机构的业务场景中流程化，实现业务的审批合规检查并自动完成整个的应用运维的实例化操作.4.6 查看监视这里的查看监视不是指Si看自动化平台本身的文件内容，而是其纳管的应用系统-服务器中的文件内容.由于服务器所使用字符集的多样性，应该支持多种字符集文件的正确显示.该功能可以在统一平台直看监视各个应用系统的日志等文本文件，分析出现的问题，解决日志采集保存方要存储量大、不易查看、实时性差等问题.该功能也能在统一界面监控业务记录,是对一些应用系统无业务监控或者监控不友好的解决方案。5.总结应用层面的自动化运维思路,以应用为基本运维对象,整合CMDB,为我们打开了广阔的开发思路和应用场景，部分功能的探索式落地实践也取得了良好的效果.相信深入挖掘，可以很大程度上真正实现统一的全方位的数据中心自动化运堆，并有助于解决各种运维系统或者工具彼此独立整合困难的问题.