目录**

一、运维的发展趋势以及为什么需要自动化运维工具 2

二、现阶段的运维有哪些痛点 2

三、自动化运维工具的选型 3

四、SaltStack的部署与安全机制 7

五、部署SaltStack过程的一些注意事项 12

六、自动化运维平台规划与设计 15

七、自动化运维平台模块设计 17

八、故障诊断部分 19

九、总结 23

一、运维的发展趋势以及为什么需要自动化运维工具**

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

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

二、现阶段的运维有哪些痛点**

1、 业务推广服务器系统的重复安装部署，频繁的手工配置等操作，每一次新业务上线和原有业务系统的扩容，服务器系统需要重新安装部署，各种参数、环境变量等都需要手动配置。

2、 部分运维人员不遵守流程，没有严格按照部署流程操作，导致出现部署故障。在部署的过程中把关键的环节给落下了或是部署流程未按顺序操作都会导致部署故障，而且有些故障的排查相对隐蔽，无形中增加了企业的运维成本，降低了运维效率。

3、 急需完善的各种操作流程：自动化运维需要各种流程文档作为底层支撑，包括部署流程、故障处理流程、数据库备份与恢复流程、交换机和服务器上下架流程等。

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

三、自动化运维工具的选型**

日常运维工作很大一部分是涉及业务的配置管理和状态维护，目前，基于状态（系统状态、代码状态、配置状态和进程状态）的配置管理已经得到极大发展，并且让运维有了很大的进步；出现了各种工具和平台，从最早的UNIX 管理工具CFEngine到后来的Puppet、Chef,以及最近的SaltStack、Ansible，每一种工具的出现都是为了满足新的场景以及解决之前解决不了的问题。新工具的出现层出不穷，令人眼花缭乱，在实际应用中，这些工具之间到底是替换还是结合，在每个特定的场景以及选型的理解上也会有所不同，最终可能以完全不同的形态进行展示。下面是几种常用运维工作的对比：

1、 Puppet是一个开源的软件自动化配置和部署工具，它使用简单且功能强大，很多大型IT公司均在使用puppet对集群中的软件进行管理和部署。优缺点分析：优点是Web界面生成处理报表、资源清单、实时节点管理，push命令可即刻触发变更，缺点是 相对其他工具较复杂 、 需学习Puppet的DSL或Ruby ， 安装过程缺少错误校验和 生成 错误报表 。

2、SaltStack是一种全新的基础设施管理方式，部署轻松，在几分钟内可以运行起来，扩展性好， 很容易管理上万台服务器，速度够快 ，服务器之间秒级通讯。优缺点分析：优点是可以使用简单的配置模块或复杂的脚本 ； Web界面可以看到运行和监控的工作状态、事件日志，扩展能力极强 ； 通过执行代理（Minion）来实现高效和可扩展的配置管理体系 ，从而无需保存账户密码等敏感信息，避免信息泄露，也便于管理员定期更换密码；可采集更丰富的配置信息和关联关系；可快速感知配置变化；可以实现快速的文件传输，方便实现配置文件的收集。 缺点是缺少生成深度报告的能力。

3、Ansible是新出现的运维工具是基于Python研发的综合了众多老牌运维工具的优点实现了批量操作系统配置、批量程序的部署、批量运行命令等功能。在进行大规模部署时，手工配置服务器环境是不现实的，这时必须借助于自动化部署工具。优缺点分析：优点是模块可以用任何语言开发、备管节点不需要安装代理软件、有Web管理界面、安装运行简单，缺点是对windows备管节点需要加强、执行效率相对较低。

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

各种运维工具只是用于帮助人员进行运维的，每种工具都有其使用的优势领域，Puppet适用于软件自动化配置和部署；SaltStack适用于基础设施管理，在几分钟内可运行起来，很容易管理上万台服务器，速度够快；Ansible适用于批量操作系统配置、批量程序的部署、批量运行命令等；运维人员不想维护过多的平台，我们都希望学习过程尽可能简单，使用的工具强大，二次开发的成本也低，从这几方面讲SaltStack是一个很好的选择。

四、SaltStack的部署与安全机制**

Saltstack在企业中实现服务器部署的自动化运维，saltstack是基于python开发的一套C/S架构配置管理工具，它的底层使用ZeroMQ消息队列pub/sub方式通信，使用SSL证书签发的方式进行认证管理。 它 是一款强大的、集中化的配置自动化管理工具，它可以通过grains、pillar实现上千台服务器的配置自动收集和管理， 使 用SaltStack的框架和扩展能力来实现配置自动化采集，采集到数据后可以输送到配置管理库或者集中管理。整个采集框架逻辑设计如下图所示：

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

Saltstack在企业中的部署步骤：

