一种资源管理方法及相关设备与流程

本发明涉及服务器领域，尤其涉及一种资源管理方法及相关设备。

背景技术：

目前，根据系统中所有设备资源的中央处理器(centralprocessingunit，cpu)、内存、磁盘、内网流量、外网流量使用率情况，来衡量设备资源使用是否合理。资源监控系统在各服务器上部署资源监控代理(agent)，agent用于每分钟定时上报服务器cpu、内存、磁盘、内网、外网流量等资源使用情况，资源监控系统缓存这些数据，并根据在某个时间窗(通常默认1天)内上报的资源使用峰值来进行资源评定，判断某个服务器是否为低负载设备。这样，通过对系统中的各个服务器进行判定打标签，可以得到系统中服务器的资源利用率。但是，这种方式仅考虑了资源使用情况，无法全面准确的反映出资源有效利用率，影响资源管理。

技术实现要素：

本发明实施例提供一种资源管理方法及相关设备，实现了提高资源管理的准确性、提高了资源管理的效率。

第一方面，本发明实施例提供了一种资源管理的方法，包括：

获取多个服务器中每个服务器的资源使用信息、以及获取所述每个服务器的成本信息；

根据所述资源使用信息以及所述成本信息，确定所述多个服务器的资源有效投入率；

根据所述资源有效投入率以及其他指标数据，确定所述多个服务器的资源评定结果；

根据所述资源评定结果，对所述多个服务器进行资源管理。

其中，所述根据所述资源使用信息以及所述成本信息，确定所述多个服务器的资源有效投入率包括：

根据所述资源使用信息，确定所述每个服务器的负载是否达到阈值；

根据所述成本信息，统计所述负载达到阈值的服务器的第一资源成本总和、以及所述负载未达到阈值的服务器的第二资源成本总和；

根据所述第一资源成本总和以及所述第二资源成本总和，确定所述多个服务器的资源有效投入率。

其中，所述根据所述第一资源成本总和以及所述第二资源成本总和，确定所述多个服务器的资源有效投入率包括：

计算所述第一资源成本总和与所述第二资源成本总和之间的差值；

将所述差值除以所述第一资源成本总和的比值作为所述资源有效投入率。

其中，所述根据所述资源使用信息，确定所述每个服务器的负载是否达到阈值包括：

确定所述每个服务器的设备类型；

根据所述每个服务器的所述设备类型，确定所述每个服务器的负载是否达到阈值。

其中，所述获取所述每个服务器的成本信息包括：

从配置信息数据表中查找所述每个服务器的配置信息；

根据所述配置信息，从成本信息数据表中查找所述每个服务器的所述成本信息。

其中，所述从配置信息数据表中查找所述每个服务器的配置信息之前，还包括：

当所述配置信息数据表中的所述配置信息的保存时间未超过第一阈值时，从配置信息数据表中查找所述每个服务器的配置信息；或/和

当所述成本信息数据表中的所述成本信息的保存时间未超过所述第二阈值时，根据所述配置信息，从成本信息数据表中查找所述每个服务器的所述成本信息。

其中，所述根据所述资源有效投入率以及其他指标数据，确定所述多个服务器的资源评定结果包括：

计算所述资源有效投入率与所述其他指标数据的乘积作为所述资源评定结果。

其中，所述根据所述资源有效投入率以及其他指标数据，确定所述多个服务器的资源评定结果包括：

计算所述资源有效投入率和所述其他指标数据的加权平均值作为所述资源评定结果。

其中，所述其他指标数据包括安全防护成功率和版本迭代资源优化率中的至少一项。

第二方面，本发明实施例提供了一种资源管理装置，包括：

获取模块，用于获取多个服务器中每个服务器的资源使用信息、以及获取所述每个服务器的成本信息；

处理模块，用于根据所述资源使用信息以及所述成本信息，确定所述多个服务器的资源有效投入率；

所述处理模块，还用于根据所述资源有效投入率以及其他指标数据，确定所述多个服务器的资源评定结果；

管理模块，用于根据所述资源评定结果，对所述多个服务器进行资源管理。

其中，所述处理模块具体用于：

根据所述资源使用信息，确定所述每个服务器的负载是否达到阈值；

根据所述成本信息，统计所述负载达到阈值的服务器的第一资源成本总和、以及所述负载未达到阈值的服务器的第二资源成本总和；

根据所述第一资源成本总和以及所述第二资源成本总和，确定所述多个服务器的资源有效投入率。

其中，所述处理模块具体用于：

计算所述第一资源成本总和与所述第二资源成本总和之间的差值；

将所述差值除以所述第一资源成本总和的比值作为所述资源有效投入率。

其中，所述处理模块，还用于确定所述每个服务器的设备类型；根据所述每个服务器的所述设备类型，确定所述每个服务器的负载是否达到阈值。

其中，所述获取模块，还用于从配置信息数据表中查找所述每个服务器的配置信息；根据所述配置信息，从成本信息数据表中查找所述每个服务器的所述成本信息。

