资产自动化管控方法、装置、系统、设备及存储介质与流程

本申请涉及运维技术领域，具体而言，涉及一种资产自动化管控方法、装置、系统、设备及存储介质。

背景技术：

随着信息时代突飞猛进般的持续发展，it运维已经成为it服务中最重要的组成部分。近年来，云计算、大数据等技术日趋成熟，生产应用自动化运维也被推到了风口浪尖。而传统的运维方式是，通过人工登录到待管控的资产上进行运维操作，这种方式对大型计算机集群而言，运维效率十分低下且容易出错，因此对资产进行自动化管控的需求已经迫在眉睫。

技术实现要素：

本申请实施例的目的在于提供一种资产自动化管控方法、装置、系统、设备及存储介质，用以解决相关技术中，对大型计算机集群而言，运维效率十分低下且容易出错的问题。

本申请实施例提供了一种资产自动化管控方法，包括：接收资产管理模块发来的资产变动信息；所述资产变动信息中携带有发生变动的资产的信息；根据所述资产变动信息从预设的操作表中，确定出所述资产变动信息对应的待执行操作；依据所述待执行操作对所述发生变动的资产进行操作。

在上述实现过程中，在接收到资产管理模块发来的资产变动信息后，即可自动根据资产变动信息从预设的操作表中，确定出资产变动信息对应的待执行操作，并依据待执行操作对发生变动的资产进行操作，实现了对资产的自动化运维，可以应用于对大型计算机集群进行运维的场景中。而由于是自动化运维，具有运维效率高，且不易出错的优势。此外，由于本申请实施例中确定出的是与该资产变动信息对应的待执行操作，这也使得后面执行的操作是与接收到的资产变动信息相匹配的，从而提升了对于资产的运维可靠性。

进一步地，所述资产变动信息还携带有所述发生变动的资产的资产状态；所述资产变动信息为新增资产；所述确定出所述资产变动信息对应的待执行操作包括：确定所述资产变动信息对应的待执行操作为，在所述发生变动的资产的资产状态为启用状态时，在所述发生变动的资产上部署监控客户端；所述发生变动的资产为新增的资产。

在上述实现过程中，在进行了资产的新增时，资产管理模块即会发来“新增资产”这一资产变动信息，并同时携带新增的资产的资产状态。进而在新增的资产的资产状态为启用时，即在新增的资产上部署监控客户端，从而实现对新增的资产的监管。整个过程通过资产管理模块发来的资产变动信息自动化触发，并自动化进行部署，实现简单，监控客户端的部署过程简单可靠。

进一步地，所述资产变动信息为所述发生变动的资产的资产状态转变为启用状态；所述确定出所述资产变动信息对应的待执行操作包括：确定所述资产变动信息对应的待执行操作为在所述发生变动的资产上部署监控客户端。

需要说明的是，在本申请实施例中，资产管理模块用于对资产进行管理。在资产的资产信息发生变动时，资产管理模块即会发来资产变动信息。在上述实现过程中，在资产的资产状态转变为启用状态时，资产管理模块即会发来告知这一信息的资产变动信息。此时由于发生变动的资产被启用了，那么即需要对其部署监控客户端进行监管，以便于进行运维。整个过程通过资产管理模块发来的资产变动信息自动化触发，并自动化进行部署，实现简单，监控客户端的部署过程简单可靠。

进一步地，所述资产变动信息还携带有所述发生变动的资产的资产标签；所述资产标签用于标示所述发生变动的资产中待监控的服务；所述在所述发生变动的资产上部署监控客户端包括：在所述发生变动的资产上部署与各所述资产标签对应的所述监控客户端；各所述监控客户端分别用于监控对应的所述资产标签所标示的服务。

应当理解的是，在实际应用过程中，资产可以是服务器等可以提供多种服务的设备。对于这类设备，可以针对所提供的服务进行专门的监管。因此可以在进行资产管理时，为各资产配置相应的资产标签，利用资产标签来标示资产中需要监控的服务。在上述实现过程中，通过在资产变动信息中携带发生变动的资产的资产标签，进而使得在发生变动的资产上部署监控客户端时，可以针对资产标签对应的服务来进行监控客户端的部署，使得对资产的监管更具针对性，使得监管过程中得到的数据更符合实际需要。

进一步地，所述资产变动信息为所述发生变动的资产的资产状态由启用状态转变为非启用状态；所述确定出所述资产变动信息对应的待执行操作包括：确定所述资产变动信息对应的待执行操作为，删除部署在所述发生变动的资产上的监控客户端。

应当理解的是，在实际应用中，资产处于非启用状态时，即表明该资产暂时并未提供服务，因此不需要进行监控。在上述实现过程中，在资产的资产状态由启用状态转变为非启用状态时，即将部署在发生变动的资产上的监控客户端进行删除，从而节约监控资源。

