CN112540771A - 自动化运维方法、系统、设备和计算机可读存储介质 - Google Patents

Abstract

本申请提出自动化运维方法、系统、设备和计算机可读存储介质。其中，方法包括：接收第一用户端针对目标应用的上线请求，根据上线请求创建上线任务；上线任务包括各个任务节点对应的用户端和任务流程；根据任务流程执行上线任务，获取上线任务的执行结果；根据最终执行结果，确定目标应用的上线结果。通过制定上线任务的流程，对应用上线任务的统一管理，保证应用上线的有序进行，同时减少交接工作量，提高工作效率。

Description

自动化运维方法、系统、设备和计算机可读存储介质

技术领域

本申请涉及计算机领域，尤其涉及自动化运维方法、系统、设备和计算机可读存储介质。

背景技术

应用的上线工作流程冗杂繁琐，参与上线的人员较多，工作交接频繁。传统的应用上线全程依靠人工，缺乏统一的流程管理，工作对接耗时且容易出错，严重影响工作效率。

发明内容

本申请实施例提供自动化运维方法、系统、设备和计算机可读存储介质，以解决相关技术存在的问题，技术方案如下：

第一方面，本申请实施例提供了一种自动化运维方法，包括：

接收第一用户端针对目标应用的上线请求，根据所述上线请求创建上线任务；所述上线任务包括各个任务节点对应的用户端和任务流程；

根据所述任务流程执行所述上线任务，获取所述上线任务的执行结果；

根据所述执行结果，确定所述目标应用的上线结果。

在一种实施方式中，所述根据所述任务流程执行所述上线任务，包括：

在测试环境中部署所述目标应用的上线版本，运行所述上线版本以获取运行结果；将所述上线任务推送至所述第二用户端，接收所述第二用户端的测试结果；

在所述运行结果正常且所述测试结果为通过的情况下，在生产环境中部署所述上线版本。

在一种实施方式中，还包括：

在确定所述上线结果为完成上线的情况下，监控所述目标应用的健康程度；

当所述健康程度低于预设健康阈值时，返回上线失败通知至所述第一用户端；

当接收到所述第一用户端的回滚请求时，回滚所述历史成功上线版本。

在一种实施方式中，还包括：

收集至少一个报警信息；

根据预先存储的报警信息的级别和各个用户端的订阅映射关系，将所述报警信息发送给对应的用户端。

在一种实施方式中，所述报警信息的内容包括报警时间、报警次数、报警原因和报警严重程度中的至少一项。

在一种实施方式中，部署所述目标应用的上线版本的过程包括：

发送部署消息至消息队列，以使自动部署模块监听来自于所述消息队列中的所述部署消息，并根据所述部署消息的类型触发对应的部署动作；

其中，所述部署消息的类型为第一类型时，触发的部署动作包括克隆或更新目标应用仓库、打包应用容器引擎镜像、将上线版本上传至应用容器引擎镜像仓库和在容器集群管理平台中执行部署或更新已有部署；

所述部署消息属于第二类型时，触发的部署动作包括克隆或更新目标应用的仓库和执行上线命令。

在一种实施方式中，所述回滚历史成功上线版本的过程包括：

发送回滚消息至消息队列，以使自动部署模块监听来自于所述消息队列中的所述回滚消息，并根据所述回滚消息的类型触发对应的回滚动作，以完成所述回滚历史成功上线版本；

其中，所述回滚消息的类型为第三类型时，触发的回滚动作包括在容器集群平台中选择所述历史成功上线版本和回滚选择的所述历史上线版本；

所述回滚消息属于第四类型时，触发的回滚动作包括仓库回滚和执行回滚命令。

在一种实施方式中，还包括：

接收所述目标应用所在第一集群的监控数据；若所述监控数据不符合预设条件，则将所述目标应用从所述第一集群调度至可用的第二集群；

或者，若接收到针对所述目标应用的集群调度请求，则根据所述集群调度请求将所述目标应用从第一集群调度至第二集群。

