企业数字化转型，科技先行。国际知名咨询机构如麦肯锡、埃森哲、IDC、IBM等，都在解读数字化定义时提及智能化运营。但要实现智能化，我们还有很长的路要走。
运维部门作为企业科技部门的一部分，在信息化时代的今天，所承受的压力日益渐增。传统的运维模式越来越难以适应业务和IT架构的扩张，运维团队需要寻求突破，来跟上企业变化的步伐。通常来说，企业的运维管理体系分为规范化运维、自动化运维、敏捷化运维和智能化运维四个阶段，其中规范化运维到自动化运维的过渡阶段是大多数企业所在阶段。
随着近年全球运维大会的火热举办，自动化运维话题被推向了前所未有地热度。自动化运维并不是炒作的概念，而是随着信息技术发展的必要趋势。“大数据”、“容器”、“DevOps”、“微服务”……，不断涌现的新技术都有共同的特点，大大增加了运维管理的操作单元数量的同时对系统可用性有更高的可用性要求。从IBM、BMC、HP等传统厂商各类工具产品纷纷面市到Puppet、Ansible、Saltstack等开源解决方案风起云涌，自动化运维已经势不可挡。
01.自动化运维的定义什么是自动化运维？很多人尝试给自动化运维下定义，“数据中心自动化（DCA）”、“开发运营一体化（DevOps）”……，始终无法形成被统一认可的概念。这里笔者对Gartner对自动运维的定义进一步引深：“通过运维工具或平台，实现IT基础设施及业务应用日常任务处理和运维流程的自动化，从而提高效率和降低风险，促进运维组织的成熟和各种能力的升级”，其中：
日常任务处理包括：设备发现、脚本执行、操作系统安装、配置备份、配置检查、配置变更、补丁分析和分发、作业调度等。
运维流程包括：应用发布流程、应用部署流程、变更流程、故障处理流程、灾备切换流程、资源交付流程等。
能力升级包括：变化适应能力、风险应对能力、合规遵从能力、业务运营能力、事件应对能力等。
自动化运维并不是孤立建设和运行的，笔者认为自动化运维是ITOM中的一部分，如下图。
“自动化”、“配置管理”、“监控”是运维管理建设的三驾马车，三者之间即相互独立，也相互联系。笔者在走访很多企业交流过程中，很多人认为这三者之间存在着依赖关系，一定要先落地其中一个才能建设另外一个。这种理解不能说错，只是三者的建设路径其实并没有严格的先后顺序，最好的做法的共同建设，共同迭代。
02.自动化运维的分类我们常听到面向业务的监控或者面向应用的监控，笔者认为自动化也是一样的，可以区分为“面向基础架构的自动化”、“面向应用的自动化”、“面向业务的自动化”。三个分类既有一定的关联性，也是相互独立的，有着各自的目标和场景。
1.面向基础架构的自动化
这里基础架构主要指的是IASS和PAAS这两层。面向基础架构的自动化运维是相对比较容易落地建设的，往往自动化运维也是从基础架构这个类别开始建设的。这个类别的自动化建设的主要目标是解放运维人员的工作量，如把运维工作中的日常巡检、补丁管理、资源创建等内容实现自动化、自助化。
2.面向应用的自动化
顾名思义面向应用的自动化的对象就是以应用为单位，应用中包含了各类的基础架构资源。然而面向应用的自动化并不依赖于基础架构自动化完全落地之后才能建设，在笔者为某单位落地自动化运维时，迈出的第一步就是核心应用系统的更新部署自动化，当时还没有任何基础架构层面的自动化。当然也不是说应用的自动化完全不依赖基础架构，如自动缩扩容、自动部署与配置等对基础架构的自动化程度有较强的依赖性。
3.面向业务的自动化
面向业务的自动化是IT自动化的最终目标，归结到底IT还是为业务提供服务。如果能够将IT自动化建设与业务关联起来，IT服务的价值也能很好的体现出来。当然，面向业务的自动化也有非常高的建设难度，对业务流程、业务关联性的系统化梳理往往不是IT部门能够独立完成的。
很多企业都在探索自动化运维应该怎样开展，目前仍然没有形成相对权威的自动化运维建设路线图。笔者结合“面向基础架构的自动化”、“面向应用的自动化”、“面向业务的自动化”的理念，以及过往的项目经验，斗胆尝试为自动化运维总结一个成熟度模型，如下图。这个层级图表达了一种迭代建设的理念：每部分内容建设都不是一蹴而就的，各部分内容建设也不是强依赖关系。同时笔者认为自动运维的建设的初期应该从下面两点出发：
优先考虑可以立即产生影响的工具，如那些解决重复性工作或冗余性的自动化工具；
衡量自动化应该
转载请注明：http://www.0431gb208.com/sjsbszl/7420.html