进一步地，所述资产变动信息为所述发生变动的资产的资产标签发生改变；所述资产标签用于标示所述发生变动的资产中待监控的服务；所述确定出所述资产变动信息对应的待执行操作包括：在资产标签发生的改变为资产标签被删除时，确定所述资产变动信息对应的待执行操作为，删除部署在所述发生变动的资产上的监控客户端；删除的所述监控客户端为与被删除的所述资产标签对应的监控客户端；在资产标签发生的改变为新增资产标签时，确定所述资产变动信息对应的待执行操作为，在所述发生变动的资产上部署与新增的所述资产标签对应的监控客户端；在资产标签发生的改变为将资产标签由第一标签改为第二标签时，确定所述资产变动信息对应的待执行操作为，删除部署在所述发生变动的资产上与所述第一标签对应的监控客户端，并在所述发生变动的资产上部署与所述第二标签对应的监控客户端；所述监控客户端用于监控与其对应的所述资产标签所标示的服务。

如前所述，在实际应用中，可以在进行资产管理时，为各资产配置相应的资产标签，利用资产标签来标示资产中需要监控的服务。在上述实现过程中，在资产标签发生改变时，若该改变为资产标签被删除，则将被删除的资产标签对应的监控客户端也删除；若该改变为资产标签的新增，那么则在发生变动的资产上部署与新增的资产标签对应的监控客户端；若该改变为将资产标签由一种标签改为另一种标签，则删除改变前的标签对应的监控客户端，并重新部署改变后的标签对应的监控客户端。这样，即能够根据实际需要实现对监控客户端的自动化部署与删除，使得对资产的监管更具针对性的同时，保证了对监控客户端的有效管理。

进一步的，在依据所述待执行操作在所述发生变动的资产上部署监控客户端时，还包括：将部署的所述监控客户端注册到预设的注册中心。

在上述实现过程中，通过预设的注册中心来对已部署的监控客户端进行注册登记，实现了对已部署的监控客户端的可控化管理。同时，在依据待执行操作在所述发生变动的资产上部署监控客户端时，便将部署的监控客户端注册到预设的注册中心，也实现了对监控客户端的自动化注册。

进一步的，在依据所述待执行操作删除部署在所述发生变动的资产上的监控客户端时，还包括：将被删除的所述监控客户端的注册信息从预设的注册中心中删除。

在上述实现过程中，在删除部署在所述发生变动的资产上的监控客户端时，需要从预设的注册中心将被删除的监控客户端的注册信息删除，实现了对已部署的监控客户端的可控化管理。同时，在依据待执行操作删除部署在发生变动的资产上的监控客户端时，便将被删除的监控客户端的注册信息自动从预设的注册中心中删除，也实现了对监控客户端的自动化管理。

本申请实施例还提供了一种资产自动化管控方法，包括：在资产发生变动时，依据所发生的变动，从预设的操作表中，确定出所发生的变动对应的待执行操作；将发生变动的资产的信息以及所述待执行操作发送给运维管理模块，以供所述运维管理模块依据所述待执行操作对所述发生变动的资产进行操作。

在上述实现过程中，在资产发生变动时，即可自动依据所发生的变动，从预设的操作表中，确定出所发生的变动对应的待执行操作，并将发生变动的资产的信息以及待执行操作发送给运维管理模块，以供运维管理模块依据待执行操作对发生变动的资产进行操作。这就实现了对资产的自动化运维，可以应用于对大型计算机集群进行运维的场景中。而由于是自动化运维，具有运维效率高，且不易出错的优势。此外，由于本申请实施例中确定出的是与该资产变动信息对应的待执行操作，这也使得后面执行的操作是与接收到的资产变动信息相匹配的，从而提升了对于资产的运维可靠性。

进一步的，所述所发生的变动为新增资产；所述确定出所发生的变动对应的待执行操作包括：在所述发生变动的资产的资产状态为启用状态时，确定所述所发生的变动对应的待执行操作为，在所述发生变动的资产上部署监控客户端；所述发生变动的资产为新增的资产。

在上述实现过程中，在进行了资产的新增，且新增的资产的资产状态为启用时，即会指示运维管理模块在新增的资产上部署监控客户端，从而实现对新增的资产的监管。整个过程通过资产管理模块来自动化触发，并由运维管理模块自动化进行部署，实现简单，监控客户端的部署过程简单可靠。

进一步的，所述所发生的变动为所述发生变动的资产的资产状态转变为启用状态；所述确定出所发生的变动对应的待执行操作包括：确定所述所发生的变动对应的待执行操作为在所述发生变动的资产上部署监控客户端。

在上述实现过程中，在资产的资产状态转变为启用状态时，此时即指示运维管理模块在发生变动的资产上部署监控客户端进行监管，以便于进行运维。整个过程通过资产管理模块发来自动化触发，并由运维管理模块自动化进行部署，实现简单，监控客户端的部署过程简单可靠。

进一步的，所述在所述发生变动的资产上部署监控客户端包括：在所述发生变动的资产上部署与所述发生变动的资产的资产标签对应的所述监控客户端；所述资产标签用于标示所述发生变动的资产中待监控的服务；所述监控客户端用于监控对应的所述资产标签所标示的服务。

在上述实现过程中，会指示运维管理模块在发生变动的资产上部署监控客户端时，针对资产标签对应的服务来进行监控客户端的部署，使得对资产的监管更具针对性，使得监管过程中得到的数据更符合实际需要。

进一步的，所述所发生的变动为资产状态由启用状态转变为非启用状态；所述确定出所发生的变动对应的待执行操作包括：确定所述所发生的变动对应的待执行操作为，删除部署在所述发生变动的资产上的监控客户端。