第二方面，本申请实施例还提供一种自动化运维系统，包括：

自动化运维装置，用于根据所述上线请求创建上线任务；所述上线任务包括各个任务节点对应的用户端和任务流程；根据所述任务流程执行所述上线任务，获取所述上线任务的执行结果；根据所述执行结果，确定所述目标应用的上线结果；

至少一个用户端，用于接收用户操作并发送给所述自动化运维装置，所述用户操作包括发起上线请求和各个所述任务节点的用户操作。

在一种实施方式中，还包括：

监控模块，用于收集报警信息，并根据预先存储的报警信息的级别和用户端的订阅映射关系，将所述报警信息发送给对应的用户端；

应用部署模块，用于监听所述自动化运维装置在执行所述上线任务时发送至消息队列中的部署消息，并根据所述部署消息的类型触发对应的部署动作；

集群调度模块，用于接收所述目标应用所在第一集群的监控数据；若所述监控数据不符合预设条件，将所述目标应用从所述第一集群调度至可用的第二集群；还用于若接收到针对所述目标应用的集群调度请求，则根据所述集群调度请求将所述目标应用从第一集群调度至第二集群。

第三方面，本申请实施例提供了一种自动化运维设备，该设备包括：存储器和处理器。其中，该存储器和该处理器通过内部连接通路互相通信，该存储器用于存储指令，该处理器用于执行该存储器存储的指令，并且当该处理器执行该存储器存储的指令时，使得该处理器执行上述各方面任一种实施方式中的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质存储计算机程序，当计算机程序在计算机上运行时，上述各方面任一种实施方式中的方法被执行。

上述技术方案中的优点或有益效果至少包括：制定上线任务的流程，对应用上线任务的统一管理，保证应用上线的有序进行，同时减少交接工作量，提高工作效率。

上述概述仅仅是为了说明书的目的，并不意图以任何方式进行限制。除上述描述的示意性的方面、实施方式和特征之外，通过参考附图和以下的详细描述，本申请进一步的方面、实施方式和特征将会是容易明白的。

附图说明

在附图中，除非另外规定，否则贯穿多个附图相同的附图标记表示相同或相似的部件或元素。这些附图不一定是按照比例绘制的。应该理解，这些附图仅描绘了根据本申请公开的一些实施方式，而不应将其视为是对本申请范围的限制。

图1为根据本申请实施例的自动化运维方法的流程图；

图2为根据本申请实施例的自动化运维方法中，步骤S102的流程图一；

图3为根据本申请实施例的自动化运维方法中，步骤S102的流程图二；

图4为根据本申请实施例的自动化运维方法中，监控报警信息的流程图；

图5为根据本申请实施例的自动化运维系统的结构框图；

图6为根据本申请实施例的自动化运维设备的结构框图。

具体实施方式

在下文中，仅简单地描述了某些示例性实施例。正如本领域技术人员可认识到的那样，在不脱离本申请的精神或范围的情况下，可通过各种不同方式修改所描述的实施例。因此，附图和描述被认为本质上是示例性的而非限制性的。

图1示出根据本申请实施例的自动化运维方法的流程图。该自动化运维方法适用于对应用的运维管理，应用又可以称为应用程序。如图1所示，该自动化运维方法可以包括：

S101、接收第一用户端针对目标应用的上线请求，根据上线请求创建上线任务；上线任务包括各个任务节点对应的用户端和任务流程；

S102、根据任务流程执行上线任务，获取上线任务的执行结果；

S103、根据执行结果，确定目标应用的上线结果。

通过制定上线任务的流程，对应用上线任务的统一管理，保证应用上线的有序进行，同时减少交接工作量，提高工作效率。

步骤S102中任务流程可以为上线任务中各个任务节点的活动流向顺序，任务流程可以规定各个节点的传递方向和次序，还可以规定各个节点之间的交接标准。假设执行任务包括自动化测试节点、测试人员补充测试节点和审批节点；那么任务流程可以规定传递方向为：自动化测试节点→测试人员补充测试节点→上线节点，以及规定如自动化测试节点的结果为运行正常才传递至测试人员补充测试节点此类的交接标准。

