企业级应用运维方法及系统

技术领域

本申请涉及服务器运维技术领域，具体涉及一种企业级应用运维方法及一种企业级应用运维系统。

背景技术

随着业务的快速发展，业务类型和业务处理量越来越繁杂，为了适应这种业务的爆发式增长，对应的企业级的应用部署架构也越来越复杂，其规模量也是越来越大，对应的应用发布变更频率也越来越高。针对企业级应用运维，目前主要存在两种方式，分别为人工管理和工具管理。其中，工具管理一般通过多个工具实现对企业级应用的运维管理。如应用部署有专门的部署工具，应用生命周期管理有专门的应用运维工具。这种方式一定程度上解决了人工工作量的问题，也减少了人工操作的复杂度和风险。但依旧存在很明显的缺陷，即首先目前缺少一个工具能够覆盖应用的部署、配置、日常运维等完整的生命周期管理过程，往往是多个工具搭配使用或者工具与人工混合，管理工具新增了工作量和复杂度；然后部署工具一般只适用单个应用模块的部署，目标应用模块依赖其他模块时，依然需要运维人员厘清模块间的依赖关系，再逐一构建部署任务；此外，应用运维工具需要脚本以提供日常运维功能，往往缺少规范来统一管理这些脚本。针对现有企业级应用运维方案存在的脚本统一管理性能差和无法依赖关系导致部署失败的问题，需要创造一种新的企业级应用运维方法。

发明内容

本申请实施例的目的是提供一种企业级应用运维方法及系统，以解决现有企业级应用运维方案存在的脚本统一管理性能差和无法依赖关系导致部署失败的问题。

为了实现上述目的，本申请第一方面提供一种企业级应用运维方法，所述方法包括：获取模块安装包；所述模块安装包为对待部署应用的应用信息打包处理获得；对所述模块安装包进行逐级解析，还原所述应用信息；对解析还原的应用信息进行分类管理并缓存；基于缓存的应用信息，进行对应待部署应用配置，并反馈配置结果。

在本申请实施例中，所述应用信息包括：待部署应用本体、对应的配置文件、配置所述待部署应用所需要的执行脚本和描述规范文件。

在本申请实施例中，所述描述规范文件包括：基础信息，用于描述待部署应用的标识信息；安装信息，用于描述待部署应用的安装流程信息；可执行指令，用于描述待部署应用配置过程中的各可执行指令，以及运维脚本路径；运行环境配置信息，用于描述配置待部署应用需要的运行资源；安装依赖信息，用于描述配置待部署应用需要在先配置的模块；nginx代理配置信息，用于描述nginx代理信息；数据库配置信息，用于描述待部署应用的数据库配置信息；其他配置信息，用于描述用户自定义配置。

在本申请实施例中，所述对所述模块安装包进行逐级解析，包括：进行所述模块安装包解析，获得对应的解析后文件；判断所述解析后文件是否包括以下应用信息：待部署应用本体、对应的配置文件、配置待部署应用所需要的执行脚本和描述规范文件；若所述解析后文件缺失任一种应用信息，则判定当前模块安装包不合规，并重新进行模块安装包下载；若重新下载预设次数后依旧判定模块安装包不合规，则停止重新下载，并输出对应的报警信息；若所述解析后文件未缺失任一种应用信息，则基于预设顺序进行所述描述规范文件逐一解析。

在本申请实施例中，所述基于预设顺序进行所述描述规范文件逐一解析，包括：基于解析基础信息、解析依赖信息、解析数据库配置信息、解析nginx代理配置信息、解析可执行指令、解析安装信息、解析运行环境配置信息、解析其他配置信息的顺序进行所述描述规范文件逐一解析，获得对应的解析信息。

在本申请实施例中，所述对解析还原的应用信息进行分类管理，包括：预设必要信息和非必要信息两种分类结果；其中，必要信息为解析结果中必须包含的信息，非必要信息为解析结果中可不包含的信息；所述必要信息包括：待部署应用本体；对应的配置文件；配置待部署应用所需要的执行脚本；以及描述规范文件中的：基础信息、可执行指令和安装信息；所述非必要信息包括描述规范文件中的：依赖信息、数据库配置信息、nginx配置信息、运行环境信息和其他配置信息。

