一名运维创业者的思考：云计算时代的自动化运维走向
关于题目“云计算时代的自动化运维”，用通俗的话讲，就是应用的自动化部署。
第一个关键词是自动化，自动化代表高效率、低成本;第二个关键词是应用部署。即，不涉及讲物理基础设施的运维(如机房基建、能源、消防、安保、布线等等)。
假设一个企业要做一个电商网站，典型的运维流程是这样：
1. 购买硬件设备：服务器、交换机。可能还有路由器、负载均衡器、防火墙，不一一穷举了。
2. 在服务器上安装操作系统
3. 在服务器上安装配置基础环境(数据库、Web服务器、搜索引擎等)
4. 在服务器上安装配置应用软件(用Java、PHP开发的电商软件)
5. 把硬件设备送进机房托管，开通公网访问
6. 监控运维中的业务，并做日常备份、扩容/缩容、迁移、升级
如果是使用公有云，则没有第1，2，5步，直接购买公有云的虚拟机、容器、平台服务(文件存储、关系数据库、内容分发等)
应用环境和应用软件部署是指第3步和第4步。
1 操作系统自动化部署
第2步是物理机的部署，现在市面上的主流服务器，都支持IPMI管理，通电接上管理端口就可以完成BIOS设置，再辅以DHCP, TFTP, KickStart可以实现无人值守的自动化安装操作系统。
目前虚拟化、私有云、公有云已经相当普及，除了一些对特殊硬件有要求的场合，和一些历史遗留场合，其它大部分场合都可以用虚拟机，物理机上安装的是宿主操作系统，应用软件装在虚拟机里，这样物理机就只需要安装宿主操作系统，需求相对简单，没有应用部署那么复杂。装完之后不会经常去改动，运行稳定。
2 应用部署
与操作系统部署相比，应用部署复杂性高得多，主要表现在：
· 场景繁多
一个小型的B2C网站，有负载均衡器、Web服务器、应用服务器、缓存服务器、搜索引擎、分布式文件系统、监制中心、日志中心、VPN服务器等十多种服务器角色
· 依赖复杂
软件包之间有依赖，服务器之间有通信依赖
· 配置各异
除标准的ini,xml, yaml, json, properties文件外，iptables, sysctl, nginx, haproxy, pptpd等都有自己独特的配置文件格式，多达上百种。文档描述和运维脚本编写都有相当大的难度。
3 应用部署技术发展历程
下面以在CentOS上安装nginx为例，回顾一下应用部署技术的发展历程：
3.1 手工安装配置
这是最古老的部署方式，直到今天也被广大小规模团队广泛采用。部署过程往往会产生这样一份文档供日后参考：
3.1.1 优点
3.1.1.1 灵活性高
可以安装任何想要的版本，启用任何想要的模块(包括自行开发的私有模块)
3.1.1.2 学习门槛低
文档是自然语言写成，阅读和书写都很简单，不需要额外学习其它技术语言。安装配置用到的工具、命令也较少，主要是网络下载、解压缩、编译、文本编辑几种，容易掌握。
3.1.2 缺点
作为最古老的部署技术，缺点也是显而易见的：
3.1.2.1 文档不精确
由于文档是自然语言写的，是写给运维工程师阅读的，而不是给机器执行的。文档写的是什么，跟机器上实际执行的是什么，并不是100%一致的，需要人肉转换。在长期版本变更、人员更替中极容易出现疏漏。当然，可以从行政管理上解决这类隐患。很多大公司都喜欢搞流程，用测试审核流程来督促人少犯错。然而，只要是这个文档是给人看而不是给机器执行的，这个文档就会一直面临笔误、表达不精确、更新不及时等隐患，要用流程来彻底杜绝这些隐患，成本很高。
3.1.2.2 效率低
上述5个步骤都是串行的，必须做完一步才能进行下一步。第1步和第3步是比较耗时的，若网速不快，或者编译时间太长，运维工程师会浪费时间等待。
另一方面，若有多台机器需要执行同样的部署操作，也无法减少重复性操作。
3.2 自动化部署：shell脚本
若服务器稍有规模的团队里，上述手工部署就成了一个大问题。
人肉阅读的文档急需转换成机器执行的代码。最早也最广泛运用的自动化部署技术便是shell脚本。以bash为例，上述5步写成bash shell就像这样(示例代码，未经测试)：
直接运行这个脚本，就可以自动安装配置好nginx了。
相比手工部署，使用shell脚本的缺点只有两点：一是写代码需要一定学习门槛。二是维护的技术难度会略高。
3.2.1 优点
3.2.1.1 精确
由于shell脚本是给机器执行的，shell脚本自身就是一份精确的可执行的文档，所以，不存在笔误、表达不精确、更新不及时的问题。
3.2.1.2 效率高
运维工程师只要把脚本启动起来就可以做别的工作了。
3.2.2 bash的缺点
Bash是几乎所有linux发行版内置的，环境兼容性好，简洁易学。但它却不是运维编程的终极之选。具体来说有两大缺点：
3.2.2.1 缺少高级语言特性
Bash不是一门高级编程语言，和Perl/Python/Ruby/PHP这些同样可以用作shell编程的语言相比，缺少很多高级语言特性，而这些特性在运维部署工作中会用到。
3.2.2.1 工具链不丰富
由于不支持OOP，因此没有完整的单元测试框架。
开发框架、缺陷分析、性能分析工具也几乎是一片空白。IDE支持虽有(JetBrains公司IntelliJ就有bash shell插件)，但功能不多。
3.3 自动化部署：运维DSL
得益于虚拟化和公有云的快速普及，高效高质量地完成应用部署不再是大公司专有的需求，也成了中小企业的刚需，前面分析过了，bash shell不能胜任大规模的、复杂的应用部署，自动化运维编程语言DSL(Domain Specific Language)被发明出来，puppet, chef,ansible, saltstack是其中杰出的代表。
4 自动化运维技术发展趋势展望
4.1 部署工作代码化
无论是使用bash / python shell，还是使用puppet、chef等DSL，都可以完成代码化这个过程。把手工操作变成代码。
使用代码自动化部署应用环境和应用，才能保证无论在办公室测试环境，还是在机房生产环境，每次运行这个部署代码，都能得到相同的结果。这是一切自动化部署的基础。
4.2 运维代码版本化
运维代码要和Java,PHP等应用代码一样，纳入SVN、GIT代码仓库，执行严格的开发-测试-上线-回滚流程。
这样便可利用svn/git的成熟SCM功能，用于这样一些场景：
4.2.1 新建分支
运维代码由1.0升级到2.0，增加了缓存层。则可以从1.0复制出一个分支出来，命名为2.0，然后再在2.0的基础上修改。
4.2.2 差异比较
若要了解1.0和2.0的运维架构到底发生了什么变化，执行svn和git的diff即可查看每一行代码的变化。
4.2.3 历史归档
1.0版稳定运行了半年，升级到2.0版本，此时1.0版冻结写请求，归档留存。2.0上线运行一段时间，发现稳定性不够。可以从归档中找出1.0版本的部署代码，回滚到1.0版本。
4.3 测试环境高保真
很多公司的测试和生产环境存在操作系统不一致、软件版本不一致、配置项不一致的情况。这种不规范的运维有两大后果：一是bug在测试环境未能测出，导致线上故障;二是线上出现异常时，测试环境不能复现。
一个应用至少有两种环境：测试环境、生产环境。大一点的公司还会分成：开发环境、功能测试环境、性能测试环境、预发环境、生产环境。这么多的环境的自动化部署代码，原则上应该是90%以上都相同，只有少数地方不一样。
4.4 自动化测试
使用代码自动化部署完之后，服务器是否立即可用，需要测试验证。自动化测试能让整个运维过程更加高效。
在应用开发领域，自动化测试、单元测试已经非常普及了，运维开发也可以做一些类似的自动化验收测试工作：
4.4.1 终端应用测试
模拟一个客户端访问刚刚部署好的服务，例如：验证其RESTfulAPI是否得到预期的结果。
优点是，最接近实际用户，若此测试通过，则说明装软件、改配置、启服务各项工作都正确。缺点是，若测试不通过，不能立即定位出哪里出错了。定位问题需借助下面更底层的测试。
4.4.2 四层网络测试
使用nmap之类的工具检测目标端口是否正常响应(包括防火墙是否放行)
4.4.3 本机测试
· 用yum,apt检测包是否安装
· 用service status检测守护进程是否正常支持
· 用ps检测进程是否正在运行
· 用ls检测文件是否存在
· 用grep检查配置荐是否设置成了指定的值
自动化测试用例覆盖足够全面，我们便有可能实现一台机器从机到上线服务全部自动化完成，无人值守。若没有自动化测试，应用部署完成之后，仍然需要人工验证是否满足上线服务的要求。
4.5 工作流
运维代码从开发到上线发挥作用，也应该和应用代码一样遵循下面的工作流：
这个流程图只展示了最基本的要求：部署到生产环境前必须经过测试环境验证。更复杂的还有代码reivew、性能测试环境验证、漏洞扫描环境验证、预发环境验证，生产环境分批发布等环节。
很多公司的现状是运维工程师开两个ssh终端，一条命令，先在本地环境跑一下看看效果，成功就拿到线上去跑了。更有甚者，不经过本地验证直接到线上操作了。这主要是因为运维工作没有充分代码化，运维代码没入svn、git仓库。
4.6 图形化界面和IDE
运维领域一直都缺少通用的、高效的图形界面和IDE。这大约有两个原因：
一是需求不强劲。运维编程的复杂度毕竟比应用编程简单好几个数量级。运维日常工作也没有代码化，还有大量的人工操作，所以，运维代码通常像冰糖葫芦一样，一个个脚本虽然串在一起，但大都是个独立的个体，没有那么强的代码组织结构。
二是运维社区极客氛围浓重。就连应用编程领域也只有Java、.NET等语言的用户比较偏爱IDE。在PHP、Python、Perl社区，vim党、emacs党、sublime text党、notepad++党各领风骚。这些党派崇拜的编辑器不同，但有一个共同信仰：不依赖IDE写代码是一个优秀程序员的必备素质。
关于这个问题，我是这样认为的，有高科技能提升编程生活质量，为什么不用用?即使puppet、chef把运维编程体验做到这么好了，我仍然期待运维业界涌现一批Eclipse、AdobeFlash这样的图形界面、IDE。让IDE的高效易用和运维的命令行操作相得益彰。
4.7 运维代码分治
运维界有一句祖训：没有折腾，就没有故障。
但为了快速响应业务需求和提高资源利用率，运维又不得不频繁折腾。有没有什么办法能打破“折腾越多、故障越多”的魔咒?有，分而治之。
分治，就是把风险高的和风险低的分开、重要性高的和不高的分开、简单的和复杂的分开、频繁变动的和不频繁的分开。应用编程领域，大家积极探索和实践的各种架构、框架、模式，归根到底都在做两件事：封装复杂度、隔离变化。
运维架构层的分治，在业界已经非常普遍了，比如应用服务器和数据库服务器分离、交易数据库和用户数据库分离;生产环境和测试环境隔绝。
4.7.1 配置项和逻辑代码分开
其实业界早就在这么做了，puppet的hiera和saltstack的pillar都是做这个用的。
有些运维变更，可能只改变了配置项的值，而并没改变运维代码里的业务逻辑、流程控制。如果只改配置文件，不改运维脚本。发布风险就低了很多，起码不会导致语法错误。
4.7.2 会变动的配置项独立
就像应用开发领域里的模板引擎一样，把配置文件写成模板，模板中包含变量，运维工具或者运维平台解析模板内容，把变量替换成真实的值。
4.7.3 服务发现
将会变动的配置项独立出来动态维护，还可以实现服务发现。以haproxy + etcd + confd为例：
confd就是一个模板引擎，类似Java里有Velocity和Python里的jinja。不同之处是：confd还有自动轮询etcd的能力。使用confd解析和管理haproxy的配置文件，摘录如下：
跟原生的haproxy配置文件不同，最后三行是confd模板。
etcd是一个KV存储，类似memcached，不同之处是etcd生来就是分布式的，自带高可用和负载均衡的基因，同时还有HTTPRESTful API，存取方便。使用etcd存储后端服务器列表。
当后端有一台nginx服务启动的时候，调etcd的api把这台机器的ip地址写入etcd上的列表。confd轮询etcd时查到这台新加入的机器，便会自己把它加进haproxy的backend server里。
这样便实现了负载均衡集群自动化扩容，下线一台nginx机器亦同此理，先调etcd的api删除某台机器，过一分钟在这台nginx上检测不到流量了再把它下线。
扩容过程中没有修改haproxy的配置，也没有部署haproxy。只是调用了etcd的RESTfulAPI，这个风险就比修改haproxy配置文件再部署上线小多了。
4.8 整合基础设施API
所有的公有云厂商都提供了HTTPOpenAPI，包括国外的aws、azure、gce和国内的阿里云、Ucloud、青云。
市场占有率排名靠前的虚拟化软件商也都有HTTPOpenAPI，包括：VMware、Hyper-V、XenServer、OpenStack。
因此技术上有可能把基础设施提供商的API整合进来，实现虚拟机创建、启动、安装操作系统、联网、执行命令、关机、销毁全生命周期的自动化。
和应用部署脚本不同，调用云厂商的API不能由DSL脚本完成，用bash shell来做也非常不方便。应该用PHP、Java之类的应用编程语言写一个应用来做。
至此，虚拟机和操作系统初始化、应用环境部署、应用软件部署全部都实现了自动化，便可以从零创建一台可上线服务的机器。
4.9 跨厂商跨城市故障转移
实现了部署工作代码化和基础设施API整合之后，便可以自由地跨厂商、跨城市迁移：在不同的机房维持两份相同的数据，每分钟同步。当基础设施发生重大故障难以在短时间内恢复时，可以迅速在另外一个有数据的机房将整套应用自动化部署起来。
4.10 弹性伸缩
几乎每一个给人类访问的网站，其服务器资源利用率都是存在明显峰谷的：
· 有的尖峰是一年出现一次，典型的例子是阿里的双十一。每年11月11日，电商狂欢。大卖家的进销存系统、淘宝生态链上的SaaS服务商(如在线打印快递单、发送短信券码、物流跟踪)的系统压力也跟着猛涨1-2个数量级。他们投资扩容的硬件设备，只有这一天才能充分利用，平时利用率极低。
· 有的尖峰是一天出现一次或者多次，比如唯品会、聚划算的10点秒杀。基本每一个电商都一天多波次的秒杀、抢购。
· 更普遍的是白天高峰、凌晨到清晨低谷。
自动化运维(包括自动购买分配虚拟机、自动部署应用环境、自动部署应用软件、自动测试)使按需调度计算资源成为了可能。实时的弹性伸缩，意味着每天、甚至每分钟都在做扩容、缩容，这必须要靠自动化运维实现。
4.10.1 公有云上的按需采购
主流的公有云计费粒度都已经细到小时(aws、阿里云、Ucloud)，有的做到了按分钟(azure、gce)，甚至还有按秒计费的(青云)。
对出现频率较低、计划中的尖峰，人工干预，提前做好扩容和缩容预案，以双十一为例，人工设定好11月10日购买一批按小时计费的机器(不是包年包月)，到了11月15日释放这些机器，厂商会停止计费。
对出现频率高的尖峰，运维平台智能调度，比如每5秒采样系统资源利用率，达到指定的扩容阈值就自动买机器并自动化部署、测试、上线服务，低于指定的回收阈值就自动下线服务器、通知厂商停止计费。这种适用于部署上线时间极短的服务，特别是无状态、无用户数据的应用服务器。若需要较长的预热时间(如数据库、缓存、搜索引擎)，则需要提前扩容，这就要根据历史性能曲线做智能预测了。
按需购买对公有云厂商也有积极意义：
· 从宏观角度讲，用多少买多少，杜绝浪费，提升了全球公有云资源池中的资源利用率，任何提升资源利用率的事情都是有积极正面的。
· 从经济角度讲，公有云按小时售卖的机器单价比包年的贵，如果两种售卖方式都能100%把机器卖出去，按小时计费的总收入更高。
· 目前有的公有云厂商已经出现部分机房物理资源售罄的情况。如果提供实时服务(如电商、支付、新闻、社交)的客户都按需采购，就有可能在闲时把资源释放出来给实时性要求不高的客户(如离线大数据处理、动画渲染)使用。
4.10.2 私有云的业务间调配
已经投资购置大量硬件的企业，可以在不同内部业务之间调度，比如白天把大多数机器用来为消费者提供服务，晚上缩减承担消费者请求的机器规模，释放出来的计算资源用来做大数据处理。
5 自动化运维平台
2012年，我刚在极其艰苦的环境下做了一个自营B2C，恰好看到12306故障频频，觉得自己能带队做一个比他们好的，于是试着去做数据库建模，结果，就是有了《身为码农，为12306说两句公道话》这篇文章，那篇文章太火了，各种微博、微信、论坛累计转发可能有几十万，还登上了《科技日报》、《南方都市报》、《新京报》等10余家平面媒体，连12306的技术负责人(中国铁科院计算所副所长)接受人民网采访都引用我的观点。后来微博上很多人转发说“这兄弟生动地诠释了：你行你上，不行别逼逼”。
2015年，我对运维做了这么多展望，技痒难耐，决定再实践一次“你行你上”，于是我自投资金百万，做了“运维厨房”这样一个自动化运维平台。在这里就不再多做阐述了。
