转载

自动化运维

为什么运维需要自动化

记得当年我刚毕业拿着某名企offer欢快的来到帝都，梦想着人生将要迎娶白富美，当上CEO，走向人生巅峰。那美好的未来一定就在不远处等待着我。

在最开始的阶段，对于接触到的技术以及业务，都会由衷感叹，好牛逼的样子，毕竟对于一个刚毕业的学生来说，是很好忽悠的。

然而时光飞逝，慢慢的，我开始反思这每天忙成狗的日子都在干什么，为什么都忙成狗了，却感受不到自己的进步呢？

然后接下来一周我开始对每天的工作做了一个统计表格，悲伤的发现80%的工作都是在重复性劳作。

看到这样的统计结果之后，我的内心是崩溃的…….

虽然当时还不明白运维到底应该是什么样的，但总觉得不应该是这样的。

后来证明，我的想法没错。

举了上面的例子，相信大家也看到了没有自动化的纯体力活的运维的一天。

假如运维每天80%的工作都是在帮助开发，产品，测试或者其他部分员工查询执行一些重复性工作，那么毫无疑问，你不是运维，你就是打杂背锅侠，

你就是打杂背锅侠，你就是打杂背锅侠。

日复一日，反反复复，意义何在？

运维的重要职能之一便是效率，想要提高效率，没有自动化，你再提高也无法有质的飞跃，也正是如此，运维自动化愈发显得重要，我们也才越来越重视自动化。

当然，自动化优势的体现和管理的服务器数量是成正比的，服务器越多，越能体现自动化的优势，你就1台服务器，做来做去也没啥意义嘛。

从我个人而言，简单来说，做自动化就是为了节省时间，提高效率，让我的工作意义最大化，而不做重复的体力活。

如何实现运维自动化

如今互联网发展迅猛，各类开源产品百花齐放，有心想做自动化并不是一件非常难的事情。

从各种云服务，到各类自动化产品，真可谓应接不暇，那么，在这纷繁的产品中，如何规划出一套最适合自己的自动化方案，才是我们需要去用心思考的问题。

其实自动化这个话题要真细说，写一本书也是绰绰有余，所以这里我也只能结合实际经验浅谈一二了。

1）机房的选择

如今随着云服务的迅猛发展，同时基于成本以及扩展性的考虑，大多数企业开始选择云服务，而不再选择IDC。国内目前比较流行的云有AWS，阿里云，腾讯云，青云等等。选择哪一家结合自己情况看吧，用过几家云服务商，我个人还是更喜欢AWS，更加专业稳定。

这一块的自动化云服务器已经基本都做了，我们也不需要投入过多的精力，直接使用就行，所以这一块我就不再赘述。

2）服务管理的自动化

对于服务管理，最开始我们都是通过一大堆脚本来做，不仅效率低下，维护成本也是非常高的，发展到最后，面对一大堆脚本自己都崩溃。这里也不是说脚本就是不好的，还是要看适用场景，做大规模批量管理，脚本毕竟不是最优方案。

那么什么方式比较好呢？

相信大家也都猜到了，自动化管理的开源软件还是有很多的，像chef，puppet，saltstack，ansible，这些都是目前市场上比较流行并且稳定的选择。

那么，是不是说我会其中一种了，就是自动化了？

这里要提到另外一点了，就是架构设计，以及冗余恢复方案的制定。这些也是在自动化实现过程中不可忽略的点，并且非常重要。

puppet举例来说，先看下面的架构图

自动化运维

puppet代码保存在svn中，本地可以修改提交，master定时从svn仓库中更新最新代码，并且定时推送到所有的client端。

大体看这个架构还不错，其实是经不起细细推敲的。

第一点，大家知道，puppet的认证是基于证书的，证书是有过期时间的，默认是五年，如果我们有成千上万的client，5年后某一天，所有证书全部失效，那将是一场灾难级的事故，画面太美，我是不敢想。所以设计之初，你应该修改下过期时间为10年，这个时间就好多了，为什么是10年，不是更久呢，因为一个公司能稳定发展10年的概率本身就很低了，另外10年后我们是否还选择使用这个软件，也得另论了。

第二点，设想一下，假如puppetmaster有一天因为一些原因，需要更换，怎么办？一样的道理，成千上万的client，证书认证都存在与master上，机器更换了，认证怎么办，重新做？简直不敢想。如果master依然存活还好，我们直接拷贝证书就好，如果已经不存活呢，画面又太美，不敢想。所以在最初的阶段，这些问题你都得设计并考虑好解决方案。对master镜像定期做备份，或者对证书定期做备份都是需要提前想到的。

第三点，一台puppetmaster真的能够承受成千上万台client的同步吗？这个值得深思。所以，改进后的架构应该是这样的：

自动化运维

3）版本迭代自动化

做运维的，版本的更新回退想必是永存的话题，那么，在自动化方面我们应该怎么更好的来做呢？

第一，选择开源产品，这方面目前hudson，jenkins都是不错的选择，也很成熟了，用他们来做版本的更新回退还是非常顺手方便的。Web访问，直接更新，更优的方案是登陆过程做一个手机ID的认证，手机直接登陆，随时更新，是不是很好呢？

第二，如果你不是很喜欢他们，总是觉得满足不了你的需求，那么你就开发自己的平台吧。对于语言的选择C, C++, java，php，perl，python等，什么语言都可以，你喜欢谁就用谁吧，个人比较推荐python，一方面python本身对于运维日常需求处理很强悍，另外，目前国内运维python比较流行，这样团队的衔接性会更好，再者，python本身也有自己的web框架，做平台开发也有自己的先天优势。

4）监控的自动化

监控在任何场景，对于运维都是重中之重的。

发现以及处理问题的及时性，业务的稳定性，都是必须有一套成熟的监控方案做底牌的。

对于监控的软件选择，Nagios，ganglia，zabbix，cacti等等，都是你可以选择的，这里不多说了。

既然是自动化，我主要想说的是监控节点的添加以及剔除的自动化，如何最大化减少人为干预。

日常工作中，服务器的数量总是会变化，今天需要添加，明天需要减少，如果每一次我们都要手动干预，总是烦心的。所以这个同样需要自动化。

这个我们可以结合资产管理系统来做，比如CMDB。每一台服务器都会在CMDB中记录，同时会跟随一个status状态值。监控机运行一个检测脚本，定时检测status值，根据值来判断是否添加新的监控节点以及删除旧的节点，并根据事先定义的模板来生成新的服务器信息。每天添加或者删除节点时，我们只需要到CMDB的web页面点点点就可以啦。

5）日常查询的自动化

作为运维，我们日常最频繁的查询便是开发SQL以及日志的查询需求，虽说每次查询也只是我们简单的几行命令，几分钟搞定，但是每天频繁这样的零散需求还是占用了我们很多的时间，再加上每次查询前后消耗的时间，总是令人很不愉快。

SQL查询：

基本上我们的数据库服务器都是要跑在内网的，那么办公室的外网想去查询，我们如何做呢？

没错，就是隧道转发，分为SSH隧道以及iptables端口转发。打通这样一条隧道后，给开发们开通SALVE只读查询权限，然后就可以潇洒的扔给他们了，玩去吧，不要再占用哥宝贵的时间了。

自动化运维