在上述实现过程中，在资产的资产状态由启用状态转变为非启用状态时，即指示运维管理模块将部署在发生变动的资产上的监控客户端进行删除，从而节约监控资源。

进一步的，所述所发生的变动为所述发生变动的资产的资产标签发生改变；所述资产标签用于标示所述发生变动的资产中待监控的服务；所述确定出所述所发生的变动对应的待执行操作包括：在资产标签发生的改变为资产标签被删除时，确定所述所发生的变动对应的待执行操作为，删除部署在所述发生变动的资产上的监控客户端；被删除的所述监控客户端为与被删除的所述资产标签对应的监控客户端；在资产标签发生的改变为新增资产标签时，确定所述所发生的变动对应的待执行操作为，在所述发生变动的资产上部署与新增的所述资产标签对应的监控客户端；在资产标签发生的改变为将资产标签由第一标签改为第二标签时，确定所述所发生的变动对应的待执行操作为，删除部署在所述发生变动的资产上与所述第一标签对应的监控客户端，并在所述发生变动的资产上部署与所述第二标签对应的监控客户端；所述监控客户端用于监控与其对应的所述资产标签所标示的服务。

在上述实现过程中，在资产标签发生改变时，若该改变为资产标签被删除，则会指示运维管理模块将被删除的资产标签对应的监控客户端也删除；若该改变为资产标签的新增，那么则会指示运维管理模块在发生变动的资产上部署与新增的资产标签对应的监控客户端；若该改变为将资产标签由一种标签改为另一种标签，则会指示运维管理模块删除改变前的标签对应的监控客户端，并重新部署改变后的标签对应的监控客户端。这样，即能够根据实际需要实现对监控客户端的自动化部署与删除，使得对资产的监管更具针对性的同时，保证了对监控客户端的有效管理。

本申请实施例还提供了一种资产自动化管控装置，包括：接收模块、第一操作确定模块、以及操作执行模块；所述接收模块用于接收资产管理模块发来的资产变动信息；所述资产变动信息中携带有发生变动的资产的信息；所述第一操作确定模块用于根据所述资产变动信息从预设的操作表中，确定出所述资产变动信息对应的待执行操作；所述操作执行模块用于依据所述待执行操作对所述发生变动的资产进行操作。

在上述实现过程中，在接收到资产管理模块发来的资产变动信息后，即可自动根据资产变动信息从预设的操作表中，确定出资产变动信息对应的待执行操作，并依据待执行操作对发生变动的资产进行操作，实现了对资产的自动化运维，可以应用于对大型计算机集群进行运维的场景中。而由于是自动化运维，具有运维效率高，且不易出错的优势。此外，由于本申请实施例中确定出的是与该资产变动信息对应的待执行操作，这也使得后面执行的操作是与接收到的资产变动信息相匹配的，从而提升了对于资产的运维可靠性。

本申请实施例还提供了一种资产自动化管控装置，包括：第二操作确定模块和发送模块；所述第二操作确定模块用于在资产发生变动时，依据所发生的变动，从预设的操作表中，确定出所发生的变动对应的待执行操作；所述发送模块用于将发生变动的资产的信息以及所述待执行操作发送给运维管理模块，以供所述运维管理模块依据所述待执行操作对所述发生变动的资产进行操作。

在上述实现过程中，在资产发生变动时，即可自动依据所发生的变动，从预设的操作表中，确定出所发生的变动对应的待执行操作，并将发生变动的资产的信息以及待执行操作发送给运维管理模块，以供运维管理模块依据待执行操作对发生变动的资产进行操作。这就实现了对资产的自动化运维，可以应用于对大型计算机集群进行运维的场景中。而由于是自动化运维，具有运维效率高，且不易出错的优势。此外，由于本申请实施例中确定出的是与该资产变动信息对应的待执行操作，这也使得后面执行的操作是与接收到的资产变动信息相匹配的，从而提升了对于资产的运维可靠性。

本申请实施例还提供了一种资产自动化管控系统，包括：资产管理模块和运维管理模块；

所述资产管理模块，用于对资产信息进行录入和管理，并在资产信息发生变动时，生成资产变动信息，并将所述资产变动信息发送给所述运维管理模块；所述资产变动信息中携带有发生变动的资产的信息；所述运维管理模块用于在接收到所述资产管理模块发来的资产变动信息时，依据所述资产变动信息确定出所述资产变动信息对应的待执行操作，并按照所述待执行操作对所述发生变动的资产进行操作。

或者，所述资产管理模块，用于对资产信息进行录入和管理，并在资产信息发生变动时，依据所发生的变动，确定出所发生的变动对应的待执行操作，并将发生变动的资产的信息以及所述待执行操作发送给所述运维管理模块；所述运维管理模块用于依据所述待执行操作对所述发生变动的资产进行操作。

上述实现过程实现了对资产的自动化运维，可以应用于对大型计算机集群进行运维的场景中。而由于是自动化运维，具有运维效率高，且不易出错的优势。此外，由于本申请实施例中确定出的是与该资产变动信息对应的待执行操作，这也使得后面执行的操作是与接收到的资产变动信息相匹配的，从而提升了对于资产的运维可靠性。

