企业级自动化运维方案设计及Saltstack、Ansible等5种工具比较分析--云平台技术栈08

企业级自动化运维方案设计及Saltstack、Ansible等5种工具比较分析--云平台技术栈08

1.企业运维现状与发展趋势

随着企业信息化的不断发展，运维人员需要面对越来越复杂的业务和越来越多样化的用户需求，不断扩展的应用需要越来越合理的模式来保障运维服务能灵活便捷、安全稳定地持续。某企业从初期的几台服务器发展到庞大的数据中心，单靠人工已经无法满足在技术、业务、管理等方面的要求，那么标准化、自动化、架构优化、过程优化等降低运维服务成本的因素越来越被人们所重视。其中，自动化开始代替人工操作在企业的运维过程中逐渐体现出来了强大的优势。

运维随着企业业务的发展，自动化作为其重要属性之一已经不仅仅只是代替人工操作，更重要的是深层探知和全局分析，关注的是在当前条件下如何实现性能与服务最优化，同时保障投资收益最大化。通过自动化运维能最大限度地在更少的维修时间内实现运维目标，提高运维服务质量。因此, 对于越来越复杂的运维来说，将人工操作逐渐改变为自动化管理是一个重要发展趋势。

2.企业运维存在的问题与需求

某企业初期只有文件共享和邮件服务等几台服务器，运维工作完全由人工操作，随着企业的发展，新业务系统不断上线企业建设了中心机房，运维工作还是以人工为主，但是这一阶段增加了网络管理系统和环境监控系统，这两个系统在一定程度上减轻了运维的工作量，基本上实现了运维的半自动化。企业在发展，运维工作量在不断的增加，企业的运维工作面临以下的问题及需要解决：

2.1运维人员的工作效率与工作主动性需要提升

在企业运维过程中，只有当故障已经发生并且造成业务影响时才能发现和着手处理，这种被动“救火”不但使运维人员终日忙碌，也使运维本身质量很难提高，导致IT部门和业务部门对运维服务满意度都不高。运维人员日常大部分时间和精力是处理一些简单重复的问题，而且由于故障预警机制不完善，往往是故障发生后或报警后才会进行处理，使得运维人员的工作经常是处于被动的状态，怎样才能在故障发生前及时发现并把故障处理掉，使运维工作变被动为主动？

2.2需要建立一套高效的运维机制

企业在运维管理过程中缺少自动化的运维管理模式，没有明确的运维人员角色定义和责任划分，使到问题出现后很难快速、准确地找到根本原因，无法及时地找到相应的人员进行修复和处理，或者是在问题找到后缺乏流程化的故障处理机制，而在处理问题时不但欠缺规范化的解决方案，也缺乏全面的跟踪记录，企业需要建立一套高效的运维管理制度为运维工作提供方向和依据。

2.3缺乏高效的运维技术工具

随着信息化建设的深入，企业业务系统日趋复杂，各种各样的网络设备、服务器、存储设备、业务系统等让运维人员难以从容应对，即使加班加点地维护、部署、管理也经常会因设备出现故障而导致业务的中断，严重影响企业的正常运转。出现这些问题部分原因是企业缺乏事件监控和诊断工具等运维技术工具，因为在没有高效的技术工具的支持下故障事件很难得到主动、快速处理。

3.业务流程标准化与健全运维管理制度

3.1实现业务流程标准化，为自动化运维打好基础

标准化是自动化运维的基础，想要实现标准化，首先识别各个运维对象，然后我们日常做的所有运维工作都应该是针对这些对象的运维。如果运维操作脱离了对象，那就没有任何意义。同样，没有理清楚对象，运维自然不得章法。例如扩容，首先确定是服务器的扩容，还是应用的扩容，还是其它对象的扩容。你会发现，对象不同，扩容这个场景所实施的动作是完全不一样的。如果把服务器的扩容套用到应用的扩容上去，必然会导致流程错乱。同时对于对象理解上的不一致，也会增加无谓的沟通成本，造成运维效率低下。这种情况下的自动化运维不但不能提升效率，还会越自动越混乱。

实现标准化的第一步是物理基础设施的标准化，例如，识别物理对像服务器、交换机、机柜等硬件；识别这些物理对像的属性，服务器的序列号、ip地址、厂商等信息；识别这些对像之间的关系，服务器所在的机柜、接入哪个交换机的哪个接口了等信息。服务器物理基础设施的标准化如下图（其它设备的标准化以此类推）：

