一.简介
行业内各巨头的自动化运维架构都各种功能各种酷炫，让人可望而不可即。最终的目标大家都知道了，但问题是如何根据自己团队的当前情况一步步向那个目标演进。
笔者曾经所在的一个团队有三个半开发人员，要维护几十台云主机，部署了十多个应用，这些应用90%都是遗留系统。应用系统的编译打包基本在程序员自己的电脑上完成。分支管理就是dev分支开发，测试通过后，再合并到master分支中。生产环境的应用配置要登录具体的机器看才知道，更不用说配置中心及配置版本化了。在监控方面，甚至连基本的机器级别的基础监控都没有。
笔者平时的工作是50%的时间做业务开发，50%的时间做运维。而且，只有笔者一个人做运维。面对这么多问题，笔者考虑如何在低成本情况下实现自动化运维。本节就是总结笔者在这方面的一些经验和实践，希望对读者有所帮助。
二.先告警
事情有轻重缓急，监控和告警是一开始就要做的，即使业务开发被拖慢也要先做。只有知道了当前情况，才能做好下一步计划。
现在市面上有很多监控系统，如Zabbix、Open-Falcon、Prometheus 等。最终笔者选择了Prometheus。有以下几个理由。
- 笔者推崇pul模式收集指标数据，Prometheus是pull模式的。自认为push模式是自己怼自己的模式。
- 不像Zabbix需要一个Web Ul，Prometheus使用文本进行配置，有利于配置版本化(这点最关键)。
- 插件丰富，想要监控什么，基本都会有现成的。
之前我们介绍过，人少机器多，所以安装Prometheus的过程也必须要自动化,同时版本化。笔者先是以自己的工作电脑为控制机器，使用Ansible部署整个监控系统
- Prometheus server负责监控数据收集和存储
- Prometheus alert manager负责根据告警规则进行告警，可集成多种告警通道。
- node-exporter的作用是从机器上读取指标数据，然后暴露一个HTTP服务，Prometheus就是从这个服务中收集监控指标数据的。Prometheus官方还提供了各种各样的exporter。
使用Ansible作为部署工具的一个好处是有很多现成的role。在安装Prometheus时，使用现成的Prometheus-ansible。
有了监控数据后，我们就可以对数据进行可视化了。Grafana和Prometheus集成得非常好，所以我们又部署了Grafana，示意图如图所示。
Prometheus默认集成了多种告警渠道，钉丁除外。钉钉集成Prometheus告警组件：prometheus-webhook-dingtalk。
完成以上工作后，基础监控架构就大号了，为后期Redis监控，JVM监控做准备
三.配置版本化
很多运维人员或者开发人员一开始为了节约时间，采用手动方式搭建监控基础设施。事实上，这只是将“填坑”的时间拖后，或者留给后面的人罢了。
笔者推崇一开始就做配置版本化。在搭建监控系统的过程中，已经将配置抽离出来，放到一个单独的代码仓库进行管理。以后所有部署，我们都会将配置和部署逻辑分离。这样，只需要复制一份配置，改一改，就可以在新的环境中快速搭建一套新的监控系统。
关于如何管理Ansible部署脚本的配置，我们使用如下目录结构。
都是文本存储，后面切换使用Consul做配置中心，只需要将本身部署到Consul中就行。而且ansible2.0以上已经原生支持Consul操作
- 标准化。所有需要部署的业务系统都可以使用此目录结构，而不论是Go项目还是Node.js项目。
- 有助于推行DevOps。开发人员对构建逻辑和部署逻辑负责。虽然推行DevOps只是手段，不是目的。