其中，所述处理模块，还用于确定所述配置信息数据表的保存时间是否超过第一阈值、和/或所述成本信息数据表的保存时间是否超过第二阈值；当所述配置信息数据表的保存时间未超过所述第一阈值、和/或所述成本信息数据表的保存时间未超过所述第二阈值时，执行获取多个服务器中每个服务器的资源使用信息、以及获取所述每个服务器的成本信息步骤。

其中，所述处理模块，还用于计算所述资源有效投入率与所述其他指标数据的乘积作为所述资源评定结果。

其中，所述处理模块，还用于计算所述资源有效投入率和所述其他指标数据的加权平均值作为所述资源评定结果。

其中，所述其他指标数据包括安全防护成功率和版本迭代资源优化率中的至少一项。

第三方面，本发明提供了一种资源管理设备，包括：处理器、存储器和通信总线，其中，通信总线用于实现处理器和存储器之间连接通信，处理器执行存储器中存储的程序用于实现上述第一方面提供的一种资源管理方法中的步骤。

在一个可能的设计中，本发明提供的资源管理设备可以包含用于执行上述方法中行为相对应的模块。模块可以是软件和/或是硬件。

本发明的又一方面提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有多条指令，所述指令适于由处理器加载并执行上述各方面所述的方法。

本发明的又一方面提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述各方面所述的方法。

实施本发明实施例，首先获取多个服务器中每个服务器的资源使用信息、以及获取每个服务器的成本信息；然后根据资源使用信息以及成本信息，确定多个服务器的资源有效投入率；根据资源有效投入率以及其他指标数据，确定多个服务器的资源评定结果；最后根据资源评定结果，对多个服务器进行资源管理。通过参考多个因素来确定资源评定结果，从而提高了资源管理的准确性，以及提高了资源管理的效率。

附图说明

为了更清楚地说明本发明实施例或背景技术中的技术方案，下面将对本发明实施例或背景技术中所需要使用的附图进行说明。

图1是本发明实施例提供的一种资源管理系统的结构示意图；

图2是本发明实施例提供的一种资源监控系统的结构示意图；

图3是本发明实施例提供的一种资源管理方法的流程示意图；

图4是本发明实施例提供的一种资源评定结果的示意图；

图5是本发明另一实施例提供的一种资源管理方法的流程示意图；

图6是本发明实施例提供的一种服务器布局的结构示意图；

图7是本发明实施例提供的一种资源管理装置的结构示意图；

图8是本发明实施例提出的一种资源管理设备的结构示意图。

具体实施方式

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

请参见图1，图1是本发明实施例提供的一种资源管理系统的结构示意图，该资源管理系统包括资源监控系统以及多个服务器。其中，服务器可以为业务服务器，资源监控系统可以部署在后台服务器上，后台服务器可以包括多核cpu(如4核cpu)、内存(如16g)。资源监控系统通过在多个服务器中分别部署agent来实现对每个服务器的监控，从每个服务器中获取资源使用信息。如图2所示，资源监控系统包括监控平台、配置管理数据库(configurationmanagementdatabase，cmdb)、全面预算管理系统(comprehensivebudgetsystem，obs)。其中，监控平台用于从多个服务器获取资源使用信息，cmdb主要用于存储各个服务器的配置信息，obs主要用于存储各个服务器的成本信息。资源管理系统还包括服务器硬件拉取模块、成本与配置信息拉取模块、cache层、mysql数据库、资源合理评分计算模块、运营成本计算模块以及前端页面等等。基于上述资源管理系统，本发明实施例提供了如下解决方案。

请参见图3，图3是本发明实施例提供的一种资源管理方法的流程示意图，该方法包括但不限于如下步骤：

s301，获取多个服务器中每个服务器的资源使用信息、以及获取所述每个服务器的成本信息。

一方面，可以在每个服务器中部署网管agent，每个服务器通过网管agent按照预设的时间间隔向资源监控系统中的监控平台上报资源使用信息和服务器的标识(如，ip)。其中，该资源使用信息包括cpu、内存、网卡、磁盘等硬件利用率信息和业务特性信息。服务器硬件拉取模块可以部署两个进程，包括：

第一个进程调用监控平台的应用程序接口(applicationprograminterface，api)按照预设的时间间隔从监控平台获取每个服务器上报的资源使用信息，并将最近一段时间(如7天)内上报的资源使用信息全部缓存在共享内存中。其中，预设时间间隔包括但不限于1分钟。然后使用预设字节长度的结构体缓存上述资源使用信息，预设字节长度包括但不限于12字节长度，缓存信息的结构体如下：

typedefstructresource{

intip_num；

charcpu_utilize；

charmem_utilize；

charblock_utilize；

chareth0_utilize；

chareth1_utilize；

}resource；