在本申请实施例中，所述方法还包括：判断解析还原的应用信息中是否存在所有必要信息；若存在必要信息缺失，则终止待部署应用配置流程，并输出报警信息。

在本申请实施例中，所述基于缓存的应用信息，进行对应待部署应用配置，包括：采集待部署应用的目标的剩余资源，基于所述运行环境配置信息判断所述剩余资源是否满足配置需求；若所述剩余资源满足配置需求，则判断是否存在安装依赖信息，并在存在安装依赖信息的情况下基于安装依赖信息进行依赖模块在先配置；基于在先配置模块创造的安装环境，基于所述安装信息进行待部署应用本体配置，并反馈配置完成信号；响应于所述配置完成信号，触发运维管理流程执行指令。

在本申请实施例中，所述运维管理流程包括：基于配置完成的应用，将预设运维脚本下发到预定目录，开放对应的运维操作；查询预设数据库中是否存在配置完成应用的应用数据，若存在，则配置对应的应用数据，并基于预写的sql语句进行所述应用数据的变更；查询预设数库中是否存在配置完成应用的nginx信息，若存在，则基于nginx信息进行所述配置完成应用的反向代理和负载均衡功能配置；配置其他配置信息，基于用户定义配置内容进行剩余内容配置，完成待部署应用部署。

本申请第二方面提供一种企业级应用运维系统，所述系统包括：采集单元，用于获取模块安装包；所述模块安装包为对待部署应用的应用信息打包处理获得；解析单元，用于对所述模块安装包进行逐级解析，还原所述应用信息；处理单元，用于对解析还原的应用信息进行分类管理并缓存；执行单元，用于基于缓存的应用信息，进行对应待部署应用配置，并反馈配置结果。

本申请第三方面提供一种处理器，其特征在于，所述处理器被配置成执行上述的企业级应用运维方法。

本申请第四方面提供一种机器可读存储介质，该机器可读存储介质上存储有指令，该指令在被处理器执行时使得所述处理器被配置成执行上述的企业级应用运维方法。

本申请第五方面提供一种计算机程序产品，包括计算机程序，该计算机程序在被处理器执行时实现上述的企业级应用运维方法。

通过上述技术方案，本发明方案提供了一种企业级应用的描述规范，用以描述应用的各类信息和配置，并在此基础上实现了该描述规范的解析和落地。实现了一次操作即可自动安装应用及其依赖模块，并且在安装完成后支持对应用的生命周期管理，从而减少了人工投入和操作风险，同时将企业级应用的运维工作标准化，提高了运维的效率。

本申请实施例的其它特征和优点将在随后的具体实施方式部分予以详细说明。

附图说明

附图是用来提供对本申请实施例的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本申请实施例，但并不构成对本申请实施例的限制。在附图中：

图1示意性示出了根据本申请实施例的企业级应用运维方法的步骤流程图；

图2示意性示出了根据本申请实施例的企业级应用运维方法的实施过程图；

图3示意性示出了根据本申请实施例的企业级应用运维系统的系统结构图；

图4示意性示出了根据本申请实施例的计算机设备的内部结构图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解的是，此处所描述的具体实施方式仅用于说明和解释本申请实施例，并不用于限制本申请实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明，若本申请实施例中有涉及方向性指示(诸如上、下、左、右、前、后……)，则该方向性指示仅用于解释在某一特定姿态(如附图所示)下各部件之间的相对位置关系、运动情况等，如果该特定姿态发生改变时，则该方向性指示也相应地随之改变。

另外，若本申请实施例中有涉及“第一”、“第二”等的描述，则该“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

随着业务的快速发展，业务类型和业务处理量越来越繁杂，为了适应这种业务的爆发式增长，对应的企业级的应用部署架构也越来越复杂，其规模量也是越来越大，对应的应用发布变更频率也越来越高。就传统方案来说，进行应用部署时，主要存在两大问题：