SaltStack从部署上包含Master和Minion两大部分。一个网络域内需要部署一个Master实现集中发现调度和管理 ， Minion安装在各个被管主机上负责接收和执行脚本，并将采集 的 结果反馈给Master。

1、确定saltstack软件依赖关系是否满足要求： saltstack要求python的版本是3.5.2版，还需要检查以下的库，包括PyYAML软件包、ZeroMQ、Pyzm、PyCryto、M2Cryto、msgpack-python、yaml、jinja2、markupsafe、apache-libcloud、requests等。

2、安装master和minions： 我这里服务器的操作系统是 centos 6.7 的，安装命令如下：

Wget http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

yum install salt-master

yum install salt-minion

注：安装成功，显示Complete。

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

M aster:

-saltmaster1. cccxht .com

• saltmaster 2 . cccxht .com

默认的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）、 查 询 网络连接情况 --是 否 能 连接 到 客户端

[root@centos salt]# salt '*' test.ping

localhost:

True

server. cccxht .com:

True

（2）、 查 询 网卡ip

[root@centos /]# salt 'localhost' network.interfaces

localhost:

eth0:

hwaddr:

08:00:27:59: a9 : 8d

inet:

• address:

192.168. 1 5 1 . 2 02

• broadcast:

192.168. 1 5 1 .255

• label:

eth0

• netmask:

255.255.255.0

（3）、 查 询 磁盘空间

[root@centos tmp]# salt 'localhost' disk.usage

localhost:

/:

1K-blocks: 28423 128

available: 21572 236

capacity: 25 %

filesystem: /dev/mapper/vg_centos-lv_root

used:5406 132

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

五、部署SaltStack过程的一些注意事项**

Salt master监听 ： 默认Salt master监听所有网卡接口(0.0.0.0)的4505和4506端口. 如果需要指定监听IP, 通过 /etc/salt/master 配置文件中的"interface"指令进行如下修改:

• interface: 0.0.0.0

• interface: 10.0.0.1

更新完配置文件后，需要重启Salt master以使其生效配置

Salt MinionDNS解析： 尽管Salt Minion有许多配置选项，但配置Minion还是非常简单的. 默认的配置Minion会尝试连接DNS名为"salt"的master，如果minion解析到的地址正确，就无需再做配置.

如果DNS名为"salt"并不能解析到本地正确的Master地址，需要通过如下方法修改/etc/salt/minion 配置文件中的"master"指令:

• master: salt

• master: 10.0.0.1

更新完配置后，需要重启Salt minion以使配置生效.

KEY的管理： Salt在Master和Minion之间的通讯采用AES加密. 这就确保了发送给minions的命令不会被篡改， Master和Minion之间的通讯认证通过信任的已接受的key进行管理.

在发送给Minion之前，需要确保minion的key已经被Master所接受. 运行salt-key命令将列出Salt Master已知的所有keys.

[root@master ~]# salt-key -L

Unaccepted Keys:

A 1

B 2

C 3

D 4

Accepted Keys:

下边的例子中，Salt已知有四个Minions，但是没有接受一个

minion的key。 接受key以使Mionions可以被Master管控，需要使用salt-key命令:

[root@master ~]# salt-key -A

[root@master ~]# salt-key -L

Unaccepted Keys:

Accepted Keys:

A 1

B 2

C 3

D 4

salt-key命令能够进行单个操作，也可以进行批量操作. 例子中使用-A进行批量接受所有待定的keys. 接受单个key使用小写字母a，-a keyname.

Master和Minion连通性测试可以通过运行test.ping命令:

[root@master ~]# salt A1 test.ping

A1 :

True

Master与所有Minons的连通性测试可以使用下边类似的方法:

[root@master ~]# salt '*' test.ping

A 1 :

True

B 2 :

True

C 3 :

True

D 4 :

True

每个Minions应该发送一个 True 回应并显示出来.

关于升级Salt： master s 应该首先升级 ， masters向后兼容，

minions运行版本比masters版本新是不能保证运行正常的。只要可能，新masters向后兼容旧minions的特性就会被保留下来。一般来说，唯一例外的情况是有安全漏洞的情况下。

防火墙需要开放哪些端口： Minions需要通过TCP端口4505和4506与Master进行通讯。此外，Minions并不需要开放额外的端口来接受数据。

通过SALT管理软件包和服务出现THE STATE IS NOT AVAILABLE 的错误提示： Salt会自动检测Minion的操作系统并安装正确的软件包或服务管理模块。但是，对于一些社区的custom spins OS和衍生操作系统，这些检测很容易失败。在这种情况下， 需要向tracker提交issue， 其中包含以下信息：

salt grains.items | grep os ， 如果在Minion上存在文件/etc/lsb-release ， 提供 这个文件的内容 即可 。