第二个进程可以计算最近一段时间内上报的资源使用信息。例如，可以根据资源使用信息计算峰值、平均值等信息。服务器上报资源使用信息的次数较多，为了避免偶发数据失真，在获取到一段时间内的资源使用信息之后，在计算各个硬件资源项的峰值时，可以首先去掉该段时间内峰值最高的前5个数据值，然后选取峰值第6高的数据值。在计算各个硬件资源项的使用平均值时，可以首先去掉最高的前5个数据值以及最低的5个数据值，然后计算剩余的其他数据值的加权平均值作为各个硬件资源项的平均值。同时，为了避免机器宕机故障导致内存数据丢失，服务器硬件拉取模块可以按照预设时长(如5分钟)将峰值、平均值等信息保存在mysql数据库。

另一方面，获取所述每个服务器的成本信息包括以下两种可选方式：

第一种离线计算方式，可以从配置信息数据表中查找所述每个服务器的配置信息；根据所述配置信息，从成本信息数据表中查找所述每个服务器的所述成本信息。具体包括：

cdmb采用三级业务模块来定义服务器属性。其中，第一级业务模块用于项目归属分类，第二级业务模块用于系统归属分类、第三级业务模块用于系统各功能子模块分类。在服务器上架之前，可以将服务器的配置信息记录到cdmb中，配置信息至少包括：采购上架时间(purchaseym)、采购城市(idccity)、固资号(svrassetid)、内网ip(serverlanip)、外网ip(serverwanip)、公司标准服务器型号(devicetype)、服务器版本号(serverversion)等多项信息。成本与配置信息拉取模块可以按照预设时间间隔从cdmb中获取配置信息，并添加到mysql数据库中的配置信息数据表中进行本地保存，其中，预设的时间间隔包括但不限于1天，配置信息数据表包括采购上架时间、采购城市、固资号、内网ip、外网ip、公司标准服务器型号以及服务器版本号中的至少一种。

可选的，由于配置信息记录条数在百万级别以上，为了避免配置信息数据表中的数据量逐渐增多导致查表效率降低，可以确定所述配置信息数据表中的配置信息的保存时间是否超过所述第一阈值，当所述配置信息数据表中的配置信息的保存时间超过所述第一阈值时，可以从配置信息数据表删除保存时间超过第一阈值的配置信息，当所述配置信息数据表中的配置信息的保存时间未超过所述第一阈值时，则从配置信息数据表中查找所述每个服务器的配置信息。其中，第一阈值可以包括但不限于3个月。

obs用于保存服务器采购年月份(purchaseym)、采购城市(idccity)、公司标准服务器类型(devicetype)、服务器版本号(serverversion)、当前核算年月份(costym)等多项信息，并且该多项信息分别对应唯一设备单价。可以按照预设的间隔时间对obs中保存的信息进行更新，成本与配置信息拉取模块也可以按照预设时间间隔从obs中获取成本信息，并添加到mysql数据库中的成本信息数据表进行本地保存。其中，预设时间间隔包括但不限于1个月，成本信息数据表包括服务器采购年月份、采购城市、公司标准服务器类型服务器版本号、当前核算年月份等多项配置信息、以及该多项配置信息与成本信息的对应关系。

可选的，由于成本信息记录条数在百万级别以上，为了避免成本信息数据表中的数据量逐渐增多导致查表效率降低，可以确定所述成本信息数据表中的成本信息的保存时间是否超过第二阈值，当所述成本信息数据表中的成本信息的保存时间超过第二阈值时，可以删除超过保存时间超过第二阈值的成本信息，当所述成本信息数据表中的成本信息的保存时间未超过第二阈值时，则从成本信息数据表中查找所述每个服务器的所述成本信息。其中，第二阈值可以包括但不限于3个月。

最后，在获取到上述成本信息数据表和配置信息数据表之后，可以通过双表联查遍历匹配方式，按照预设时间间隔获取各个服务器的成本信息。包括：首先从配置信息数据表中获取各个服务器的采购上架时间、采购城市、标准服务器型号、服务器版本号等配置信息，然后根据该配置信息从成本信息数据表获取各个服务器的成本信息。同时，将获取到的成本信息插入到成本计算中间表(t_device_account)作临时保存，成本计算中间表的信息字段包括：一级业务模块、二级业务模块、三级业务模块、核算年月日、上架时间、采购城市标准服务器类型、服务器版本号、服务器单价以及插入更新时间的至少一项。

第二种在线计算方式，用户可以在前端页面提交ip列表，ip列表包括用户需要查询的所有服务器的标识。该ip列表提交到资源监控系统之后，首先将ip列表拼接成json字符串参数，以post拉取方式从cdmb中获取ip列表中各个服务器的配置信息并缓存在共享内存中，然后根据配置信息，对成本信息数据表进行匹配查询，查询到的成本信息与ip列表中的各个服务器的配置信息进行组合拼接插入到成本计算实时表中。其中，成本计算实时表的信息字段在成本计算中间表已有字段基础上另外新增了业务标识(identification，id)和用户名字段，以便区别用户在不同时间段内多次提交的查询记录。

s302，根据所述资源使用信息以及所述成本信息，确定所述多个服务器的资源有效投入率。