1)目前大部分应用部署工具仅能发布部署企业级应用自身，对于企业的安装依赖关系(某些应用在部署前，需要在先部署依赖的应用以供创造对应的部署环境)无法分析，所以直接进行应用部署时，往往因为不存在在先部署应用支撑，导致部署失败，也就无法实现从无到有的一键式安装。

2)目前部署工具缺失对应用的生命周期管理的统一标准，也就使得对于部署和运维方案，不存在统一的处理方案，造成部署过程混乱。后续启动、停止、卸载、升级、状态查询等过程无法统一标准调度。

针对企业级应用运维，目前主要存在两种方式，分别为人工管理和工具管理。其中，人工管理为应用开发人员需提前准备部署介质(包括中间件、应用版本文件、部署脚本等)以及相关运维脚本(如启动脚本、停止脚本、卸载脚本、升级脚本，状态查询脚本等)；然后运维人员通过线上或线下方式获取相关文件，并将这些文件传输到目标机器上，然后通过命令安装部署应用版本文件及依赖的数据库和中间件，手动进行参数配置。应用完成部署后，后续与应用运维相关的操作也由运维人员手动操作脚本实现。例如，将所有相关参数收录到一个U盘中，然后由运维人员达到设备现场，将该U盘接入对应的设备，以供设备进行应用安装或升级。这种方式严重依赖运维人员的经验。部署应用时，应用往往依赖多个模块才能正常运行。这要求运维人员能够厘清模块间的依赖关系，才能按照顺序逐一安装模块。安装顺序不对、遗漏子模块都会导致目标模块无法提供正常的业务能力。在应用需要启停、卸载、升级等时，运维人员需要登录目标机器，手动执行运维脚本。而且，这些工作在应用集群场景下工作量和复杂度剧增。

而工具管理一般通过多个工具实现对企业级应用的运维管理。如应用部署有专门的部署工具，应用生命周期管理有专门的应用运维工具。应用部署工具一般通过调用部署脚本实现本应用的安装部署；应用运维工具通过调用相关的运维脚本实现应用的生命周期管理。这种方式一定程度上解决了人工工作量的问题，也减少了人工操作的复杂度和风险。但依旧存在很明显的缺陷，即首先目前缺少一个工具能够覆盖应用的部署、配置、日常运维等完整的生命周期管理过程，往往是多个工具搭配使用或者工具与人工混合，管理工具新增了工作量和复杂度；然后部署工具一般只适用单个应用模块的部署，目标应用模块依赖其他模块时，依然需要运维人员厘清模块间的依赖关系，再逐一构建部署任务；此外，应用运维工具需要脚本以提供日常运维功能，往往缺少规范来统一管理这些脚本。没有规范的工具可用性和易用性大打折扣。

针对现有企业级应用运维方案存在的脚本统一管理性能差和无法依赖关系导致部署失败的问题，创造了一种新的企业级应用运维方法。本发明方案提供了一种企业级应用的描述规范，用以描述应用的各类信息和配置，并在此基础上实现了该描述规范的解析和落地。实现了一次操作即可自动安装应用及其依赖模块，并且在安装完成后支持对应用的生命周期管理，从而减少了人工投入和操作风险，同时将企业级应用的运维工作标准化，提高了运维的效率。

图1示意性示出了根据本申请实施例的企业级应用运维方法的流程示意图。如图1所示，在本申请一实施例中，提供了一种企业级应用运维方法，包括以下步骤：

步骤S10：获取模块安装包。

具体的，进行企业级应用部署和运维时，主要存在的难点为前者涉及到依赖模块时，按照依赖关系顺序安装各模块的复杂度较高，而后者涉及的脚本众多，每个应用可能都有多个脚本，如果不统一管理，运维人员不但难以进行应用的日常运维工作，而且还需要耗费大量精力在维护和管理众多脚本上。本发明方案基于目前企业级应用存在的难点，提出了对应的解决方案，即提出了一种描述规范，用于规范化描述企业级应用的各类信息，使得整个部署过程规范化。