第二步是应用的标准化，应用服务、中间件，数据库等；例如，数据库的表、视图、存储过程的标准化，表的字段名、值，索引等，表和视图之间的关联关系等。

第三步是流程标准化，如备份、软件升级、杀毒，新业务上线等流程的标准化，下图是现在的运维流程：

自动化运维是基于流程化的框架，将事件与IT流程相关联，一旦被监控系统发现性能超标，超过预先配置的阀值或宕机，就会触发相关事件以及事先定义好的流程，可自动启动故障响应和恢复机制。自动化工作平台还可帮助运维人员完成日常的重复性工作，提高运维效率，下图是实现自动化运维的流程图：

运维的自动化能够预测故障、在故障发生前能够报警，让运维人员把故障消除在发生前，将所产生损失减到最低。由过去的手工执行转为自动化操作，从而减少乃至消除运维中的延迟，实现“零延时”的运维。

3.2建立完整、全面的运维管理制度，为自动化运维的实现保驾护航

运维制度的建立包括环境管理、资产管理、介质管理、设备管理、监控管理、网络安全管理、系统安全管理、恶意代码防范管理、密码管理、变更管理、备份与恢复管理、安全事件处置，应急预案管理等制度。

1)运维管理制度是衡量运维工作的一把尺子，完善的管理制度能有效的提升运维工作效率，日常工作以管理制度为依据，按规定的要求和规定的流程操作既快速又准确；

2)全面的运维管理制度能在问题和故障还没有出现没有造成损失前就被及时的发现，从而问题得到有效的处理，业务连续性得到了保障；

3)运维管理制度为运维工作提供了规范化的解决方案，使运维人员在处理问题时有章可循快速找到问题的根本原因，把问题对业务造成的损失降到最低；

4)运维管理制度是为业务服务的，业务是不断发展的，运维管理制度要跟得上业务的不断发展实现管理制度的创新。

4.自动化运维技术路线选型

4.1自动化运维概述

自动化运维范围包括安装自动化、部署自动化、监控自动化、发布自动化、升级自动化、安全管控自动化、优化自动化、数据备份自动化等。

自动化运维系统包括商用自动化运维系统、开源自动化运维系统，自建（研发）自动化运维系统。

商业的运维系统在功能上要全面一些，服务支持上能好一些，更新与升级有保障，采购成本较高，对运维人员的技术要求相对较低。开源运维系统更灵活一些，服务支持需要运维人员自身多投入一些时间和精力，更新与升级更个性化一些，相对成本较低。自建自动化运维系统对人员的技术要求最高，成本也不低，但是当企业发展到一定规模后自建的运维系统才能更适合企业对于自动化运维的要求。

4.2开源运维工具的应用场景与优势

1)Puppet是一个开源的软件自动化配置和部署工具，它使用简单且功能强大，很多大型IT公司均在使用puppet对集群中的软件进行管理和部署。

优缺点分析：优点是Web界面生成处理报表、资源清单、实时节点管理，push命令可即刻触发变更，缺点是相对其他工具较复杂、需学习Puppet的DSL或Ruby，安装过程缺少错误校验和生成错误报表。

2)SaltStack是一种全新的基础设施管理方式，部署轻松，在几分钟内可以运行起来，扩展性好，很容易管理上万台服务器，速度够快，服务器之间秒级通讯。

优缺点分析：优点是可以使用简单的配置模块或复杂的脚本，Web界面可以看到运行和监控的工作状态、事件日志，扩展能力极强，缺点是缺少生成深度报告的能力。

3)Ansible是新出现的运维工具是基于Python研发的综合了众多老牌运维工具的优点实现了批量操作系统配置、批量程序的部署、批量运行命令等功能。在进行大规模部署时，手工配置服务器环境是不现实的，这时必须借助于自动化部署工具。

优缺点分析：优点是模块可以用任何语言开发、备管节点不需要安装代理软件、有Web管理界面、安装运行简单，缺点是对windows备管节点需要加强、执行效率相对较低。

下图是Puppet、Saltstack、Ansible这三款运维工具处理能力与处理效率的对比：

各种运维工具只是用于帮助人员进行运维的，每种工具都有其使用的优势领域，Puppet适用于软件自动化配置和部署；SaltStack适用于基础设施管理，在几分钟内可运行起来，很容易管理上万台服务器，速度够快；Ansible适用于批量操作系统配置、批量程序的部署、批量运行命令等。

下面是两个常用的开源监控系统：