具体实现中，可以根据所述资源使用信息，确定所述每个服务器的负载是否达到阈值；根据所述成本信息，统计所述负载达到阈值的服务器的第一资源成本总和、以及所述负载未达到阈值的服务器的第二资源成本总和；根据所述第一资源成本总和以及所述第二资源成本总和，确定所述多个服务器的资源有效投入率。

s303，根据所述资源有效投入率以及其他指标数据，确定所述多个服务器的资源评定结果。

具体实现中，可以计算所述资源有效投入率与所述其他指标数据的乘积作为所述资源评定结果。所述其他指标数据包括安全防护成功率和版本迭代资源优化率中的至少一项。资源评定结果score＝资源有效投入比*安全防护成功率*版本迭代资源优化率*100(分)。

需要说明的是，本发明实施例中资源有效投入率是影响资源评定结果最主要的参考因子，安全防护成功率和版本迭代资源优化率比较平稳，接近于100％，因此在计算资源评定结果时不作为主要参考因子。其中：

安全防护成功率＝(1-防护容量不足的失败率)*(1-蓝军反向验证攻破的成功率)。其中，防护容量不足的失败率为威胁攻击的流量超过系统当前能防护的流量的次数/系统调用防护的总次数*100％，其主要原因是防护容量不足导致攻击威胁绕过。蓝军反向验证攻破的成功率＝蓝军成功攻击突破防护的规则数/蓝军总攻击规则数*100％，其主要原因是防护自身程序存在缺陷导致攻击威胁绕过、或防护策略规则不全导致攻击威胁绕过。

在相同攻击威胁流量或包量测试情况下，版本迭代资源优化率为上一个版本程序开发消耗机器硬件资源cpu的利用率与当前版本程序消耗机器硬件资源cpu的利用率之间的比值。例如：上一个版本在100g攻击流量威胁下，防护集群cpu利用率为80％，当前版本程序经过算法调整、策略精简等优化，在100g攻击流量威胁下，防护集群cpu利用率为60％，版本迭代资源优化率：80％/60％＝1.33。

其中，获取安全防护成功率和版本迭代资源优化率的方式包括：第一种离线方式，各个服务器上部署的agent除了可以向服务器上报资源使用信息之外，还支持业务自定义上报特性数据，例如，通过监控平台的api接口，按照预设的周期向资源监控系统提交安全防护成功率和版本迭代资源优化率等数据，并缓存在共享内存中。第二种在线方式，可以由用户在前端页面向资源监控系统提交安全防护成功率和版本迭代资源优化率。

可选的，可以计算所述资源有效投入率和所述其他指标数据的加权平均值作为所述资源评定结果。其中，可以根据系统实际安全威胁情况对测定资源评定结果的参考因子进行增删，或者可以进行不同权重赋值，再计算各项参考因子的加权平均值作为资源评分结果。

s304，根据所述资源评定结果，对所述多个服务器进行资源管理。

具体实现中，可以对各个资源评定结果进行排序，为服务器的资源优化提供依据，减少当前安全设备利用率过低的情况出现。同时，根据资源评定结果可以反映出服务器资源的有效价值输出，从而为各安全系统扩缩容、资源腾挪投入提供量化依据和资源采购决策参考。

例如，如图4所示，图4是本发明实施例提供的一种资源评定结果的示意图。可以从各个系统(如，ddos防护系统、入侵检测系统、漏洞扫描系统或档案系统)中的服务器中获取资源使用信息，然后根据服务器的成本信息，计算各个系统的资源有效投入率，最后结合安全防护成功率和版本迭代资源优化率，按照预设的周期计算各个系统的资源评定结果。从图可知，同一系统在不同时间点的资源评定结果可能不同，不同系统在同一时间点的资源评定结果也可能不同。通过对同一个系统在不同时间点的资源评定结果的比较、或不同系统在同一时间点的资源评定结果的比较，对各个系统进行优化。

在本发明实施例中，首先获取多个服务器中每个服务器的资源使用信息、以及获取每个服务器的成本信息；然后根据资源使用信息以及成本信息，确定多个服务器的资源有效投入率；根据资源有效投入率以及其他指标数据，确定多个服务器的资源评定结果；最后根据资源评定结果，对多个服务器进行资源管理。通过参考多个因素来确定资源评定结果，从而提高了资源管理的准确性，以及提高了资源管理的效率。

请参见图5，图5是本发明另一实施例提供的一种资源管理方法的流程示意图，该方法包括但不限于如下步骤：

s501，获取多个服务器中每个服务器的资源使用信息、以及获取所述每个服务器的成本信息。本步骤与上一实施例相同，本发明实施例不再赘述。

s502，根据所述资源使用信息，确定所述每个服务器的负载是否达到阈值。

具体实现中，在各个服务器上报资源使用信息之后，资源监控信息可以根据一个时间窗(如，1天)内的cpu、内存、磁盘、内网或外网流量的使用峰值，判断每个服务器的负载是否达到阈值。当某个服务器的负载没有达到阈值时，则确定该服务器的为低负载设备，负载不达标。当某个服务器的负载达到阈值时，则确定该服务器的为负载达标设备。

