自动化运维

记得当年我刚毕业拿着某名企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只读查询权限，然后就可以潇洒的扔给他们了，玩去吧，不要再占用哥宝贵的时间了。

日志查询：

这里我推荐一款ELK架构，也就是elasticsearch + logstash + kibana。

这个是目前很热门的一套成熟稳定的日志收集，查询，统计，分析的架构方案。对于服务器上的所有日志，包括但不限于系统日志，软件服务日志，项目应用日志等等都可以很好的处理，并非常友好的通过web页面展示。

有了这套架构，以后开发们所有的日志查询需求，都不再需要我们手动去帮他们查来查去了，直接丢给他们自己查吧，哥依然还是时间宝贵，没闲工夫陪你们。

这套方案的架构选择性比较过，下面给出其中两种供大家参考。具体使用哪种就看个人自己啦。

                                                             方案一

                                                           方案二

最后总结下，自动化是方向，没有最好的，只有更适合自己的。根据自己业务的差异性定制出一套属于自己的自动化方案将是我们亘久不变的话题。

技术是死的，人是活得，展开自己的想象，不断思考怎么做才能更优，一点一点的来，最终总会做出令自己满意的结果。

这里我就不再多说了，先写这么多吧，有机会希望我们再一起探讨。

                                                                                              （ 作者/武鹏飞责编/王鑫贺 ）

订阅“AWS中文技术社区”微信公众号，实时掌握AWS技术及产品消息！

AWS中文技术社区为广大开发者提供了一个Amazon Web Service技术交流平台，推送AWS最新资讯、技术视频、技术文档、精彩技术博文等相关精彩内容，更有AWS社区专家与您直接沟通交流！快加入AWS中文技术社区，更快更好的了解AWS云计算技术。