本次交流活动,针对企业在建设自动化运维体系时,要面对的几个要点问题进行了讨论。下面,分别从自动化运维的演进过程、运维工具选择、CMDB设计、监控指标和风险应对等方面对本次活动进行总结。
活动中,几位会员通过案例与大家分享了各自企业在自动化运维建设实践中,所历经的几个演变阶段。将自动化运维体系的演进过程总结为:操作自动化、流程自动化、智能化运维三个阶段。
第一阶段实现操作自动化,该阶段就是使用脚本或者工具替代传统手工的运维工作,该阶段仅仅是解决了手工执行的问题,而随着系统规模和需求的变化,脚本和工具配置方式也要随之变化,可以说仅仅实现操作层面的自动化,我们的运维压力仍然很大。那么,这就需要向流程自动化演进。
第二阶段实现流程自动化,该阶段要将第一阶段的脚本或者运维工具与企业的ITIL进行对接,使自动化运维技术和流程衔接起来,让运维的具体工作流程化,这时,就要制定企业的运维标准化,包括硬件、OS、监控、协议等各组件的标准化,并且在标准化制定后,无论是变更、系统上线等运维工作都要遵循标准化的基线,做到能够实时更新和细化CMDB配置项。
前两个阶段建设完成后,简化了大量日常运维工作,运维流程也能够梳理得比较顺畅,还可以在故障发生时及时告警;但,并不能有效发现系统潜在风险点,故障预警也比较困难。
第三阶段实现运维智能化,该阶段的目的就是要解决前两个阶段的痛点,通过集中存储运维数据和日志(包括历史指标、性能监控等),按照CMDB中各系统间关联关系和运维体系中相应的处理策略,形成对所运维对象潜在风险挖掘与分析和故障快速定位及处理。
案例分享1,来自董志卫
第一阶段:业务快速发展,服务器大量扩增,运维人员少,系统状态实时监控就无法兼顾,面对上述问题,采用IBM-Tivoli产品实现自动化监控。
第二阶段,面对业务快速部署需求,采用了IBM PureApplication一体机实现了应用快速部署,采用PowerVC、VMware等技术实现了虚机自动发布。
第三阶段,面对大量信息系统配置变更影响需求,开始实现CMDB自动采集功能。只是列举一部分,自动化运维这条路是永无止境,需着技术发展,自动化运维将是越来越普及的
案例分享2,来自chengzq:
第一阶段: 使用ca的监控工具ehealth和spectrum ,配合直接开发脚本或工具完成绝大部分监控。
第二阶段:配合以上工具,使用python开发资产管理系统配合监控等,配合cmdb 逐步完善功能,开发专有工具完成was的自动部署。
企业在自动化运维建设过程中,CMDB起到的支撑作用越来越大,CMDB已不在是传统意义上的资产管理,而更加侧重在IT资源的关联上,那么CMDB该如何设计才能够让IT资源联动起来,使运维发挥最大的价值呢?在实施CMDB过程中又该注意哪些问题? 有哪些标准化的模型?
监控:
整个cmdb包括的东西很多:主机,存储,网络,web,中间件,db ,资产等等,需要监控的指标可多可少,也可逐步完善。
在数据录入CMDB过程中,遇到了数据来源多,有冲突的问题,以及数据准确率低、没有及时维护的情况。
解决这类问题,首先确定了CMDB地位,以CMDB为核心修改上下游数据;还要做好对CMDB数据的定期审计,利用策略和规则统一数据的更新来源。
在企业自动化运维体系的建设中,关于工具的选型。从宏观上,可将运维工具分为两大类:一类是IT运维监控和诊断工具。另一类是运维流程和配置的自动化工具。前者主要功能是对系统进行健康及安全合规检查、对重要IT设备实施监控及时报警,主要的工具有Zabbix、Nagios、 Tivoli Monitor等。后者主要功能是配置维护和管理以及系统日志的收集分析等,主要的工具有Puppet、 Ansible等。
总体来说,自动化运维产品的功能特点都大同小异,也各有千秋,如Microsoft autopiolt、BMC bladelogic、HP-Opsware、IBM-Tivoli TEC、Puppet、Saltstack、Ansible这几款产品基本上都能满足企业自动化运维的需求,在选择上还是要根据自身系统需求来。下面,简述下这几种自动化运维工具的重点:
商业化产品的优势在于服务响应较快,运维自动化的数据模型较为丰富:
BMC bladelogic产品链较为丰富,在Server、Network、Database上都有自动化的产品,这些产品的侧重点是协助日常巡检、合规性检查、漏洞扫描等,是使用较多的运维工具。
IBM-Tivoli TEC除了有和Tivoli Monitor类似的监控功能外,但更加侧重与各类资源所产生事件的关联,有比较完善的分析模型。
Microsoft autopiolt侧重于大规模的web service自动化管理,业内使用得较少,但其设计思想及模型值得学习。
HP-Opsware是较早期的一款产品,后来被惠普收购,有较多的异构设备数据,覆盖范围较广,使用得也比较少。
开源产品的优势在于成本较低、易于上手和进行二次开发:
Puppet的侧重点在配置和管理系统的状态上,是目前成熟度高的工具,但个人认为,其在实时触发上稍微弱了点。
Ansible无需安装agent,主机通过SSH协议与监控对象进行通讯,从运维成本和维护性上来说,Ansible只要关注主机的运行状态即可,不会增加额外的运维成本。
SaltStack需要在master和监控对象主机上启动进程,并且需要检测该守护进程的状态,增加了一定成本,也造成了安全隐患。
与监控平台互补:自动化运维工具的选择,要结合企业监控运维平台的架构规划,对监控平台进行有效支撑和互补,尽量自动化运维组件与监控组件集成,避免重复建设。
自动化运维体系是一条集监、管、控一体的能力链,而其中监控告警是其中的基础环节,监控本身也需要形成对故障的采集、处理、发现、定位、解决的一个闭环。
对于自动化运维监控指标的定义,应该以ITIL为基础,而标准和规范的制定也要结合实际需求,可以按照:监控指标梳理-->监控指标阈值设置-->指标评估,这个流程进行。
可采集以下监控指标供参考:
机房环控层面监控指标可以有机房温湿度、UPS电池及主机状态、空调等。
首先要有场景,把所有涉及到的设备、日志和业务指标都统一放到这个场景中(例如:xxxx应用场景:F5哪个端口,哪些Farm,主机的CPU、网络设备端口、日志关键字还有业务指标这些全部关联到这个场景),可以根据已有的规则就行报警,要是没有规则可以把报警信息全部列出来,分析完问题后,可以新增规则,根据这些规则就可以搭建智能报警和诊断分析模型。
这方面的产品大致原理是基于业务架构,结合数据流关系,通过触发条件和一些权重算法,将监控告警信息进行筛选分类,并按照告警触发场景的规则建立关联关系。
主流的监控产品如zabbix确实有您说的这个问题,在告警自动分析和规则设定上缺少完善的模型,这种情况,大部分还是要运维人工为系统增添分析策略包括一些脚本话的开发。
IBM TIviol产品还是不错的,开放平台与AS400平台,可以自发定制告警场景,构建告警策略,有日志分析平台,可根据你的日志分析需求,进行定制开发。其实你也可以自己搭建个规则处理平台,让告警平台提供一个接口,让所有的告警都发到你的规则处理平台,进行日志分析。
日志分析是定位故障最基础的数据来源,对日志分析的整个流程,无非就是日志采集、存储、处理、分析及故障定位这几个关键步骤。
早期的自动化运维工具和一些监控工具大都是利用系统日志来触发告警,如今的自动化运维慢慢发展到要结合企业CMDB的建设,但CMDB中,日志同样也是重要的配置项。
如果仅仅要对日志分析,可考虑使用如ELK、Hadoop等一些工具,无论是使用工具与否,做好日志分析,还是要从以上所说的几个关键步骤来做:
日志采集上要注意对大量异构日志的采集方法,做到可持续高速即可。
日志存储上方面可借助一些非关系型数据库,保证存储能够水平扩展以及进行全文索引。
日志处理分析层面要结合相关的情景数据进行监控和关联分析,这也是快速定位故障的关键。
自动化运维工具上线后,在减轻运维工作量的同时也带来了潜在风险,尤其是在对系统进行大批量变更时,如安全基线防护、补丁升级等工作,一旦出现问题,往往难以补救。而除了上述风险,自动运维平台自身可能也存在漏洞,很容易被黑客攻击利用,出现灾难性的后果。
措施:
企业实施自动化运维后,运维团队的职责应该进行细化,至少应有如下职责分工:
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞6
添加新评论0 条评论