一种系统故障管理方法、装置及系统与流程

本发明涉及信息系统运行维护技术领域，特别涉及一种系统故障管理方法、装置及系统。

背景技术：

it系统线上故障管理在系统的日常运维中尤为重要，不仅考验技术，更考验时效。

线上故障管理过程是对技术人员/技术团队反应能力、判定能力、组织能力的考验。面对突发的生产故障，如何快速定位问题、找到恢复预案、快速实恢复预案，并不是一件容易的事情。现阶段常规的系统线上故障管理过程中，从故障识别到故障恢复整个链路所需耗时太长，并且，如果不能在短时间内一次找准故障根因并进行修复，整个故障时间有倍增风险。系统故障造成的业务中断对一个企业来说往往是不可接受的，可能是损失大量订单、也可能是客户流失，极端情况下会造成不良社会影响。

因此，亟待寻求一种能快速、准确找到并处理故障的方法。

技术实现要素：

为解决上述技术问题，本发明提供了一种系统故障管理方法、装置及系统，其采用多维度以及并行式故障排查方式，大大提升故障处理时效。

本发明提供的技术方案如下：

第一方面，提供一种系统故障管理方法，所述方法至少包括如下步骤：

根据接收到的故障提示信息识别系统故障并触发相应维度的故障工单；

根据故障工单生成相应维度内并行的故障排查任务并分别推送至相应的故障处理人员，根据接收到的与各个故障排查任务对应的故障排查结果定位故障点；

在预设的恢复预案匹配关系中查找与所述故障点相匹配的恢复预案，并将恢复预案按照优先级排序后推送至故障处理人员；

接收并执行故障处理人员选择的恢复预案以对系统故障进行修复。

在一些较佳的实施方式中，所述根据接收到的故障提示信息识别系统故障并触发相应维度的故障工单，包括如下子步骤：

接收多维度监控告警信息或人工告警信息中的至少一种故障提示信息；

将所述故障提示信息推送至相应维度的故障受理人员；

根据接收到的故障受理人员的受理指令，触发相应维度的故障工单。

在一些较佳的实施方式中，当所述故障提示信息为人工告警信息时，所述将所述故障提示信息推送至相应维度的故障受理人员之前，还包括：

提取人工告警信息中的故障类型关键词，

根据所述故障类型关键词判断在预设的故障分类表中是否有匹配的故障所属维度；

若有，则将所述故障提示信息推送至相应维度的故障受理人员；

若无，则将所述故障提示信息推送至通用维度的故障受理人员。

在一些较佳的实施方式中，所述根据故障工单生成相应维度内并行的故障排查任务并分别推送至相应的故障处理人员，根据接收到的与各个故障排查任务对应的故障排查结果定位故障点，包括如下子步骤：

根据故障工单的故障信息在预设的干系人表中匹配出相应故障处理人员；

根据所述故障信息在预设的故障排查模型中匹配相应的故障排查任务；

根据所述故障信息将故障排查任务与故障处理人员建立排查任务关联关系；

基于所述排查任务关联关系生成并行的故障排查任务并推送至相应的故障处理人员；

接收每一相应故障处理人员执行相应故障排查任务获得的故障排查结果；

筛选结果为异常的故障排查结果并分析获得故障点。

在一些较佳的实施方式中，将故障排查任务推送至相应的故障处理人员，具体采用：

同时触发拨号通知、创建故障管理沟通群并推送预设时间段内的生产变更信息、邮件通知的方式将故障排查任务推送至故障处理人员。

在一些较佳的实施方式中，所述在预设的恢复预案匹配关系中查找与所述故障点相匹配的恢复预案，并将恢复预案按照优先级排序后推送至故障处理人员，包括如下子步骤：

在预设的恢复预案匹配关系中查找是否有与所述故障点相匹配的恢复预案，若有，则将恢复预案按照优先级排序后推送至故障处理人员；

若无，则调用无预案恢复操作作为恢复预案推送至故障处理人员。

