“运维自动化软件哪家强？”面对云计算带来的海量系统运维的挑战，运维自动化是大势所趋。过去有IBM、HP、BMC、CA四大传统厂商，现在有Puppet、Chef、Saltstack、Ansible四大开源产品，如何选择适合的自动化软件、并结合自身情况提升运维成熟度是一个问题。
本文综合过去10多年互联网和企业级运维经验，谈谈我理解的运维自动化，以及运维自动化成熟度模型和选型实施建议。
一、操作自动化不等于运维自动化
云计算容易陷入人云亦云的误区，运维自动化也有不同的理解。我认为运维自动化是手段而不是目标，很多人被“自动化”三个字的概念先入为主，转因为果，把运维自动化当成目标，就容易陷入误区：
误区一：认为运维自动化就是操作自动化
很多人把运维自动化理解为狭义的维护自动化，认为运维自动化就是编写批量脚本、下发脚本、批量执行脚本这三步，帮助运维人员去处理人工重复的工作量。
误区二：认为运维自动化的核心是兼容和适配
由于传统企业运维建设缺乏标准化建设，运维人员需要面对各种软硬件设备，因此，很多人认为运维自动化的核心工作量在兼容和适配。
为什么说这两个误区很有问题呢？以二战时的坦克火炮为例，当时的炮弹都是人工装填，维护复杂、射速慢，和现代的全自动化火炮区别非常大。如果某一个厂商，为二战火炮开发全自动的上弹机，并且适配了各种口径的火炮，这样的产品对用户能产生多大的价值？很显然，只解决人工维护的问题，不去对火炮本身升级换代，只能是鸡肋。
传统的四大IT自动化厂商的产品基本都是秉承以上两个原则，罗列出一堆批量功能和适配设备，但只是简单的操作管道，无法对客户的运维产生本质的影响。再配上windows 2000风格的复杂界面，易用性很差，运维人员也很难有兴趣去探索。所以，传统自动化软件卖不好、实施难、用的少。
二 、运维自动化的核心是配置自动化
运维这个词是operation，既可以翻译为运维，也可以翻译为运行，并进一步引申为运营。运维自动化变为手段，运行自动化才是目标。
狭义的运维自动化的核心是批量执行的管道和广泛适配的能力；而以运行自动化为目标的广义运维自动化，本质是“连接”和“升级”，即通过自动化能力为纽带，去连接各种运维场景，寻求和执行运维的最佳实践，促进运维组织的成熟和各种能力的升级。
同样以二战火炮的自动化演进为例，首先，自动装弹机的出现刺激火炮射速的提升，自动夜视仪升级了火炮的监控系统；之后，自动化炮射雷达，将雷达和火炮进行连接；最后，各种信息化系统，把火炮接入C4ISR一体化作战平台，实现协同作战。从中可以看到，为了自动化而自动化没有意义，通过自动化进行广泛的连接与升级，才能实现飞跃。
广义的运维自动化的核心是配置自动化。以Puppet为代表的新一代运维自动化工具，最大的特点就是强调配置管理。通过配置语言去描述系统的目标状态，由Puppet去负责标准化的实施，既解决了传统的脚本维护负责的难题，又可以促进运维标准化和成熟度的提升。
只有实现配置管理和配置自动化，才能实现真正的应用系统的弹性伸缩，享受到云计算下全自动扩容缩容的优势；反之，如果只把运维自动化工具当做执行命令的操作管道，那只能实现虚拟机级别的弹性伸缩，最多算半自动化。
三 、云霁运维自动化成熟度模型
对大企业而言，运行管理的体系化和自动化是核心目标。传统意义的运维自动化太窄，仅仅是操作自动化根本解决不了运维的问题；现在的devops（开发与运维衔接）又太前卫，大部分企业运维自身的问题都没解决，运维各个部门还是烟囱式架构，无法互联互通的时候，怎么去和开发衔接呢？更加不用说从运维到运营了。因此，需要考虑现状和目标之间的距离，制定合理的阶段目标和演进策略。
参考Garnter关于运行管理架构的研究报告，我进一步把运维自动化细分成5个阶段，代表着不同的运维成熟度。
1）初始级：设备数量不多，只有最基础的监控需求，没有运行管理和运维自动化的需求；
2）操作自动化级：设备数量增多，维护的压力加大，针对人工重复性的操作，如设备巡检和设备的安装部署，实现操作命令的批量自动化；
3）资源统一管理级：还属于基础设施运维阶段，面向设备和资源，不仅要解决异构资源统供给的问题，还要进一步实现资源的配置管理，从源头启动全生命周期的管理；
4）一体化运维级：引入了自服务和devops理念，从面向资源变成面向服务，整合分散的运维工具和流程，打破部门墙；优化服务交付；
5）双模DCOS运营平台级：重点是以业务为中心，构建IT运营体系；兼容各种技术环境，混合传统IT、私有云、公有云、容器环境；按需提供能力和服务，实现动态变更和实时基础设施。
四、运行自动化演进策略和阶段目标
传统的运维人员加班加点，日夜操劳，大都是亚健康的体质，一不留神就容易得个伤风感冒。冰冻三尺非一日之寒，运维体系的改造、运维自动化的实施和治病类似，需要有清晰的演进策略和阶段目标，从缓解症状，到治标，再到治本，最终体现运维的能力和价值。
◇ 操作自动化（缓解症状，树立信心）
操作自动化是基础和起点，当前运行的老系统历史包袱较重，先将运维人员从机械重复的繁琐日常工作中解放出来，才能腾出时间来思考和寻找方向。如重感冒患者，不停的打喷嚏流眼泪，根本腾不出时间干别的。这一阶段中的企业，首先要缓解症状，树立信心。
▲人员组织：维持现状，立足现有人员，引入外部专家；
▲流程制度：基本维持现状，先不动流程，也不建立新的流程；但在制约自动化的部分风险制度上进行试点突破；
▲技术工具：自动化装机、自动添加监控点、自动化巡检，应用程序脚本一键部署、一键重启等；
◇ 资源统一管理（治标）
资源统一管理，针对应用扩容、机房搬迁，物理机向虚拟机迁移等场景，针对于新上线设备，实现资源标准化管理、自动供给、统一配置管理，先从源头控制住新设备，防止新的资源再出现原来一样的混乱场景；承上启下，要治本先治标。
▲人员组织：维持组织现状，数据中心各个专业团队确定自动化牵头人员，协调内部的资源；
▲流程制度：针对资源的采购、上架、安装和供给，建立标准化规范，和通过自服务进行申请、审批、实施的的流程；通过标准化来推行配置管理
▲技术工具：资源池管理、资源服务目录、XMDB统一数据管理、配置管理和配置下发系统，应用程序包管理系统；
◇ 一体化运维 （治本）
一体化运维，建立数据中心的整体视角目标，以精细化管理、流程再造为手段，推动数据中心的整体重构，实现统一运维、全自动的闭环管理，正本清源。
▲人员组织：建立“大运行”的数据中心组织架构，职能部门进行整合，合并工具团队，整合跨中心的人员，实现开发、测试、生产、灾备的统一管理；
▲流程制度：引入devops思想，针对新技术、新需求寻找和提炼最佳实践，进行流程重构，提高流程的自动化和智能化程度，确保流程闭环，兼顾风险和效率；
▲技术工具：统一运维平台（门户），可编排的流程引擎、集中事件平台、蓝图系统、应用自动发布系统、多中心切换
这个阶段已经进入平台化和体系化阶段，需要将整体的平台建设和实施分离，平台建设的要点在于提供技术组件和经过检验的运维场景；实施则侧重于按照最佳实践进行各种调整，开发相应的服务。
◇ 双模DCOS的IT运营平台（更高、更快、更智能）
运营指挥平台，脱离IT自身的诉求，以业务为中心，探索新的方向，寻求技术和业务的融合。强身健体之后，寻求新的奋斗目标，挑更重的担子，多接几家活，或者推动业务跑的更快
▲人员组织：整个IT部门作为一个整体考虑，建立起专业的服务支持和服务运营团队，从开发运维衔接到开发运维融合，；
▲流程制度：针对不同类型和不同级别的业务，制定不同的流程和安全制度，健全的SLA和多租户的成本考核指标；
▲技术工具：运营指挥平台、故障根源分析、运维大数据分析、应用财务模型等。
五、开源自动化运维软件选型建议
最后谈一下基础的运维自动化产品选型建议，四大传统厂商的自动化软件大都是15年之前的产品，产品老化很严重，已经进入替换期；BAT这样的大型互联网公司又大都是自研。目前对大部分企业用户而言，选择装机量比较大的开源产品，是一个比较好的选择。2012年时根据银行的自动化运维需求，做了几个开源产品的对比，当时的结果如下：
时隔4年今天再看，Puppet即将上市，CFEngine确实老了，Chef的用户还是国外，Saltstack和2013年发布的Ansible发展迅速，。今天国内的用户主要是在Puppet、Saltstack、Ansible三者之间选择，这三款软件都具有配置自动化和操作自动化的功能。
Puppet的优点是最为成熟，广泛适配各种操作系统，支持各种私有云和公有云，生态也较为成熟，支持4000多个模块的配置管理；缺点是使用门槛较高。Saltstack和Ansible则是参考了Puppet的一些实践，在易用性和技术架构实现上有优势。值得一提的是，Ansible的一大优势是无代理，不需要安装agent，但这是优点也是缺点，对一部分安全要求较高的客户，就需要在服务端的认证和安全合规上花更大的精力。
简单的来说，软硬件和操作系统复杂、对于配置管理和安全要求高的大中型企业用户建议优先选择Puppet；操作系统标准化程度高、尽快实现操作自动化的互联网和中小型企业可优先选择Saltstack和Ansible。但无论最终选择哪个软件都只是起点，用好工具更关键，从操作自动化走向配置自动化，从运维自动化走向运行自动化，不断提升自身的运维成熟度，才能真正实现把运维变成“运筹帷幄”。
联系客服