1）Nagios是一款免费的开源IT基础设施监控系统，其功能强大，灵活性强，能有效监控 Windows 、Linux、VMware 和 Unix 主机状态，交换机、路由器等网络设备的网络设置等。一旦主机或服务状态出现异常时，会发出邮件或短信报警第一时间通知 IT 运维人员，在状态恢复后发出正常的邮件或短信通知。

优缺点分析：优点是配置灵活、监控项目很多、自动日志滚动、支持冗余方式主机监控、报警设置多样性。缺点是事件控制台功能较弱、无法查看历史数据、插件易用性不好。

2）Zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。用于监控网络上的服务器或服务以及其他网络设备状态的网络管理系统，后台基于C，前台由PHP编写，可与多种数据库搭配使用，提供各种实时报警机制。

优缺点分析：优点是企业级开源、功能强大、入门容易、数据可以图形的方式呈现、提供多种API接口，可定制化开发。缺点是深层次需求开发难度较大、报警设置复杂、缺少数据汇总功能、数据报表需要二次开发。

Nagios适用于IT基础设施的监控系统，其功能强大，灵活性强，能有效监控各种操作系统的主机、交换路由设备等；Zabbix提供分布式系统监视以及网络监视功能，用于监控网络上的服务器，服务以及其他网络设备状态的网络管理系统。

以上这五种工具都是开源的，运维人员可以根据企业的规模、业务需要、所要实现的运维功能等要求使用多种工具组合，发挥运维与监控工具各自的优势，工具的使用需要人工的干预和决策，工具不能完全代替全部运维工作。还需要结合实际业务逻辑和业务场景，把工具与业务融合到一起，例如，按业务要求对工具进行二次开发，更好的发挥运维与监控工具的优势，提升运维人员工作效率。

4.3 Saltstack实现服务器部署的自动化

Saltstack在企业中实现服务器部署的自动化运维，saltstack是基于python开发的一套C/S架构配置管理工具，它的底层使用zeroMQ消息队列pub/sub方式通信，使用SSL证书签发的方式进行认证管理。

salt我们选择了0.16.0版，该版中加入了multi-masterr 特性，在这种架构下所有的minion将连接到所有配置的master上去。当一个master出现故障可以使用其余的master继续提供服务，不会影响我们的正常使用，saltstack架构如下图：

Saltstack在企业中的部署步骤：

1、确定saltstack软件依赖关系是否满足要求：saltstack要求python的版本大于2.6或小于3.0，还需要检查以下的库，包括msgpack-python、yaml、jinja2、markupsafe、apache-libcloud、requests等。

3、创建一个master服务的备份节点并复制主master节点的key到备节点：

默认的master的private key是在目录：/etc/salt/pki/master. 将该目录下的master.pem拷贝到备master节点的同一位置，对master的public key文件master.pub做同样的操作，启用备master节点，在备节点接受key。

4、重启minions：配置完成后，minion将会对主master和备master进行核对，并且两个master都对minion有操作权限。

注：minion可以自动检测失败的master，并且尝试重连到一个更快的master，将minion端的参数master_alive_interval 设置为true，即可开启该功能。

5、saltstack状态文件的编写，saltstack上线后，运维工作从复杂的重复的服务器部署和配置工作转移到saltstack状态文件的编写和维护，状态文件的编写要考虑模块化和通用性，在大批量部署之前要经过测试，没有问题后再部署，以下是一些经常用到的测试命令：

（1）、查询网络连接情况--是否能连接到客户端

（2）、查询网卡ip

（3）、查询磁盘空间

还有很多经常用到的命令在此就不一一列举了，Saltstack可以实现云计算与数据中心架构编排，Saltstack可以由zabbix监控事件调用，通过Saltstack的salt-cloud实现对docker和openstack等云平台的支持，配合saltstack的mine实时发现功能就可以实现各种云平台业务自动扩展；Saltstack可以与CMDB相结合实现运维平台化、自动化和智能化。

5.自动化运维方案设计

5.1自动化运维规划图

提到自动化运维就不能不说ITIL，ITIL即信息技术基础架构库(Information Technology Infrastructure Library)，主要适用于IT服务管理（ITSM）。ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范。ITIL已经成为了IT服务管理的国际标准，而CMDB配置管理数据库（Configuration Management Database）则是实现ITIL最重要的内容。

随着企业的发展，对于运维要求越来越高，使用现有的开源工具已经不能满足企业对于运维的要求，根据企业业务的发展与对运维的要求建设统一的运维管理平台成为了企业迫切的需求。下面是企业自动化运维总体规划图：