在一些较佳的实施方式中，所述接收并执行故障处理人员选择的恢复预案对系统故障进行修复之后还包括：验证系统故障是否完成修复，具体包括如下子步骤：

将恢复预案执行结果推送至故障处理人员；

接收故障处理人员验证故障是否恢复的验证指令，当验证指令为未恢复，

则继续执行下一优先级恢复预案；

至接收到的验证指令为已恢复，结束故障工单。

在一些较佳的实施方式中，所述根据接收到的故障提示信息识别系统故障并触发故障工单之后，还包括：向访问用户推送与所述故障工单对应的替代预案，具体包括如下子步骤：

在预设的故障替代预案关系中查找与故障工单的故障信息匹配的若干替代预案；

识别用户访问所述故障工单相关链路时将替代预案信息推送至用户端。

第二方面，提供一种系统故障管理装置，所述装置至少包括：

故障工单触发模块，用于根据接收到的故障提示信息识别系统故障并触发相应维度的故障工单；

故障点定位模块，用于根据故障工单生成相应维度内并行的故障排查任务并分别推送至相应的故障处理人员，根据接收到的与各个故障排查任务对应的故障排查结果定位故障点；

应急预案模块，用于在预设的恢复预案匹配关系中查找与所述故障点相匹配的恢复预案，并将恢复预案按照优先级排序后推送至故障处理人员；

故障修复模块，用于接收并执行故障处理人员选择的恢复预案以对系统故障进行修复。

第三方面，提供一种计算机系统，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令，所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

根据接收到的故障提示信息识别系统故障并触发相应维度的故障工单；

根据故障工单生成相应维度内并行的故障排查任务并分别推送至相应的故障处理人员，根据接收到的与各个故障排查任务对应的故障排查结果定位故障点；

在预设的恢复预案匹配关系中查找与所述故障点相匹配的恢复预案，并将恢复预案按照优先级排序后推送至故障处理人员；

接收并执行故障处理人员选择的恢复预案以对系统故障进行修复。

本发明相比现有技术而言的有益效果在于：

本发明提供一种系统故障管理方法、装置及系统，该方法首先根据接收到的故障提示信息识别系统故障并触发相应维度的故障工单，然后生成相应维度内并行的故障排查任务并分别推送至相应的故障处理人员，接着根据接收到的故障排查结果定位故障点，查找与故障点相匹配的恢复预案并将恢复预案推送至故障处理人员，待故障处理人员选择后执行恢复预案以对系统故障进行修复，该方法采用多维度以及并行式故障排查方式，缩短故障排查时间，提高故障排查准确性，提高故障管理效率；

进一步，故障提示信息至少包括告警平台获取的多维度监控告警信息或人工告警信息中的一种，该方法按照故障类型分为不同维度，对不同的维度分别进行监控，通过多维度监控触发故障工单，可大大提升故障识别灵敏度，缩短故障上报时间，不仅能缩短故障管理时间，还能避免故障倍增风险以及提高用户使用体验，如此，当触发故障工单时即可获知相应的故障类型，在进行故障定位、排查及修复时也可以仅针相应维度进行即可，减小排查范围进一步提高故障识别准确性及时效性，同时，采用多维度监控告警信息及人工告警信息相结合的方式进行故障识别，能全面覆盖所有系统故障，避免遗漏；

在触发故障工单后，向访问用户推送预先设置的与故障点对应的替代预案，在等待系统恢复期间，通过执行替代预案仍可实现系统功能，有效避免业务中断及用户的重复操作给服务和流量带来不必要的压力，从而提高用户使用体验。

本申请的方案只要实现其中任一技术效果即可。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例一中的一种系统故障管理方法流程图；

图2是本发明实施例一中的故障排查任务示意图；

图3是本发明实施例二中的一种系统故障管理装置的结构图；

图4是本发明实施例三中的计算机系统架构图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

当前系统线上故障管理中，通常是用户使用过程中上报故障，技术人员通过串行的方式排查故障，导致故障管理时间较长、故障识别不灵敏且不易快速定位故障点，本实施例提供一种系统故障管理方法、装置及系统，其能有效克服上述问题。