在一种实施方式中，上述方案可以应用自动化运维装置，自动化运维装置连接至少一个用户端，用户端可以作为用户对上线资源操作统一入口。自动化运维装置还连接应用的测试环境和生产环境，通过自动化运维装置可以对测试环境和生产环境进行代码搭建、部署、重启和回滚等操作。

在一种实施方式中，用户端所提供的页面上提供图形报表展示各个应用的信息。另外，用户端还可以管理用户权限、审批部署工作和记录操作。

在一种实施方式中，在步骤S101之前，接收用户端的应用添加信息，对应用添加信息进行存储。其中，应用添加信息包括仓库地址、应用名称和应用上线分类中的至少一种。完成添加的应用信息可以列表的形式展示在用户端的页面中。

在一种实施方式中，步骤S101的上线请求可以包括上线动作信息，上线动作信息可以包括目标应用的名称信息、目标应用的标签(Tag)号信息、本次更新内容以及与本次上线相关的用户端信息中的至少一种。示例，用户端通过接收用户在显示页面录入或选择的信息来得到上线动作信息，在接收到用户点击申请上线按键的情况下，根据上线动作信息生成上线请求并发送给自动化运维装置。第一用户端可以为开发端，即由开发人员的账户登录的用户端。

通过上述方案，用户可以直接在用户端发起上线请求，无需另外再撰写邮件或者进行线下对接，减少用户的工作量。

在一种实施方式中，参见图2，步骤S102，包括：

S201、在测试环境中部署目标应用的上线版本，运行上线版本以获取运行结果；

S202、将上线任务推送至第二用户端，接收第二用户端的测试结果；

S203、在运行结果正常且测试结果为通过的情况下，在生产环境中部署上线版本。

其中，测试环境(Testing environment)是指测试运行其上的软件和硬件环境的描述，以及任何其它与被测软件交互的软件。测试环境包括为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据等。

生产环境包括正式提供对外服务的环境，一般会关掉错误报告，打开错误日志。生产环境可以理解为包括所有的功能的环境，任何项目所使用的环境都以这个为基础，然后根据客户的个性化需求来做调整或者修改。

在一种实施方式中，当上线任务推送至对应的用户端时，用户端在任务列表中展示该上线任务。

在另一种实施方式中，步骤S202之后还可以将上线版本在预生产环境中部署运行后，再进入步骤S203。预生产环境作为测试环境到生产环境的过渡。测试环境可能会受到一些限制，一些流程或者数据没有测试到，就可以在预生产环境进行验证，从而保证产品上线质量。

在一种实施方式中，在步骤S102中，在每次获取用户端的测试结果后，还可以包括将上线任务、运行结果和测试结果打包发送给另一用户端，由另一用户端审批通过才进入下一任务节点。

在一种实施方式中，用户通过不同的账户登录用户端形成不同的用户端。例如，将用户端划分为开发端、测试端和审批端。在自动化运维装置中预先限定了不同账户的操作权限，例如测试端开放用户录入应用的上线版本的测试结果的权限，又例如审批端开放用户通过或者拒绝目标应用的上线流程。本实施例中对用户端的划分仅仅为示例，还可以进一步扩展。

参见图3示例，步骤S102可以包括：

S301、在测试环境部署上线版本，运行上线版本以获取第一运行结果；将上线任务推送至测试端，接收测试端的第一测试结果；

S302、在第一运行结果正常和第一测试结果为通过的情况下，将上线任务推送至审批端，获取第一审批结果；

S303、在第一审批结果为通过的情况下，在预生产环境部署上线版本，运行上线版本以获取第二运行结果；将上线任务推送至测试端，接收测试端的第二测试结果；

S304、在第二运行结果正常和第二测试结果为通过的情况下，将上线任务推送至审批端，获取第二审批结果；