进一步的，所述资产管理模块包括收集单元和验证单元；所述收集单元用于收集资产信息；所述验证单元用于对收集到的资产信息进行验证，在验证通过之后对所述资产信息进行录入。

在上述实现过程中，可以资产管理模块在收集到资产信息后，需要对收集到的资产信息进行验证，在验证通过之后才对资产信息进行录入。这就提高了资产信息的录入准确性和系统安全性。

进一步的，所述收集单元具体用于执行预设脚本以收集资产信息。

在上述实现过程中，通过执行预设脚本的方式实现了对资产信息的自动化收集，进一步的节约了人力成本，提供了资产信息收集效率。

进一步的，所述资产信息中包括资产标签和资产状态；所述资产标签用于标示所述资产中待监控的服务；所述资产状态用于标示资产当前的使用状态。

在上述实现过程中，在收集的资产信息中会包含资产标签和资产状态，从而便于的对资产的状态和需要监控的服务进行管理。

本申请实施例还提供了一种电子设备，包括处理器、存储器及通信总线；所述通信总线用于实现处理器和存储器之间的连接通信；所述处理器用于执行存储器中存储的一个或者多个程序，以实现上述第一种的资产自动化管控方法的步骤，或实现上述第二种的资产自动化管控方法的步骤。

本申请实施例中还提供了一种可读存储介质，所述可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述第一种的资产自动化管控方法的步骤，或实现上述第二种的资产自动化管控方法的步骤。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种资产自动化管控过程的流程示意图；

图2为本申请实施例提供的一种资产自动化管控系统的结构示意图；

图3为本申请实施例提供的一种资产管理模块的结构示意图；

图4为本申请实施例提供的一种较具体的资产自动化管控系统的结构示意图；

图5为本申请实施例提供的一种资产自动化管控装置100的结构示意图；

图6为本申请实施例提供的一种资产自动化管控装置200的结构示意图；

图7为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

实施例一：

为了解决相关技术中对大型计算机集群而言，运维效率十分低下且容易出错的问题，本申请实施例中提供了一种资产自动化管控系统及其对应的方法。可以参见图1所示：

s101：资产管理模块对资产信息进行录入和管理。

在本申请实施例中，可以参见图2所示，资产自动化管控系统包括资产管理模块1和运维管理模块2两个部分。其中，资产管理模块1用于进行资产信息的录入以及管理，而运维管理模块2用于进行资产上监控客户端的自动化管控。

在本申请实施例中，可以参见图3所示，资产管理模块1可以包括收集单元11和验证单元12，其中收集单元用于收集资产信息，验证单元用于对收集到的资产信息进行验证，在验证通过之后对验证通过的资产信息进行录入。

值得注意的是，在本申请实施例中，对于资产信息的收集可以是由用户手动进行收集后，导入到收集单元中的。例如，资产管理模可以提供csv(comma-separatedvalues，字符分隔值)模版供用户下载，用户下载csv模板后，在模板中填写好收集到的资产信息，然后将编辑后的csv模板导入收集单元(收集单元为一个接口)，进而实现对资产信息的收集。此外，在本申请实施例中也可以预先配置好脚本，由收集单元来执行该脚本以收集资产信息。在本申请实施例中，收集单元可以以json格式收集资产信息，例如可以按如下格式收集资产信息(需要说明的是，以下数据中收集到的资产信息仅为一种可能的资产信息，实际应用中应当以实际收集到的数据为准)：

{

“name”：“server1”，

“ip”：“192.168.123.2”，

“port”：“2012”，

“label”：“apache，mysql”，

“sn”：“7m580k2”，

“cpu_type”：“intel(r)xeon(r)cpue5-4610v4@1.80ghz”，

“cpu_num”：“10”，

“memory”：“515.575g”，

“disk”：“558.38g”，

“disk_info”：“‘sda’：‘558.38gb’”，

“os”：“centos”，

“os_version”：“7.1.1503”

}

还值得注意的是，在本申请实施例中，收集的资产信息中可以包含资产标签和资产状态等信息，例如参见下表一所示，表一中所对应的信息即为收集到的资产信息的具体内容(即资产信息可以包括资产名、ip号、端口号、资产状态、资产标签、序列号、cpu(中央处理器)型号、cpu核数、内存大小、硬盘大小、硬盘信息等)。需要说明的是，表一所示的资产信息仅为一种可行的示例，在实际应用中，资产信息所包含的具体内容可以与表一的内容不同，例如除了可以包括上述内容外，还可以包括操作系统(即os)，操作系统版本(即osversion)等。具体所需收集的内容可以由工程师根据实际需要进行设定。

表一

需要说明的是，在本申请实施例中，资产标签用于标示资产中需要监控的服务，其内容可以直接为服务名，如表一种所示的“apache”、“mysql”等。资产状态用于标示资产当前的使用状态，如“启用”、“停用”、“上架”等。应当理解的是，在实际应用中也可以预先约定好相应的表征值来表征不同的服务或状态，如可以用字符“a”表征服务“apache”，用字符“b”表征服务“mysql”；用字符“c”表征服务“nginx”；用数字“1”表征“启用”；用数字“2”表征“停用”；用数字“3”表征“上架”等。

