随着互联网蓬勃发展，各公司对用户体验、数据安全、系统可靠性等运营指标的更加重视，运维部门的工作显得愈发的重要。同时，在运维行业的多年发展和积累下，也逐渐形成了高效自动化运维的体系，而一个实用的自动化运维平台也成为了新一代IT基础运维体系实施的重要基础。

本文将通过对运维的阶段，当下面临的主要问题，以及自动化运维平台的模型剖析来为大家一步步揭开自动化运维平台的面纱。

企业运维的四个阶段

1、人人运维

在一家公司发展的初期，基础设施尚未达到一定规模时候，公司未必会设立专门的运维部门或者专员来处理系统运维工作，而是将运维工作分担到各类岗位中。

大部分时候这类工作都分散到了研发人员头上，比如研发人员各自管理运维及自己研发应用所用的服务。在这个阶段，公司可以在运维上节约一定成本和注意力，但是这种方式在出现事故后的应急处理是存在很大问题的，并且无法维护大规模的系统。

2、规范运维

随着业务的增长，IT设施也发展到更大规模的量级，这时组建一个内部专门的运维人员团队或者与外部专业的运维服务提供商合作就成了一件势在必行的工作。

当拥有了专门的运维团队后，日常的运营维护工作就变得有一定规范，并且可以实现在自己业务范围内适用的自动化了。

但是当运维发展到了这个阶段时，还是会面临一些问题与挑战，比如选择哪种技术和工具去完成相应的运维工作，按照什么样的标准去完成对服务器，各类基础服务的配置？如何把一些工作流程化使用技术手段实现自动化等等。

3、自动化系统

建立在各类开源技术以及自己研发的脚本和工具上，自动化运维系统成为了运维人员高效完成日常运维工作的一大法宝。

谷歌，阿里，腾讯等大规模公司除了自身专业运维团队之外，都研发了一套或多套的自动化运维系统来完善运维工作。如自动部署系统、基于CMDB的设备管理系统或是将一些工作流程化的调度系统，它们都为运维带来了巨大的便捷。

可以说，在此时，在各类自动化系统的帮助下，运维工作已经实现了标准化，工具化，系统化。

4、运筹帷幄

当运维工作所需要的基本元素以及自动化系统都准备好了之后，如何进一步将之完善，高效化，流程化，全自动化，从“ 运营维护” 真正的做到 “ 运筹帷幄” ？

除了DevOps这种指导性的开发与运维合作发展理念之外，在技术和运维工作的“ 装备” 上，一套集成各重要自动化系统并将之全部整合、规范、流程化的运维平台就成了运维发展的新阶段。

当下运维面临的问题

据笔者观察和了解，目前在国内除了一些规模化的大企业，大部分中小型企业的运维水平还是停留在前文所介绍的第一及第二阶段，即人人皆运维，或是拥有运维团队和基本运维工具脚本但仍存在众多问题。

如下我列出了目前运维遇到的七大问题，称之为 ” 运维七大痛点“ 。

痛点1：复杂的系统

众所周知，当系统规模发展到一定量级的时候，管理服务器和其他IT基础设备的工作就会变得复杂烦琐起来。最明显的工作就是去收集服务器的信息，工作状况以及服务器上锁安装的资源。

痛点2：混合云环境

随着云计算技术的发展以及可靠性的提高，很多企业和公司都加快了“ 上云” 的步伐。而亚马逊，微软，阿里云等众多IaaS提供商的优质产品，以及私有云技术Openstack的流行和普及，多种选择下的企业开始倾向于使用公私云混合或是多家云一起使用的混合环境模式来搭建系统。

那么在这样一个多元的系统中，没有一个统一管理的界面或平台也成为了运维日常工作的效率的一大障碍。

痛点3：繁多的工具

在开源技术的带动下，业内运维相关的工具可谓层出不穷，从小到简单的自动部署一个配置，大到分析收集所有设备上的资源并跟踪操作记录，都有着不同的方法和工具可以实现。