具体的，这些描述规范文件，包括：基础信息，用于描述待部署应用的标识信息；安装信息，用于描述待部署应用的安装流程信息；可执行指令，用于描述所述待部署应用配置过程中的各可执行指令，以及运维脚本路径；运行环境配置信息，用于描述配置所述待部署应用需要的运行资源；安装依赖信息，用于描述配置所述待部署应用需要在先配置的模块；nginx代理配置信息，用于描述nginx代理信息；数据库配置信息，用于描述待部署应用的数据库配置信息；其他配置信息，用于描述用户自定义配置。

在一种可能的实施方式中，这些信息详细部署为：

基础信息，包括应用名称，版本，描述，类型等，应用运维工具通过解析这部分信息获取企业级应用的基本信息。

安装信息，描述如何安装当前应用，包括安装脚本名称和安装参数。应用运维工具通过解析这部分信息调用对应的安装脚本，从而实现企业级应用的安装部署。

可执行指令，描述应用启动、停止、重启，状态查询，卸载等各类可执行指令及实际运行的运维脚本路径。应用运维工具解析这部分信息后，可以提供运维操作功能，点击后触发相应的可执行指令。

运行环境配置，包括内存，cpu等运行时需要的资源。应用运维工具部署应用时需要比较运行环境配置与目标主机的配置，如果目标主机的配置无法满足部署应用所需的配置资源时，则无法部署应用。

安装依赖信息，当前模块所依赖的其他模块，包括模块名称和版本。代理配置，用于描述应用前端代理信息。应用运维工具解析这部分信息，从而获取应用模块的依赖关系，之后才能按照安装顺序逐一安装依赖模块，从而实现一键安装与应用相关的所有模块。

nginx代理配置信息，用于描述nginx代理信息。如果应用使用Nginx进行反向代理或负载均衡，则应用运维工具可以根据这部分信息来设置代理信息。

数据库配置信息，描述应用的数据库配置信息。应用运维工具解析后可以应用的数据库配置，如数据库的类型、数据库名、用户名、密码等。

其他配置信息，描述应用的其他配置信息，如日志文件路径、需关闭的防火墙端口等。如果有个性化的扩展配置，也可以在此自定义。

在设计对应的描述规范文件的同时，还提供了配套的工具系统，该工具系统能够解析描述规范，并依照规范一键安装应用。基于设计的描述规范文件和对应的配套工具，不同应用按照规范提供描述规范文件，应用运维工具解析描述规范文件后，获得应用的安装脚本以及依赖模块信息，从而实现应用模块及其依赖模块的自动安装；同时在应用运维工具中可以触发应用的可执行指令，调用实际运维脚本，从而实现应用的日常运维工作。

基于此，进行安装包封装时，需要将这些对应的配置所述待部署应用所需要的执行脚本和描述规范文件与待部署应用本体一并压缩整合。然后在需要执行对应待部署应用配置时，向对应的主机下发配置指令，该主机进行模块安装包下载。该模块安装包为基于待部署应用的应用信息打包处理获得的模块安装包。其中，应用信息包括：待部署应用本体、对应的配置文件、配置所述待部署应用所需要的执行脚本和描述规范文件。

步骤S20：对所述模块安装包进行逐级解析，还原所述应用信息。

具体的，进行所述模块安装包解析，获得对应的解析后文件；判断所述解析后文件是否包括待部署应用本体、对应的配置文件、配置所述待部署应用所需要的执行脚本和描述规范文件；若所述解析后文件缺失任一种应用信息，则判定当前模块安装包不合规，并重新进行模块安装包下载；若重新尝试下载预设次数后，依旧判定模块安装包不合规，则停止重新尝试下载，并输出对应的报警信息；若所述解析后文件未缺失任一种应用信息，则基于预设顺序，进行所述描述规范文件逐一解析。

