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

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

1、系统软件：指控制和防调计算机及其外部设备，支持应用软件开发和运行的系统，是无需要用户干预的各种程序的集合.我们一股指操作系统、数据库以及中间件等辅助的成熟的软件.应用系统：指专门为满足不同领域、不同问题的应用需求而编制的软件，分为应用软件包和用户程序,翌如：银行的核心系统、前置系统、中间业务系统、财务系统等等.IE维：运维是一个非常广泛的定义.在不同的公司不同的阶段有着不同的职责与定位，展基本的职责是保证业务稳定运行.大型的公司对于运维工作要求越来越高，分工也越来越细，从大的方向可分为网站运维、系统运维、应用运维、网络运维、数据库运维、安全运维等等.CMDB:CMDBConfiguration

2、ManagementDatabase配置管理数据库。CMDB存储与管理企业IT架构中设备的各种配背信息，它与所有服务支持和服务交付流应用层面处于整个运维环节的中心位2S,与业务和资源关系最密切，因此，基于应用层面建设自动化运维将大大扩展自动化运维的使用范围和使用效果.CMDB,几乎是每个运维人都绕不过去的字眼，但又是很多运维人的痛，因为CMDB很少有成功的，因此我也把它称之为运维人的耻辱.其中失败原因大都可归结到CMDB很难做到与实际工作同步变更，造成信息的过时或错i吴，最终失去使用价值.如果从应用层面建设自动化运维系统，再丰富服务器网络等底层资源信息和管理控制，丰富业务层次的关联信息，这些实

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

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

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

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

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

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

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

10、日潮MXMfO1.a)*发版大屏监视：3.4 应用运维与系统运维的区别应用运维系统运维这堆对象应用系统服务咨执行用户（播作系统层次）生产用户或者维护用户超级用户或者监控用户运推命令或者料本较复杂.大多与用户环境相关,需要个性化鬣置.不适宜全部模板方式集中存放,但是可用APP发布式等方式共享.较御单.适宜模板方式集中存放运推任务（巡检.维护.发版等）任务大多单一但是执行情况可能S攵复杂,需要监视.因此，适宜总任务效ffit务SS执行任务简单但是可多任务多凰务器执行，事后查阅关注要素服务状态.S8务进程正常.响应及时交易状态:文易记录正常.交易情况相关情况:关联通信正京,对账正常数据座:应用表设备

11、状态:CPU、存储等使用率榛作系统:安全稳定软件安装:中间件等数据库：资源使用率4 .自动化运维平台的开发设计自动化运维平台作为管理众多应用系统和服务器等的数据中心的主要的运维管理平台，我认为要优先致力于各类运维规范标准的建设、根据规范标准建设完善平台自身功能和标准的推广应用.平台要让要应用运维人员或者普遍服务台人员麋作,除了平台本身权限控制外，还要在服务器的操作系统用户层面针对不同的功能作操作安全权限控制，总之操作记录跟踪和安全权限要作为建设点点，以便控制风险并有据可查，满足严格的监管要求。制造自动化、办公自动化除了技术升级改造外还有关键的规范化标准化工序或元件，要实现自动化运维也同样离不开

12、运堆操作和流程的规范化标准化，自动化运维平台建设必须与运维规范标准化相辅相成.通过建设自动化运维管理平台将日期IT运维中大的重复性工作(软件维护.做谨护.运行巡楼、应用自动化发布、IT信息收集、流程管理等)由过去的手工执行转为自动化媒作.通过梳理.制定IT运堆工作0三范，以技术手段作为辅助,促进仃运维工作尤其是应用运堆的榭S以流程化RJ自动化,提高工作效率,降低运雄风跄.平台建设流程控制跟踪安全权限定制化、可视化分析总结标准化操作规范化、标准化安全化、易用化各系统推广应用典型系统应用推广应用4.1 体系架构实现层as视护运行巡检日常，护席程发威.服务层自触调度自动化操作结果分析外部ma集成规范

13、化、标准化运维协议自动化接口协议处理子应用应用数据业务CMDB代理层自动化代理(Aqent)应用层面的自动化运维功能首选操作对象是应用，然后通过应用自动选择其最终操作的服务器和对应的基本操作设定，从而达到应用层面的运维目的.4.2 代理选型和接口的设计自动化运维的实现原理是通过自动化运维服务器控制数据中心的其它服务器等应用系统资源设备.要控制服务器有2种模式：代理模式和非代理模式,非代理模式如果不远程登录则只能做测试通信等有限的功能，如登录，则需要记录用户密码，在修改用户密码后需要同步，或者使用ssh的互信免密设置（SSh实际也类似于代理程序），同时登录也会耗时影响效率.因此，目前基本都是采用