那面对这样令人眼花缭乱的工具们，运维人员该如何做出选择也成为了一个“幸福的困扰”。

痛点4：人类的错误

运维人员也是人，是人都会犯错。而运维工作作为公司业务的基础，如果在运维上出现了不可逆的人为过错，那么可能会影响到整个公司的业务。所以如何利用标准的流程和自动的调度来减免人为犯错的可能性，也是运维工作需要注意的。

痛点5：人员的流动

笔者认为，运维人员流动对于一家公司的影响其实要比其他技术类岗位带来的麻烦更大。

如果开发人员好比你家负责烧菜的阿姨，那运维人员就是负责你家整理用品的阿姨。烧菜的阿姨每天来烧几个菜就可以完成任务，换一个阿姨来烧也无所谓，但是如果整理用品的阿姨换了，那么你还要给她再做一遍哪些东西在哪、该放在哪里等一些琐碎的背景介绍。

通过这个生活的类比，我们可以看到运维人员的流动其实是很损耗运维团队精力的。

痛点6：运维文档的缺失

一个完善的运维资料库其实可以解决很多问题，比如人员的流动或是对新员工的培养。但现实是：很多公司其实在运维文档上并没有做好太多准备，甚至没有意识到它的重要性。

痛点7：行为跟踪

行为跟踪的重要性可以从两个角度去审视：一是安全，二是排障。

从安全上看，做好行为跟踪可以监控到人员对服务器的操作，对一些敏感性的数据所在服务器显得异常关键；而从排障的角度上看，一旦系统出了故障，一些行为的跟踪记录也可以作为重要的线索来定位及解决问题。

面对以上种种问题，以及运维发展的趋势，自动化运维平台成了运维人员实现高效运维的一种必备武器。在后文中，我们将以一个自动化运维平台的模型来展示我们所谈论和期待使用的自动化运维平台到底是什么样子。

自动化运维平台模型

1、系统概述

笔者认为，一个符合当下运维需求的自动化运维平台，需要包含以下几点基础功能：设计搭建、部署、监测、优化、排障。

在这个基础上，再加入云计算与DevOps的概念和相关技术，实现单一虚拟管理平台的整体系统的全面的运维。下面我们将对这几个功能模块做一个详细的分析。

2、设计、搭建与部署

一个系统从无到有，从零到整，都应遵循合理的流程以及做好详细的历史记录。

首先，我们需要将搭建配置的信息统一整合起来，像提交订单一样存入设计系统。随后，这样一个订单将被传递到搭建系统，搭建系统根据 ” 订单 “ 内容自动从配置服务器中调取相应的配置文件以及安装包。

这时，便是部署系统需要工作的时候了，可以使用似Ansible的工具将配置文件部署在目标服务器后自动部署安装。在这个过程中，也可以将监控系统随同一起部署在目标主机上，为后续的监控工作做好基础。

作为自动化运维的基石CMDB，也应在这里开始发挥起作用。具体讲，这里的CMDB应该包括对服务器基本信息、服务器上资源信息、服务器变更做好统计记录。

这样的设计一方面可以帮助企业相应部门清洗的了解到目前系统的资源利用情况，尤其是那些对业务有重要价值的资源，同时对变更的记录也是很好的排障线索。

此外，值得一提的是，随着Docker技术的不断发展和在企业系统内部日益增长的使用率，CMDB也要记录虚拟机上 Container 的情况，比如Container内的服务和其存在性。这一点，可以利用监控工具来完成，比如Zabbix的Low Level Discovery。

3、系统优化

在一个系统已经成功搭建完成后，再投入生产之前，应该对其做一个全方位的 “体检”。

与其说这一步功能是为了完成对系统的优化，倒不如说是去过滤并解决一些在系统搭建阶段遗留的人为错失，为后续的系统运维达打下良好的基础。