在本发明实施例中，数据在进行传输时，可能因为网络故障等原因造成数据缺失，若进行模块安装包传输时，产生了这种数据缺失，其势必会造成后续部署失败的问题。进一步的，本发明方案解决对应技术问题的核心在于提出了描述规范文件，所以在进行模块安装包解析时，需要保证解析文件中存在对应的描述规范文件，后续均需要基于该描述规范文件进行部署。所以，当判断解析文件中不存在待部署应用本体、对应的配置文件、配置所述待部署应用所需要的执行脚本和描述规范文件时，表示后续的部署方案将无法按照预期执行，则停止进行后续的部署方案。进一步的，因为造成数据缺失可能是偶发原因，当然也可能是整理模块安装包本身存在问题，为了排除偶发原因，执行多次重新尝试下载以及解析，若经过预设次数重新尝试后，依旧判定模块安装包存在问题，则输出对应的报警信息，告知用户进行故障排查。

进一步的，基于解析基础信息、解析依赖信息、解析数据库配置信息、解析nginx代理配置信息、解析可执行指令、解析安装信息、解析运行环境配置信息、解析其他配置信息的顺序进行所述描述规范文件逐一解析，获得对应的解析信息。

步骤S30：对所述应用信息进行分类管理并缓存。

具体的，因为不同的待配置应用存在不同的描述规范文件，所以并非所有的待配置应用均具有依赖应用或对运行环境存在要求，针对不同待部署应用的差异性，本发明方案提出了一种应用信息分类方法。即预设必要信息和非必要信息两种分类结果；其中，必要信息为解析结果中必须包含的信息，非必要信息为解析结果中可不包括的信息；所述必要信息包括：待部署应用本体、对应的配置文件、配置所述待部署应用所需要的执行脚本；以及描述规范文件中的：基础信息、可执行指令和安装信息；所述非必要信息包括描述规范文件中的：依赖信息、数据库配置信息、nginx配置信息、运行环境信息和其他配置信息。

在一种可能的实施方式中，解析应用模块的基础信息，主要包括模块的名称，类型，版本，作者，描述等。其中名称，版本，类型为必填项，其他为可选项，必填项如果不存在，则直接终止解析。然后解析应用模块的依赖信息，主要包括依赖模块的名称，版本等，例如存在四个依赖模块，则安装应用模块时会按顺序安装这四个模块，依赖可以穿透，即如果当前依赖模块也存在它所需要的依赖，则优先安装依赖的依赖。依赖信息为可选，如果不填写，则直接安装应用模块。进一步的，解析数据库配置信息，配置该应用模块连接数据库的类型、名称、用户名和密码，数据库相关配置为可选项。进一步的，解析nginx配置信息，nginx相关配置为可选项，只有选择nginx进行反向代理或负载均衡时才需要填写。Nginx配置不在此展开。进一步的，解析可执行指令，可执行指令为必选项，开发人员需要配置可执行指令实际调用的脚本和参数，如果没有配置则解析失败，直接退出解析，可执行指令一般包括启动、停止、重启、状态查询、卸载。进一步的，解析安装信息。安装信息为必选项，如果没有配置则解析失败，直接退出解析。安装信息包括是否使用root权限，安装的集群节点数，安装命令和参数等。进一步的，解析运行环境信息，运行环境信息为可选项，说明了安装本模块需要的CPU核数以及运行内存等环境资源。进一步的，解析其他配置信息，可选项，说明了其他配置信息，包括日志文件的路径和需关闭的防火墙端口等，这部分配置可自定义扩展。如果以上解析步骤无误，则将解析的信息存放到数据库，为后续的安装和配置流程做准备。

步骤S40：基于缓存的应用信息，进行对应待部署应用配置，并反馈配置结果。

具体的，采集待部署应用的目标的剩余资源，基于所述运行环境配置信息判断所述剩余资源是否满足配置需求；在所述剩余资源满足配置需求时，判断是否存在安装依赖信息，并在存在安装依赖信息时，基于安装依赖信息进行依赖模块在先配置；基于在先配置模块创造的安装环境，基于所述安装信息进行待部署应用本体配置，并反馈配置完成信号；响应于所述配置完成信号，触发运维管理流程执行指令。