14、代理模式.代理一旦选定推广，不易修改.代理的选型网上有很多文章，这里不加阐述。但是我们应该可以通过编写接口函数想藏代理细节，实现更灵活的可自由选型的自动化运维.综观了一些代理的介绍和我们应用过的Puppet+mcollective和Control-M等自动化代理软件.虽然代理工具有很多辅助的控制调用功能，但是真正能广泛使用的只是常用的几种调用，可能基于自动化等考虑，代理软件都屏蔽了标准输入，不能实时标准输出必须等命令执行完毕才能将得到整个标准输出,这就意味着我们与应用连最简单的交互都不能直接做，对运行长久的命令不能及时了解执行进展.这对于一些运维场景不是很合适或者需要做一些技术处理。原理上自动

15、化运维平台可做数据中心的全面监控，但是基于代理软件的资源开销比较大，而监控尤其是基础设备监控往往频繁又要求实时，建议安装轻量级的监控专用代理,只使用自动化运维平台中的基本关系数据.4.3 应用运维的扩展根据应用运维的模型设计，应用运维如同一个功能容器，我们可以根据不同类型的用户在上面做不同的功能整合，扩展为系统运维、数据库运维、网络运维和安全运维等专家职能运维.数据库运维主要指数据库管理员职能操作，我们可在数据库服务器上建立专属的数据库应用，将常用功能在专属的应用容器封装.网络运维指对路由器等网络设备的运维，通常我们都是通过可访问的电脑联网访问维护，我们可在专用服务器安装自动化代理建立专属的网

16、络应用，或者直接在自动化平台服务器中虚拟一个专属的网络应用，将常用功能在专属的应用容器中封装.应用层面的自动化运维，因与业务层面关系密切，可较容易地与面向业务或管理方向的ITR.类系统对接，实现业务层面的自动化运维.详见下文的日常维护。系统运运维4.4 巡检监控的扩展-指标监控分析通常监控平台都是将采集和分析显示包揽起来，完成纳管服务器等设备的所有工作,这就造成了监控功能的局限性，同时让监控管理人员疲于应付.我们可以转换思路，将采集数据做成开放式的，监控平台主做分析显示的功能.开放的监控数据我称为指标，定义各类指标规范，让各应用系统各服务器运维人员将想监控的指标按规范发送监控服务器集中分析显示

17、。如此，充分体现让专业人做专业事以及主动运维的思想.指标监控能轻易地实现网络监控、应用监控、业务监控等.警如：定义数据模型：指标编码，类别，时间，笔数，数值，状态（成功,失败），简要说明。监控平台能实时选择类别（包括全部），图示按时间（时间段可为分钟，时间段可动态调整）的指标笔数，数值总额,指标失败率，如果连续一定时间失败率超高，报警（可通过颜色声音短信等），并可查询指定时间段的明细数据.4.5 日常维护日常维护主要是指自定义豳本维护数据表少量记录、修改某一个参数，启停某一个服务等一次性的维护操作,与例行维护不同的是不需要也不允许多次执行,很多自动化平台缺乏该功能，过分强调自动化运维的批量性和

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

19、维的实例化操作.4.6 查看监视这里的查看监视不是指Si看自动化平台本身的文件内容，而是其纳管的应用系统-服务器中的文件内容.由于服务器所使用字符集的多样性，应该支持多种字符集文件的正确显示.该功能可以在统一平台饯看监视各个应用系统的日忐等文本文件，分析出现的问题，解决日志来集保存需要存储量大、不易查看、实时性差等问题。该功他也能在统一界面监控业务记录，是对一些应用系统无业务监控或者监控不友好的解决方案.5.总结应用层面的自动化运维思路，以应用为基本运维对象，整合CMDB,为我们打开了广阔的开发思路和应用场景，部分功能的探索式落地实践也取得了良好的效果.相信深入挖掘，可以很大程度上真正实现统一的全方位的数据中心自动化运维，并有助于解决各种运维系统或者工具彼此独立整合困难的问题.