一种整机系统诊断平台的优化方法、系统、装置及介质与流程

1.本发明涉及计算机技术领域，更具体的说是涉及一种整机系统诊断平台的优化方法、系统、装置及介质。


背景技术：

2.随着现代互联网的急速发展，尤其是“大数据”、“人工智能”等需求驱动着数字经济的高速发展，服务器的需求量也呈指数级增长。并且为了满足不同客户的各种定制化需求，服务器生产厂商会推出各种常规和非常规配置的机型。另一方面，当前各行业对服务器运行稳定性和并发处理能力要求越来越高，尤其是金融行业和互联网行业，要求在较短时间及负载运行情况下，完成服务器的诊断检测及维修服务。服务器的规模庞大，配置丰富，在研发、生产以及故障诊断中都带来了较大的难度，人工检验时间长且无法做到面面俱到，因此在服务器生产的过程中，需要对服务器整机进行一套系统、全面的诊断和检验，将故障和异常全部消灭在出厂前。关于服务器整机诊断，从最初的脚本运维、工具运维到平台化运维发展至今，需要人为介入的场景依然占据着比较大的空间，对运维人员的工作经验要求较高，且工作量较为繁重。面对着越来越多的定制化需求，人力成本不断提升，无法满足系统故障诊断自动化的要求。
3.服务器整机系统诊断平台当前面临的一大痛点的是成本高、时效性差。整机诊断的过程中出现了问题主要基于人工分析和经验判断结果，人工经验分析依赖大量研发和运维的人力投入。在这些故障中，有相当一部分的问题在澄清之后，还需要反馈到诊断系统中做出修正以适配，从故障的分析到系统的热修，是一个漫长且具有一定风险的过程。对于诊断平台而言，定期的系统升级已然无法满足对各种定制化配置的诊断，在定期升级的间隙中穿插了大量的系统热修，这违背了系统诊断自动化、智能化的思维。
4.目前比较常规的整机系统诊断平台，其部署形式是将诊断程序源代码以文件的形式放置于服务器中，在进行生产时，由待检测机器通过局域网下载源代码文件然后执行诊断程序。整机系统诊断平台的源码通过版本控制工具管控，系统的升级和运维需要按照流程进行严格的管控。待检测机器发生故障后，由研发或运维人员介入，发现问题并澄清，如果需要在诊断平台放行通过，需要对诊断平台进行hotfix(俗称在线修复)。这个过程相对耗时较长。在系统定期维护的间隙，往往伴随着多次的hotfix，对产线的生产环境会产生一定的风险，进而有可能使产线的生产发生大规模的中断。
5.可见，针对目前服务器整机系统诊断的痛点问题，如何快速提升整机诊断系统平台处理处理服务器故障的准确率和实效性，降低运维成本，提升诊断效能，是当下亟待解决的新课题。


技术实现要素：