进一步的，可以确定所述每个服务器的设备类型；根据所述每个服务器的所述设备类型，确定所述每个服务器的负载是否达到阈值。具体的，可以根据配置信息中的“公司标准服务器型号”字段判断服务器所属的设备类型，其中，设备类型包括接入类服务器、逻辑类服务器、cache类服务器、存储类服务器、db类服务器以及离线计算类服务器。每种设备类型的服务器设定不同的负载判定标准。

例如，cpu利用率<20％且内存使用量占比<60％且内网流量占比<16％且外网流量占比<12％时，则确定接入类的服务器负载不达标。cpu利用率<25％且内网流量占比<16％，则确定逻辑类的服务器负载不达标。cpu利用率<20％且内存使用量占比<60％且内网流量占比<16％，则确定cache类的服务器负载不达标。cpu利用率<20％且内网流量占比<16％且磁盘存储量占比<40％且磁盘bio占比<40％，则存储类的服务器负载不达标。cpu利用率<20％且磁盘存储量占比<40％且磁盘bio占比<40％，则db类的服务器负载不达标，cpu利用率<20％且磁盘存储量占比<40％且磁盘bio占比<40％，则离线计算类的服务器负载不达标。

如图6所示，图6是本发明实施例提供的一种服务器布局的结构示意图。其中，接入类的服务器的设备量为655，39.8％的服务器负载不达标。逻辑类的服务器的设备量3416，24.8％的服务器负载不达标。cache的服务器的设备量为69，46％的服务器负载不达标。存储类的服务器的设备量为436，37.8％的服务器负载不达标。db类的服务器的设备量为365，27.7％的服务器的负载不达标。离线计算类的服务器的设备量为246，0.4％的服务器负载不达标。

s503，根据所述成本信息，统计所述负载达到阈值的服务器的第一资源成本总和、以及所述负载未达到阈值的服务器的第二资源成本总和。

具体的，在判断各个服务器的负载是否达到阈值之后，对各个服务器进行打标签，将负载达到阈值的服务器划分为第一类，将负载未达到阈值的服务器划分为第二类。分别计算第一类中所有服务器的成本信息之和作为第一资源成本总和、和第二类中所有服务器的成本信息之和作为第二资源成本总和。

s504，根据所述第一资源成本总和以及所述第二资源成本总和，确定所述多个服务器的资源有效投入率。

具体的，可以计算所述第一资源成本总和与所述第二资源成本总和之间的差值；将所述差值除以所述第一资源成本总和的比值作为所述资源有效投入率。计算公式如下：资源有效投入率＝(第一资源成本总和-第二资源成本总和)/第一资源成本总和。

s505，根据所述资源有效投入率以及其他指标数据，确定所述多个服务器的资源评定结果。本步骤与上一实施例相同，本发明实施例不再赘述。

s506，根据所述资源评定结果，对所述多个服务器进行资源管理。本步骤与上一实施例相同，本发明实施例不再赘述。

上述详细阐述了本发明实施例的方法，下面提供了本发明实施例的装置。

请参见图7，图7是本发明实施例提供的一种资源管理装置的结构示意图，该资源管理装置可以包括：

获取模块701，用于获取多个服务器中每个服务器的资源使用信息、以及获取所述每个服务器的成本信息。

一方面，可以在每个服务器中部署网管agent，每个服务器通过网管agent按照预设的时间间隔向资源监控系统中的监控平台上报资源使用信息和服务器的标识(如，ip)。其中，该资源使用信息包括cpu、内存、网卡、磁盘等硬件利用率信息和业务特性信息。服务器硬件拉取模块可以部署两个进程，包括：

第一个进程调用监控平台的应用程序接口(applicationprograminterface，api)按照预设的时间间隔从监控平台获取每个服务器上报的资源使用信息，并将最近一段时间(如7天)内上报的资源使用信息全部缓存在共享内存中。其中，预设时间间隔包括但不限于1分钟。然后使用预设字节长度的结构体缓存上述资源使用信息，预设字节长度包括但不限于12字节长度，缓存信息的结构体如下：

第二个进程可以计算最近一段时间内上报的资源使用信息。例如，可以根据资源使用信息计算峰值、平均值等信息。服务器上报资源使用信息的次数较多，为了避免偶发数据失真，在获取到一段时间内的资源使用信息之后，在计算各个硬件资源项的峰值时，可以首先去掉该段时间内峰值最高的前5个数据值，然后选取峰值第6高的数据值。在计算各个硬件资源项的使用平均值时，可以首先去掉最高的前5个数据值以及最低的5个数据值，然后计算剩余的其他数据值的加权平均值作为各个硬件资源项的平均值。同时，为了避免机器宕机故障导致内存数据丢失，服务器硬件拉取模块可以按照预设时长(如5分钟)将峰值、平均值等信息保存在mysql数据库。

另一方面，获取所述每个服务器的成本信息包括以下两种可选方式：

第一种离线计算方式，可以从配置信息数据表中查找所述每个服务器的配置信息；根据所述配置信息，从成本信息数据表中查找所述每个服务器的所述成本信息。具体包括：

