首页 > 知识库 > 正文

韩晓光高效运维评论：0 点击：

本文主要介绍我们的运维自动化系统如何设计与实现的，在介绍运维自动化时，首先需要先探讨一下运维标准规范化与自动化关系，因为这是大多数运维自动化的必经之路，也是很多运维体系成长的必经之路。

一、运维标准化、规范化、流程化

要做运维自动化，首先要落实运维体系的标准化、规范化、流程化。否则，如果不规范标准化，很难具体实施运维自动化。

在开发运维自动化系统过程与执行中，会有很多事情无法开展，或很难执行下去。

1.1 对于运维自动化与标准规范化的认识

对于运维自动化、标准规范化的认识与理解。

不同企业圈子，每个人的理解总会有差异性，但总体方向应该是一致的：我们需要运维自动化、标准化，因为它能促使我们的工作更加高效、智能、有规则，有预见性……对于运维自动化，标准规范化的认识，这里举例说明两种极端类型。

极端类型一：极端排斥流程标准及自动化，认为这是噱头，不干实事，不出成果。

这种类型的人做事貌似风风火火，思考规划10分钟，边想边干1整天，结果到了明天再重来——典型地边计划边实施边填坑，结果是又忙又乱又出错。

其实这种类型的问题就出在：事前没有规划好，事中没有实施好，事后没有总结好，无规矩不成方圆。

针对该类型，我们的观点是：标准规范与自动化是当前主流运维成熟进阶的必经之路。

流程标准很重要，必须要执行与持续完善，这是运维自动化以及公司运营一切的基础。

看过复杂的航空线路图，航海线路图，铁路交通图吧！是不是会感叹标准化与自动化的重要性。

运维工作也是一样的道理，例如在实际项目过程中，你要上新业务买设备，则需要提出技术需求，找财务、上级会签审批，然后还得招投标(内部邀标)，签合同，收到货得付款，设备入库备案，初始化设备，自动化部署系统，自动化部署应用，自动采集信息与告警……等等，正是这些规范流程，运维自动化才使我们的运维工作高效能、高质量、低风险。

极端类型二：极端追求标准流程。例如还是上述购新业务及采购设备流程。该类型的人做事非常规范细致：

while (true): {

调研;

开会;

统计需求;

提交审批;}

如此一遍又一遍的死循环，必须做到极致。如此结果是今年的需求，明年服务器才到货，后年业务才上线，为了部署一次性就全面全部OK，就费尽穷举一切可能，但凡有例外，就认为不是自动化，标准化。

这样做貌似流程规范做到了天衣无缝，但其结果往往是人算不如天算，因为时间事情随时在变，最后在实际生产中还是会有意外尴尬事情发生……

针对该类型，我们的观点是：流程规范是最佳实践方法论，但不是目的。

从哲学角度，这个世界不完美，因此2/8原则与持续性改进应该是思考与解决事情的一种最佳实践。流程标准固然很重要，但是流程标准目的是为了很好地执行并解决事情，而不是要卡死、堵死一系列意外。

我们没必要纠结于高大全的标准与自动化，我们需要从运维需求出发，痛点出发，持续改进与解决运维实际问题。

例如，在做自动化部署过程，总会有一些例外的情况。例如批量部署salt minion，由于系统版本，安装批次不一样。导致有些salt安装因没有依赖包而部署失败。

这就要考虑，自动部署环节是要考虑增加更多状态部署细节，还是保留一个精简的状态部署方案。

或许对于一个例外问题，例外分析与解决，而不是为了这一个例外而变动所有的全体。记住，不要认为搞个运维自动化系统，部署一个saltstack，puppet工具就能解决所有运维问题。

1.2 运维自动化与标准规范化的关系

任何一个企业运行都有很多配套的公司流程标准，否则很多事情将一团乱麻，根本无法推行，运维自动化也不例外，实施自动化前提需要标准规范与流程化。

比如，如果系统版本，主机名，IP不统一规范，则可能会导致saltstack部署执行，zabbix自动化发现，日志监控部署，应用部署等一系列问题。

没有良好的标准与自动化解决方案，运维人员常会背黑锅

运维自动化需要规范标准化，当然运维自动化又促进规范标准化。运维自动化，标准化需要落实，不能空谈，不能只说不练，有“法“不依。

标准要深入人心，融入日常行为思想中，达到个人与集体的潜移默化间的一致性、共通性。例如，我们总会碰到一些不规范的程序员，随意往线上部署了一段代码，搞得系统缓慢，最后由运维人员背黑锅。

标准与自动化往往是由业务、IT环境需求驱动的

诸如上述，运维自动化与标准化往往是由业务，IT环境驱动的，逐步优化完善出来的，或者是被动逼出来的。比如，由于业务增长迅速，系统(应用)环境需求天天都有很多。

那你还是手工一台台系统(应用)部署么，或许就算键盘敲到手抽筋仍然没完成业务需求，这时突然你又发现部署的代码不一致…..此时估计整个人都快要”疯掉了”，或许此时你对运维自动化，标准规范化的理解与需求会透彻骨子里。

标准与自动化需要持续性改进优化

运维自动化不是一蹴而就，而是逐渐持续性优化改进(ITIL理念)和实施的。