S305、在第二审批结果为通过的情况下，在生产环境部署上线版本；

S306、在生产环境部署上线版本后，将上线任务推送至测试端，获取测试端的第三测试结果；若第三测试结果不通过，选择的目标应用的上次成功上线版本进行回滚，结束任务流程。

在一种示例中，步骤S302的审批端为用开发经理所登录的用户端，步骤S304的审批端为运维人员登录的用户端。

在另一种实施方式中，步骤S302之后还可以包括：在第一运行结果不正常和/或第一测试结果为不通过的情况下，返回上线失败通知相关的用户端，结束任务流程。通知的相关的用户端可以为预先设定的，如设定开发端。

同理，步骤S304之后还可以包括：在第二运行结果正常和/或第二测试结果为不通过的情况下，返回上线失败通知相关的用户端，结束任务流程。

在一种示例中，步骤S306中若第三测试结果不通过，选择的目标应用的上次成功上线版本进行回滚，包括：发送第三测试结果不通过的通知至对应运维端，接收运维端的回滚请求，根据回滚请求中所选择的目标应用的上次成功上线版本进行回滚。

在一种实施方式中，在步骤S102的过程中，还包括：记录和存储上线任务中各个任务节点的数据，以便用户端可以查看历史任务节点的数据。自动化运维装置设有数据库，用于存储上线任务中各个任务节点的数据。

在一种实施方式中，在生产环境部署上线版本后，以预设设定的通知方式发送上线结果至与上线任务相关的用户端。通知方式可以包括线上通讯软件、邮箱、短信、电话语音等。

在一种实施方式中，在步骤S103之后，还包括：在确定上线结果为完成上线后，监控目标应用的健康程度；当健康程度低于预设健康阈值时，返回上线失败通知至第一用户端；当接收到第一用户端的回滚请求时，回滚历史成功上线版本。例如，健康程度可以包括……。历史成功上线版本包括在本次上线版本之前成功上线过的多个版本，可以选择退回其中任意一个，或者退回距当前时间最近的一个。

在一种实施方式中，在步骤S102执行上线任务过程中，部署目标应用的上线版本包括：

发送部署消息至消息队列，以使自动部署模块监听来自于消息队列中的部署消息，并根据部署消息的类型触发对应的部署动作；

其中，部署消息的类型为第一类型时，触发的部署动作可以包括克隆或更新目标应用仓库、打包应用容器引擎镜像、将上线版本上传至应用容器引擎镜像仓库和在容器集群管理平台中执行部署或更新已有部署。

部署消息属于第二类型时，触发的部署动作可以包括克隆或更新目标应用的仓库和执行上线命令。

例如，第一类型为Kubernetes应用上线，第二类型为Ansible应用上线。Kubernetes为一种用于管理云平台中多个主机上的容器化的应用。Ansible是一个配置管理和应用部署工具，通过Ansible可以管理云主机。

Kubernetes应用可以为部署于容器中的应用，Ansible应用可以为直接部署在云主机上的应用。

在一种实施方式中，回滚历史成功上线版本的过程包括：

发送回滚消息至消息队列，以使自动部署模块监听来自于消息队列中的回滚消息，并根据回滚消息的类型触发对应的回滚动作，以完成回滚历史成功上线版本；

其中，回滚消息的类型为第三类型时，触发的回滚动作包括在容器集群平台中选择历史成功上线版本和回滚选择的历史上线版本；

回滚消息属于第四类型时，触发的回滚动作包括仓库回滚和执行回滚命令。

例如，第三类型为Kubernetes应用回滚，第四类型为Ansible应用回滚。

需要说明的是，消息队列是一种应用间的通信方式，消息发送后可以立即返回，由消息系统来确保消息的可靠传递。消息发布者把消息发布到消息队列，消息使用者从消息队列中获取消息。示例，消息队列为RabbitMQ消息队列。RabbitMQ是实现了高级消息队列协议的消息代理软件。

