现在大家都在讲运维自动化，那么我也跟风聊聊一些看法，比较随意，写哪里算哪里。
一、什么样的任务适合自动化
在我看来，运维自动化的根本目的是自动化日常琐碎的工作任务，解放运维人员，让运维能有更多时间放在结构规划，新知识学习等更有价值的方面。
之所以现在这么热，就是因为它可以提高效率，降低成本，而这两点是任何先进事物替代旧事物的根本动力，比如蒸汽机，比如计算机，比如云计算。
那么就自动化本身来说，什么样的工作适合自动化呢？我觉得有3大类：
1.每天做的简单体力劳动类，例如监控，安装系统，配置nginx这类的。
2.不常用，但非常复杂，容易出错的，例如安装openstack，ceph集群等等这类的。
3.一些参数会实时动态变化的，例如云主机的管理，虚拟机的创建和管理这类的。
至于一些简单的，偶然出现的日常需求，重复3次以内的，还是直接写shell搞定就是了。
二、标准化是一切自动化的前提
如题，运维要想活得容易一些，就要重视标准化，只有在标准化的基础上才能更好的开展自动化。
标准化，从硬件选型到软件安装，到网络配置，存储划分等等都要有相应的标准。
2.1
硬件
要根据公司的业务需求，制定几种服务器角色，对每种角色，定义好能满足95%以上需求场景的配置。
例如：数据库，虚拟宿主，大内存缓存，负责均衡器。
这就像AWS云主机的EC2，不会允许你随意配置，而是预先定义好的一些配置。
这些配置定好以后，我们采购服务器就不用考虑太多，按需选择就是。
这样做的好处是，服务器配件基本是可替换的，假如遇上厂家售后缺备件等情况，我们可以自行调整先顶上去，保证业务运转。
还有一个额外的好处是可以跟服务器厂家谈框架采购协议，这样服务器厂家就不必每次都要申请折扣，能够获得最优价格。
同时提高采购到货效率，采购部门也能活得轻松一点。
对于特殊需求，一定会有，但是量绝不会大，而且是在基础配置上稍加改动即可。
对于一定时期内，同一批次尽可能采购同一厂家的服务器，不要五花八门。
对于网络设备的采购也是类似原则，不再赘述。
设备采购到位后，信息采集也要标准化，上架也要标准化。
我们公司的做法是，到货的服务器用条码枪扫描服务器外包装上的SN和网卡MAC地址，存在表格中。
向财务部门申请资产编号，将服务器SN与资产编号一一对应，填好的表格发回给财务部门入账。
这样，能确保服务器自到货开始就是有踪迹可循的，无论怎么搬迁，SN是随着服务器不会变的。
而不能采用IP地址这类的可变信息做标识符，每年资产盘点也能少费点时间到处找。
MAC地址收集来干嘛用呢？用来后边PXE安装系统时根据这个信息，发给服务器不同的安装配置文件。
我们机房的网线是按颜色区分的，红色公网，蓝色内网，黄色管理网，灰色存储网。
而网络接口，从左到右(上下)依次安排为公网，内网。
网线标签如何命名，资产标签粘贴位置等等也有固定的规则。
这样做的好处显而易见，一个新入职的同事，只要花30分钟让他理解熟悉这套规则，你就可以放心让他进机房操作，不用担心他会出现拔错线，重启错机器这样的低级错误。
2.2
软件
软件的标准化，主要是版本和配置的标准化，这也包括网络设备的配置。
软件版本根据业务需求，测试稳定可用后，选定就不要随意追新版更改，要更改一定是安排好的批量升级。
操作系统安装应该采用kickstart方式，杜绝手工安装。
hostname怎么命名要有规范，配置文件的位置，注释的写法等等细节也要有个规范，让大家讲同一种语言。
软件我个人比较反对自己编译安装的方式，一般采用这种方式的理由就是可以将所有需要的东西都放在一起，容易迁移。
这个理由，貌似有道理，但其实是没有标准化的结果。
如果一些软件，例如nginx，你需要编译进去一些自己的模块，那么也建议打包成rpm的形式安装，因为可以标识版本，用yum来统一管理。
自己做rpm包并不难，使用fpm等工具可以非常容易完成，而不一定要去写SPEC文件，关于fpm可以参考我blog中的相关文档。
软件配置也包含网络中的地址，路由，VLAN规划，这些都可以定义好，大家共同遵守。
三、不能用技术手段约束的规范就是一纸空文
上编说的一堆规范，如果不能用技术手段予以约束和实施，那么就是一纸空文。
因为人总会有疏漏，无论你采用什么惩罚措施，也不能挽回损失。所以，要让这些规范落地，就需要技术手段保证。
例如：服务器的hostname，分区方法，网卡配置，DNS配置，默认开机启动的service，selinux，默认防火墙规则，zabbix
agent自动安装配置等等，这些都可以通过kicstart来保证。
而一些日常操作，例如发布上线，修改配置等等，可以用puppet，saltstack，ansible这样的自动化工作完成。
不过有一个比较困扰的问题，我也一直无解，就是业务运行中总有一些东西是开发的后台覆盖不到的，这时候业务就会要求运维DBA来手工改数据库。我们数落产品人员如何无能也解决不了问题，所以也只能给改，能做的也只是强制加上一些人为审批流程保护一下自己而已。这个问题，不知同行有没有好方法解决呢？
对于稍大的互联网公司来说，一般会有“开发，测试，预发布，生产”这四种环境。
这些环境下的软件配置，参数应该保持一致，才能保证顺利上线。Docker的优势之一就是docker
file可以保证这一点。
对于没有采用docker的公司，我们也可以采用自动化，标准化的方法保证，我们以ansible为例。
我们采用同一套playbook来确保安装、更改等操作的一致性，但是不能将所有主机放到一个inventory文件中，那样容易乱，如果机器数量巨大，简直是噩梦。
参考了digitalocean的文档，我将ansible的目录规划为如下结构：
.
├──
ansible.cfg
├──
environments/
# 环境目录
│
│
│
├── dev/
# 开发环境
│
│ ├── group_vars/
# 开发环境的group_vars
│
│ │ ├──
all
│
│ │ ├──
db
│
│ │ └──
web
│
│ └── hosts
# 开发环境服务器列表
│
│
│
├── prod/
# 生产环境
│
│ ├── group_vars/
# 生产环境的group_vars
│
│ │ ├──
all
│
│ │ ├──
db
│
│ │ └──
web
│
│ └── hosts
# 生产环境服务器列表
│
│
│
└── stage/
# 预发布环境
│
├──
group_vars/ # 预发布环境的group_vars
│
│
├── all
│
│
├── db
│
│
└── web
│
└── hosts
# 预发布环境服务器列表
│
├──
playbook.yml
│
└── . .
.
然后在ansible.cfg中配置，默认使用开发环境
[defaults]
inventory = ./environments/dev
这样，所有操作默认是开发环境，如果需要动生产环境，必须手工输入-i
environments/prod，多了一层保险机制，防止出错。
对于自动化工具的选择，我觉得环境大，可以考虑saltstack，中等或小公司，可以考虑ansible。
先写这么多，想到了啥再补充。
参考文档：
https://www.digitalocean.com/community/tutorials/how-to-manage-multistage-environments-with-ansible#ansible-recommended-strategy-using-groups-and-multiple-inventories