cdmb采用三级业务模块来定义服务器属性。其中，第一级业务模块用于项目归属分类，第二级业务模块用于系统归属分类、第三级业务模块用于系统各功能子模块分类。在服务器上架之前，可以将服务器的配置信息记录到cdmb中，配置信息至少包括：采购上架时间(purchaseym)、采购城市(idccity)、固资号(svrassetid)、内网ip(serverlanip)、外网ip(serverwanip)、公司标准服务器型号(devicetype)、服务器版本号(serverversion)等多项信息。成本与配置信息拉取模块可以按照预设时间间隔从cdmb中获取配置信息，并添加到mysql数据库中的配置信息数据表中进行本地保存，其中，预设的时间间隔包括但不限于1天，配置信息数据表包括采购上架时间、采购城市、固资号、内网ip、外网ip、公司标准服务器型号以及服务器版本号中的至少一种。

可选的，由于配置信息记录条数在百万级别以上，为了避免配置信息数据表中的数据量逐渐增多导致查表效率降低，可以确定所述配置信息数据表中的配置信息的保存时间是否超过所述第一阈值，当所述配置信息数据表中的配置信息的保存时间超过所述第一阈值时，可以从配置信息数据表删除保存时间超过第一阈值的配置信息，当所述配置信息数据表中的配置信息的保存时间未超过所述第一阈值时，则从配置信息数据表中查找所述每个服务器的配置信息。其中，第一阈值可以包括但不限于3个月。

obs用于保存服务器采购年月份(purchaseym)、采购城市(idccity)、公司标准服务器类型(devicetype)、服务器版本号(serverversion)、当前核算年月份(costym)等多项信息，并且该多项信息分别对应唯一设备单价。可以按照预设的间隔时间对obs中保存的信息进行更新，成本与配置信息拉取模块也可以按照预设时间间隔从obs中获取成本信息，并添加到mysql数据库中的成本信息数据表进行本地保存。其中，预设时间间隔包括但不限于1个月，成本信息数据表包括服务器采购年月份、采购城市、公司标准服务器类型服务器版本号、当前核算年月份等多项配置信息、以及该多项配置信息与成本信息的对应关系。

可选的，由于成本信息记录条数在百万级别以上，为了避免成本信息数据表中的数据量逐渐增多导致查表效率降低，可以确定所述成本信息数据表中的成本信息的保存时间是否超过第二阈值，当所述成本信息数据表中的成本信息的保存时间超过第二阈值时，可以删除超过保存时间超过第二阈值的成本信息，当所述成本信息数据表中的成本信息的保存时间未超过第二阈值时，则从成本信息数据表中查找所述每个服务器的所述成本信息。其中，第二阈值可以包括但不限于3个月。

最后，在获取到上述成本信息数据表和配置信息数据表之后，可以通过双表联查遍历匹配方式，按照预设时间间隔获取各个服务器的成本信息。包括：首先从配置信息数据表中获取各个服务器的采购上架时间、采购城市、标准服务器型号、服务器版本号等配置信息，然后根据该配置信息从成本信息数据表获取各个服务器的成本信息。同时，将获取到的成本信息插入到成本计算中间表(t_device_account)作临时保存，成本计算中间表的信息字段包括：一级业务模块、二级业务模块、三级业务模块、核算年月日、上架时间、采购城市标准服务器类型、服务器版本号、服务器单价以及插入更新时间的至少一项。

第二种在线计算方式，用户可以在前端页面提交ip列表，ip列表包括用户需要查询的所有服务器的标识。该ip列表提交到资源监控系统之后，首先将ip列表拼接成json字符串参数，以post拉取方式从cdmb中获取ip列表中各个服务器的配置信息并缓存在共享内存中，然后根据配置信息，对成本信息数据表进行匹配查询，查询到的成本信息与ip列表中的各个服务器的配置信息进行组合拼接插入到成本计算实时表中。其中，成本计算实时表的信息字段在成本计算中间表已有字段基础上另外新增了业务标识(identification，id)和用户名字段，以便区别用户在不同时间段内多次提交的查询记录。

处理模块702，用于根据所述资源使用信息以及所述成本信息，确定所述多个服务器的资源有效投入率。

首先，可以根据所述资源使用信息，确定所述每个服务器的负载是否达到阈值。在各个服务器上报资源使用信息之后，资源监控信息可以根据一个时间窗(如，1天)内的cpu、内存、磁盘、内网或外网流量的使用峰值，判断每个服务器的负载是否达到阈值。当某个服务器的负载没有达到阈值时，则确定该服务器的为低负载设备，负载不达标。当某个服务器的负载达到阈值时，则确定该服务器的为负载达标设备。

进一步的，可以确定所述每个服务器的设备类型；根据所述每个服务器的所述设备类型，确定所述每个服务器的负载是否达到阈值。具体的，可以根据配置信息中的“公司标准服务器型号”字段判断服务器所属的设备类型，其中，设备类型包括接入类服务器、逻辑类服务器、cache类服务器、存储类服务器、db类服务器以及离线计算类服务器。每种设备类型的服务器设定不同的负载判定标准。

