如何基于开源软件自主开发自动化运维系统docxWord文档下载推荐.docx

如何基于开源软件自主开发自动化运维系统docxWord文档下载推荐.docx

《如何基于开源软件自主开发自动化运维系统docxWord文档下载推荐.docx》由会员分享，可在线阅读，更多相关《如何基于开源软件自主开发自动化运维系统docxWord文档下载推荐.docx（13页珍藏版）》请在冰豆网上搜索。

2、基础监控盲点多，覆盖面不全，信息系统故障得不到及时响应，告警信息无法正确匹配软硬件资源而产生误告的痛点。

（1）信息资产多，信息更新快，监控部署和清除跟不上变化，需经常查漏补缺，未及时被监控的系统风险极大。

（2）未被自动化运维系统管控的计算实例，无法自动釆集信息、批量查询、操作和巡检等，需要人工梳理和发现。

（3）未被监控和自动化运维的计算实例无法通过有效地手段告知运维人员。

3、运维人员忙乱于繁杂的软硬件与运行环境的部署、安装、创建与配置，整体运维效率低下，精细化水平不高。

（1）运维人员的大部分精力耗费在运维环境部署上，尤其体现在新系统上线频度高，上线量和环境部署量大时，因时间不足，得不到更高运维价值的锻炼,运维眼界和思路得不到开拓。

（2）单个系统逐个手动部署、安装、创建和配置，容易遗漏、错配，或者配置需保持一致的多台计算实例产生差异化。

（3）监控、备份等运维服务得不到重视，运维人员在大量完成应用环境准备后，无精力去部署监控和备份，造成系统上线后无有效监控的问题。

4、存在直接运维操作风险，运维人员水平参差不齐，无法调动更多的运维人力参与运维工作，释放更多操作员的主观能动性，团体运维的价值和力量体现严重欠缺。

（1）运维人员少，工作压力大，操作员多，但工作范畴相对单一，但介于运维技术的专业性，无法将操作员更好融入运维团队。

（2）人工巡检直接登陆系统，通过超级用户巡检，风险隐患极大，巡检人员素质参差不齐，需要靠运维人员实时跟踪其巡检，耗费精力，其他事情搁置。

（3）每次人工巡检的结果未归档和保留，更无法查询，造成运维巡检数据丢失，得不到有效积累，更无法通过历史运维数据挖掘深层次信息。

5、日常运维巡检过程可能因巡检误操作带来衍生风险，需巡检的软硬件设备与日俱增，巡检效率低下，遗检漏检等现象严重。

（1）巡检点多，类别多，涵盖面广，依靠人工单个巡检无法面面俱到。

6、应用的资源和环境申请源源不断，导致了运维人员大量时间花费在环境部署和复核方面，未及时复核的、不满足配置与基线规范的系统往往存在较大的系统、数据库、中间件、高可用等安全风险隐患，随着系统运行和业务激增，业务故障后，方才发现配置的不合规性。

（1）基础架构的标准规范无法得到有效落地，形成一•纸空文。

（2）系统上线前基础环境的配置与基线误配、错配和漏配导致的运行风险陡增。

（3）依靠人工的检查和上线前基础环境复核的点过多，难以面面俱到，同时复核到位程度也跟运维人员的能力有关，隐藏配置不合规风险问题依旧存在。

二、总体规划

为有效解决我行现有痛点，对照我行固本强基、提质增效的工作总要求，我科坚决革故鼎新，在运维领域坚持自主运维与科技创新齐进，推动运维领域工作迈向信息化、数字化、自动化、智能化、场景化转型。

因此在我行现有基础监控、动力环境监控、网络监控、硬件监控、业务性能监控等监控子系统，和集中监控平台、运维大数据平台、运维流程平台等统一平台的基础之上，进一步拓展、扩大运维体系架构和覆盖范围，例如终端性能监控、应用性能监控和网络性能监控等监控子系统，统一CMDB平台、自动化运维平台和IT可视化平

台等统一平台。

整体规划架构图如下所示:

1、监控体系架构简介：

满足业务系统端到端监控的需求。

建立用户APP、WEB、客户端等终端的终端性能和体验监控系统，通过不同的方式收集各类终端的行为或体验数据，接入后端运维大数据，为不同的用户的行为进行画像，供精准营销或者风控项目消费，进一步指导业务的运营和管理；

建立从业务层、网络层和应用层三个层面和角度的专业监控系统，输出各个层面的监控和统计指标，满足故障排查和定位根因提供不同角度的监控支持，而非传统监控的只发现现象而无法定位根源点和原因；

结合现有各项基础监控子系统，全面实时掌控业务系统各个层面的指标状态，及时定位故障根因，提升业务系统连续性。

2、自动化运维体系架构简介：

搭建自动化运维系统、自动化批量调度、自动化投产上线三个维度的自动化体系，结合上层可集成整合化的自动化运维平台，满足生产系统端到端自动化运维的需求。

加速端到端运维交付的质量和规范性，减轻运维工作成本，释放运维动能。

3、智能运维体系架构简介：

智能运维需要数据才能有产出，基础配置数据来源于CMDB,分析数据来源于各不同角度的监控子系统，通过建立运维大数据平台，来整合所有的基础性能数据、用户终端性能数据、网络性能数据、业务性能数据和应用程序性能数据等指标型数据，事件告警数据、应用口志数据和系统日志数据等口志型数据，甚至网络报文数据等，产出例如告警事件与指标性数据的关联，进行智能分析，得出可能的原因，定位告警源。

运维大数据不仅仅是简单的数据集中化和展示，更深层次的目标是多数据源的挖掘和分析，需结合人工智能技术深入探索运维智能化的落地与见效。

4、多系统、平台间联动体系简介：