下面将结合具体实施例及附图1～4对该系统故障管理方法、装置及系统作进一步说明。

实施例一

结合图1所示，本实施例提供一种系统故障管理方法，其至少包括如下步骤：

s1、根据接收到的故障提示信息识别系统故障并触发相应维度的故障工单。

其中，故障提示信息至少包括告警平台触发的多维度监控告警信息及人工告警信息中的一种。

本实施例中，将故障按照故障类型分为不同维度。其中，告警平台用于监控触发几率较大的故障维度并发出相应维度监控告警信息。当用户触发告警平台的多个维度以外的其他故障时，则通过生成人工告警信息进行系统故障的提示。

通过多维度监控触发故障工单，可大大提升故障识别灵敏度，缩短故障上报时间，缩短故障管理时间。大概率故障触发告警平台的监控告警，在触发故障工单后即可获知相应的故障类型，后续进行故障定位、排查及修复时也可以仅针相应维度进行即可有效减小排查范围以提高故障识别准确性及时效性。具体地，步骤s1包括如下子步骤：

s11、接收多维度监控告警信息或人工告警信息中的至少一种故障提示信息；

s12、将故障提示信息推送至相应维度的故障受理人员；

s13、根据接收到的故障受理人员的受理指令，触发相应维度的故障工单。

优选地，当故障提示信息为人工告警信息时，执行步骤s12中将故障提示信息推送至相应维度的故障受理人员之前，还包括：

提取人工告警信息中的故障类型关键词，根据故障类型关键词判断在预设的故障分类表中是否有匹配的故障所属维度；

若有，则将所述故障提示信息推送至相应维度的故障受理人员；

若无，则将所述故障提示信息推送至通用维度的故障受理人员。

本实施例采用多维度监控告警信息及人工告警信息相结合的方式进行故障识别，能全面覆盖所有系统故障，避免遗漏。

示例性地，该系统故障管理方法应用于物流管理系统时，告警平台监控业务层运行数据、链路层运行数据及后台运行数据三个维度，当这三个维度的运行数据超过告警阈值时，触发告警，生成业务告警信息(stp)、链路监控告警信息(tro)或后台监控告警信息(aops)，即多维度监控告警信息。上述三个维度以外的其余维度的运行数据出现异常时，则执行人工上报，生成人工告警信息。

然后将故障提示信息推送至相应维度的故障受理人员，并根据接收到的故障受理人员的受理指令，触发相应维度的故障工单。因此，将故障提示信息推送至相应维度的故障受理人员进一步核实，故障受理人员根据经验，结合当前的生产环境对故障提示信息作进一步的判断，以排除生产环境造成的偶然现象。如某平台先前由于大促而造成寄件达成量骤增，当前寄件达成量相较于大促时间明显下降30％，触发stp告警。故障受理人结合先前大促情况，可判定该故障提示信息并非故障产生，不予受理。在判断确实为系统故障时，故障受理人员受理并发出受理指令，根据接收到的故障受理人员的受理指令，触发相应维度的故障工单。

通用维度通常为首次出现的故障类型且未被告警平台覆盖的故障类型，对于此类故障统一认定为通用故障，转至通用维度的故障受理人员处理，后续受理之后也采用通用的故障排查模型进行故障排查。

s2、根据故障工单生成相应维度内并行的故障排查任务并分别推送至相应的故障处理人员，根据接收到的与各个故障排查任务对应的故障排查结果定位故障点。具体地，步骤s2包括如下子步骤：

s21、根据故障工单的故障信息在预设的干系人表中匹配出相应故障处理人员。

在执行该故障管理方法之前，预先构建各维度内故障信息与故障处理人员关联的干系人表。

以物流管理系统为例，故障信息包括所属维度、业务类型标识、监控指标、触发内容及故障编码等信息。

s22、根据故障信息在预设的故障排查模型中匹配相应的故障排查任务。

具体为，根据故障信息中的业务类型标识在预设的故障排查模型中匹配相应的故障排查任务。