例如，cpu利用率<20％且内存使用量占比<60％且内网流量占比<16％且外网流量占比<12％时，则确定接入类的服务器负载不达标。cpu利用率<25％且内网流量占比<16％，则确定逻辑类的服务器负载不达标。cpu利用率<20％且内存使用量占比<60％且内网流量占比<16％，则确定cache类的服务器负载不达标。cpu利用率<20％且内网流量占比<16％且磁盘存储量占比<40％且磁盘bio占比<40％，则存储类的服务器负载不达标。cpu利用率<20％且磁盘存储量占比<40％且磁盘bio占比<40％，则db类的服务器负载不达标，cpu利用率<20％且磁盘存储量占比<40％且磁盘bio占比<40％，则离线计算类的服务器负载不达标。

如图4所示，图4是本发明实施例提供的一种服务器布局的结构示意图。其中，接入类的服务器的设备量为655，39.8％的服务器负载不达标。逻辑类的服务器的设备量3416，24.8％的服务器负载不达标。cache的服务器的设备量为69，46％的服务器负载不达标。存储类的服务器的设备量为436，37.8％的服务器负载不达标。db类的服务器的设备量为365，27.7％的服务器的负载不达标。离线计算类的服务器的设备量为246，0.4％的服务器负载不达标。

然后，根据所述成本信息，统计所述负载达到阈值的服务器的第一资源成本总和、以及所述负载未达到阈值的服务器的第二资源成本总和。具体的，在判断各个服务器的负载是否达到阈值之后，对各个服务器进行打标签，将负载达到阈值的服务器划分为第一类，将负载未达到阈值的服务器划分为第二类。分别计算第一类中所有服务器的成本信息之和作为第一资源成本总和、和第二类中所有服务器的成本信息之和作为第二资源成本总和。

最后，根据所述第一资源成本总和以及所述第二资源成本总和，确定所述多个服务器的资源有效投入率。具体的，可以计算所述第一资源成本总和与所述第二资源成本总和之间的差值；将所述差值除以所述第一资源成本总和的比值作为所述资源有效投入率。计算公式如下：资源有效投入率＝(第一资源成本总和-第二资源成本总和)/第一资源成本总和。

处理模块702，还用于根据所述资源有效投入率以及其他指标数据，确定所述多个服务器的资源评定结果。

具体实现中，可以计算所述资源有效投入率与所述其他指标数据的乘积作为所述资源评定结果。所述其他指标数据包括安全防护成功率和版本迭代资源优化率中的至少一项。资源评定结果score＝资源有效投入比*安全防护成功率*版本迭代资源优化率*100(分)。

需要说明的是，本发明实施例中资源有效投入率是影响资源评定结果最主要的参考因子，安全防护成功率和版本迭代资源优化率比较平稳，接近于100％，因此在计算资源评定结果时不作为主要参考因子。其中：

安全防护成功率＝(1-防护容量不足的失败率)*(1-蓝军反向验证攻破的成功率)。其中，防护容量不足的失败率为威胁攻击的流量超过系统当前能防护的流量的次数/系统调用防护的总次数*100％，其主要原因是防护容量不足导致攻击威胁绕过。蓝军反向验证攻破的成功率＝蓝军成功攻击突破防护的规则数/蓝军总攻击规则数*100％，其主要原因是防护自身程序存在缺陷导致攻击威胁绕过、或防护策略规则不全导致攻击威胁绕过。

在相同攻击威胁流量或包量测试情况下，版本迭代资源优化率为上一个版本程序开发消耗机器硬件资源cpu的利用率与当前版本程序消耗机器硬件资源cpu的利用率之间的比值。例如：上一个版本在100g攻击流量威胁下，防护集群cpu利用率为80％，当前版本程序经过算法调整、策略精简等优化，在100g攻击流量威胁下，防护集群cpu利用率为60％，版本迭代资源优化率：80％/60％＝1.33。

其中，获取安全防护成功率和版本迭代资源优化率的方式包括：第一种离线方式，各个服务器上部署的agent除了可以向服务器上报资源使用信息之外，还支持业务自定义上报特性数据，例如，通过监控平台的api接口，按照预设的周期向资源监控系统提交安全防护成功率和版本迭代资源优化率等数据，并缓存在共享内存中。第二种在线方式，可以由用户在前端页面向资源监控系统提交安全防护成功率和版本迭代资源优化率。

可选的，可以计算所述资源有效投入率和所述其他指标数据的加权平均值作为所述资源评定结果。其中，可以根据系统实际安全威胁情况对测定资源评定结果的参考因子进行增删，或者可以进行不同权重赋值，再计算各项参考因子的加权平均值作为资源评分结果。

管理模块703，用于根据所述资源评定结果，对所述多个服务器进行资源管理。

