案例1：基于云的运维自动化
我们是小规模的公司，搭建在 AWS 上的服务，主要使用 Ruby on Rails，并实现了应用的水平扩容。
在专案一开始的时候只有一台 EC2 就可以跑了，后来因为专案越做越大，开始做平行扩充以及 SOA，因此我们导入了 Chef 做自动化运营，主要使用 Chef 做机器的安装及部署，使用 Cloud Watch 做机器与 Application 的效能监控，在每次 deploy 的时候做AMI，当资源负担到达设定值时，Chef 会使用***的 AMI 开一台新的机器加入 ELB，这个过程大约是 5 分钟，于此我们做到了 Application 面的平行扩展。
数据库的部分，我们使用 PostgreSQL 做集群，一台 Master + 多台 Slave 加上 AWS 本身的 muti-AZ 机制，可以动态加开 slave 以及 load balance;Redis 的部分亦同。
现在我们使用 Jenkins 做 CI，每次跑完 CI 会包一个 Docker 版本来跑 staging 环境，staging 环境现在跑 docker，但现在还不敢放到 production 环境中。
案例2：关于自动化部署
我从多个方面来描述下我们广告公司运维自动化的实施情况。
编译：
我们这边RTB是用linux下的C++开发的，部署的过程中需要依赖一些特定版本的linux的运行库，而编译本身需要的库和头文件会更多，所以我们是将编译和自动部署分开的，业务需求完成编码和测试后，会将可执行文件放在指定的位置，用jenkins来调用之前调试好的自动部署脚本来进行推送和启动运行，这样能保证编译的程序相关的功能都是测试通过，且经过验证的，自动化部署之后外围还有相应的监控系统会定时扫描端口开放情况以及程序运行情况。
商务平台：
这部分是用java开发的，包管理使用maven，已经做好了关联的特定版本的jar包的管理，这部分功能就是开发测试完毕，将验证没有问题的特定版本号的svn地址提交给系统部，通过jenkins从SVN拉代码，调用maven进行编译，部署和启动，相关功能都是在运行服务器上执行。
数据：
数据部分采用了redis和tair集群，用于存储人群属性和cookie映射数据，redis和tair是通过jenkins进行部署的，数据导入是每天定时跑完画像数据后自动导入的，而数据的迁移是通过人工触发的，当部分节点数据存在问题时，外部有系统监控，发现问题，人工触发数据迁移。人工触发数据迁移是一般是在发现数据分布不均衡，特定节点负载非常高的情况下，会在后半夜触发迁移操作。
流程规划：
业务相关的程序开发之后，默认是手动部署的，手动部署时会梳理相关的流程，形成脚本，后续jenkins的自动化脚本也是来源于手动部署的脚本。
Auto Scale：
集群是auto scale的，平时会有一个最基本的机器数量配置，部署相应的程序，部署完成后不存在减机器的情况，如果有流量突发高峰和广告投放高峰，有一部分备用的机器可以快速部署，然后把流量指到新部署的机器上
规模：
目前大概用于RTB的机器有40多台高配的服务器，每台服务器上会有20个左右的进程，商务平台和展现点击收集以及计费系统，服务器有20多台机器，而后端的日志存储和人群画像部分用到的hadoop有50多台机器。
精彩观点摘录
自动化运维的本质，个人愚见就是把人解放出来，人腾出来做更有价值的事，事不会少，但产生价值的事要越来越多，其实从某种程度上面来讲，对运维人员是一个悲剧，如果运维人员不提升自己的核心竞争力，那就面临着下岗，在老板心目中，机器能更快更好的做好，为什么需要人来做(慢，不能量化)。当然反过来说，运维人员就要在老板面前找到自己的价值。
自动化运维，我更关注人。
基于公司实际情况，制定完善的流程，把重复的工作工具化，有挑战的工作简单化，相应的流程及工具文档化。总之尽可能不需要人为干预，即便需要人操作，懂点技术的员工按流程和文档即可完成操作。
Q & A
Q1：数据集群采用Jenkins部署是否存在不妥，是否违背了编译和部署分开的原则?
其实数据集群用jenkins部署主要是编译的基础环境是一定的，可以在使用jenkins部署之前完成机器系统安装之后会将相关的编译环境也批量安装好，所以用jenkins部署是没有问题的。
Q2：Jenkins在里面用得太重了，不知道会不会导致CI慢或其它问题?
其实不会，因为子系统划分是将对比较轻的，不会有非常复杂和耗时的编译。