这一部分“体检”，可以通过审计脚本来完成，而这个审计脚本的核心即为一个定期更新的，符合业界标准的，并且可以基本满足自身业务特征的 “ 配置参照物“。

在执行审计的时候，通过脚本将所检查服务器的系统与上层服务的配置信息与规范的标准作比对，后将不符合标准的配置可视化列出便于工程师做出相应处理。

4、监控

在监控方，可以使用类Zabbix的开源技术。深度二次开发可以实现更多的监控点，如对于Hadoop参数的监控，Docker 服务的监控。

此外，二次开发的Zabbix 还可以与平台系统数据库以及一个工单系统做集成。这样，每次系统中的警报都可以被记录在案，并且通过工单系统实现事故排障的流程化，提高工程师的工作效率。

Zabbix 监控

5、排障

在排障的过程中，我们其实可以利用的系统模块应该有很多。比如前文中提到的在CMDB中，我们可以获取到服务器的变更信息，借此查找事故前是否有不良操作。

同时，自动化运维平台也应有服务器管理中心，根据不同的服务器类型抓取服务器上的不同信息，展示其工作情况，比如对数据库的实时信息提取。当然，日志分析也相当重要，所以ELK （ Elastic Search, Logstash, Kibna）也是运维平台中不得缺少的部分。

ELK日志系统

数据库工作信息

6、其他

除上述功能外，一个自动化运维系统还可以包含以下模块：任务管理分配功能、应用层面代码安全扫描功能、各常见公有云入口、备份系统等功能。

小结

伴随着互联网及运维的发展，运维自动化平台的使用将大大加快运维效率，把运维工作高效化，自动化，流程化。无论是自己去设计搭建一个这样的平台也好，还是直接使用三方服务商提供的这样的平台工具来完善自己的运维工作也好，笔者认为都将减轻许多运维负担，把更多的注意力放在公司的业务发展上。（王寒原创）

随着互联网蓬勃发展，各公司对用户体验、数据安全、系统可靠性等运营指标的更加重视，运维部门的工作显得愈发的重要。同时，在运维行业的多年发展和积累下，也逐渐形成了高效自动化运维的体系，而一个实用的自动化运维平台也成为了新一代IT基础运维体系实施的重要基础。

本文将通过对运维的阶段，当下面临的主要问题，以及自动化运维平台的模型剖析来为大家一步步揭开自动化运维平台的面纱。

企业运维的四个阶段

1、人人运维

在一家公司发展的初期，基础设施尚未达到一定规模时候，公司未必会设立专门的运维部门或者专员来处理系统运维工作，而是将运维工作分担到各类岗位中。

大部分时候这类工作都分散到了研发人员头上，比如研发人员各自管理运维及自己研发应用所用的服务。在这个阶段，公司可以在运维上节约一定成本和注意力，但是这种方式在出现事故后的应急处理是存在很大问题的，并且无法维护大规模的系统。

2、规范运维

随着业务的增长，IT设施也发展到更大规模的量级，这时组建一个内部专门的运维人员团队或者与外部专业的运维服务提供商合作就成了一件势在必行的工作。

当拥有了专门的运维团队后，日常的运营维护工作就变得有一定规范，并且可以实现在自己业务范围内适用的自动化了。

但是当运维发展到了这个阶段时，还是会面临一些问题与挑战，比如选择哪种技术和工具去完成相应的运维工作，按照什么样的标准去完成对服务器，各类基础服务的配置？如何把一些工作流程化使用技术手段实现自动化等等。

3、自动化系统

建立在各类开源技术以及自己研发的脚本和工具上，自动化运维系统成为了运维人员高效完成日常运维工作的一大法宝。

谷歌，阿里，腾讯等大规模公司除了自身专业运维团队之外，都研发了一套或多套的自动化运维系统来完善运维工作。如自动部署系统、基于CMDB的设备管理系统或是将一些工作流程化的调度系统，它们都为运维带来了巨大的便捷。