同样的，在执行该故障管理方法之前，预先构建各维度内故障信息与故障排查任务关联的故障排查模型。

s23、根据故障信息，将故障排查任务与故障处理人员建立排查任务关联关系。

s24、基于排查任务关联关系生成并行的故障排查任务并推送至相应的故障处理人员。

每一个维度包括若干个代表不同故障位置的子维度，当触发属于某一维度的故障工单后，为了彻底排查以全面、尽快定位故障点，需要对该维度内的所有子维度进行故障排查。本实施例采用所有子维度并行式排查的方式，即同时推送排查任务至相应的故障处理人员，由相应的故障处理人员几乎在同一时间段内各自进行故障排查并生成故障排查结果。

以物流管理系统的故障管理为例，排查维度包括存储、应用、dba、开发、机房、数据中心网络、园区网络七个子维度，更进一步，排查过程中主要判断应用容器运行状态、中间件运行状态、数据库运行状态等是否为正常运行状态。

当触发stp相关故障工单后，在预先构建的干系人表及故障排查模型分别查找出相关的故障处理人员以及故障排查任务，并建立排查任务关联关系。向相应故障处理人员分别发送七个不同的排查任务并要求在一定时间段内完成排查并生成故障排查结果。

如图2所示为排查维度中开发子维度的排查任务界面，排查任务包括与“该系统链路监控告警是否正常”相关的各项运行指标是否正常的输入项，故障处理人员在通过各项运行指标的排查后进行选择输入，以给出排查结果，完成排查任务。

其中，将故障排查任务推送至相应的故障处理人员具体采用：同时触发拨号通知、创建故障管理沟通群并推送预设时间段内的生产变更信息、邮件通知的方式将故障排查任务推送至故障处理人员。

本实施例采用“一键通知”向所有的故障处理人员通过多种方式发送相应的排查任务，以提高时效。示例性的通知途径有：基于监控告警信息对应的系统id，确定系统id对应的故障处理人员清单信息，读取故障处理人员电话号码，传值调用“阿里小号”拨号功能，依据播报模板拨打故障处理人员电话播报故障系统相关信息，以及传值调用“企业微信”建群功能，创建故障处理沟通群；通过系统邮箱发送故障通知邮件给故障处理值班人员；推送当前异常系统24小时内所有生产变更信息(包括版本和变更日志)推送到企业微信即时处理群；将异常的业务监控视图定时推送到企业微信即时沟通群；基于监控告警指标对应的系统id，确定id对应的故障处理人员清单信息，推送相应的排查任务给故障处理人员。

s25、接收每一故障处理人员执行相应故障排查任务获得的故障排查结果。

每一故障处理人员在接收到故障排查任务后，即排查相应的子维度的运行数据并给出故障排查结果。如排查“24小时内该系统变更是否正常后”选择“正常”或“异常”。

s26、筛选结果为异常的故障排查结果并分析获得故障点。

具体地，筛选出异常故障排查结果，将异常故障排查结果经过预设异常关联关系或预先构建的异常分析模型等处理后定位故障点，本实施例对于具体哪一种方式并不做限制。

本实施例中的系统故障管理方法采用多维度以及并行式故障排查方式，缩短故障排查时间，提高故障排查准确性，提高故障管理效率。

故障处理过程通常需要一定的时间，在此时间段内用户无法使用相关的功能，作为一种优选地实施方式，在触发故障工单之后，该方法还包括步骤：sa、向访问用户推送与故障工单对应的替代预案，sa具体包括如下子步骤：

sa1、在预设的故障替代预案关系中查找与故障工单的故障信息匹配的若干替代预案；

sa2、当用户访问故障工单相关链路时将替代预案信息推送至用户端，替代预案信息包括替代预案建议及替代路径。

在步骤sa之前，该方法还包括：预先构建故障替代预案关系。构建方式为：盘点历史故障场景以及该故障影响的相关系统功能，为每一受影响的系统功能预设替代预案，并形成故障与替代预案之间的关联关系。当用户触发该故障时，自动向相应用户发送替代预案。