还值得注意的是，在实际应用中，若采用预设脚本来自动收集资产信息，可能存在某些服务不能通过脚本收集相关信息的情况，例如对于apache和mysql服务而言，便不能通过脚本收集到。此时可以在执行脚本时，以参数的方式手动指定。例如资产上运行了apache和mysql服务，且需要对这两个服务进行监控，则可以在执行脚本时，指定资产的标签为“apache，mysql”，如通过pythonget.py--label“apache，mysql”实现指定。还值得注意的是，在执行脚本时，对于资产状态可以默认设定为“启用”，此外也可以在收集资产信息时判断资产上是否运行有相关服务，如果运行则设定资产状态为“启用”，否则设定资产状态为“停用”等。

还值得注意的是，在本申请实施例中，对于收集到的资产进行验证的方式可以是，依据收集到的资产信息中的基准信息来与预先设定好的基准信息库中的基准信息进行比较，若与基准信息库中的基准信息一致则验证通过，否则即验证不通过(需要理解的是基准信息是指的资产固有的一些特性信息，如资产名、ip、序列号、cpu型号、cpu核数、内存大小、硬盘大小、硬盘信息等信息)。

需要说明的是，对收集到的资产信息的验证过程并不是实现本申请实施例的必要过程。应理解，不进行验证而直接录入收集到的资产信息也是可行的，只是进行验证的方案系统安全性更高而已。

s102：在资产信息发生变动时，生成资产变动信息；

需要说明的是，资产管理模块1中在收集的资产信息导入后，可能存在新增资产的情况。此外，若收集到的资产原本已录入，则还可能存在新收集到的资产信息和原本已录入的资产信息相比，部分信息存在变更的情况。不论是新增了资产，或是原有已录入的资产信息发生变更，对于本申请实施例而言，都被称为资产信息发生变动。此外，本申请实施例中可以提供相应的修改接口，以供用户对已录入的资产信息进行改动。这种由于用户主动修改产生的变动同样会使得资产管理模块1生成资产变动信息。

值得注意的是，在生成的资产变动信息中，应当携带有发生变动的资产的信息，即携带有能明确指示出发生变动的资产是哪一个资产的信息，如资产名、资产的ip号、资产的序列号等信息中的一个或多个。

s103：将资产变动信息发送给运维管理模块2；

在本申请实施例中，运维管理模块2可以采用开源的自动化运维工具来实现，如可以实现ansible等自动化运维工具来实现。

s104：运维管理模块2在接收到资产管理模块1发来的资产变动信息时，依据资产变动信息确定出资产变动信息对应的待执行操作。

在本申请实施例中，可以在运维管理模块2内预先设置一个操作表，操作表中预先配置好资产变动信息对应的待执行操作，进而依据接收到的资产变动信息确定出对应的待执行操作。

在本申请实施例的一种可选实施方式中，资产变动信息可以为新增资产(此时新增的资产即为发生变动的资产)，同时资产变动信息还可以携带有发生变动的资产的资产状态。此时，可以确定资产变动信息对应的待执行操作包括：在发生变动的资产的资产状态为启用状态时，在发生变动的资产上部署监控客户端。

在本申请实施例的又一种可选实施方式中，资产变动信息可以为发生变动的资产的资产状态转变为启用状态(如从上架状态转变为启用状态，或者从停用状态转变为启用状态)。此时，可以确定资产变动信息对应的待执行操作包括：在发生变动的资产上部署监控客户端。

值得注意的是，在本申请实施例的前述两种可选实施方式中，资产变动信息还可以携带有发生变动的资产的资产标签。进而在发生变动的资产上部署监控客户端时，可以在发生变动的资产上部署与各资产标签对应的监控客户端。此时各监控客户端分别用于监控对应的资产标签所标示的服务。

需要说明的是，本申请实施例中所述的监控客户端并非惯常概念中的物理实体终端，而是指的配置在资产上，可以对资产的运行情况进行监控的程序控件。在部署时，运维管理模块2可以通过远程控制等方式在资产上安装监控客户端，从而完成部署。

在本申请实施例的又一种可选实施方式中，资产变动信息可以为资产状态由启用状态转变为非启用状态。此时，可以确定资产变动信息对应的待执行操作包括：删除部署在发生变动的资产上的监控客户端。值得注意的是，在本可选实施方式中，可以将部署在发生变动的资产上的所有监控客户端全部删除，从而更好地达到节约资源的目的。

在本申请实施例的又一种可选实施方式中，资产变动信息可以为发生变动的资产的资产标签发生了改变。此时存在以下三种变动情况：

情况一：资产标签发生的改变为资产标签被删除。此时可以确定资产变动信息对应的待执行操作为，删除部署在发生变动的资产上的监控客户端。需要说明的是，被删除的监控客户端为与被删除的资产标签对应的监控客户端。

情况二：资产标签发生的改变为新增资产标签。此时可以确定资产变动信息对应的待执行操作为，在发生变动的资产上部署与新增的资产标签对应的监控客户端。

情况三：资产标签发生的改变为将资产标签由第一标签改为第二标签。此时可以确定资产变动信息对应的待执行操作为，删除部署在所述发生变动的资产上与所述第一标签对应的监控客户端，并在发生变动的资产上部署与第二标签对应的监控客户端。需要说明的是，本申请实施例中所述的第一标签和第二标签并不特指某一种具体的资产标签，而是在发生了资产标签由一种标签改为了另一种标签的情况时，将改动前的资产标签称之为第一标签，将改动后的资产标签称之为第二标签。