统一CMDB为所有系统和平台提供统--的配置基准数据，提升联动的数据质量和效果；

自动化运维平台自动釆集和发现价值数据和数据关联，供其他系统和平台使用，和各项资源建立自动化关联关系，提供不同自动化运维场景调用API,供其他系统和平台调用；

集中监控平台对接所有监控系统和平台，实时收集所有事件和告警，结合CMDB配置数据，第一时间匹配和丰富事件告警内容，以丰富的通知手段和详尽真实的告警详情告知相关负责人；

运维大数据通过多样化、不同通道的方式，集成各系统和平台的实时或历史的结构化、非结构化数据，并进行过滤、清洗、加工、整合、分析、输出和数据持久化；

IT架构可视化系统通过业务系统部署架构图、业务逻辑架构图、业务网络拓扑图三类架构图的方式，结合运维大数据中，不同数据源的数据，包括智能运维产出的建议，进行实时的展示，让数据和图联动，更为直观的展示业务系统整体运行状况。

运维以IT架构可视化为主，智能运维为辅，强调人在运维中不可替代性。

三、自动化运维系统实践

在以上的总体规划基础之上，我科全面展开了自动化运维系统、批量调度自动化、自动化投产三位一体的自动化运维平台建设工作，通过以上项目的建设，可以很好的满足端到端运维自动化的工作任务。

由于整体文章篇幅的问题，笔者下面将重点介绍其中之一的，基于开源ansible软件和cmdbuild软件，自主部署的自动化运维系统。

我科通过Shell脚本，成功开发了若干实用功能的自动化、批量运维的友好窗口界面，并自主搭建了CMDB（配置管理数据库），便于软硬件资源集中管控。

该系统大幅提升了运维工作的效率，进一步减轻了运维人员的工作压力，并标准规范化了运维操作，同时规避了人工直接运维带来的操作风险；

该系统涵盖了生产交易类与管理类系统近2000余个计算实例的批量运维工作。

自动化运维系统整体架构如下图所示：

•用户通过窗口界面调用Ansible,来向受管控的主机执行各种命令，实现各类功能场景，包括监控批量部署、备份批量部署、日常批量运维、软件批量安装、批量巡检、配置基线批量核查等等；

•Ansible所在服务器定期执行任务计划，自动收集受管控主机的各类软硬件配置信息，并同步至CMDB中；

•Ansible所在服务器定期执行任务计划，将CMDB中的软硬件配置信息同步至集中监控平台，监控平台的告警事件的信息更精准；

•Ansible所在服务器定期执行任务计划，将集中监控平台中的监控点与CMDB中的软硬件配置信息进行比对，发现尚未部署的监控点，将该信息上送给CMDB,便于运维人员查看；

•Ansible所在服务器定期执行任务计划，同步CMDB中需要自动化运维的主机信息，并检测是否都己具备自动化运维条件（互信、Python安装等），并将尚不能进行自动化运维的主机信息上送给CMDB,便于运维人员查看；

•Ansible所在服务器定期执行任务计划，比对集中监控平台中的监控分组信息与CMDB中软硬件配置信息，发现尚未纳入监控分组中的主机，将该信息上送给CMDB,便于运维人员查看；

•Ansible所在服务器定期执行任务计划，将一体化流程平台中的软硬件资源申请相关信息同步至CMDB中，减轻人工录入的工作量。

下面对其主要功能、实践方案和实践效果详细说明。

1、理顺双数据中心软硬件资源及关联关系，将数据纳入自主开发的信息系统管理（CMDB）,结合自动化运维平台对计算实例中软硬件资源及软件版本的自动化釆集和对接将来的RFID射频定位数据，自动化地精准软硬件资源的信息数据。

消除目前的信息资源数据难管理、难使用、准确性低的痛点。

实践方案：

（1）CMDB与Ansible环境搭建：

通过开源CMDBuild搭建CMDB配置管理系统，建立自上而下的数据表和表间关联关系，导入和梳理现有软硬件资源及配置数据；

Ansible环境搭建可参考笔者另一篇文章：

Ansible自动化运维体系在生产环境下实践（11步极快速搭建）

（2）CPU和内存大小自动获取：

通过Ansiblesetup模块获取各主机facts数据，通过Filter过滤出CPU颗数和内存总大小；

编辑Ansible-cmdb的TPL模板，利用Ansible-cmdb模块输出主机IP、CPU颗数与内存大小列表，并对该列表的格式进行加工、转换成适合进一步加工成SQL语句的csv格式文件，最终运行SQL语句更新CPU和内存数据至对应的CMDB表中。

方案逻辑流程如下图所示：

（3）硬盘容量、操作系统版本自动获取：

通过Ansiblesetup模块获取各主机facts数据，通过Filter过滤出各硬盘容量大小和操作系统类型。

编辑Ansible-cmdb的TPL模板，通过对操作系统类型进行判断（AIX或者Linux）,当为AIX操作系统时，调用AnsibleScript模块，将脚本注入各主机执行，获取所有VG的总大小，或者通过调用AnsibleCommand模块获取AIX操作系统详细版本，其后再通过计算并按照模板格式输出；

当为Linux操作系统时，直接釆用setup过滤后的值。

这些指标最终统一通过Ansible-cmdb模块输出为主机IP、硬盘总容量、操作系统版本列表，并对该列表的格式进行加工、转换成适合进一步加工成SQL语句的csv格式文件，最终运行SQL语句更新硬盘容量、操作系统版本数据至对应的CMDB表中。

方案逻辑流程如下图所示：

（4）软件组合和版本自动获取：

调用AnsibleScript模块，将脚本注入各主机执行，获取该主机上安装的标准软件和对应版本等数据；

编辑Ansible-cmdb的TPL模板，按照模板格式输出软