Linux 系统运维自动化概述
一、运维自动化背景
二、运维自动化发展阶段
三、运维自动化体系架构
四、运维自动化常用工具
五、运维自动化对运维人员要求
一、运维自动化背景
1.问题引入
近期一网站业务需要上线，预计短时间内会有几百台服务器要上线， 部署几百台服务器， 以运维部目前有限的人手， 根本不够。怎么办？解决方案：采取自动化安装、配置及监控的方案（运维自动化）。
2.官方解释
何谓运维自动化，即在最少的人工干预下，利用脚本与第三方工具，保证业务系统7*24小时高效稳定运行。
3.高端、大气、上档次
运维自动化是指搂着妹子、喝着Coffee、看着显示器、点点鼠标。(运维的终极目标啊，不解释，你懂得。哈哈^_^……)
二、运维自动化发展阶段
1.苦B阶段（纯手工）
依靠纯手工，重复的进行软件的部署与运维；
2.给力阶段（脚本+文档）
通过编写脚本，方便的进行软件的部署与运维；
硬件状态监控：通过编写脚本，对CPU、内存、磁盘、进程、网络等关键硬件参数状态进行实时监控，发现异常触发报警（发送短信或邮件）信息给管理员；
业务监控：通过编写脚本对常用业务的网站实时进行监控，发现网站页面异常触发报警信息给管理员；
系统安全加固：通过编写脚本对常用的Windows、Linux、Unix服务器进行快速的安全加固；
补丁更新：通过编写脚本实现应用及操作系统补丁的快速更新；
数据备份：通过编写脚本实现关键业务数据、关键日志、数据库、操作系统、中间件等的快速备份（本地与异地）；
过期日志清理：通过编写脚本实现过期日志清理；
……
3.高富帅阶段（自动化运维工具）
借助第三方工具，高效的进行软件的部署与运维；
我在选择对于百万量级、千万量级的网站尤其会考虑选择成熟的工具、性能高的工具、熟悉的工具、第三方工具。而对于小规模的网站，则会考虑选择一些开源的、免费的工具。这个原则就是以应用为导向，百万量级、千万量级的网站牵涉的面广、要求高，不成熟的工具往往很难说服我使用，所以主要是在成熟度方面。
4.阶段对比
各个阶段 运维规模(/台) 运维效率 技能要求
纯手工 小于50 低 一般
脚本与文档 50-100 一般 高
运维工具（第三方工具） 100-500 高 一般
脚本+运维工具 大于500 最高 高
三、运维自动化体系架构
1、运维工作
系统安装（物理机、虚拟机）--》程序安装、配置、服务启动--》批量操作--》程序发布
2、程序发布
不能影响用户体验
系统不能停机
不能导致系统故障或造成系统完全不可用
灰度发布模块：
通过调度器将线上的一批服务器(maintannance)标记为离线模式--》关闭相应的服务--》部署新版的应用程序至目标位置--》启动相关应用--》调度其上线
自动化灰度发布：脚本、发布平台、
基于主机：
基于用户：
一个完善的运维自动化体系包括系统预备、配置管理以及监控报警3个功能模块:
1. 系统预备
自动化安装操作系统及常用软件包
自动化安装与升级系统补丁
自动化升级相关软件
……
2. 配置管理
自动化部署业务系统软件包并完成配置
远程管理服务器（开关服务等 ）
变更回滚
……
3. 监控报警
服务器可用性、性能状态、安全监控
向管理员发送报警信息等
……
四、运维自动化常用工具
根据提供的功能不同，运维自动化工具也可以分为以下3类，如下表所示：
1. 预备类工具
预备类工具可以使 Linux 操作系统及软件安装自动化。它们借助服务器上的软件包系统比如 rpm 或者 apt 来安装软件包，甚至C会做一些粗略的配置工作。
常用的工具：
PXE，Cobbler
Cloud(云）:模版
2. 配置管理类工具
配置管理类工具可以自动化部署常用的应用程序，设置参数或者开启一个新服务器上的服务，也可以用来把对操作系统及业务支撑系统的变更管理回滚到上一版本。
常用工具：
Configuartion(配置）：
Chef、Cfengine 早期著名工具，日暮西山，慢慢落后了 （性能好）
Puppet（爬被特）:主流（google,facebook） ruby研发
saltstack（索拉丝呆克）：python（爬森）研发 新研发，坑很多 国内用的少，资料少，安装麻烦，做二次开发比较方便
Command and Control(批量运行命令）:
Fabric
Ansible：python研发，越来越流行 包括Fabric的功能和部分Puppet功能
3. 监控报警类工具
监控工具用来收集服务器数据，从而生成可用性、性能和其它系统状态的报告。可用性监控可以第一时间向运维人员发送业务不可用的警告，以便第一时间 处理，减少业务中断时间。
监控数据采集：
用户行为日志
服务器性能
运行数据报告
监控管理：
异常报警
失效转移
自动优雅降级
红帽资助的 Genome 项目是将预备类、配置管理类集成到一起的框架，如 下图所示：
4.常用自动化运维工具对比选型
(1).预备类工具
Kickstart 供 Anaconda 读取的无人值守安装配置脚本， 自动化安装配置过程繁琐
Cobbler 一个集成工具，集成了 PXE、DHCP、DNS 和 Kickstart 服务管理和 yum 仓库管理，简化了运 维工程师工作量 (常用)
(2).集中化配置管理类
chef 工具
需要用户熟悉 ruby 语言，入门门槛高，管 理模块开发周期长
资源脚本从前向后执行，维护调试繁琐
chef 在配置中心服务器端需要依赖软件比 较多，需要 couchdb、RabbitMQ、Solr、java 和 erlang，配置过程复杂繁琐
chef 的配置管理文件放在 couchdb 和 solr 索引等二进制文件中，通过远程命令工具 knife 来操作这些配置，维护不方便
chef 的用户群少，出了问题不方便排查
puppet 工具 (常用)
puppet 自有的配置语言较为高级，入门简单，管理模块开发周期短
puppet 资源之间有显式的依赖关系，与这 些资源在配置文件的位置或前后没有关系
puppet 安装简单，需要的支持软件也少， 配置过程十分简单
puppe 的配置管理文件为 puppet 语言描述 的文本文件，易于发布、备份和扩展
puppet 的用户很多，Google、Redhat 等大公司都在使用，可以借鉴成熟的经验
cfengine 工具
老牌的配置管理工具，功能强大，但语法 晦涩，学习、维护成本高
Puppet + Func 工具
新兴的配置管理工具，语法简单，易于学 习、维护，但远程执行命令 Exec 资源只能返回成功与否，执行过程无法跟踪查看， 需要和简单易用的 Linux 集群管理工具 Func 配合使用
(3).监控类工具
监控类工具中有 Zabbix、Nagois 和 Cacti 等工具，Zabbix 和 Nagois+cacti 组合都是很优秀的 工具，鉴于 Zabbix 参考资料相对较少，选择了常用的 Nagois+Cacti 组合。
五、运维自动化对运维人员要求
1.事前预警
在故障出现之前，管理人员应该能在任何时间，任何地点接收到告警信息，并及时处理问题，把故障隐患扼杀在摇篮中。（强大的监控与报警机制）
2.事中恢复
即使是再完美的运维方案，也可能有预料之外的故障。为保证在最短时间内恢复业务，关键数据不因故障丢失，我们需要有完整备份方案来应对自如。（强大的备份与恢复机制）
3.事后存档
这里更加强调运维管理的方法，针对处理过的故障，应该记录在案，在处理过程当中运用过的处理技术，处理方案，应该形成经验文档，以供知识分享。（强大的FAQ机制）
要实现以上三个要求，并不是一件容易的事情。需要一个经验丰富且高效的运维团队，随着我们的业务系统不断增加，业务量的不断上升，传统依靠纯手工的运维方式，逐渐被淘汰。高效的运维自动化方案正在逐渐形成规模。（不仅大公司在部署，小公司也开始逐渐部署）