一方面，上述实施例触发自动部署和自动回滚的动作，减少了人工部署和回滚的工作量，提高效率且降低出错率。同时采用自动化部署和回滚的方式，可以有效统计部署和回滚的频率及回滚。另一方面，通过消息队列实现部署信息和回滚信息的有序执行，避免消息阻塞。

在一种实施方式中，本实施例还包括监控报警信息的流程，参见图4，该流程包括：

S401、收集至少一个报警信息；其中，报警信息的级别包括云主机级别、网络级别和应用级别；

S402、根据预先存储的报警信息的级别和用户端的订阅映射关系，将报警信息发送给对应的用户端。例如，运维人员订阅主机级别的报警信息，开发人员订阅代码运行错误信息。

在一种实施方式中，报警信息的内容包括报警时间、报警次数、报警原因和报警严重程度中的至少一项。

在一种实施方式中，可以接收用户端报警订阅信息，根据报订阅信息生成报警信息的级别和用户端的订阅映射关系。报警订阅信息包括目标级别信息。比如运维人员订阅主机级别的报警信息，开发人员订阅应用运行的报警信息。

在一种实施方式中，用户端报警订阅信息还包括报警信息接收方式，报警信息接收方式包括邮件、线上通讯软件、邮箱、短信和电话语音中的一种。

上述实施方式中，通过监控模块进行报警信息的汇总，并且针对不同用户端发送对应的报警信息，避免过多报警信息淹没了有用信息。

在一种实施方式中，还包括：接收目标应用所在第一集群的监控数据；若监控数据不符合预设条件，将目标应用从第一集群调度至可用的第二集群。监控数据可以来自监控模块。

示例，自动运维平台可以连接集群调度模块，集群调度模块可以接收监控数据，并且对监控数据的进行计算以识别集群的问题，根据集群的问题的严重等级超过预设等级，则确定监控数据不符合预设条件，进行集群无缝调度，保证了目标应用的高可用性。

在一种实施方式中，还包括：若接收到针对目标应用的集群调度请求，根据集群调度请求将目标应用从第一集群调度至第二集群。示例，当集群内资源不足或者有突发事件导致没有触发自动调度的情况下，用户可以通过用户端发起集群调度请求。

在一种实施方式中，自动化运维装置为基于Django框架所开发的装置。Django是一个开放源代码的Web应用框架，由Python语言写成。

图5示出本发明实施例提供的自动化运维系统的结构框图。参见图5，该自动化运维系统包括：

自动化运维装置501，根据上线请求创建上线任务；上线任务包括各个任务节点对应的用户端和任务流程；根据任务流程执行上线任务，获取上线任务的执行结果；根据执行结果，确定目标应用的上线结果；

至少一个用户端502，用于接收用户操作并发送给自动化运维装置，用户操作包括发起上线请求和在各个任务节点的用户操作。

在一种实施方式中，用户端502还用于展示各个应用的统计分析数据，统计分析数据可以包括每次上线任务中的每一个任务节点和执行结果、应用的回滚次数、指定时间内应用的上线次数、回滚次数最多的应用、回滚次数最多的用户端。

在一种实施方式中，继续参见图5，系统还可以包括：

监控模块503，用于收集报警信息，并根据预先存储的报警信息的级别和用户端的订阅映射关系，将报警信息发送给对应的用户端。

在一种实施方式中，监控模块503集成了Prometheus和Sentry。监控模块503为Prometheus和Sentry配置地址后，通过Prometheus和Sentry抓取报警信息。

Prometheus一般监控主机、应用、网络级别的报警信息，并通过超文本传输协议(HTTP)方式将报警信息发送到自动化运维模块，Prometheus报警信息也可以直接发送到对应的用户端(如运维端)。Sentry用来捕获开发端的用户未捕获的异常信息，同样通过HTTP接口发送到自动化运维平台，并通知与此次异常相关的开发人员。

在一种实施方式中，继续参见图5，系统还可以包括：