具体实现中，可以对各个资源评定结果进行排序，为服务器的资源优化提供依据，减少当前安全设备利用率过低的情况出现。同时，根据资源评定结果可以反映出服务器资源的有效价值输出，从而为各安全系统扩缩容、资源腾挪投入提供量化依据和资源采购决策参考。

例如，如图4所示，图4是本发明实施例提供的一种资源评定结果的示意图。可以从各个系统(如，ddos防护系统、入侵检测系统、漏洞扫描系统或档案系统)中的服务器中获取资源使用信息，然后根据服务器的成本信息，计算各个系统的资源有效投入率，最后结合安全防护成功率和版本迭代资源优化率，按照预设的周期计算各个系统的资源评定结果。从图可知，同一系统在不同时间点的资源评定结果可能不同，不同系统在同一时间点的资源评定结果也可能不同。通过对同一个系统在不同时间点的资源评定结果的比较、或不同系统在同一时间点的资源评定结果的比较，对各个系统进行优化。

在本发明实施例中，首先获取多个服务器中每个服务器的资源使用信息、以及获取每个服务器的成本信息；然后根据资源使用信息以及成本信息，确定多个服务器的资源有效投入率；根据资源有效投入率以及其他指标数据，确定多个服务器的资源评定结果；最后根据资源评定结果，对多个服务器进行资源管理。通过参考多个因素来确定资源评定结果，从而提高了资源管理的准确性，以及提高了资源管理的效率。

请继续参考图8，图8是本发明实施例提出的一种资源管理设备的结构示意图。如图所示，该资源管理设备可以包括：至少一个处理器801，至少一个通信接口802，至少一个存储器803和至少一个通信总线804。

其中，处理器801可以是中央处理器单元，通用处理器，数字信号处理器，专用集成电路，现场可编程门阵列或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本发明公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，数字信号处理器和微处理器的组合等等。通信总线804可以是外设部件互连标准pci总线或扩展工业标准结构eisa总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信总线804用于实现这些组件之间的连接通信。其中，本发明实施例中设备的通信接口802用于与其他节点设备进行信令或数据的通信。存储器803可以包括易失性存储器，例如非挥发性动态随机存取内存(nonvolatilerandomaccessmemory，nvram)、相变化随机存取内存(phasechangeram，pram)、磁阻式随机存取内存(magetoresistiveram，mram)等，还可以包括非易失性存储器，例如至少一个磁盘存储器件、电子可擦除可编程只读存储器(electricallyerasableprogrammableread-onlymemory，eeprom)、闪存器件，例如反或闪存(norflashmemory)或是反及闪存(nandflashmemory)、半导体器件，例如固态硬盘(solidstatedisk，ssd)等。存储器803可选的还可以是至少一个位于远离前述处理器801的存储装置。存储器803中存储一组程序代码，且处理器801执行存储器803中的程序。

获取多个服务器中每个服务器的资源使用信息、以及获取所述每个服务器的成本信息；

根据所述资源使用信息以及所述成本信息，确定所述多个服务器的资源有效投入率；

根据所述资源有效投入率以及其他指标数据，确定所述多个服务器的资源评定结果；

根据所述资源评定结果，对所述多个服务器进行资源管理。

可选的，处理器801还用于执行如下操作步骤：

根据所述资源使用信息，确定所述每个服务器的负载是否达到阈值；

根据所述成本信息，统计所述负载达到阈值的服务器的第一资源成本总和、以及所述负载未达到阈值的服务器的第二资源成本总和；

根据所述第一资源成本总和以及所述第二资源成本总和，确定所述多个服务器的资源有效投入率。

可选的，处理器801还用于执行如下操作步骤：

计算所述第一资源成本总和与所述第二资源成本总和之间的差值；

将所述差值除以所述第一资源成本总和的比值作为所述资源有效投入率。

可选的，处理器801还用于执行如下操作步骤：

确定所述每个服务器的设备类型；

根据所述每个服务器的所述设备类型，确定所述每个服务器的负载是否达到阈值。

可选的，处理器801还用于执行如下操作步骤：

从配置信息数据表中查找所述每个服务器的配置信息；

根据所述配置信息，从成本信息数据表中查找所述每个服务器的所述成本信息。

可选的，处理器801还用于执行如下操作步骤：

当所述配置信息数据表中的所述配置信息的保存时间未超过第一阈值时，从配置信息数据表中查找所述每个服务器的配置信息；或/和

当所述成本信息数据表中的所述成本信息的保存时间未超过所述第二阈值时，根据所述配置信息，从成本信息数据表中查找所述每个服务器的所述成本信息。

可选的，处理器801还用于执行如下操作步骤：

计算所述资源有效投入率与所述其他指标数据的乘积作为所述资源评定结果。

可选的，处理器801还用于执行如下操作步骤：

计算所述资源有效投入率和所述其他指标数据的加权平均值作为所述资源评定结果。

其中，所述其他指标数据包括安全防护成功率和版本迭代资源优化率中的至少一项。

进一步的，处理器还可以与存储器和通信接口相配合，执行上述发明实施例中资源管理装置的操作。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk(ssd))等。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。