企业级应用运维自动化架构设计与方案实施六大核心问题解读

随着银行业务的快速发展，支撑业务的IT基础设施的变化节奏也大大加快。运维团队担负着对IT基础设施运维的重要使命，核心任务是保障生产安全运营，并提高软硬件环境的交付质量。

运维管理规模的不断扩大，运维人员的不断扩充，使我们的日常运维工作面临更大的压力与风险。

在很长一段时间里，应用运维尝试通过脚本辅助来提升工作效率，但仍然面临着繁重的工作压力：

(1)、管理工作繁重，所管理的资源类型和数量众多，但是缺乏一个准确的整体资源视图。
(2)、生产操作以手工操作为主，在手工操作时存在一些无意的误操作，给生产环境造成操作风险。
(3)、日常巡检仍需由专人负责应用系统相关的日报生成与发布。数据采集缺少统一的管理界面，数据分析工作依赖于管理员个人经验进行，出现问题缺少记录与跟踪。

在运维管理工作中就会出现以下几个主要问题：

(1)、手工操作的风险不可控：日常巡检、服务请求、问题查询都通过登录生产主机进行操作。
(2)、运维工作及时性差异：各运维人员管辖的应用系统、主机数量多，巡检工作以手工为主，无法及时有效地在系统开门前做全面巡检。
(3)、工作规范性不强：新员工对现有的工作制度、工作流程需要一个逐步适应和熟悉的过程。不同人员对应用系统的运维管理工作细致程度存在差异，缺少统一标准。

面临以上问题，企业需要建设一个服务于运维人员的统一管理工作平台——应用自动化运维系统，用来进行日常的生产系统操作任务，隔离运维人员与生产系统的直接接触。

在11月8日的线上交流活动中，围绕着自动化运维的框架、配置管理、应用发布以及自动化中的标准化等方面进行了问题的讨论，也得到了各位专家的支持，大家针对自动化运维相关问题体现出了非常大的热情，在此也对自动化架构设计与方案实施核心问题及大家的观点总结如下：

Q1、自动化运维是个包含了发布、变更、巡检、监控、维护等多个方面的大体系，是需要持续建设的。大体应该分为几个阶段？每个阶段完成哪些功能？如何较好的对接各个已有的运维系统（如监控、CMDB等）？

自动化工具平台建设的阶段划分与企业内现有的运维工作模式有关。在建设过程中，实施推动一般选择可见收益高（领导关注的重点问题）的先动手，出效果再推动周边。

监控系统一般都是必备，是最早的自动化工具。其他方面建设，从技术上，我建议先从配置管理入手，辅助实现发布或变更这类长期需要人工操作的有丰富经验积累的场景入手。在同期可以适当开展监控与自动化的联动功能应用。

各模块关系我们一般提“监、管、控”，也即监控、流程管理与配置管理、自动化，多系统形成联动。

Q2、大型国有企业信息化发展多年，系统、架构、人员都已经适应传统运维方式。但自动化运维是企业信息化发展的必然趋势，企业由传统运维模式专为自动化运维，前期需要做哪些准备工作？

传统企业有着很多的历史资产，人员能力、技术沉淀、设备资产等等，实施自动化运维的过程中会有各方面的困难，在新的环境驱动下需要一些转变。自动化运维不仅仅是一个工具平台，而是从组织、文化、管理和技术几个方面建立一个系统性的能力框架体系，形成一种运维长效机制，为数据中心向运营转型提供支撑能力。

在这样的背景下做自动化运维，更多的是组织内部沟通问题。首先需要有一个前期规划，无论是内部还是外部人员实施规划，都需要对现状做一些分析梳理，建立一个适合企业现状的实施路径很重要。传统国企内部的组织权威性也是挑战之一，必须要获取高层领导的支持（项目管理的干系人），在组织层面至少没有反对，再选择合适的切入点实施。

对于现有人员需要进行充分必要的沟通，对自动化带来的便利性进行宣传，对风险进行揭示和应对，同时为现有组织在自动化实施后带来的变化进行必要的内部沟通讨论，让大多数人能够看到自动化运维带来的便利而不是冲击。

Q3、如何设计自动化运维架构？包括监控如何设计、告警如何设计、备份如何设计、CMDB如何设计，脚本如何管理，主机配置文件如何统一管理和个性配置？

在我们的实践中都是在不同阶段设计实施的。如果是从零开始，有一个设想，但没经过实践。我觉得监控、cmdb都是数据信息的管理，要实现数据的采集和管理，告警是数据分析产生的结果。所以是不是可以建立统一的数据采集层，对所需数据采集；再建立数据管理分析层，对配置数据入配置库，运行数据分析后产生告警（还可以利用算法技术实现告警压缩等等）；然后建立调度层，实现操作命令下发；在这几层之上是一个流程控制，通过流程将各个环节打通形成应用场景，这些应用可以在pc、手机等等终端展现使用。

Q4、应用自动化运维的场景应如何发掘？

自动化运维的场景来源于日常运维的实际工作中，对日常工作归类提取，比如应用发布、应用告警处理、节假日的巡检、关键日的保障，发布就是要进行应用程序的部署，告警处理就是对告警进行一些分析检查、服务重启、服务流控等，节假日巡检和关键日保障就是对系统运行数据进行分析，这些常规运维工作中的需求分析归类后就可以提取出应用发布、运维工具、巡检等场景。

Q5、运维工具Saltstack、Ansible该怎么选择？目前运维工具那么多，Saltstack、Ansible比较热门，怎么选择以及架构如何部署？

运维工具多而且热说明大家的痛点都相同，只是在实践中采取了不同技术路线。对于Saltstack、Ansible我只是做了了解，并没有在实践中使用，但他们与一些商业化产品的思路是相近的：流程+脚本（或API）来实现手工操作自动化。选择适用于自身企业要求的就行，可以考虑企业对于实施成本、产品的支持能力以及企业应用的技术体系适用性（如x86 or 小机 or 主机等）。

在部署上一是要做集群，避免单点、增强可靠性；二是微服务（或者模块化），提供连续服务能力；三是开发测试和生产隔离，避免误操作。

Q6、自动化工具的选型？一般自动化工具有两种实现方式，一种是在客户端部署agent，由平台通知agent进行实现；另一种是建立平台和客户端的互信关系，通过远程执行代码的方式实现。这两种方式有何优劣？在管理几十、几百或者上千个客户端的不同情况下，哪一种方式会更合适？

就目前数据中心设备种类繁多，有服务器、也有些嵌入式操作系统的专有设备、还有网络设备。有些设备不适合部署agent，因此自动化平台搭建的时候需要考虑多种方式管理的兼容。

有agent的产品可以减少网络交互带来的一些影响，无agent的产品对管理对象而言更轻便。

个人建议分不同设备要求，如设备允许情况下使用agent管理。