如：故障场景为：微信扫码下单功能异常，该场景下影响的业务有：散客订单下单业务。针对该场景在预先构建的故障替代预案关系中查找到替代预案为采用支付宝下单，在确认替代预案可用的情况下，向用户发送替代预案建议。

当该故障从未发生过，故障替代预案关系中并不存在相应的替代预案，则推送至相关人员请求给出替代方案，在接收到替代方案并有效执行后，将该故障及相应的替代方案添加进故障替代预案关系中。

因此，在触发故障工单后，向访问用户推送预先设置的与故障点对应的替代预案，在等待系统恢复期间，通过执行替代预案仍可实现系统功能，有效避免业务中断及用户的重复操作给服务和流量带来不必要的压力，从而提高用户使用体验。

s3、在预设的恢复预案匹配关系中查找与故障点相匹配的恢复预案，并将恢复预案按照优先级排序后推送至故障处理人员。具体地，步骤s3包括如下子步骤：

在预设的恢复预案匹配关系中查找是否有与故障点相匹配的恢复预案，若有，则将恢复预案按照优先级排序后推送至故障处理人员；

若无，则调用无预案恢复操作作为恢复预案推送至故障处理人员。

在步骤s3之前，该方法还包括：预先构建恢复预案匹配关系。构建过程为：盘点历史故障点以及所采用的恢复预案，采用统计分析等方法，统计所采用的恢复预案的使用频率、成功率等数据，为存在的多个恢复预案按照优先级排序之后形成故障点与恢复预案之间的关联关系。

s4、接收并执行故障处理人员选择的恢复预案以对系统故障进行修复。

示例性的，恢复预案包括但不限于系统重启或者版本回滚等，考虑到故障发生时间较短，版本回滚通常采用24h版本回滚。

s4之后还包括s5、验证系统故障是否完成修复，s5具体包括如下子步骤：

s51、将恢复预案执行结果推送至故障处理人员；

s52、接收故障处理人员验证故障是否恢复的验证指令，当验证指令为未恢复，则继续执行下一优先级恢复预案；

至接收到的验证指令为已恢复，结束故障工单。

需要说明的是，本实施例对于不同步骤涉及的故障处理人员并未作区分，实际应用中以分工不同酌情区分，对此并不加以限制。

实施例二

为执行上述实施例一中的系统故障管理方法，本实施例提供一种与之对应的系统故障管理装置，如图3所示，该装置至少包括：

故障工单触发模块1，用于根据接收到的故障提示信息识别系统故障并触发相应维度的故障工单；

故障点定位模块2，用于根据故障工单生成相应维度内并行的故障排查任务并分别推送至相应的故障处理人员，根据接收到的与各个故障排查任务对应的故障排查结果定位故障点；

应急预案模块3，用于在预设的恢复预案匹配关系中查找与所述故障点相匹配的恢复预案，并将恢复预案按照优先级排序后推送至故障处理人员。

故障修复模块4，用于接收并执行故障处理人员选择的恢复预案以对系统故障进行修复。

进一步地，故障工单触发模块1包括：

第一接收单元，用于根据接收到的故障提示信息识别系统故障并触发相应维度的故障工单；

推送单元，用于将所述故障提示信息推送至相应维度的故障受理人员；

故障工单触发单元，用于根据接收到的故障受理人员的受理指令，触发相应维度的故障工单。

进一步地，故障提示信息至少包括告警平台获取的多维度监控告警信息或人工告警信息中的一种；当故障提示信息为人工告警信息时，故障工单触发模块1还包括：

提取单元，用于提取人工告警信息中的故障类型关键词；

判断单元，用于根据所障类型关键词判断在预设的故障分类表中是否有匹配的故障所属维度。

故障点定位模块2包括：

第一匹配单元，用于根据故障工单的故障信息在预设的干系人表中匹配出相应故障处理人员；

第二匹配单元，用于根据所述故障信息在预设的故障排查模型中匹配相应的故障排查任务；

关联单元，用于根据所述故障信息将故障排查任务与故障处理人员建立排查任务关联关系；