六、自动化运维平台规划与设计**

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

自动化运维平台建设原则:**

1、 平台要做成统一通道，通过运维和脚本去屏蔽业务和场景的差异性，平台只做执行引擎的角色，这样才能避免大量重复性的开发工作。

2、 求同存异，例如对某台或一些设备进行统一的技术操作，这些业务形态基本上是一样的，平台要抓取业务形态的共同点，把差异化的东西交给用户自定义处理。

3、 平台不是独立存在的，需要具备与其它平台互连、调用或是集成的通用接口。

4、 平台具有易操作性和易维护性，将操作一批设备变得和操作一台设备一样快捷简单，将维护多个业务变得和维护一个业务一样方便。

随着企业的发展，对于运维要求越来越高，根据企业业务的发展与对运维的要求建设统一的运维管理平台成为了企业迫切的需求。下面是企业自动化运维平台总体规划图：

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

七、自动化运维平台模块设计**

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

因此把CMDB系统当作运维的核心系统来对待， 有利于 后续各个系统之间的互通。 以下是部分模块的设计要求：

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

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

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

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

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

CMDB 作为运维标准化、自动化、平台化的基础输入。解决 IT基础架构信息化以及业务配置信息线上化， 业务 系统主要功能模块如下图:

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

八、故障诊断部分**

1、 问题描述：安装sale master过程中报错，

错误代码：ERROR: Command errored out with exit status 1:

UnicodeDecodeError: 'gbk' codec can't decode byte 0xa6 in position 1246: illegal multibyte sequence

ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

处理方法：下载源码的包，进行代码改动之后install。

(1) 、找到原始package的文件，找到报错的那一行。

REPL的官方地址是：https://github.com/mbr/repl。查看报错的setup文件的源码。

定位问题：源码中没有指定open时的编码方式，使得默认为gbk编码。

报错的源码：

def read(fname):

return open(os.path.join(os.path.dirname(__file__), fname)).read()

(2) 、下载原始包文件后，解压找到setup.py文件，修改文件里的这一行，即加上encoding='utf-8'，保存后打包为新的安装包。

修改后的代码：

def read(fname):

return open(os.path.join(os.path.dirname(__file__), fname),encoding='utf-8').read()

(3) 、输入pip install repl-1.0.tar.gz，用新的安装包来进行install，完成后功能解决问题。

2、关于salt-minion dead but pid file exists 的解决方法，安装salt-minion后客户端却无法正常启动，如下报错：

[root@namenode ~]# /etc/init.d/salt-minion status

salt-minion dead but pid file exists

解决过程：

由报错知：minion进程已经死，但是进程文件还在 ， 于是去找进程文件，在minion机的配置文件里/etc/init.d/salt-minion里发现进程文件是：/var/run/salt-minion.pid然后尝试把进程文件删掉，再重新启动：

[root@namenode ~]# /etc/init.d/salt-minion restart

Stopping salt-minion daemon: [FAILED]

Starting salt-minion daemon: [ OK ]

[root@namenode ~]# /etc/init.d/salt-minion status

salt-minion dead but pid file exists

仍然没有解决问题 ， 不要着急，debug一下：

[root@namenode ~]salt-minion -l debug

[INFO ] Setting up the Salt Minion "namenode"

[DEBUG ] Created pidfile: /var/run/salt-minion.pid

[DEBUG ] Reading configuration from /etc/salt/minion

[DEBUG ] Attempting to authenticate with the Salt Master at 192.168.1.53

[DEBUG ] Initializing new SAuth for ('/etc/salt/pki/minion', 'namenode', 'tcp://192.168.1 12 .53:4506')

[ERROR ] The master key has changed, the salt master could have been subverted, verify salt master's public key

[CRITICAL] The Salt Master server's public key did not authenticate!

The master may need to be updated if it is a version of Salt lower than 2015.5.5, or

If you are confident that you are connecting to a valid Salt Master, then remove the master public key and restart the Salt Minion.The master public key can be found at:

/etc/salt/pki/minion/minion_master.pub

查看salt-minion日志 ：

[root@namenode ~]less /var/log/salt/minion

也发现同样的错误：

The Salt Master server's public key did not authenticate!

10647 The master may need to be updated if it is a version of Salt lower than 2015.5.5, or

10648 If you are confident that you are connecting to a valid Salt Master, then remove the master public key and restart the Salt Minion.

10649 The master public key can be found at:

10650 /etc/salt/pki/minion/minion_master.pub

解决方法：

直接在客户端上 执行

[root@namenode ~]# rm -rf /etc/salt/pki/minion/minion_master.pub

[root@namenode ~]/etc/init.d/salt-minion restart

九、总结**

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

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

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

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

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