成功建设自动化运维体系，这六个关键点如何把握：演进过程工具选择CMDB设计等

Posted 2021-05-01 twt企业IT社区

自动化运维已成为企业信息化建设生态环境中重要一环，为企业各信息系统正常运行和日常监管提供有力支撑，并能有效提升企业ITSM，降低TCO成本。而如何梳理好自动化运维体系的相应要点，为企业搭建成一体化、综合性的日常运维、监管、监控和调度平台值得深入了解。

不久前的社区交流活动“自动化运维体系要点分析及探讨”，针对企业在建设自动化运维体系时，要面对的几个要点问题进行了讨论。由活动特邀嘉宾willow（某银行系统工程师），分别从自动化运维的演进过程、运维工具选择、CMDB设计、监控指标和风险应对等几方面对内容进行梳理。

一、企业在自动化运维体系建设中的演进过程

活动中，几位会员通过案例与大家分享了各自企业在自动化运维建设实践中，所历经的几个演变阶段。将自动化运维体系的演进过程总结为：操作自动化、流程自动化、智能化运维三个阶段。

第一阶段实现操作自动化，该阶段就是使用脚本或者工具替代传统手工的运维工作，该阶段仅仅是解决了手工执行的问题，而随着系统规模和需求的变化，脚本和工具配置方式也要随之变化，可以说仅仅实现操作层面的自动化，我们的运维压力仍然很大。那么，这就需要向流程自动化演进。

第二阶段实现流程自动化，该阶段要将第一阶段的脚本或者运维工具与企业的ITIL进行对接，使自动化运维技术和流程衔接起来，让运维的具体工作流程化，这时，就要制定企业的运维标准化，包括硬件、OS、监控、协议等各组件的标准化，并且在标准化制定后，无论是变更、系统上线等运维工作都要遵循标准化的基线，做到能够实时更新和细化CMDB配置项。

前两个阶段建设完成后，简化了大量日常运维工作，运维流程也能够梳理得比较顺畅，还可以在故障发生时及时告警；但，并不能有效发现系统潜在风险点，故障预警也比较困难。

第三阶段实现运维智能化，该阶段的目的就是要解决前两个阶段的痛点，通过集中存储运维数据和日志（包括历史指标、性能监控等），按照CMDB中各系统间关联关系和运维体系中相应的处理策略，形成对所运维对象潜在风险挖掘与分析和故障快速定位及处理。

具体案例如下：

案例分享 1

（by 董志卫)

第一阶段：业务快速发展，服务器大量扩增，运维人员少，系统状态实时监控就无法兼顾，面对上述问题，采用IBM-Tivoli产品实现自动化监控。

第二阶段，面对业务快速部署需求，采用了IBM PureApplication一体机实现了应用快速部署，采用PowerVC、VMware等技术实现了虚机自动发布。

第三阶段，面对大量信息系统配置变更影响需求，开始实现CMDB自动采集功能。只是列举一部分，自动化运维这条路是永无止境，需着技术发展，自动化运维将是越来越普及的.

案例分享 2

（by chengzq）

第一阶段： 使用ca的监控工具ehealth和spectrum ，配合直接开发脚本或工具完成绝大部分监控。

第二阶段：配合以上工具，使用python开发资产管理系统配合监控等，配合cmdb 逐步完善功能，开发专有工具完成was的自动部署。

二、自动化运维体系中CMDB的设计

企业在自动化运维建设过程中，CMDB起到的支撑作用越来越大，CMDB已不在是传统意义上的资产管理，而更加侧重在IT资源的关联上，那么CMDB该如何设计才能够让IT资源联动起来，使运维发挥最大的价值呢？在实施CMDB过程中又该注意哪些问题？ 有哪些标准化的模型？

CMDB设计原则：

1.CMDB内容的获取的方式和数据库的准确性。 如何通过工具及时有效自动完成cmdb内容的更新是后续维护cmdb准确性的重要方面。

2.配置流程管理： 配置流程和cmdb 的位置同等重要，就算cmdb 再怎么正确，如果没有适合公司自身的配置管理流程，也将会乱的一塌糊涂。

3.监控: 整个cmdb包括的东西很多：主机，存储，网络，web，中间件，db ，资产等等，需要监控的指标可多可少，也可逐步完善。

CMDB设计中痛点解决：

1.我们在进行CMDB建模过程中，由于缺乏经验和一些实际的参考，造成了粒度失真，模型建立不实用的问题。 针对这类问题，我们重新梳理了数据，将数据类型标签化，标准就是能够做到动态调整数据属性，还有就是我们重新梳理了各数据类型间的关系，也重新建立联系。

2.在数据录入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和监控对象主机上启动进程，并且需要检测该守护进程的状态，增加了一定成本，也造成了安全隐患。

选用自动化运维工具时要考虑的因素：

1.个性化开发：所选择的运维工具应该能够结合用户痛点和用户体验，应该能够实现各类监控对象的脚本定制开发。

2.易交付、易操作：自动化运维平台工具的选择本身就是为了提高运维的工作效率，因此尽量选择本身设计简单化并且易于交付的工具。

3.与监控平台互补：自动化运维工具的选择，要结合企业监控运维平台的架构规划，对监控平台进行有效支撑和互补，尽量自动化运维组件与监控组件集成，避免重复建设。

四、监控指标

自动化运维体系是一条集监、管、控一体的能力链，而其中监控告警是其中的基础环节，监控本身也需要形成对故障的采集、处理、发现、定位、解决的一个闭环。

监控指标如何定义和采集：