可以说，在此时，在各类自动化系统的帮助下，运维工作已经实现了标准化，工具化，系统化。

4、运筹帷幄

当运维工作所需要的基本元素以及自动化系统都准备好了之后，如何进一步将之完善，高效化，流程化，全自动化，从“ 运营维护” 真正的做到 “ 运筹帷幄” ？

除了DevOps这种指导性的开发与运维合作发展理念之外，在技术和运维工作的“ 装备” 上，一套集成各重要自动化系统并将之全部整合、规范、流程化的运维平台就成了运维发展的新阶段。

当下运维面临的问题

据笔者观察和了解，目前在国内除了一些规模化的大企业，大部分中小型企业的运维水平还是停留在前文所介绍的第一及第二阶段，即人人皆运维，或是拥有运维团队和基本运维工具脚本但仍存在众多问题。

如下我列出了目前运维遇到的七大问题，称之为 ” 运维七大痛点“ 。

痛点1：复杂的系统

众所周知，当系统规模发展到一定量级的时候，管理服务器和其他IT基础设备的工作就会变得复杂烦琐起来。最明显的工作就是去收集服务器的信息，工作状况以及服务器上锁安装的资源。

痛点2：混合云环境

随着云计算技术的发展以及可靠性的提高，很多企业和公司都加快了“ 上云” 的步伐。而亚马逊，微软，阿里云等众多IaaS提供商的优质产品，以及私有云技术Openstack的流行和普及，多种选择下的企业开始倾向于使用公私云混合或是多家云一起使用的混合环境模式来搭建系统。

那么在这样一个多元的系统中，没有一个统一管理的界面或平台也成为了运维日常工作的效率的一大障碍。

痛点3：繁多的工具

在开源技术的带动下，业内运维相关的工具可谓层出不穷，从小到简单的自动部署一个配置，大到分析收集所有设备上的资源并跟踪操作记录，都有着不同的方法和工具可以实现。

那面对这样令人眼花缭乱的工具们，运维人员该如何做出选择也成为了一个“幸福的困扰”。

痛点4：人类的错误

运维人员也是人，是人都会犯错。而运维工作作为公司业务的基础，如果在运维上出现了不可逆的人为过错，那么可能会影响到整个公司的业务。所以如何利用标准的流程和自动的调度来减免人为犯错的可能性，也是运维工作需要注意的。

痛点5：人员的流动

笔者认为，运维人员流动对于一家公司的影响其实要比其他技术类岗位带来的麻烦更大。

如果开发人员好比你家负责烧菜的阿姨，那运维人员就是负责你家整理用品的阿姨。烧菜的阿姨每天来烧几个菜就可以完成任务，换一个阿姨来烧也无所谓，但是如果整理用品的阿姨换了，那么你还要给她再做一遍哪些东西在哪、该放在哪里等一些琐碎的背景介绍。

通过这个生活的类比，我们可以看到运维人员的流动其实是很损耗运维团队精力的。

痛点6：运维文档的缺失

一个完善的运维资料库其实可以解决很多问题，比如人员的流动或是对新员工的培养。但现实是：很多公司其实在运维文档上并没有做好太多准备，甚至没有意识到它的重要性。

痛点7：行为跟踪

行为跟踪的重要性可以从两个角度去审视：一是安全，二是排障。

从安全上看，做好行为跟踪可以监控到人员对服务器的操作，对一些敏感性的数据所在服务器显得异常关键；而从排障的角度上看，一旦系统出了故障，一些行为的跟踪记录也可以作为重要的线索来定位及解决问题。

面对以上种种问题，以及运维发展的趋势，自动化运维平台成了运维人员实现高效运维的一种必备武器。在后文中，我们将以一个自动化运维平台的模型来展示我们所谈论和期待使用的自动化运维平台到底是什么样子。

