作者介绍
朱祥磊，山东移动BOSS系统架构师，负责业务支撑系统架构规划和建设。获国家级创新奖1项、通信行业级科技进步奖2项、移动集团级业务服务创新奖3项，申请发明专利13项。
系统规模的不断发展以及应用软件架构的发展，推动着自动化运维的演进。因此在说自动化运维之前，需要先说说应用软件架构的发展简史。回顾过去，应用软件架构先后经过了单块架构、多层架构、服务化架构、分布式、微服务架构等：
应用软件发展早期，系统规模一般很小，特点是应用功能集中、代码和数据中心化，表现为一个软件发布包，集中部署，各模块运行在同一个进程的应用程序。此时一般几台机器就可以完成全部应用软件功能。
以Web应用程序为例，在Web应用程序开发的早期，由于受到面向过程的思维及设计方式的影响，所有的逻辑代码并没有明显的区分，因此代码之间的调用相互交错，错综复杂。譬如，我们早期使用的ASP、JSP以及PHP，都是将所有的页面逻辑、业务逻辑以及数据库访问逻辑放在一起，这是我们通常提到的单块架构。
在这种架构下，所需的机器数量很小，完全的scale-up模式，据说IBM公司在上世纪50年代曾经宣称， 全世界只需要5台计算机就够了！
为了解决单块架构扩展性差的问题，同时解决代码集中带来的并行开发测试困难等问题，逐步出现了多层架构，把表示层、业务逻辑层、数据访问层适当分离，分别打包部署。如通过实现Model-View-Controller的模式将数据、业务、展现进行分离。还有一种RPC架构，通过远程过程调用实现应用架构分离。
此时每层都独立打包，独立部署于容器和单独的服务器中，应用结构更加复杂但也更加清晰，当然所需的服务器数量就进一步增加了。
多层架构尽管大幅提升了应用的扩展性，但是随着软件和系统规模的不断扩大，垂直应用越来越多，应用之间交互不可避免，此时层间应用接口变得越来越庞大，最终会变得难以管理。通过将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速地相应多变的市场需求，也使不同服务的独立扩展成为可能。
在这种模式下，可以按服务进一步拆分部署，应用可以扩展到更多的机器和容器上。
随着业务不断发展，硬件成本的下降，基于X86架构的廉价硬件+分布式软件的模式日趋成熟，得到了大规模应用，分布式服务框架逐渐替代传统的服务化架构，解决了传统服务化的弊端，例如企业集成总线ESB是实体总线，性能线性扩展能力有限，硬件负载均衡器的压力越来越大，不断扩容导致硬件成本增加，随着业务规模的不断增长，传统的数据库、配置中心等逐渐成为单点瓶颈。当然应用也彻底变为了scale-out架构，导致机器和容器数量大幅上升。
微服务架构是对上面分布式云化架构的拓展、服务化的进一步延伸，通过对服务进一步细化，形成微服务，运行于单独的容器平台，可实现云的弹性和敏捷，如弹性伸缩、线上线下一致的环境、提升自动化运维能力等。
别着急，下面再允许我介绍下自动化运维的内容，究竟包含哪些内容？
硬件和网络的自动管理
云化、虚拟机的自动管理
操作系统和软件的自动化安装、配置
常规任务（健康检查、安全加固和检查、备份、清理、数据管理、弹性伸缩等）
手工任务（容灾切换、应急操作、应用部署和起停……）
监控
问题诊断
可视化
其中1、2、3主要是传统IaaS层关注的工作内容，重点是计算、存储、网络的自动化管理，4到8主要是PaaS层关注的工作内容，IaaS层和PaaS层相互结合，共同完成自动化运维。
好了，终于到正题了，自动化运维前世今生来了…..
史前时代：此时系统规模很小，一般几台，不超过几十台，此时一般通过手工单台登录即可满足运维要求。
中世纪时代（集中管理阶段）：系统规模有了较大扩展，从几十台到上百台，此时再通过手工方式已经无法进行，于是出现了各种Shell脚本，通过脚本实现相关的运维，脚本仅仅是针对特定的场景，难以实现全流程的自动化。
中世纪拓展（集中管理的进阶）：为了方便管理以及可视化，出现了各类商用或开源工具软件实现自动化运维，如HP Openview、puppet、SaltStack、Chef等等，做为脚本方式的提升。
新时代：系统规模进一步扩大，从上百台演进到上千上万台，以前的方式由于存在弊端，如缺乏统一的CMDB或太简单、不支持复杂环境、缺乏友好的可视化界面等，难以满足要求，此时又出现了几个分枝：
分枝一：从底向上的云平台方案：通过云管理平台实现计算、网络、存储的IaaS层自动化管理，同步建立软件PaaS层自动管理，最终实现融合。
分枝二：从上向下的云平台方案：通过上层PaaS层自动化管理，逐步向下探索，如容器等。
下面重点介绍几个自动化运维工具或平台：
Openstack是IaaS层目前最活跃的一个开源的云计算 IaaS 平台，即云操作系统，类似于AWS（亚马逊的云服务），通过各种开源组件实现了不同功能，目前大部分云管理平台均基于Openstack实现计算、网络、存储的统一管理，Openstack支持如下功能组件：
计算服务（Nova）：按需提供计算资源，创建和管理批量虚拟机 ，动态虚拟机管理：创建、重启、调整大小、迁移等。
对象存储服务（Swift）：基于普通硬件的大规模存储，无中心节点，分布式存储、水平扩展，同时多数据备份，保证安全，通过API接口对外访问。
块存储服务（Cinder)：为虚拟机提供云硬盘。
网络服务（Neutron）：为虚拟机提供网络访问能力。
编排服务（Heat）：提供自动化部署及管理服务。
数据库服务（Trove）：提供数据库管理服务。
认证服务（Keystone）：提供身份认证机制服务。
镜像服务（Glance）：提供虚拟机镜像存储服务。
监控服务（Ceilometer）：提供计量与监控服务。
Dashboard（Horizon）：自服务、权限、图形化界面。
Openstack尽管对IaaS层的自动化管理比较强大，但仍然需要注意如下几点：
1、Openstack版本众多，如何选择是一个难题。
例如存在社区版、发行版、商业公司定制版本等，如何选择是一个难题，而且Openstack每半年一个稳定版本，演进很快。一般认为对Openstack项目中的开源代码进行修改定制是个不错的主意，但这从长期角度来看不一定最佳。“定制云”很可能需要付出高昂的代价，不仅投资巨大、成本高昂，企业用户还将被迫面对一大堆后续的管理及维护开销，并被绑定在单一供应商或版本身上。
建议企业如果有很强的技术能力的话，可以根据自己的需求做定制，但需要把握好和社区发展的关系。 一般来说，需要根据自己的需求，选择合适的版本，尽量不改变社区版本，定制化需求尽量在外围进行改动。如果采用了厂商的版本，实际上也是某种绑定，可能离社区越来越远。
2、需要慎重选择相关组件合功能
由于Openstack理念是分布式、最终一致性，因此所有的原始功能组件都是基于这一设计，企业用户考虑采纳Openstack之前，必须对企业业务应用进行分析：应用程序是否有可扩展性和弹性伸缩的要求？ 应用程序是否可以接受最终一致性？ 应用程序是否无状态化？ 应用程序的性能要求？应用程序的可靠性要求？ 应用程序的安全要求？ 应用程序的容灾备份需求？ 不同的要求决定了Openstack不同的计算、存储、网络等模块设计。
3、Openstack对PaaS层和物理机管理较弱，需借助其他工具实现
Openstack已经能够支持很多的IaaS自动化运维和部分PaaS自动化运维任务，但不能满足全部，如批量运维、深入监控、软件管理等功能缺少，特别是对物理机运维较弱，一般需要结合其他PaaS层管理进一步完善自动化运维体系。
PaaS层自动化运维工具就太多了，例如监控就有Nagios、Ganglia、Zabbix等，运维工具则有Puppet、Chef、SaltStack、Ansible等，不同企业根据企业自身开发实力、结合配置管理工具的资源丰富程度、依赖复杂程度考虑，会有不同的选择。通过对运维工具本身的研究，结合运维人员的运维经验和评估企业未来的规模，下面以开源SaltStack+定制实现的方案进行介绍。
SaltStack是继 Puppet、Chef 之后新出现的S配置管理及远程执行工具，与 Puppet 相比，SaltStack较为轻量；不像 Puppet有一套自己的 DSL 用来写配置，SaltStack 使用 YAML 作为配置文件格式，相对简单，同时也便于动态生成；此外，SaltStack 在远程执行命令时的速度快，由于使用了ZeroMQ，这个下发过程可以并行执行，速度比Ansible的无agent ssh通信快得多，是一个分布式远程执行系统，用来在远程节点（可以是单个节点，也可以是任意规则挑选出来的节点）上执行命令和查询数据。
从部署结构上看，SaltStack的在部署上可以分为master和minion两个部分，其中master相当于统领所有机器的总管，而minion则是部署在被管理机器上面的agent进程，master通过网络将配置管理相关的操作下发到minion，由minion在对应机器的本地执行。典型的部署例子如下图所示：
在现实生产环境中，大批量的用户创建需求，文件上传需求、配置变更需求、软件升级需求占用了维护人员大量的时间，引入SaltStack后，该工具的远程执行和配置管理可以解决该问题，真正实现批量化和自动化，满足海量运维的需求。
有了Openstack和SaltStack为代表的的PaaS层自动化工具还不够，针对应用自动化运维场景，如弹性伸缩、DevOps（开发运维一体化、开发测试一致的环境、自动资源调度、应用日志统一管控、应用服务的编排、微服务管理等），此时出现了容器技术，容器技术实现有很多种，但最流行的是Docker。
传统容器技术相较虚拟机优势不是特别大。Docker能够流行一大重要因此就是它的创新--Docker镜像。Docker构建了一整套构建、发布、运行体系：容器（Container）、仓库（Repository）、镜像（Images）。传统容器只解决了容器运行（run）的问题。而Docker定义了一套容器构建（build）分发（ship）的标准，使应用管理非常便捷，尤其适合微服务管理。
注意容器对应用有特定的要求，并不是所有应用都适合，例如需要无状态化、镜像文件不能太大等。
自动化运维需要注意的几点：
一般的自动化运维工具均缺乏良好的可视化界面，需要进行结合定制开发。良好的界面可以更易于在企业内部推广自动化运维。
自动化运维工具众多，各有所长，应结合熟悉程度、技术特点进行针对性选择。
多层的自动化管理工具，多头的配置管理是个难题，建议考虑定制化，设计统一的CMDB，做到一点配置，多点更新。
Ok，本文就到这里，由于自动化运维是个很大的话题，涉及话题很大很广，这次仅仅是答题的概述，后续将结合专题进行细化讨论。
原文发布时间为：2017-02-28
本文来自云栖社区合作伙伴DBAplus