对于自动化运维监控指标的定义，应该以ITIL为基础，而标准和规范的制定也要结合实际需求，可以按照：监控指标梳理-->监控指标阈值设置-->指标评估，这个流程进行。

可采集以下监控指标供参考：

1.系统资源层面可按照OS、DB、Middleware、Storage这几个大类来细分；

OS层面可进行监控的指标有CPU、MEM、磁盘空间、换页、报错日志。

DB层面重点监控实例运行状态、表空间、锁资源、缓冲池命中率、会话数等。

Middleware中业务中间件如WAS、Weblogic重点监控内存资源使用情况、最大连接数、空闲线程数之类，消息中间件监控如队列管理器和通道状态、死信队列、是否有消息堆积等。

Storage监控的指标有I/O性能、光纤交换机、多路径状态等。

2. 应用层面的监控指标可细分为服务进程、交易数据、日志、作业调度、批处理、报文等。

3. 硬件层面可对服务器、网络设备、存储等设备监控如电源、温度、风扇从不同维度反应设备运行情况和质量。

4. 机房环控层面监控指标可以有机房温湿度、UPS电池及主机状态、空调等。

告警如何自动分析处理：

首先要有场景，把所有涉及到的设备、日志和业务指标都统一放到这个场景中（例如：xxxx应用场景：F5哪个端口，哪些Farm，主机的CPU、网络设备端口、日志关键字还有业务指标这些全部关联到这个场景），可以根据已有的规则就行报警，要是没有规则可以把报警信息全部列出来，分析完问题后，可以新增规则，根据这些规则就可以搭建智能报警和诊断分析模型。

这方面的产品大致原理是基于业务架构，结合数据流关系，通过触发条件和一些权重算法，将监控告警信息进行筛选分类，并按照告警触发场景的规则建立关联关系。

主流的监控产品如zabbix确实有您说的这个问题，在告警自动分析和规则设定上缺少完善的模型，这种情况，大部分还是要运维人工为系统增添分析策略包括一些脚本话的开发。

IBM TIviol产品还是不错的，开放平台与AS400平台，可以自发定制告警场景，构建告警策略，有日志分析平台，可根据你的日志分析需求，进行定制开发。其实你也可以自己搭建个规则处理平台，让告警平台提供一个接口，让所有的告警都发到你的规则处理平台，进行日志分析。

监控日志的分析：

日志分析是定位故障最基础的数据来源，对日志分析的整个流程，无非就是日志采集、存储、处理、分析及故障定位这几个关键步骤。

早期的自动化运维工具和一些监控工具大都是利用系统日志来触发告警，如今的自动化运维慢慢发展到要结合企业CMDB的建设，但CMDB中，日志同样也是重要的配置项。

如果仅仅要对日志分析，可考虑使用如ELK、Hadoop等一些工具，无论是使用工具与否，做好日志分析，还是要从以上所说的几个关键步骤来做：

日志采集上要注意对大量异构日志的采集方法，做到可持续高速即可。

日志存储上方面可借助一些非关系型数据库，保证存储能够水平扩展以及进行全文索引。

日志处理分析层面要结合相关的情景数据进行监控和关联分析，这也是快速定位故障的关键。

五、自动化运维潜在风险及应对措施

自动化运维工具上线后，在减轻运维工作量的同时也带来了潜在风险，尤其是在对系统进行大批量变更时，如安全基线防护、补丁升级等工作，一旦出现问题，往往难以补救。而除了上述风险，自动运维平台自身可能也存在漏洞，很容易被黑客攻击利用，出现灾难性的后果。

措施：

1. 制定比较通用的校验架构，按脚本规范编写脚本利于脚本的校验；

2. 自动化运维的管理账号权限设置是否合理，该账号是否限定了权限，能不能通过该账号重启一些重要服务;

3. 有一些像配置核查的功能也能够帮助我们找出配置的不一致，这些校验功能帮助我们查出风险；

4. 自动化运维的交互界面，对一些高危动作，如执行rm *，是否做了二次提醒和密钥验证

5. 自己编写一些脚本各数据的脚本做成定时任务执行，定时的反馈信息；

6. 还有就是一些报表，报表也可以校验数据。不同的校验方法针对不同校验级别的数据和功能;

7. 需要使用自动化运维平台实施的大规模变更，是否有完善的审核制度。

8. 对于自动化运维平台本身程序版本、运维策略，是否验证过备份和恢复。

9. 还有限制一些风险的操作，例如：rm，像这些操作就要有审核机制或者其他管理方法。应对风险还有一种就是操作日志，可以通过操作日志进行方向操作能够找回数据。

六、自动化运维人员职责范围

企业实施自动化运维后，运维团队的职责应该进行细化，至少应有如下职责分工：

1. 监控运维：由值班人员7*24小时，维护监控工具，做简单的故障处理和告警通知。

2. 系统运维：由系统管理员和DBA负责，处理系统级问题

3. 应用运维：由应用人员负责，补丁更新、优化应用程序，支撑业务开发

以上3类职责划分，是IT组织架构中较为常见的运维分工。但是，在自动化运维过程中，企业需要进行大量二次开发，来实现自动化运维的工具化、平台化、定制化。因此就需要运维开发这个角色，但目前该角色定义比较模糊，传统运维角色也存在一个转型的过程。个人认为，自动化运维也是一个能将运维人员从后台辅助角色转变为保障业务质量领导者的一个过程。

点击本文左下角“阅读原文”，浏览“自动化运维体系要点分析及探讨”交流更多内容