自动化运维平台模型

1、系统概述

笔者认为，一个符合当下运维需求的自动化运维平台，需要包含以下几点基础功能：设计搭建、部署、监测、优化、排障。

在这个基础上，再加入云计算与DevOps的概念和相关技术，实现单一虚拟管理平台的整体系统的全面的运维。下面我们将对这几个功能模块做一个详细的分析。

2、设计、搭建与部署

一个系统从无到有，从零到整，都应遵循合理的流程以及做好详细的历史记录。

首先，我们需要将搭建配置的信息统一整合起来，像提交订单一样存入设计系统。随后，这样一个订单将被传递到搭建系统，搭建系统根据 ” 订单 “ 内容自动从配置服务器中调取相应的配置文件以及安装包。

这时，便是部署系统需要工作的时候了，可以使用似Ansible的工具将配置文件部署在目标服务器后自动部署安装。在这个过程中，也可以将监控系统随同一起部署在目标主机上，为后续的监控工作做好基础。

作为自动化运维的基石CMDB，也应在这里开始发挥起作用。具体讲，这里的CMDB应该包括对服务器基本信息、服务器上资源信息、服务器变更做好统计记录。

这样的设计一方面可以帮助企业相应部门清洗的了解到目前系统的资源利用情况，尤其是那些对业务有重要价值的资源，同时对变更的记录也是很好的排障线索。

此外，值得一提的是，随着Docker技术的不断发展和在企业系统内部日益增长的使用率，CMDB也要记录虚拟机上 Container 的情况，比如Container内的服务和其存在性。这一点，可以利用监控工具来完成，比如Zabbix的Low Level Discovery。

3、系统优化

在一个系统已经成功搭建完成后，再投入生产之前，应该对其做一个全方位的 “体检”。

与其说这一步功能是为了完成对系统的优化，倒不如说是去过滤并解决一些在系统搭建阶段遗留的人为错失，为后续的系统运维达打下良好的基础。

这一部分“体检”，可以通过审计脚本来完成，而这个审计脚本的核心即为一个定期更新的，符合业界标准的，并且可以基本满足自身业务特征的 “ 配置参照物“。

在执行审计的时候，通过脚本将所检查服务器的系统与上层服务的配置信息与规范的标准作比对，后将不符合标准的配置可视化列出便于工程师做出相应处理。

4、监控

在监控方，可以使用类Zabbix的开源技术。深度二次开发可以实现更多的监控点，如对于Hadoop参数的监控，Docker 服务的监控。

此外，二次开发的Zabbix 还可以与平台系统数据库以及一个工单系统做集成。这样，每次系统中的警报都可以被记录在案，并且通过工单系统实现事故排障的流程化，提高工程师的工作效率。

Zabbix 监控

5、排障

在排障的过程中，我们其实可以利用的系统模块应该有很多。比如前文中提到的在CMDB中，我们可以获取到服务器的变更信息，借此查找事故前是否有不良操作。

同时，自动化运维平台也应有服务器管理中心，根据不同的服务器类型抓取服务器上的不同信息，展示其工作情况，比如对数据库的实时信息提取。当然，日志分析也相当重要，所以ELK （ Elastic Search, Logstash, Kibna）也是运维平台中不得缺少的部分。

ELK日志系统

数据库工作信息

6、其他

除上述功能外，一个自动化运维系统还可以包含以下模块：任务管理分配功能、应用层面代码安全扫描功能、各常见公有云入口、备份系统等功能。

小结

伴随着互联网及运维的发展，运维自动化平台的使用将大大加快运维效率，把运维工作高效化，自动化，流程化。无论是自己去设计搭建一个这样的平台也好，还是直接使用三方服务商提供的这样的平台工具来完善自己的运维工作也好，笔者认为都将减轻许多运维负担，把更多的注意力放在公司的业务发展上。（王寒原创）