6.针对以上问题，本发明的目的在于提供一种整机系统诊断平台的优化方法、系统、装置及介质，可以大量的减少由于hotfix带来的程序部署的频次，降低了运维的工作量和
生产异常的风险。
7.本发明为实现上述目的，通过以下技术方案实现：一种整机系统诊断平台的优化方法，包括：
8.将整机系统诊断平台拆分为系统层和业务层；
9.为整机系统诊断平台构建新型数据库系统，新型数据库系统包括关系型数据库和非关系型数据库；
10.改造业务层程序代码的部署形式；
11.通过整机系统诊断平台收集待检测机器的运行数据，并输入训练完成的诊断模型进行故障诊断。
12.进一步，所述将整机系统诊断平台拆分为系统层和业务层，包括：
13.在整机系统诊断平台中设置系统层，用于执行并监控运维人员部署的定制化脚本，监控系统诊断的流程，在服务器检测的过程中收集服务器预设部件的基础信息，实时反馈服务器的运行状态，收集系统日志。
14.进一步，所述将整机系统诊断平台拆分为系统层和业务层，还包括：
15.将系统层的源码固化为以文件存储为载体、通过版本控制工具进行管控、定期维护升级的一组固化程序，并存放于中央服务器中。
16.进一步，所述将整机系统诊断平台拆分为系统层和业务层，包括：
17.在整机系统诊断平台中设置业务层，所述业务层采用运行在系统层之上的诊断检查程序，用于获取部件配置及固件版本信息、衡量部件传感器信息指标、部件压力测试、系统以及部件日志故障排查。
18.进一步，所述关系型数据库采用oracle或mysql，用于保存业务层脚本和程序的代码，并保存代码的版本信息；所述非关系型数据库采用文档型数据库mongodb，用于存储待检测机器运行时的部件信息、实时状态以及运行中产生的文档数据。
19.进一步，所述改造业务层程序代码的部署形式，包括：对系统层和业务层进行功能解耦；解耦完成后，将系统层的源代码以文件为载体存储在中央服务器；在系统层之上开发管理模块，引入在线代码编辑器框架，通过此编辑器进行运维脚本的开发、语法检查、测试；将版本控制功能组件的代码以二进制的形式存入新型数据库系统；将诊断规则和指标、压力测试的阈值、系统日志的黑白名单提取出来，通过对服务器生产诊断的调研，调整提取的指标类数据，并存储在管理模块。
20.进一步，所述通过整机系统诊断平台收集待检测机器的运行数据，并输入训练完成的诊断模型进行故障诊断，包括：
21.通过整机系统诊断平台收集待检测机器的运行数据，所述运行数据包括在生产过程中部件的配置信息、固件版本信息、性能指标、压力测试数据、产生的系统日志和bmc sel日志；将运行数据作为故障诊断的运行特征，输入训练完成的诊断模型进行故障诊断，输出诊断结果；收集诊断结果，并进行诊断结果分类，统计出每种配置的机型在各个环节出现单体故障的故障率。
22.相应的，本发明还公开了一种整机系统诊断平台的优化系统，包括：
23.功能拆分模块，用于将整机系统诊断平台拆分为系统层和业务层；
24.数据库构建模块，用于为整机系统诊断平台构建新型数据库系统，新型数据库系
统包括关系型数据库和非关系型数据库；
25.部署模块，用于改造业务层程序代码的部署形式；
26.故障诊断模块，用于通过整机系统诊断平台收集待检测机器的运行数据，并输入训练完成的诊断模型进行故障诊断。
27.相应的，本发明公开了一种整机系统诊断平台的优化装置，包括：
28.存储器，用于存储整机系统诊断平台的优化程序；
29.处理器，用于执行所述整机系统诊断平台的优化程序时实现如上文任一项所述整机系统诊断平台的优化方法的步骤。
30.相应的，本发明公开了一种可读存储介质，所述可读存储介质上存储有整机系统诊断平台的优化程序，所述整机系统诊断平台的优化程序被处理器执行时实现如上文任一项所述整机系统诊断平台的优化方法的步骤。
31.对比现有技术，本发明有益效果在于：本发明提供了一种整机系统诊断平台的优化方法、系统、装置及介质，在传统系统诊断平台的基础上，将各项诊断功能、性能指标、压力阈值、故障黑白名单抽象出来，以二进制的形式存储于平台数据库中，通过一个独立的web功能进行维护，其维护与发布形式灵活，即时生效，不依赖、不影响整体系统的升级迭代。在生产过程中收集故障信息以及系统日志进行分析，为安全生产做出规范性指导。本发明能够减少整机系统诊断平台hotfix的频次，增强平台的可维护性，提升运维的效率，降低运维风险。
32.由此可见，本发明与现有技术相比，具有突出的实质性特点和显著的进步，其实施的有益效果也是显而易见的。
附图说明
33.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
34.图1是本发明具体实施方式的方法流程图。
35.图2是本发明具体实施方式的系统结构图。
36.图中，1、功能拆分模块；2、数据库构建模块；3、部署模块；4、故障诊断模块。
具体实施方式
37.为了使本技术领域的人员更好地理解本发明方案，下面结合附图和具体实施方式对本发明作进一步的详细说明。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
38.实施例一：
39.如图1所示，本实施例提供了一种整机系统诊断平台的优化方法，包括如下步骤：
40.s1：将整机系统诊断平台拆分为系统层和业务层。
41.作为示例的，在整机系统诊断平台中设置系统层，用于执行并监控运维人员部署
的定制化脚本，监控系统诊断的流程，在服务器检测的过程中收集服务器预设部件的基础信息，实时反馈服务器的运行状态，收集系统日志。其中，将系统层的源码固化为以文件存储为载体、通过版本控制工具进行管控、定期维护升级的一组固化程序，并存放于中央服务器中。同时，在整机系统诊断平台中设置业务层，所述业务层采用运行在系统层之上的诊断检查程序，用于获取部件配置及固件版本信息、衡量部件传感器信息指标、部件压力测试、系统以及部件日志故障排查。
42.具体来说：
43.从整机系统诊断平台的功能性方面，这里将平台划分为系统层和业务层。系统层指的是支撑整个系统稳定运行的底层逻辑，负责执行并监控运维人员部署的定制化脚本，监控系统诊断的流程，在服务器检测的过程中收集服务器各大部件(cpu、gpu、内存、硬盘等)的基础信息，实时反馈服务器的运行状态，收集各类系统日志。由于系统层功能趋于稳定，迭代频率较小，因此将系统层的源码固化为以文件存储为载体、通过版本控制工具进行管控、定期维护升级的一组固化的程序，存放于中央服务器中。
44.业务层指的是运行在系统层之上的一系列的诊断检查程序，包括不限于部件配置及固件版本信息、衡量部件传感器信息指标、部件压力测试、系统以及部件日志故障排查以及其他的定制化检查。不同型号的服务器或者同一型号但不同配置的服务器，往往搭载的部件和固件版本各不相同，并且同一部件也会有不同型号不同代次的差别，因此对于这些内容的检查可能也会略有不同。为了应对这类问题，需要时常对检测程序做出调整以适配不同的情况。通过对整机系统诊断平台各功能的分析和识别，将系统层和业务层功能进行拆分、解耦，使得运维人员可以更方便的维护业务层功能。
45.s2：为整机系统诊断平台构建新型数据库系统，新型数据库系统包括关系型数据库和非关系型数据库。
46.其中，关系型数据库采用oracle或mysql，用于保存业务层脚本和程序的代码，并保存代码的版本信息；非关系型数据库采用文档型数据库mongodb，用于存储待检测机器运行时的部件信息、实时状态以及运行中产生的文档数据。
47.具体来说：
48.重新设计整机系统诊断平台的数据库，选用的数据库类型包含关系型数据库和非关系型数据库。关系型数据库指的是采用了关系模型来组织数据的数据库以行和列的形式存储数据。关系型数据库按照结构化的方式存储数据，数据表必须预先定义好表的结构，再根据表结构存入数据。由于数据的形式和内容在存入之前就已经定义好了，所以整个数据表的可靠性和稳定性都比较高。主流的关系型数据库有oracle、mysql等。在整机系统诊断平台中，使用关系型数据库保存业务层脚本和程序的代码，并且保存代码的版本信息，以便进行简单的提交和回退(相当于备份)。
49.随着互联网web2.0网站的兴起，传统的关系型数据库在处理大规模和高并发的动态数据领域已经显得力不从心，出现了很多难以克服的问题，非关系数据库的诞生就是为了解决大规模数据集合多重数据种类带来的挑战。非关系型数据库的一大优势是不再关注传统数据库的关系型特性，数据之间无关系，从架构的层面上提升了可扩展的能力。在本系统中采用文档型数据库(mongodb)，存储待检测机器运行时的部件信息、实时状态以及运行中产生的各类日志等半结构化的文档数据，以便后续进行故障分析。
50.s3：改造业务层程序代码的部署形式。
51.本步骤包括：对系统层和业务层进行功能解耦；解耦完成后，将系统层的源代码以文件为载体存储在中央服务器；在系统层之上开发管理模块，引入在线代码编辑器框架，通过此编辑器进行运维脚本的开发、语法检查、测试；将版本控制功能组件的代码以二进制的形式存入新型数据库系统；将诊断规则和指标、压力测试的阈值、系统日志的黑白名单提取出来，通过对服务器生产诊断的调研，调整提取的指标类数据，并存储在管理模块。
52.作为示例的，系统层和业务层功能解耦之后，系统层功能的源代码维持现状，以文件为载体存储于中央服务器。在系统层之上开发管理模块，引入在线代码编辑器框架，通过此编辑器完成运维脚本的开发、语法检查、测试。同时具备基础的版本控制功能(提交和回退)，开发完成后将代码以二进制的形式存入数据库。同时还需要将诊断规则和指标、压力测试的阈值、系统日志的黑白名单等提取出来。通过对服务器生产诊断的调研，在生产过程中，调整这些指标类数据在运维工作中占据较大的比重，使用管理模块存储此类数据，可以做到快速的维护和调整，并且调整完成之后可以立即生效，无需通过修改源代码的形式进行发布，提升了运维的效率，降低风险。
53.s4：通过整机系统诊断平台收集待检测机器的运行数据，并输入训练完成的诊断模型进行故障诊断。
54.作为示例的，通过整机系统诊断平台收集待检测机器的运行数据，所述运行数据包括在生产过程中部件的配置信息、固件版本信息、性能指标、压力测试数据、产生的系统日志和bmc sel日志；将运行数据作为故障诊断的运行特征，输入训练完成的诊断模型进行故障诊断，输出诊断结果；收集诊断结果，并进行诊断结果分类，统计出每种配置的机型在各个环节出现单体故障的故障率。
55.具体来说：通过整机系统诊断平台，收集待检测机器的运行数据，包括在生产过程中各类部件的配置信息、固件版本信息、性能指标、压力测试数据、产生的系统日志、bmc sel日志，作为故障诊断的运行特征，输入已训练完成的诊断模型进行故障诊断。所谓的诊断模型是指通过机器学习框架，基于大量的运行数据、故障信息和诊断结果，自动训练出的故障诊断结果最为准确的目标模型，基于此模型，预测出相应的诊断结果。当待检测机器各部件发生迭代升级，可以通过平台进行简单而快捷的维护，调整相应的性能指标和压力阈值，做出更加精确的整机诊断。
56.另外，在生产过程中，收集各类待检测机器生产中出现的故障并进行分类，统计不同的机型，不同的配置，在各个环节出现的单体故障的故障率，为产线的安全生产做出规范性指导。
57.本实施例提供了一种整机系统诊断平台的优化方法，在传统系统诊断平台的基础上，将各项诊断功能、性能指标、压力阈值、故障黑白名单抽象出来，以二进制的形式存储于平台数据库中，通过一个独立的web功能进行维护，其维护与发布形式灵活，即时生效，不依赖、不影响整体系统的升级迭代。在生产过程中收集故障信息以及系统日志进行分析，为安全生产做出规范性指导。本方法能够减少整机系统诊断平台hotfix的频次，增强平台的可维护性，提升运维的效率，降低运维风险。
58.实施例二：
59.基于实施例一，如图2所示，本发明还公开了一种整机系统诊断平台的优化系统，
包括：功能拆分模块1、数据库构建模块2、部署模块3和故障诊断模块4。
60.功能拆分模块1，用于将整机系统诊断平台拆分为系统层和业务层。
61.数据库构建模块2，用于为整机系统诊断平台构建新型数据库系统，新型数据库系统包括关系型数据库和非关系型数据库。
62.部署模块3，用于改造业务层程序代码的部署形式。
63.故障诊断模块4，用于通过整机系统诊断平台收集待检测机器的运行数据，并输入训练完成的诊断模型进行故障诊断。
64.本实施例提供了一种整机系统诊断平台的优化系统，能够减少整机系统诊断平台hotfix的频次，增强平台的可维护性，提升运维的效率，降低运维风险。
65.实施例三：
66.本实施例公开了一种整机系统诊断平台的优化装置，包括处理器和存储器；其中，所述处理器执行所述存储器中保存的整机系统诊断平台的优化程序时实现以下步骤：
67.1、将整机系统诊断平台拆分为系统层和业务层。
68.2、为整机系统诊断平台构建新型数据库系统，新型数据库系统包括关系型数据库和非关系型数据库。
69.3、改造业务层程序代码的部署形式。
70.4、通过整机系统诊断平台收集待检测机器的运行数据，并输入训练完成的诊断模型进行故障诊断。
71.进一步的，本实施例中的整机系统诊断平台的优化装置，还可以包括：
72.输入接口，用于获取外界导入的整机系统诊断平台的优化程序，并将获取到的整机系统诊断平台的优化程序保存至所述存储器中，还可以用于获取外界终端设备传输的各种指令和参数，并传输至处理器中，以便处理器利用上述各种指令和参数展开相应的处理。本实施例中，所述输入接口具体可以包括但不限于usb接口、串行接口、语音输入接口、指纹输入接口、硬盘读取接口等。
73.输出接口，用于将处理器产生的各种数据输出至与其相连的终端设备，以便于与输出接口相连的其他终端设备能够获取到处理器产生的各种数据。本实施例中，所述输出接口具体可以包括但不限于usb接口、串行接口等。
74.通讯单元，用于在整机系统诊断平台的优化装置和外部服务器之间建立远程通讯连接，以便于整机系统诊断平台的优化装置能够将镜像文件挂载到外部服务器中。本实施例中，通讯单元具体可以包括但不限于基于无线通讯技术或有线通讯技术的远程通讯单元。
75.键盘，用于获取用户通过实时敲击键帽而输入的各种参数数据或指令。
76.显示器，用于运行服务器供电线路短路定位过程的相关信息进行实时显示。
77.鼠标，可以用于协助用户输入数据并简化用户的操作。
78.本实施例还公开了一种可读存储介质，这里所说的可读存储介质包括随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动硬盘、cd-rom或技术领域内所公知的任意其他形式的存储介质。可读存储介质中存储有整机系统诊断平台的优化程序，所述整机系统诊断平台的优化程序被处理器执行时实现以下步骤：
79.1、将整机系统诊断平台拆分为系统层和业务层。
80.2、为整机系统诊断平台构建新型数据库系统，新型数据库系统包括关系型数据库和非关系型数据库。
81.3、改造业务层程序代码的部署形式。
82.4、通过整机系统诊断平台收集待检测机器的运行数据，并输入训练完成的诊断模型进行故障诊断。
83.综上所述，本发明可以大量的减少由于hotfix带来的程序部署的频次，降低了运维的工作量和生产异常的风险。
84.本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的方法而言，由于其与实施例公开的系统相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
85.专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
86.在本发明所提供的几个实施例中，应该理解到，所揭露的系统、系统和方法，可以通过其它的方式实现。例如，以上所描述的系统实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，系统或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
87.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
88.另外，在本发明各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个单元中。
89.同理，在本发明各个实施例中的各处理单元可以集成在一个功能模块中，也可以是各个处理单元物理存在，也可以两个或两个以上处理单元集成在一个功能模块中。
90.结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。
91.最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意
在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
92.以上对本发明所提供的整机系统诊断平台的优化方法、系统、装置及可读存储介质进行了详细介绍。本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本发明进行若干改进和修饰，这些改进和修饰也落入本发明权利要求的保护范围内。