值得注意的是，在上述第四种可选实施方式中，可以限定发生变动的资产的资产状态为启用状态时才依据上述方式执行。

s105：按照待执行操作对发生变动的资产进行操作。

需要说明的是，上述图1描述的实施方案中，对于待执行操作的确定是由运维管理模块2来确定的。在本申请实施例的另一实施方案中，对于待执行操作也可以由资产管理模块1来确定，进而将确定出的待执行操作以及发生变动的资产的信息发送给运维管理模块2，进而由运维管理模块2依据发来的待执行操作对发生变动的资产进行操作即可。在本实施方案中，待执行操作可以以程序脚本的形式发送给运维管理模块2。此外，发生变动的资产的信息是指能明确指示出发生变动的资产是哪一个资产的信息，如资产名、资产的ip号、资产的序列号等信息中的一个或多个。

具体而言，在本实施方案中，在资产发生变动时，资产管理模块1可以依据所发生的变动，从预设的操作表中，确定出所发生的变动对应的待执行操作。进而将发生变动的资产的信息以及待执行操作发送给运维管理模块2，以供运维管理模块2依据待执行操作对发生变动的资产进行操作。

此时，本实施方案中同样包括但不限于以下四种可选实施方式：

可选实施方式一：在所发生的变动为新增资产时，可以在发生变动的资产的资产状态为启用状态时，确定所发生的变动对应的待执行操作为，在发生变动的资产(即新增的资产)上部署监控客户端。

可选实施方式二：在所发生的变动为发生变动的资产的资产状态转变为启用状态时，可以确定所发生的变动对应的待执行操作为在发生变动的资产上部署监控客户端。

在上述可选实施方式一和二中，若发生变动的资产具有资产标签，则在发生变动的资产上部署监控客户端时，可以在发生变动的资产上部署与发生变动的资产的资产标签对应的监控客户端。

可选实施方式三：在所发生的变动为资产状态由启用状态转变为非启用状态时，可以确定资产变动信息对应的待执行操作为，删除部署在发生变动的资产上的监控客户端。示例性的，待执行操作可以为，将部署在发生变动的资产上的监控客户端上的所有监控客户端全部删除。

可选实施方式四：在所发生的变动为发生变动的资产的资产标签发生改变时，可以在资产标签发生的改变为资产标签被删除时，确定所发生的变动对应的待执行操作为，删除部署在发生变动的资产上的与被删除的资产标签对应的监控客户端；在资产标签发生的改变为新增资产标签时，确定所发生的变动对应的待执行操作为，在发生变动的资产上部署与新增的资产标签对应的监控客户端；在资产标签发生的改变为将资产标签由第一标签改为第二标签时，确定所发生的变动对应的待执行操作为，删除部署在发生变动的资产上与第一标签对应的监控客户端，并在发生变动的资产上部署与第二标签对应的监控客户端。

值得注意的是，在本申请实施例中，参见图4所示，资产自动化管控系统还可以设置有一个注册中心3，用于对监控客户端进行合法化管理。示例性的，可以在依据待执行操作在发生变动的资产上部署监控客户端时，将部署的监控客户端注册到预设的注册中心3。在依据待执行操作删除部署在发生变动的资产上的监控客户端时，将被删除的监控客户端的注册信息从预设的注册中心3中删除。以上注册和删除过程可以通过预先定义的接口实现自动化处理。在本申请实施例中，将部署的监控客户端注册到预设的注册中心3时，注册的信息可以包括监控客户端的唯一标识(如序列号等)、对应的资产标签、所部属的监控客户端所在的资产的资产名、ip号、监控客户端的端口号等信息。

在本申请实施例中，仍旧参见图4所示，资产自动化管控系统还可以配置相应的监控服务4、告警服务5。监控服务4可以实现对资产的监控和告警功能。示例性的，监控服务4可以实时地从注册中心3发现监控客户端的相关信息(如所部属的监控客户端所在的资产的资产名、ip号、监控客户端的端口号等)，进而可以从相应的监控客户端拉取到监控数据，并存储、分析监控数据，将超过预设阈值的监控数据推送给告警服务5，由告警服务5发送告警信息提醒工程师。需要注意的是，预设阈值可以是由工程师根据实际需要进行设定，对于不同的监控服务4而言，其设定的阈值可以存在区别。还需要注意的是，在本申请实施例中，可以将监控服务4获取到的监控数据以及告警服务5产生的告警信息通过网页界面的形式显示给用户，以便用户更直观的了解当前资产的运行情况。

需要说明的是，在本申请实施例中，对于交换机、防火墙等资产而言，交换机资产标签可以标记为switch，防火墙资产标签可以标记为firewall。对于交换机、防火墙等资产，只需开启snmp功能(运行snmp功能的程序可以视为监控客户端)，由运维管理模块2开启并将交换机、防火墙等资产信息注册到注册中心，监控服务即可直接通过snmp协议获取监控数据。