应用部署模块504，用于监听自动化运维装置在执行上线任务时发送至消息队列中的部署消息，并根据部署消息的类型触发对应的部署动作；

在一种实施方式中，继续参见图5，系统还可以包括：

集群调度模块505，用于接收目标应用所在第一集群的监控数据；若监控数据不符合预设条件，将目标应用从第一集群调度至可用的第二集群；还用于若接收到针对目标应用的集群调度请求，则根据集群调度请求将目标应用从第一集群调度至第二集群。

上述系统实施例中未详细叙述之处可以参照本申请方法实施例的相关说明，此处不再赘述。

本实施例所提供的自动化运维系统包括如下有益效果：

1.用户可以通过自动化运维系统实现运维操作，例如开发人员可以直接通过自动化运维系统发起上线申请，测试人员可以在自动化运维系统补充测试结果；

2.实现集群管理，包括方便更新代码，提高平台内资源使用率，实现集群的自动化调度，保证应用的可用性；

3.记录和展示应用数据，例如在用户端页面展示上线成功率、失败率、回滚等数据；

4.实现报警信息有效输出，避免有用报警信息淹没；

5.实现应用的自动部署，无需人工部署，提高效率。

图6示出根据本发明实施例的自动化运维设备的结构框图。如图6所示，该自动化运维设备包括：存储器610和处理器620，存储器610内存储有可在处理器620上运行的计算机程序。处理器620执行该计算机程序时实现上述实施例中的自动化运维方法。存储器610和处理器620的数量可以为一个或多个。

该自动化运维设备还包括：

通信接口630，用于与外界设备进行通信，进行数据交互传输。