没有任何一个企业创立之初，其IT架构就非常高大上，上来就构建全球机房，初始就设计一个超级高性能，高安全的系统，立刻满足上亿的UV请求……这些或许没必要，也几乎不可能。

二、运维自动化系统设计

如下以一个实际的运维自动化系统为例，介绍一些该系统平台的设计与实现的内容。

2.1 运维自动化需求

随着业务规模逐渐增大，IT运维环境会越来越庞大复杂，这些将驱使运维工作需要科学规范化的管理。

这要求我们用较少的人力、物力资源做更多的工作，必须高效、准确执行任务。

当前市场上已经有很多成熟的(商业、开源)运维产品工具，各有特色也各有利弊，这也同时造成一个尴尬局面：运维人员要不断学习和管理很多运维产品工具，但却很难找出一个可以很好适应本企业(持续不断)定制化需要的产品工具。

因此，很多有实力的企业都会选择自主运维及开发。

从运维大环境来看，IT运维综合管理已成为主流运维管理发展方向，运维+开发成为运维发展的大趋势。

我们不再单纯、局限地依靠某个网管监控产品，而是需要运维自动化，提供体系化运维解决方案，包括系统网络管理、CMDB资产信息管理、知识库管理、乃至ITSM信息服务流程管理等。

2.2 系统概要设计介绍

如图2-1所示，本运维自动化综合管理平台的设计理念是：尽量融合、统一管理现有的各个运维工具平台，统一监控管理系统资源，有效关联整合数据信息。自主开发(同时基于现有运维管理工具二次开发)出适合自身需要的综合运维管理平台。

本解决方案立足从三大维度构建，分别是IT运维流程、IT监控平台整合、IT运维自动化。这三大维度主要具有如下几大功能模块。

◆IT运维流程：资产管理、知识库管理、安全管理、事件管理、日常事项管理。

◆IT监控平台整合：监控报警管理、日志管理、性能管理、报表管理。

◆IT运维自动化：应用管理、配置管理、程序运行管理。

2-1 系统逻辑架构设计

本解决方案使用的开发语言及工具：

◆后端及系统客户端开发主要通过Python、Shell等程序语言实现。

◆信息采集写入MySQL数据库。

◆前端WEB展示以及与后台数据层、应用层的逻辑交互通过Django框架实现。

◆界面修饰美化使用Bootstrap等框架工具。

2.3 程序功能框图设计

根据我们的需求，程序功能框图设计如下图所示。

2-2 程序功能框图

　　2.4 数据库模型设计

数据库模型(部分)设计如图2-3所示。

图2-3

2.5 工单流程设计

基于ITIL理念的事件工单流程如图2-4所示。

图2-4

2.6 系统架构示意图

基于我们的运维现状及需求等内容，我们的系统架构设计如下图2-5所示。

图2-5

三、运维自动化系统平台实例介绍

如图3-1所示是系统一级菜单与二级菜单，对应了上述设计的各主要模块。

图3-1

如图3-2所示在全局查询里，可以输入任意要查询的关键字。该模块主要是基于数据库表的查询，而不是对于日志的查询。该模块会基于关键字，模糊遍历所有的关键库表，然后将查询结果自动组织后再反馈到Web展示。

图3-2

如下图3-3所示是系统性能信息图表。该模块主要使用echarts前端绘图工具，后端逻辑处理使用了django restframework框架模块进行信息序列化。性能数据来自系统客户端采集入库信息。

图3-3

如图3-4所示是资产管理模块中的硬件配置模块。主要是资产的增删改查功能。对于大量资产信息的录入是通过后台管理中的信息导入模块(将固定格式的Excel资产信息表)批量录入到系统中。该模块主要通过Django CBV方式快速实现。

图3-4

如图3-5所示是基于Wordpress定制的系统以作为知识库系统。用于日常信息、知识资料的发布与共享。

图3-5

如图3-6所示是事件信息模块。本模块基于ITIL流程理念。系统平台一些重要的事件信息会自动触发事件流程，并需要人为交互去响应处理不同类型级别的事件。对于不同类型的事件，在处理时，所触发的流程也有所不同。

图3-6

如图3-7所示是集成融合了现有基调网络监控产品。通过该运维自动化管理平台，实现了对现有各种分散的工具软件的统一整合集成。

图3-7

如图3-8所示是基于ELK深度定制的日志监控模块。基于各类日志信息进行监控与统计。

图3-8

如图3-9所示是日志安全与审计。主要是针对服务器系统、网络设备等安全日志进行监控与审计。系统日志的采集使用了rsyslog和logstash shipper客户端两种方式采集发送信息。对于audit审计日志，则首先在被管节点上配置审计策略，然后由logstash shipper进行日志采集与发送。

图3-9

如图3-10所示是基于Cacti深度定制的网络流量监控。主要是动态实时地监控各个主要节点的网络流量。

图3-10

如图3-11所示是网址链接状态监测模块。可自动或手动监控一些(自定义的)重要网址连接状态。

图3-11

如3-12所示是系统服务状态监控信息。由client客户端抓取系统服务状态信息，然后反馈给服务器端进行统计与展示。在各种监控配置方面，一方面采取服务器端主动抓取监控信息(如上述的网址监控)，另一方面，由客户端程序主动抓取当前系统的监控信息(如系统账号、文件系统、配置、服务等)，并通过C/S架构发(数据以json格式为主)给服务器端接收。