综上，本申请实施例所提供的资产自动化管控方法及系统，用户只需通过资产管理模块1对资产进行简单管理，即可完成对服务器全方位的自动化监控，人力投入低。方案可以应用于对大型计算机集群进行运维的场景中，且由于是自动化运维，具有运维效率高，且不易出错的优势。此外，由于本申请实施例中确定出的是与该资产变动信息对应的待执行操作，这也使得后面执行的操作是与接收到的资产变动信息相匹配的，从而提升了对于资产的运维可靠性。

实施例二：

本实施例在实施例一的基础上，以一种较具体的资产自动化管控系统为例，对本申请做进一步示例说明。

参见图4所示，系统包括资产管理模块1、运维管理模块2、注册中心3、服务器(资产)、监控服务4、告警服务5和网页界面。

在本申请实施例中，在进行资产的自动化管控之前，需要先将资产信息导入资产管理模块1。导入的方式包括人工导入和脚本方式导入两种。

在人工导入资产信息时，用户需要先从资产管理模块1对应的网页界面中下载csv模版；然后根据csv模版的提示信息填写要导入的资产的相关信息，如有多个资产标签则使用逗号隔开；最后将csv模版上传导入至资产管理模块1，资产管理模块1对导入的csv模板进行解析、验证并入库。csv模板可以如下表二所示：

表二

在通过脚本方式导入资产信息时，可以将预先编写好的资产信息收集脚本下载到资产管理模块1所在的服务器上并执行。执行脚本时即自动收集资产信息并将收集到的资产信息以json格式获取到资产管理模块1中。资产管理模块1对获取到的json格式的数据进行解析、验证并入库。对于无法通过脚本收集到的资产信息，则在执行脚本的时候以参数的方式手动指定，如资产上运行了apache和mysql服务，且需要对这两个服务进行监控，则可以在运行脚本时指定资产的标签为“apache，mysql”，如：pythonget.py--label“apache，mysql”。另外可以设置，通过脚本导入的资产，资产状态默认为“启用”。

此外，在本申请实施例中，资产管理模块1可以提供资产调整接口，从而使得用户可以在资产管理模块1对应的网页界面中对资产的相关信息进行调整。

在导入资产或对资产信息进行了修改后，若相关的变动(新增了资产信息或原有资产信息发生了变动)触发了预先设定好的自动化部署条件，则可以对应的确定出待执行操作，并发送给运维管理模块2进行执行。

在本申请实施例中，运维管理模块2可以采用开源的自动化运维工具ansible来实现。ansible在接收到了待执行操作后，ansible可以远程连接相应的资产并执行待执行操作，并将执行结果返回给资产管理模块1。

在本申请实施例中，预先设定好的自动化部署条件和相应的待执行操作之间的对应关系可以如下表三所示：

表三

在本申请实施例中，监控服务4会实时从注册中心3发现监控客户端的信息(如所部属监控客户端所在的资产的资产名、ip号，监控客户端的ip号、监控客户端的端口号等)，进而监控服务4可以从监控客户端拉取监控数据，同时存储并分析监控数据，将超过阈值的监控数据推送给告警服务5，由告警服务5发送告警。同时提供显示服务，可以将监控数据及告警信息通过网页界面显示给用户。

示例性的，监控服务4可以通过以下代码从注册中心3发现监控客户端的信息：

scrape_configs：

-job_name：‘consul’

consul_sd_configs：

-server：‘consul.service.consul：8500’#注册中心3的地址

通过上述方案，用户只需通过资产管理模块对资产进行简单管理，即可完成对服务器全方位的自动化监控，人力投入更低，可以适用于更多的应用场景。

实施例三：

基于同一发明构思，本申请实施例中还提供资产自动化管控装置100和200。请参阅图5和图6所示，图5示出了采用图1所示的方法中，与运维管理模块所执行的步骤一一对应的资产自动化管控装置100，图6示出了待执行操作由资产管理模块来确定的方案中，与资产管理模块所执行的步骤一一对应的资产自动化管控装置200。应理解，装置100和200具体的功能可以参见上文中的描述，为避免重复，此处适当省略详细描述。装置100和200包括至少一个能以软件或固件的形式存储于存储器中或固化在装置100和200的操作系统中的软件功能模块。具体地：

参见图5所示，装置100包括：接收模块101、第一操作确定模块102、以及操作执行模块103；

接收模块101用于接收资产管理模块发来的资产变动信息；资产变动信息中携带有发生变动的资产的信息；

第一操作确定模块102用于根据资产变动信息从预设的操作表中，确定出资产变动信息对应的待执行操作；

操作执行模块103用于依据待执行操作对发生变动的资产进行操作。

在本申请实施例中，资产变动信息还携带有发生变动的资产的资产状态；资产变动信息为新增资产；第一操作确定模块102具体用于，确定资产变动信息对应的待执行操作为，在发生变动的资产的资产状态为启用状态时，在发生变动的资产上部署监控客户端；发生变动的资产为新增的资产。

在本申请实施例中，资产变动信息为发生变动的资产的资产状态转变为启用状态；第一操作确定模块102具体用于，确定资产变动信息对应的待执行操作为在发生变动的资产上部署监控客户端。

在本申请实施例中，资产变动信息还携带有发生变动的资产的资产标签；资产标签用于标示发生变动的资产中待监控的服务；