生成单元，用于基于所述排查任务关联关系生成并行的故障排查任务；

第一推送单元，用于将故障排查任务推送至相应的故障处理人员；

第二接收单元，用于接收每一故障处理人员执行相应故障排查任务获得的故障排查结果；

第一处理单元，用于筛选结果为异常的故障排查结果并分析获得故障点。

应急预案模块3包括：

第一查找单元，用于在预设的恢复预案匹配关系中查找是否有与故障点相匹配的恢复预案，

第二推送单元，用于当存在与故障点相匹配的恢复预案时，将恢复预案按照优先级排序后推送至故障处理人员；还用于当不存在与故障点相匹配的恢复预案时，调用无预案恢复操作作为恢复预案推送至故障处理人员。

该装置还包括：验证模块5，用于验证系统故障是否完成修复；

第三推送单元，用于将恢复预案执行结果推送至故障处理人员；

第二处理单元，用于接收故障处理人员验证故障是否恢复后输入的验证指令，当验证指令为未恢复，则继续执行下一优先级恢复预案；至接收到的验证指令为已恢复，结束故障工单。

该装置还包括：替代预案模块6，用于向访问用户推送与所述故障工单对应的替代预案，包括：

第二查找单元，用于在预设的故障替代预案关系中查找与故障工单的故障信息匹配的若干替代预案；

第四推送单元，用于当用户访问所述故障工单相关链路时将替代预案信息推送至用户端，所述替代预案信息包括替代预案建议及替代路径。

需要说明的是：上述实施例提供的系统故障管理装置在触发实施例一中系统故障管理业务时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的一种故障管理装置与实施例一提供的一种故障管理方法的实施例属于同一构思，即该装置是基于该方法的，其具体实现过程详见方法实施例，这里不再赘述。

实施例三

对应上述方法和装置，本申请实施例三提供一种计算机系统，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

根据接收到的故障提示信息识别系统故障并触发故障工单，所述故障提示信息至少包括多维度监控告警信息及人工告警信息中的一种；

根据故障工单生成并行的故障排查任务并分别推送至相应的故障处理人员，根据接收到的与各个故障排查任务对应的故障排查结果定位故障点；

在预设的恢复预案匹配关系中查找与所述故障点相匹配的恢复预案，并将恢复预案按照优先级排序后推送至故障处理人员；

接收并执行故障处理人员选择的恢复预案以对系统故障进行修复。

图4示例性的展示出了计算机系统的架构，具体可以包括处理器1510，视频显示适配器1511，磁盘驱动器1512，输入/输出接口1513，网络接口1514，以及存储器1520。上述处理器1510、视频显示适配器1511、磁盘驱动器1512、输入/输出接口1513、网络接口1514，与存储器1520之间可以通过通信总线1530进行通信连接。

其中，处理器1510可以采用通用的cxu(centralxrocessingunit，中央处理器)、微处理器、应用专用集成电路(axxlicationsxecificintegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器1520可以采用rom(readonlymemory，只读存储器)、ram(randomaccessmemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1520可以存储用于控制计算机系统1500运行的操作系统1521，用于控制计算机系统1500的低级别操作的基本输入输出系统(bios)。另外，还可以存储网页浏览器1523，数据存储管理系统1524，以及图标字体处理系统1525等等。上述图标字体处理系统1525就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器1520中，并由处理器1510来调用执行。

输入/输出接口1513用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口1514用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。

总线1530包括一通路，在设备的各个组件(例如处理器1510、视频显示适配器1511、磁盘驱动器1512、输入/输出接口1513、网络接口1514，与存储器1520)之间传输信息。

另外，该计算机系统1500还可以从虚拟资源对象领取条件信息数据库1541中获得具体领取条件的信息，以用于进行条件判断，等等。

需要说明的是，尽管上述设备仅示出了处理器1510、视频显示适配器1511、磁盘驱动器1512、输入/输出接口1513、网络接口1514，存储器1520，总线1530等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，云服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的数据下，即可以理解并实施。

尽管已描述了本发明实施例中的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例中范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。