自动化运维平台的建设以ITIL标准为依据，按照先底层后高层的原则先建设服务工具区域的各个运维子系统，各个运维子系统通过API的方式对上层提供服务，最后不同的业务平台去调用这些服务接口即可，运维平台的各个层面建设要全面符合管理制度的要求。

5.2自动化运维平台模块设计

自动化运维平台以ITIL标准为依据在此规范上开发的，第一阶段已经做到了业务流程的标准化，现阶段从事件管理子系统开始逐渐完善各个子系统，把各种配置当作服务来看待，CMDB也可以理解成统一的元数据库，比如说机房信息、服务器信息、人员信息、服务信息、业务信息以及他们之间的物理和业务拓扑关系等，上层的所有系统都应该关联到CMDB，以CMDB为中心，变更后的数据信息必须实时反馈到CMDB中，各个运维子系统才能看到最新的数据信息，确保其他系统能同步这份变更，以达到统一同步的目的。因此把CMDB系统当作运维的核心系统来对待，有利于后续各个系统之间的互通。以下是部分模块的设计要求：

事件管理：负责记录、归类和安排专家处理事故并监督整个处理过程直至事故得到解决和终止。事件管理的目的是在尽可能最小地影响客户和用户业务的情况下使IT系统恢复到SLA服务级别协议（Service-Level Agreement）所定义的服务级别；

问题与日志管理：通过调查和分析IT基础架构的薄弱环节、查明事故产生的原因，并制定解决事故的方案和防止事故再次发生的措施，将由于问题和事故对业务产生的负面影响减小到最低的服务管理流程。在问题管理这部分要做好问题处理过程的日志的功能，对于问题的处理提供查询的功能，可以追踪问题以防止类似问题再次发生。

变更管理：在最短的时间窗口内完成基础架构或服务的变更而对其进行控制的服务管理流程。变更管理的目标是确保在变更实施过程中使用标准的方法和步骤，尽快地实施变更，以将由变更所导致的业务中断对业务的影响减小到最低。

可行性管理：通过分析用户和业务系统的可行性需求并据以优化和设计IT基础架构的可行性，从而确保以合理的成本满足不断增长的可行性需求的管理流程。可行性管理是一个前瞻性的管理流程，它通过对业务和用户可行性需求的定位，使得IT服务的设计建立在真实需求的基础上，从而避免IT服务运作中采用了过度的可行性级别，节约了IT服务的运作成本。

突发事件：分析业务系统的运行状况和已经发生过的问题日志，掌握系统常规问题发生的根源、对于突发事件做到规范化的处理流程。及时发现、及时解决，强化监控监管、技术、备件备品、应急措施、方案、策略等相结合的办法避免和及时的解决突发事件。

自动化运维平台是面向业务的调度平台，平台以业务为导向协调各个子系统，指挥底层各个子系为它服务。自动化运维平台的建设是一个循序渐进的过程，根据业务和运维的需要不断的测试和改进才能从根本上改变运维现状，提升运维工作效率，最终实现自动化运维。

6.企业自动化运维方案总结

企业的运维工作经历了从最开始的全部人工操作，到后来的大部分人工操作少部分自动化，到现在的自动化运维的过程。在没有建设运维平台之前，一个新业务上线，需要做很多操作，例如DNS变更、LVS变更、OS初始化、自动化测试、持续部署、持续反馈、监控、业务调用关系配置等等。现在新业务上线只需要简单的配置，剩余的工作由平台协调自动完成上线。使用自动化运维平台后用户满意度从33%上升到95%，同时期IT费用营收占比从4%下降到2.4%。

通过建设自动化运维平台实现了对业务流程的有效梳理，有效的了解现有的IT资源、运行状况、可靠性与可用性，使企业从全局掌握IT资源和资产的详细信息，为企业的决策提供了有力的支撑；

通过建设自动化运维平台提高了运维工作效率，以前有很多需要人工参与处理的故障和事件，现在绝大部分由运维平台自动按预定的规则进行处理，在运维响应时间上有了很大的提升；

通过建设自动化运维平台发现潜在的问题，降低了故障率，运维人员再也不是以前的“救火”队员了，一些潜在的问题在萌芽阶段就被发现和处理了，避免了故障造成的业务中断；

通过建设自动化运维平台有利于故障的快速恢复，通过对以往时间点配置的保存建立配置基准快照，然后根据出现故障前后的配置基准的比对快速的发现故障的线索和根源，及时找到故障处理办法恢复系统运行。

聂奎甲：十余年工作经验，主要参与政府、电力、国土等行业的系统集成项目，包括主机存储、oracle数据库，精通计算机网络与安全。

长按订阅更多精彩↓