如果存储器610、处理器620和通信接口630独立实现，则存储器610、处理器620和通信接口630可以通过总线相互连接并完成相互间的通信。该总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral ComponentInterconnect，PCI)总线或扩展工业标准体系结构(Extended Industry StandardArchitecture，EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

可选的，在具体实现上，如果存储器610、处理器620及通信接口630集成在一块芯片上，则存储器610、处理器620及通信接口630可以通过内部接口完成相互间的通信。

本发明实施例提供了一种计算机可读存储介质，其存储有计算机程序，该程序被处理器执行时实现本申请实施例中提供的方法。

本申请实施例还提供了一种芯片，该芯片包括，包括处理器，用于从存储器中调用并运行存储器中存储的指令，使得安装有芯片的通信设备执行本申请实施例提供的方法。

本申请实施例还提供了一种芯片，包括：输入接口、输出接口、处理器和存储器，输入接口、输出接口、处理器以及存储器之间通过内部连接通路相连，处理器用于执行存储器中的代码，当代码被执行时，处理器用于执行申请实施例提供的方法。

应理解的是，上述处理器可以是中央处理器(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signal processing，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现场可编程门阵列(fieldprogrammable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者是任何常规的处理器等。值得说明的是，处理器可以是支持进阶精简指令集机器(advanced RISC machines，ARM)架构的处理器。

进一步地，可选的，上述存储器可以包括只读存储器和随机存取存储器，还可以包括非易失性随机存取存储器。该存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以包括只读存储器(read-onlymemory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以包括随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用。例如，静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic random access memory，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data date SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhancedSDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包括于本申请的至少一个实施例或示例中。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分。并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。

应理解的是，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。上述实施例方法的全部或部分步骤是可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。上述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。该存储介质可以是只读存储器，磁盘或光盘等。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到其各种变化或替换，这些都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (12)

1.一种自动化运维方法，其特征在于，包括：

接收第一用户端针对目标应用的上线请求，根据所述上线请求创建上线任务；所述上线任务包括各个任务节点对应的用户端和任务流程；

根据所述任务流程执行所述上线任务，获取所述上线任务的执行结果；

根据所述执行结果，确定所述目标应用的上线结果。

2.根据权利要求1所述的方法，其特征在于，所述根据所述任务流程执行所述上线任务，包括：

在测试环境中部署所述目标应用的上线版本，运行所述上线版本以获取运行结果；将所述上线任务推送至所述第二用户端，接收所述第二用户端的测试结果；

在所述运行结果正常且所述测试结果为通过的情况下，在生产环境中部署所述上线版本。

3.根据权利要求1所述的方法，其特征在于，还包括：

在确定所述上线结果为完成上线的情况下，监控所述目标应用的健康程度；

当所述健康程度低于预设健康阈值时，返回上线失败通知至所述第一用户端；

当接收到所述第一用户端的回滚请求时，回滚所述历史成功上线版本。

4.根据权利要求1所述的方法，其特征在于，还包括：

收集至少一个报警信息；

根据预先存储的报警信息的级别和各个用户端的订阅映射关系，将所述报警信息发送给对应的用户端。

5.根据权利要求4所述的方法，其特征在于，所述报警信息的内容包括报警时间、报警次数、报警原因和报警严重程度中的至少一项。

6.根据权利要求2所述的方法，其特征在于，部署所述目标应用的上线版本的过程包括：

发送部署消息至消息队列，以使自动部署模块监听来自于所述消息队列中的所述部署消息，并根据所述部署消息的类型触发对应的部署动作；

其中，所述部署消息的类型为第一类型时，触发的部署动作包括克隆或更新目标应用仓库、打包应用容器引擎镜像、将上线版本上传至应用容器引擎镜像仓库和在容器集群管理平台中执行部署或更新已有部署；

所述部署消息属于第二类型时，触发的部署动作包括克隆或更新目标应用的仓库和执行上线命令。

7.根据权利要求3所述的方法，其特征在于，所述回滚历史成功上线版本的过程包括：

发送回滚消息至消息队列，以使自动部署模块监听来自于所述消息队列中的所述回滚消息，并根据所述回滚消息的类型触发对应的回滚动作，以完成所述回滚历史成功上线版本；

其中，所述回滚消息的类型为第三类型时，触发的回滚动作包括在容器集群平台中选择所述历史成功上线版本和回滚选择的所述历史上线版本；

所述回滚消息属于第四类型时，触发的回滚动作包括仓库回滚和执行回滚命令。

8.根据权利要求1所述的方法，其特征在于，还包括：

接收所述目标应用所在第一集群的监控数据；若所述监控数据不符合预设条件，则将所述目标应用从所述第一集群调度至可用的第二集群；

或者，若接收到针对所述目标应用的集群调度请求，则根据所述集群调度请求将所述目标应用从第一集群调度至第二集群。

9.一种自动化运维系统，其特征在于，所述系统包括：

自动化运维装置，用于根据所述上线请求创建上线任务；所述上线任务包括各个任务节点对应的用户端和任务流程；根据所述任务流程执行所述上线任务，获取所述上线任务的执行结果；根据所述执行结果，确定所述目标应用的上线结果；

至少一个用户端，用于接收用户操作并发送给所述自动化运维装置，所述用户操作包括发起上线请求和各个所述任务节点的用户操作。

10.根据权利要求9所述的系统，其特征在于，还包括：

监控模块，用于收集报警信息，并根据预先存储的报警信息的级别和用户端的订阅映射关系，将所述报警信息发送给对应的用户端；

应用部署模块，用于监听所述自动化运维装置在执行所述上线任务时发送至消息队列中的部署消息，并根据所述部署消息的类型触发对应的部署动作；

集群调度模块，用于接收所述目标应用所在第一集群的监控数据；若所述监控数据不符合预设条件，将所述目标应用从所述第一集群调度至可用的第二集群；还用于若接收到针对所述目标应用的集群调度请求，则根据所述集群调度请求将所述目标应用从第一集群调度至第二集群。

11.一种自动化运维设备，其特征在于，包括：包括处理器和存储器，所述存储器中存储指令，所述指令由处理器加载并执行，以实现如权利要求1至8任一项所述的方法。

12.一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至8中任一项所述的方法。

Images