第一操作确定模块102在发生变动的资产上部署监控客户端时，具体包括：在发生变动的资产上部署与各资产标签对应的监控客户端；各监控客户端分别用于监控对应的资产标签所标示的服务。

在本申请实施例中，资产变动信息为资产状态由启用状态转变为非启用状态；第一操作确定模块102具体用于，确定资产变动信息对应的待执行操作为，删除部署在发生变动的资产上的监控客户端。

在本申请实施例中，资产变动信息为发生变动的资产的资产标签发生改变；资产标签用于标示发生变动的资产中待监控的服务；

第一操作确定模块102具体用于：

在资产标签发生的改变为资产标签被删除时，确定资产变动信息对应的待执行操作为，删除部署在发生变动的资产上的监控客户端；被删除的监控客户端为与被删除的资产标签对应的监控客户端；

在资产标签发生的改变为新增资产标签时，确定资产变动信息对应的待执行操作为，在发生变动的资产上部署与新增的资产标签对应的监控客户端；

在资产标签发生的改变为将资产标签由第一标签改为第二标签时，确定资产变动信息对应的待执行操作为，删除部署在发生变动的资产上与第一标签对应的监控客户端，并在发生变动的资产上部署与第二标签对应的监控客户端；

监控客户端用于监控与其对应的资产标签所标示的服务。

在本申请实施例中，操作执行模块103还用于在依据待执行操作在发生变动的资产上部署监控客户端时，将部署的监控客户端注册到预设的注册中心。

在本申请实施例中，操作执行模块103还用于在依据待执行操作删除部署在发生变动的资产上的监控客户端时，将被删除的监控客户端的注册信息从预设的注册中心中删除。

参见图6所示，装置200包括：第二操作确定模块201和发送模块202；

第二操作确定模块201用于在资产发生变动时，依据所发生的变动，从预设的操作表中，确定出所发生的变动对应的待执行操作；

发送模块202用于将发生变动的资产的信息以及待执行操作发送给运维管理模块，以供运维管理模块依据待执行操作对发生变动的资产进行操作。

在本申请实施例中，所发生的变动为新增资产；第二操作确定模块201具体用于，在发生变动的资产的资产状态为启用状态时，确定所发生的变动对应的待执行操作为，在发生变动的资产上部署监控客户端；发生变动的资产为新增的资产。

在本申请实施例中，所发生的变动为发生变动的资产的资产状态转变为启用状态；第二操作确定模块201具体用于，确定所发生的变动对应的待执行操作为在发生变动的资产上部署监控客户端。在本申请实施例中，资产包括资产标签时，第二操作确定模块201具体用于，在发生变动的资产上部署与发生变动的资产的资产标签对应的监控客户端；资产标签用于标示发生变动的资产中待监控的服务；监控客户端用于监控对应的资产标签所标示的服务。

在本申请实施例中，所发生的变动为资产状态由启用状态转变为非启用状态；第二操作确定模块201具体用于，确定所发生的变动对应的待执行操作为，删除部署在发生变动的资产上的监控客户端。

在本申请实施例中，所发生的变动为发生变动的资产的资产标签发生改变；资产标签用于标示发生变动的资产中待监控的服务；

第二操作确定模块201具体用于：

在资产标签发生的改变为资产标签被删除时，确定所发生的变动对应的待执行操作为，删除部署在发生变动的资产上的监控客户端；被删除的监控客户端为与被删除的资产标签对应的监控客户端；

在资产标签发生的改变为新增资产标签时，确定所发生的变动对应的待执行操作为，在发生变动的资产上部署与新增的资产标签对应的监控客户端；

在资产标签发生的改变为将资产标签由第一标签改为第二标签时，确定所发生的变动对应的待执行操作为，删除部署在发生变动的资产上与第一标签对应的监控客户端，并在发生变动的资产上部署与第二标签对应的监控客户端；

监控客户端用于监控与其对应的资产标签所标示的服务。

实施例四：

本实施例提供了一种电子设备，参见图7所示，其包括处理器701、存储器702以及通信总线703。其中：

通信总线703用于实现处理器701和存储器702之间的连接通信。

处理器701用于执行存储器702中存储的一个或多个第一程序，以实现上述实施例一中，对于待执行操作的确定由运维管理模块来确定的方案中，运维管理模块所执行的各步骤；

或，处理器701用于执行存储器702中存储的一个或多个第二程序，以实现上述实施例一中，对于待执行操作由资产管理模块来确定的方案中，资产管理模块所执行的各步骤。

可以理解，图7所示的结构仅为示意，电子设备还可包括比图7中所示更多或者更少的组件，或者具有与图7所示不同的配置。

本实施例还提供了一种可读存储介质，如软盘、光盘、硬盘、闪存、u盘、sd(securedigitalmemorycard，安全数码卡)卡、mmc(multimediacard，多媒体卡)卡等，在该可读存储介质中存储有实现上述各个步骤的一个或者多个程序，这一个或者多个程序可被一个或者多个处理器执行，以实现上述实施例一中，对于待执行操作的确定由运维管理模块来确定的方案中，运维管理模块所执行的各步骤，或实现上述实施例一中，对于待执行操作由资产管理模块来确定的方案中，资产管理模块所执行的各步骤。在此不再赘述。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

在本文中，多个是指两个或两个以上。

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