1.Linux 分发系统
Expect是一个用来处理交互的命令。借助Expect，我们可以将交互过程写在一个脚本上，使之自动化完成。形象的说，ssh登录，ftp登录等都符合交互的定义。下文我们首先提出一个问题，然后介绍基础知四个命令，最后提出解决方法。
Expect中最关键的四个命令是send,expect,spawn,interact。
send：用于向进程发送字符串
expect：从进程接收字符串
spawn：启动新的进程
interact：允许用户交互1. send命令
send命令接收一个字符串参数，并将该参数发送到进程。
(1)基础知识
expect命令和send命令正好相反，expect通常是用来等待一个进程的反馈。expect可以接收一个字符串参数，也可以接收正则表达式参数。
常用expect选项
-i选项
-i选项一般用于同时控制多个spawn进程，通过这个选项向不同spawn_id发送命令就可以同时控制多个进程了，
-d选项
几乎所有expect命令都支持-d选项，d代表default，也就是设置某些命令的默认值。
-re选项
re代表regular expression，也就是正则表达式，用于expect、interact命令族中，这种类型的表达式具有匹配一切字符的能力。
3. spawn命令
上文的所有demo都是和标准输入输出进行交互，但是我们跟希望他可以和某一个进程进行交互。spawm命令就是用来启动新的进程的。spawn后的send和expect命令都是和spawn打开的进程进行交互的。
4.interact
到现在为止，我们已经可以结合spawn、expect、send自动化的完成很多任务了。但是，如何让人在适当的时候干预这个过程了。比如下载完ftp文件时，仍然可以停留在ftp命令行状态，以便手动的执行后续命令。interact可以达到这些目的。
interact 执行完成后保持交互状态，把控制权交给控制台，这个时候就可以手工操作了。如果没有这一句登录完成后会退出，而不是留在远程终端上。
expect eof 结束expect匹配。
一般为远程连接时，连接中断会报此错。在此处出现理解为interact已经退出expect捕获信息了，再次执行expect eof即会报错。
2.自动化运维
互联网发展到今天，业务变得越来越复杂，用户的需求也变得越来越广泛。为了保证服务器能够安全稳定的工作。就需要有专门的人来进行运维。在互联网服务器方面，Linux由于效率高、应用广等优势，在中高端服务器中一直占据着主导的地位。互联网Linux运维工作。主要任务是保证公司的互联网业务能够24小时为用户提供稳定、高质、安全的服务。工作内容包括应用系统的发布、部署、变更、监控、事件处理、优化以及系统架构设计调优、提供运维报告等。
而自动化运维是在传统运维的基础上产生的。由于服务器的数量一般都很巨大，仅仅通过人工已经无法满足管理上的要求。于是自动化运维开始受到人们的重视。自动化运维能够大大降低运维人员的工作负担。自动化运维是通过编程，使得计算机能够自动发现故障，并能够报警或者按照事先给定的程序解决问题。主要是将运维中大量的重复性工作转换成自动化操作。
与传统的普通运维相比，能够大量减少人力财力，同时能够有效减少甚至消除运维中的延迟状况。实现真正意义上的零延时Linux运维。
所谓的运维自动化实际上就是某些运维过程的自动化，比如初始化自动化、测试/部署自动化，加监控自动化，简单报警处理自动化，业务降级/恢复自动化....，慢慢的让系统可以承担更多的重复劳动，减少人力投入和学习成本。
通常来说，200台机器其实是一个比较小的规模，在这个量级上，运维自动化的需求主要是部署自动化，如果你掌握着真实的物理机集群，并且有一群听你话的RD，那么研究研究Openstack+Docker应该是个不错的选择，作为一个广受社区吹捧的容器服务框架，关于他的测试/部署自动化的文章简直不要太多。官网blog也有不少，你可以去看看；如果你是在维护一个伟大的或者尾大不掉的系统，那么需要研究现有的部署架构和方法，然后再选择合适的自动化部署系统，这方面jenkins，hudson， go之类的也挺多的，自己写也不复杂，前提是你有人力。
加监控自动化什么的，就取决于你选什么监控系统，是不是自己搭建了，如果自己搭建的话，搭建前务必看看他是怎么加的，是否支持API，然后想想上线系统是不是可以自动化实现，剩下的就是调研验证and写脚本了；如果是买的商业监控系统，问售后要解决方案就是了。
简单报警处理自动化和监控有关联，报警触发的时候回调，然后执行相应处理脚本就好了，当然要是监控系统太挫的话，也只能你自己脚本或程序实现故障发现了。业务降级/恢复自动化就靠和开发一块协作了，他给升级降级的方法，你负责关联故障。
装机/初始化自动化这个，看你公司机器变动频率够不够高了，如果一年没几台增加，没必要花太多精力，如果天天加机器，那还是研究kickstart/WDS之类的东西吧，另外这些系统是资源进入运维管理的第一站，和CMDB的接驳也是要早规划的。
这些事情说起来不难，实际上从零开始的话，牵扯的事情其实挺多的，比如部署的标准化（以简化你的各个自动化系统）、CMDB的建设和维护，业务程序打包和监控接口的配合调整，产品版本控制系统的建设和接驳.... 目前世界上还没有完全意义上的运维自动化，就看你能把多少自动化了，and切记：
1. 不要为了自动化而自动化，而是要找出最消耗你时间的事情然后自动化之，如此往复。
2. 不要贪恋web化，你会发现你会时常面临web化的呼声，每当这时，请保持冷静，考虑风险和收益再做决断
3. 第二阶段大作业
用13台虚拟机搭建一个高可用负载均衡集群架构出来，并运行三个站点，具体需求如下。
1 设计你认为合理的架构，用visio把架构图画出来
2 搭建lnmp、tomcat+jdk环境
3 三个站点分别为：discuz论坛、dedecms企业网站以及zrlog博客
4 由于机器有限，尽可能地把三个站点放到同一台服务器上，然后做负载均衡集群，要求所有站点域名解析到一个ip上，也就是说只有一个出口ip
5 需要共享静态文件，比如discuz需要共享的目录是 data/attachment，dedecms需要共享upload（具体目录，你可以先上传一个图片，查看图片所在目录）
6 设计合理的目录、文件权限，比如discuz的data目录需要给php-fpm进程用户可写权限，其他目录不用写的就不要给写权限（目录755，文件644，属主属组root）
7 所有服务器要求只能普通用户登录，而且只能密钥登录，root只能普通用户sudo
8 给所有服务器做一个简单的命令审计功能
9 php-fpm服务要求设置慢执行日志，超时时间为2s，并做日志切割，日志保留一月
10 所有站点都需要配置访问日志，并做日志切割，要求静态文件日志不做记录，日志保留一月
11 制定合理的mysql数据备份方案，并写备份脚本，要求把备份数据传输到备份服务器
12 制定代码、静态文件的备份方案，并写备份脚本，要求把备份数据传输到备份服务器
12 编写数据恢复文档，能保证当数据丢失在2小时内恢复所有数据
13 搭建zabbix监控告警系统，要求监控各个基础指标（cpu、内存、硬盘），网卡流量需要成图，还需要监控web站点的可用性，
14 定制自定义监控脚本，监控web服务器的并发连接数，接入zabbix，成图，设置触发器，超过100告警
15 定制自定义监控脚本，监控mysql的队列，接入zabbix，成图，设置触发器，队列超过300告警
16 定制自定义监控脚本，监控mysql的慢查询日志，接入zabbix，成图，设置触发器，每分钟超过60条日志需要告警，需要仔细分析慢查询日志的规律，确定日志条数
17 利用jmx，在zabbix上监控tomcat
18 给三个站点的后台访问做二次认证，增加安全性
19 用shell脚本实现文件、代码同步上线（参考分发系统）
设计初步图：