优选的，所述运维管理流程包括：基于配置完成的应用，将预设运维脚本下发到预定目录，开放对应的运维操作；查询预设数据库中是否存在配置完成应用的应用数据，若存在，则配置对应的应用数据，并基于预写的sql语句进行所述应用数据变更；查询预设数库中是否存在配置完成应用的nginx信息，并在存在所述nginx信息时，基于nginx信息进行所述配置完成应用的反向代理和负载均衡功能配置；配置其他配置信息，基于用户定义配置内容进行剩余内容配置，完成待部署应用部署。

在一种可能的实施方式中，通过以下步骤进行待部署应用配置：

1)首先检查应用模块的运行环境信息与需要安装模块的主机的剩余资源。一般来说检查CPU核数以及内存。如果主机上剩余资源大于安装应用模块需要的资源，则可以安装，否则无法安装，需要重新选择主机。若当前主机不存在备用主机，则对应进行当前逐级无用缓存数据清楚，扩充剩余资源，保证当前待部署应用模块配置。

2)在数据库中查找应用模块的依赖关系。如果应用模块存在依赖模块，则进入步骤3)安装依赖模块。如果不存在依赖模块，则进入步骤4)安装应用模块。

3)此处实际上是调用依赖模块的安装和配置流程，即依赖模块也需要按照应用模块的要求准备安装包以及描述规范文件等。因为依赖模块与待部署应用一样，均是在主机中部署的预设应用，所以基于本发明方案提出的部署方案进行依赖模块部署，同样可以实现依赖模块的一键部署。安装完依赖模块后，回到步骤2)继续判断是否还有其他依赖模块，并在判断存在其他依赖模块时，重复该步骤，直到所有依赖模块配置完毕。

4)在数据库中查找应用模块的安装信息，然后使用对应的用户调用安装命令，进行应用模块的安装。

5)安装完成后，将应用的运维脚本下发到指定目录。后续在页面上即可触发相应的运维操作，实现应用的生命周期管理。

6)如果数据库中能够查到应用的数据库信息，则开始配置应用的数据库，并且可以执行预先写好的sql语句实现数据库的变更操作。

7)如果数据库中能够查到nginx信息，则可以配置应用的反向代理和负载均衡等功能。

8)配置应用的其他信息，包括日志路径、需关闭的防火墙端口等等。

图2为一个实施例中企业级应用运维方法的流程示意图。应该理解的是，虽然图2的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图3所示，提供了一种企业级应用运维系统，所述系统包括：采集单元，用于获取模块安装包；所述模块安装包为对待部署应用的应用信息打包处理获得；解析单元，用于对所述模块安装包进行逐级解析，还原所述应用信息；处理单元，用于对解析还原的应用信息进行分类管理并缓存；执行单元，用于基于缓存的应用信息，进行对应待部署应用配置，并反馈配置结果。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。

本申请实施例提供了一种存储介质，其上存储有程序，该程序被处理器执行时实现上述企业级应用运维方法。

本申请还提供一种处理器，其特征在于，所述处理器被配置成执行根据上述的企业级应用运维方法。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图4所示。该计算机设备包括通过系统总线连接的处理器A01、网络接口A02、存储器(图中未示出)和数据库(图中未示出)。其中，该计算机设备的处理器A01用于提供计算和控制能力。该计算机设备的存储器包括内存储器A03和非易失性存储介质A04。该非易失性存储介质A04存储有操作系统B01、计算机程序B02和数据库(图中未示出)。该内存储器A03为非易失性存储介质A04中的操作系统B01和计算机程序B02的运行提供环境。该计算机设备的网络接口A02用于与外部的终端通过网络连接通信。该计算机程序B02被处理器A01执行时以实现一种企业级应用运维方法。

本领域技术人员可以理解，图4中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，本申请提供的企业级应用运维系统可以实现为一种计算机程序的形式，计算机程序可在如图4所示的计算机设备上运行。计算机设备的存储器中可存储组成该企业级应用运维i痛的各个程序模块，各个程序模块构成的计算机程序使得处理器执行本说明书中描述的本申请各个实施例的企业级应用运维方法中的步骤。

本申请还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行上述的企业级应用运维方法。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。