浅谈自动化运维设计思想

转载本文，主要原因在于本文对于“自动化运维”理解深入，如果原作者所在公司真能够做到文中描述，那么其运维水平已经不次于百度，在部分层面比百度要好，学习了。

传统运维的弊端：

1. 由人来发起运维事件，运维人员被动、效率低

2. 系统异构性大，缺乏高效的运维流程

3. 随着云计算大数据的爆发带来更大的困难，极度缺乏一套高效的运维工具。

由于这些问题的存在，自动化应该遵循四化原则：管理体系化、工作流程化、人员专业化、任务自动化。

以监控作为自动化运维的核心概念

运维工作效率不高，主要原因是响应速度。由于大量的人员长期盯着报警页面，等待故障，然后通知相应人员。所以在生产系统中，需将服务器的状态监控作为自动化运维的核心问题。下图为自动化运维平台处理流程图，由监控来驱动运维事件的发起、处理、和结束，由ElkStack 、Zabbix 和 Zabbix-Agent来获取到服务器的日常工作状态和服务信息，并生成时序统计图等用于成果分析。

通过精准有效的报警策略做到专业的事由专业的人去做。生产系统已经实现了邮件、微信、短信告警等功能，可以根据故障类型和影响级别及时通知到相应人员，并且可以根据SLA进行事件升级。后续还可以针对微信平台进行持续开发，提供更多功能，比如说模板化处理机制的问题。

举个例子，服务器的磁盘占用率达到百分九十的时候，告警也会自动通过微信通知到相应的处理人员，这时候处理人员只需采取从微信中选择，并操作对应的清理垃圾模板，如：数据修复模板、清理历史日志模板等，进行清理作业即可。

以模板化部署为自动化运维的必备利器

对于运维工程师来说，真正意义上维护服务器的工作并不算繁重，真正繁重的应该是环境的部署，有的时候环境实施部署会占据到运维工作百分之八十以上的时间。由于操作系统版本的不统一，手动且随意的初始化系统环境，不同软件包的版本更新等一系列的问题，会导致工程师部署运维工具或公司产品时，总会出现各种各样非常奇妙的囧境。

所以我将模板化部署作为自动化运维的第二块内容，下图为自动化运维平台流程范例。通过cobber可以模板化操作系统，系统初始化配置，软件包版本控制，从而做到整个计算机集群基础环境完全一模一样。减少了因为基础环境不同而导致部署错误。

当然仅仅是系统的模板标准化还远远不够，我们还可以通过结合Ansible Playbook 将运维常用的工具脚本化，这样不仅仅是为了减少人为因素的出错点，更可以通过批量执行大大的提高工作效率。同时还可以通过Ansible 进行并行的配置管理。

在我设计的运维平台中有两个核心组件，分别是告警调度引擎（messageserver）和事件调度引擎（jobserver），告警调度引擎主要作用于分析日常报警信息，通过报警事件、时间、机器、类别等维度生成图表。事件调度引擎的主要功能是根据相应的告警项目，自动处理事件从而实现自动化运维的目的。

自动化技术思想

有了上述的几张图和方案相信运维的大部分效率是可以带动起来的。但是这真的就是自动化吗？当然不是，自动化运维不仅仅是工具上的革新，更多的是思想上的转变，流程上的优化，这将会是一个持续改进的过程。

首先，运维需要规范化流程化。其次，运维工具容器化，将常用的运维工具和公司产品构建到容器或者VM中，尽量减少部署时间。再次，日常维护需脚本化，通过配置管理工具实现自动配置维护，并且尽量减少人工的处理与参与。最后，是自动化。

我认为一个真正的自动化运维平台并不只是通过人或者通过技术去减少人工的参与成本，而是需要和运维产品相结合，最终做到智能运维。这样的话产品本身就可以做到自维护，从而形成一个完整的个体。

我们在自动化运维平台建设的多年实践中，往往花时间最多的是在运维流程优化、权限控制、日志审核、等功能上。后期我们还整合了跳板机的功能并应用整合到我们的自动化运维平台中。

现在部署一套环境仅需要二十分钟。100台服务器同时上线效率提高了35倍。环境日常维护或者应用部署上线已经很少在登陆到单独的节点上去操作，只要通过系统统一的平台操作基本都能搞定。我想或许自动化运维只是Ops到DevOps转型所衍生出的一种特性吧,未来将走向全面智能运维时代。众号