CN110855489B - 故障处理方法、装置和故障处理装置 - Google Patents

故障处理方法、装置和故障处理装置 Download PDF

Info

Publication number
CN110855489B
CN110855489B CN201911111280.2A CN201911111280A CN110855489B CN 110855489 B CN110855489 B CN 110855489B CN 201911111280 A CN201911111280 A CN 201911111280A CN 110855489 B CN110855489 B CN 110855489B
Authority
CN
China
Prior art keywords
fault
type
chain
data
related data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201911111280.2A
Other languages
English (en)
Other versions
CN110855489A (zh
Inventor
白石
马宁
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Jingdong Century Trading Co Ltd
Beijing Jingdong Shangke Information Technology Co Ltd
Original Assignee
Beijing Jingdong Century Trading Co Ltd
Beijing Jingdong Shangke Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Jingdong Century Trading Co Ltd, Beijing Jingdong Shangke Information Technology Co Ltd filed Critical Beijing Jingdong Century Trading Co Ltd
Priority to CN201911111280.2A priority Critical patent/CN110855489B/zh
Publication of CN110855489A publication Critical patent/CN110855489A/zh
Application granted granted Critical
Publication of CN110855489B publication Critical patent/CN110855489B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H04L41/065—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis involving logical or physical relationship, e.g. grouping and hierarchies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0677—Localisation of faults
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0686—Additional information in the notification, e.g. enhancement of specific meta-data

Abstract

本公开涉及一种故障处理方法、装置和故障处理装置，涉及计算机技术领域。该方法包括：响应于计算机系统发生故障，向运维人员的终端发送报警信息；根据终端返回的数据查询请求，向终端发送获取的故障相关数据，数据查询请求根据报警信息确定；根据终端返回的故障处理请求和获取的故障相关数据，确定计算机系统的故障类型，故障处理请求根据故障相关数据确定；根据故障类型，对计算机系统的故障进行处理。

Description

故障处理方法、装置和故障处理装置
技术领域
本公开涉及计算机技术领域，特别涉及一种故障处理方法、故障处理装置和故障处理装置。
背景技术
当前，云计算平台的主要厂商大都采用发送短信、邮件、客服人员拨打电话等方式进行系统故障报警。运维人员和技术保障人员都能接收到故障报警信息，以便处理系统故障。
在相关技术中，运维人员接到报警后，需要登录到云计算平台的前台系统或后台管理系统，对故障相关资源的信息进行查询和分析，并通过人工经验排除系统故障。
发明内容
本公开的发明人发现上述相关技术中存在如下问题：故障处理效率低下。
鉴于此，本公开提出了一种故障处理技术方案，能够提高故障处理效率。
根据本公开的一些实施例，提供了一种故障处理方法，包括：响应于计算机系统发生故障，向运维人员的终端发送报警信息；根据终端返回的数据查询请求，向终端发送获取的故障相关数据，数据查询请求根据报警信息确定；根据终端返回的故障处理请求和获取的故障相关数据，确定计算机系统的故障类型，故障处理请求根据故障相关数据确定；根据故障类型，对计算机系统的故障进行处理。
在一些实施例中，根据故障相关数据和终端返回的故障处理请求，确定计算机系统的故障类型包括：根据故障相关数据和故障处理请求，确定计算机系统的各系统异常事件；根据各系统异常事件的发生时间顺序，生成各系统异常事件组成的异常事件序列；根据异常事件序列，确定故障类型。
在一些实施例中，根据异常事件序列，确定故障类型包括：确定异常事件序列中各异常事件对应的故障相关数据；根据各故障相关数据落入哪个故障类型的故障数值范围，判断该异常时间序列属于哪个故障类型。
在一些实施例中，故障类型的故障数值范围通过如下步骤确定：获取各历史异常事件序列相应的各历史故障相关数据；根据各历史异常事件序列，利用机器学习模型确定对应的故障类型；根据各历史异常事件序列与各故障类型的对应关系，以及各历史故障相关数据，确定各故障类型对应的故障数值范围。
在一些实施例中，异常事件序列为多个；根据故障类型，对计算机系统的故障进行处理包括：根据每个异常事件序列，确定每个故障类型；根据各故障类型之间的因果关系，生成各故障类型组成的故障链；根据故障链，对计算机系统的故障进行处理。
在一些实施例中，根据故障链，对计算机系统的故障进行处理包括：判断故障链中各故障类型的修复是否依赖于故障链中其他故障类型；根据判断结果，确定故障链中各故障类型的修复顺序。
在一些实施例中，判断故障链中各故障类型的修复是否依赖于故障链中其他故障类型包括：判断故障链中的当前故障类型的修复是否依赖于前一个故障类型；在依赖于前一个故障类型的情况下，将该前一个故障类型作为新的当前故障类型重复进行上述判断；在不依赖于前一个故障类型的情况下，将当前故障类型从故障链中删除后加入到修复链中，将该前一个故障类型作为当前故障类型重复进行上述判断直到故障链中所有的故障类型均加入到修复链中。修复链为判断结果，修复链中的各故障类型按照加入的时间从早到晚排列。
在一些实施例中，根据终端返回的数据查询请求，向终端发送获取的故障相关数据包括：获取故障发生前后的系统运行数据；根据数据查询请求，在系统运行数据中确定故障相关数据。
在一些实施例中，根据终端返回的数据查询请求，向终端发送获取的故障相关数据包括：根据运维人员的身份信息，确定运维人员是否具有获取故障相关数据的权限；在具有故障相关数据的权限的情况下，向终端发送故障相关数据。
在一些实施例中，根据终端返回的数据查询请求，向终端发送获取的故障相关数据包括：对数据查询请求进行解析，以确定数据查询请求中的查询关键词；根据查询关键词，生成数据查询指令；根据数据查询指令，获取故障相关数据.
在一些实施例中，根据故障相关数据和终端返回的故障处理请求，确定计算机系统的故障类型包括：对故障处理请求进行解析，以确定故障处理请求中的处理关键词；根据处理关键词，生成故障处理指令；根据故障处理指令，确定故障类型。
根据本公开的另一些实施例，提供一种故障处理装置，包括：发送单元，用于响应于计算机系统发生故障，向运维人员的终端发送报警信息，根据终端返回的数据查询请求，向终端发送获取的故障相关数据，数据查询请求根据报警信息确定；确定单元，用于根据终端返回的故障处理请求和获取的故障相关数据，确定计算机系统的故障类型，故障处理请求根据故障相关数据确定；处理单元，用于根据故障类型，对计算机系统的故障进行处理。
在一些实施例中，确定单元根据故障相关数据和故障处理请求，确定计算机系统的各系统异常事件；根据各系统异常事件的发生时间顺序，生成各系统异常事件组成的异常事件序列，根据异常事件序列，确定故障类型。
在一些实施例中，确定单元确定异常事件序列中各异常事件对应的故障相关数据，根据各故障相关数据落入哪个故障类型的故障数值范围，判断该异常时间序列属于哪个故障类型。
在一些实施例中，确定单元根据各历史异常事件序列，利用机器学习模型确定对应的故障类型，根据各历史异常事件序列与各故障类型的对应关系，以及获取的各历史异常事件序列相应的各历史故障相关数据，确定各故障类型对应的故障数值范围。
在一些实施例中，异常事件序列为多个；处理单元根据每个异常事件序列，确定每个故障类型，根据各故障类型之间的因果关系，生成各故障类型组成的故障链，根据故障链，对计算机系统的故障进行处理。
在一些实施例中，处理单元判断故障链中各故障类型的修复是否依赖于故障链中其他故障类型，根据判断结果，确定故障链中各故障类型的修复顺序。
在一些实施例中，处理单元判断故障链中的当前故障类型的修复是否依赖于前一个故障类型；在依赖于前一个故障类型的情况下，处理单元将该前一个故障类型作为新的当前故障类型重复进行上述判断；在不依赖于前一个故障类型的情况下，处理单元将当前故障类型从故障链中删除后加入到修复链中，将该前一个故障类型作为当前故障类型重复进行上述判断直到故障链中所有的故障类型均加入到修复链中。修复链为判断结果，修复链中的各故障类型按照加入的时间从早到晚排列。
在一些实施例中，发送单元根据数据查询请求，在获取的故障发生前后的系统运行数据中确定故障相关数据。
在一些实施例中，发送单元在运维人员具有故障相关数据的获取权限的情况下，向终端发送故障相关数据，获取权限根据运维人员的身份信息判断。
在一些实施例中，该装置还包括解析单元用于：对数据查询请求进行解析，以确定数据查询请求中的查询关键词；根据查询关键词，生成数据查询指令；故障相关数据根据数据查询指令获取。
在一些实施例中，解析单元对故障处理请求进行解析，以确定故障处理请求中的处理关键词；根据处理关键词，生成故障处理指令；故障类型根据故障处理指令确定。
根据本公开的又一些实施例，提供一种故障处理装置，包括：存储器；和耦接至存储器的处理器，处理器被配置为基于存储在存储器装置中的指令，执行上述任一个实施例中的故障处理方法。
根据本公开的再一些实施例，提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述任一个实施例中的故障处理方法。
在上述实施例中，在计算机系统发生故障的情况下，本公开不但向运维人员发送警报，还发送故障相关数据以便运维人员进行故障判断；并且能够根据判断结果对系统故障进行自动处理。这样，运维人员无需登录系统即可实现故障相关数据的自动获取和系统故障的自动处理，从而提高了故障处理效率。
附图说明
构成说明书的一部分的附图描述了本公开的实施例，并且连同说明书一起用于解释本公开的原理。
参照附图，根据下面的详细描述，可以更加清楚地理解本公开：
图1示出本公开的故障处理方法的一些实施例的流程图；
图2示出图1中步骤130的一些实施例的流程图；
图3示出图1中步骤140的一些实施例的流程图；
图4示出图3中步骤1430的一些实施例的流程图
图5示出本公开的故障处理装置的一些实施例的示意图；
图6示出本公开的故障处理方法的一些实施例的示意图；
图7示出本公开的故障处理装置的一些实施例的框图；
图8示出本公开的故障处理装置的另一些实施例的框图；
图9示出本公开的故障处理装置的又一些实施例的框图。
具体实施方式
现在将参照附图来详细描述本公开的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本公开的范围。
同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。
以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本公开及其应用或使用的任何限制。
对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，技术、方法和设备应当被视为授权说明书的一部分。
在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。
应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。
图1示出本公开的故障处理方法的一些实施例的流程图。
如图1所示，该方法包括：步骤110，发送报警信息；步骤120，发送故障相关数据；步骤130，确定故障类型；和步骤140，处理系统故障。
在步骤110中，响应于计算机系统发生故障，向运维人员的终端发送报警信息。例如，可以通过短信通道、邮件通道、Web通道、专用应用通道等多种信息传递的通道向运维人员终端发送警报信息。专用应用通道可以是为运维人员配置的专用界面、专用后端管理平台、专用APP(Application，应用)等。
在步骤120中，根据终端返回的数据查询请求，向终端发送获取的故障相关数据。数据查询请求根据报警信息确定。例如，运维人员根据报警信息预判发生的系统故障，根据预判结果申请查询相应的数据(如网络数据、主机运行状况数据等)。
在一些实施例中，获取故障发生前后的系统运行数据；根据数据查询请求，在系统运行数据中确定故障相关数据。例如，可以获取日志中故障发生前后一段时间的各种系统运行数据；运维人员请求查询“网络数据”，则在系统运行数据中筛选出与“网络数据”相关的数据。
在一些实施例中，根据运维人员的身份信息，确定运维人员是否具有获取故障相关数据的权限；在具有故障相关数据的权限的情况下，向终端发送故障相关数据。
在一些实施例中，对数据查询请求进行解析，以确定数据查询请求中的查询关键词；根据查询关键词，生成数据查询指令；根据数据查询指令，获取故障相关数据。例如，运维人员发送的数据查询请求为语音或文本，可以通过分词处理从中提取关键词已确定运维人员的查询目标。
在步骤130中，根据终端返回的故障处理请求和获取的故障相关数据，确定计算机系统的故障类型。故障处理请求根据故障相关数据确定。
在一些实施例中，对故障处理请求进行解析，以确定故障处理请求中的处理关键词；根据处理关键词，生成故障处理指令；根据故障处理指令，确定故障类型。例如，运维人员发送的故障处理请求为语音或文本，可以通过分词处理从中提取关键词已确定运维人员想要进行的处理操作。
在一些实施例中，可以通过图2中的实施例执行步骤130。
图2示出图1中步骤130的一些实施例的流程图。
如图2所示，步骤130包括：步骤1310，确定各系统异常事件；步骤1320，生成异常事件序列；和步骤1330，确定故障类型。
在步骤1310中，根据故障相关数据和故障处理请求，确定计算机系统的各系统异常事件。
在一些实施例中，故障处理请求是“处理网络故障”，则可以筛选出故障相关数据中与网络相关的数据及其数值；如果数值超过预设的阈值，则可以判断发生了系统异常事件。例如，系统异常事件可以是系统通信卡顿、流量过大、网速下降等。
在步骤1320中，根据各系统异常事件的发生时间顺序，生成各系统异常事件组成的异常事件序列。
在一些实施例中，根据时间顺序可以确定异常事件序列为：流量过大、网速下降、系统通信卡顿。
在步骤1330中，根据异常事件序列，确定故障类型。
在一些实施例中，确定异常事件序列中各异常事件对应的故障相关数据；根据各故障相关数据落入哪个故障类型的故障数值范围，判断该异常时间序列属于哪个故障类型。例如，“流量过大”的故障相关数据为流量值、“网速下降”的故障相关数据为网速值、“系统通信卡顿”为延迟率；在这些故障相关数据的数值均落入了“网络服务器故障”这一故障类型的各故障数值范围的情况下，确定故障类型为“网络服务器故障”。
例如，故障类型的故障数值范围通过如下步骤确定：获取各历史异常事件序列相应的各历史故障相关数据；根据各历史异常事件序列，利用机器学习模型确定对应的故障类型；根据各历史异常事件序列与各故障类型的对应关系，以及各历史故障相关数据，确定各故障类型对应的故障数值范围。
在步骤140中，根据故障类型，对计算机系统的故障进行处理。
在一些实施例中，异常事件序列为多个。例如，可以通过图3中的实施例执行步骤140。
图3示出图1中步骤140的一些实施例的流程图。
如图3所示，步骤140包括：步骤1410，确定各故障类型；步骤1420，生成故障链；和步骤1430，处理系统故障。
在步骤1410在步骤何种，根据每个异常事件序列，确定每个故障类型。例如，根据各异常事件序列确定的故障类型包括：服务中止、服务器宕机、服务程序中止。
在步骤1420中，根据各故障类型之间的因果关系，生成各故障类型组成的故障链。例如，服务器宕机导致服务程序中止，服务程序中止导致服务中止；在这种情况下，故障链为：服务器宕机、服务程序中止、导致服务。
在步骤1430中，根据故障链，对计算机系统的故障进行处理。
在一些实施例中，判断故障链中各故障类型的修复是否依赖于故障链中其他故障类型；根据判断结果，确定故障链中各故障类型的修复顺序。例如，有限修复不依赖于其他故障类型的故障类型，然后再修复依赖于其他故障类型的故障类型。
例如，可以通过图4中的实施例执行步骤1430。
图4示出图3中步骤1430的一些实施例的流程图。
如图4所示，步骤1430包括：步骤410，获取故障链；步骤420，判断当前故障类型是否存在依赖关系；步骤430，更新当前故障类型；和步骤440，加入修复链。
在步骤410中，可以根据上述任一个实施例中的方法获取计算机系统当前故障的故障链。
在步骤420中，判断故障链中的当前故障类型的修复是否依赖于前一个故障类型。在依赖的情况下，执行步骤430；在不依赖的情况下，执行步骤440。
在步骤430中，将该前一个故障类型作为新的当前故障类型重复进行上述判断(执行步骤420)。例如，在这种情况下，在故障链中暂时保留修复具有依赖关系的故障类型，继续判断前一个故障类型。
在步骤440中，将当前故障类型从所述故障链中删除后加入到修复链中；将该前一个故障类型作为当前故障类型重复进行上述判断(执行步骤420)，直到故障链中所有的故障类型均加入到修复链中。修复链为判断结果，修复链中的各故障类型按照加入的时间从早到晚排列。例如，在这种情况下，在故障链中删除修复不具有依赖关系的故障类型，将删除后的故障链作为下一轮判断的对象。
在一些实施例中，故障链中共5个故障类型依次为：故障类型5、故障类型4、故障类型3、故障类型2、故障类型1。
第一步，判断出故障链中目前排在最末的故障类型5(此次故障的最直接反映)的修复不依赖于故障类型4，则在故障链中删除故障类型5，将故障类型5加入修复链。
第二步，判断出故障类型4的修复依赖于不依赖于故障类型3，则在故障链中保留故障类型4。
第三步，判断出故障链中故障类型3的修复依赖于故障类型2，则在故障链中保留故障类型2。
第四步，判断出故障链中故障类型2的修复不依赖于故障类型1，则在故障链中删除故障类型2，将故障类型2加入修复链。
第五步，判断出故障链中故障类型1(此故障类型在故障链中没有前一个故障类型)的修复不依赖于其他故障类型，则在故障链中删除故障类型1，将故障类型1加入修复链。
经过上一轮的处理，故障链目前包含：故障类型4、故障类型3。对该故障链重复上述判断。
第六步，判断出故障链中目前排在最末的故障类型3的修复依赖于故障类型4，则在故障链中保留故障类型3。
第七步，判断出故障链中故障类型4(此故障类型在故障链中没有前一个故障类型)的修复不依赖于其他故障类型，则在故障链中删除故障类型4，将故障类型4加入修复链。
经过上一轮的处理，故障链目前包含：故障类型3。对该故障链重复上述判断。
第八步，判断出故障链中故障类型3(此故障类型在故障链中没有前一个故障类型)的修复不依赖于其他故障类型，则在故障链中删除故障类型3，将故障类型3加入修复链。
经过上一轮的处理，故障链目前不包含任何故障类型3，结束判断。在这种情况下，依据故障类型加入修复链的顺序(从早到晚)得到修复链为：故障类型5、故障类型2、故障类型1、故障类型3、故障类型4。可以给予修复链中的顺序，处理系统故障，从而提高处理效率。
上述实施例中，在计算机系统发生故障的情况下，本公开不但向运维人员发送警报，还发送故障相关数据以便运维人员进行故障判断；并且能够根据判断结果对系统故障进行自动处理。这样，运维人员无需登录系统即可实现故障相关数据的自动获取和系统故障的自动处理，从而提高了故障处理效率。
在上述实施例中，将云计算平台分为各个检测层(各故障类型对应的系统实体)。通过检测初始检测层(故障链中最后的故障类型对应的系统实体)运行状态是否正常，将初始检测层运行状态不正常作为进入各级检测层的入口。然后逐级将下一级检测层作为当前检测层进行检测，以获得当前检测层运行状态。进而寻找到运行状态不正常的最低级检测层，确定最终故障所在检测层。这样，可以实现自动发现故障的目的。
而且，在故障解决方面，还通过判断故障所在检测层，针对各级检测层问题(故障类型)做出不同的解决机制，尽可能的减少故障时间，实现了快速恢复服务的目的。
在一些实施例中，可以通过提供基于上述任一个实施例中的故障处理方法的装置，实现运维和技术保障人员与云计算平台后台系统的及时交互。这样，能够更快、更方便地获得关于故障的各种相关信息。从而，一方面帮助运维和技术保障人员尽快查找故障原因；另一方面更智能地解决一部分通过系统操作可以修复的系统异常。
图5示出本公开的故障处理装置的一些实施例的示意图。
如图5所示，运维人员通过故障交互终端与故障处理装置交互。故障处理装置可以包括通信引擎、接入控制系统、AI(ArtificialIntelligence，人工智能)交互系统、故障感知分析系统、故障预警报警系统、故障处理系统。
故障交互终端是运维人员使用的终端，用于与云计算平台的后台系统(包括故障处理装置)进行数据通信。例如，数据通信形式可以包括移动终端、应用终端、Web页面等多种能实现后台系统与运维人员进行文本或语音等信息交互的通信形式。
在一些实施例中，运维人员通过故障交互终端获得故障的预警、报警和故障报告等信息。运维人员通过故障交互终端输入查询、处理故障的文本或语音作为请求信息。并将请求信息传递到后台系统。
例如，运维人员可在专用应用界面输入文本或语音进行信息反馈；也可以通过回复短信、邮件等信息实现信息反馈给后台系统。
在一些实施例中，后台系统根据故障的级别、故障相关资源，检查运维人员的权限。在运维人员权限允许范围内，进行信息交互和系统操作。
通信引擎是后台系统与故障交互终端进行通信的管理模块。例如，通信引擎可以支持短信通道、邮件通道、Web通道、专用应用通道等多种信息传递的通道。后台系统利用不同通道提供的信息交互接口，将故障预警、报警、故障信息等信息发送到故障交互终端上；还可以将故障交互终端上运维人员输入的信息发送给后台系统。
在一些实施例中，通信引擎可以包括信息折射模块，用于通过运维人员的社会关系，将信息传递给运维人员。这样，可以尽可能消除故障信息不能触达到运维人员的情况，减少故障损失。
例如，在紧急故障信息(报警信息、故障相关数据等)不能及时被运维人员进行阅读和处理的情况下，通信引擎(如通过发送单元)可以将相应的提示信息通过短信、邮件、微信等形式发送给运维人员的紧急联系人(如同事、家人等与运维人员有密切关联关系的人)。
例如，提示信息可设定为不包含故障信息，担保函提醒内容的信息，如“请您告诉某某人查看一下短信/邮件信息，谢谢”等，以防止泄露系统信息。
例如，在运维人员进行了信息接收反馈的情况下，停止给紧急联系人发提示信息。
接入控制系统可以通过多因子认证(如口令、人脸识别、短信验证码等认证方式的多项)确定运维人员的身份信息；然后根据身份信息，通过权限控制判断运维人员对敏感数据的访问权限。
在一些实施例中，某运维人员被设定为网络维护人员，则不能访问数据库状态、内存状态等数据。在访问权限的验证不通过的情况下，运维人员不能从云计算平台的后台系统获取对应的信息和执行相关的操作。
AI交互系统(如可包含解析单元)可以利用AI技术对文本和语音的处理能力，围绕系统故障实现运维人员与后台系统的交互。例如，AI交互系统可以包含文本解析模块、语音解析模块、语音转文字摘要模块、情绪解析模块、AI交互表达模块。
文本解析模块用于将运维人员发来的文本信息解析为故障处理逻辑。
在一些实施例中，文本解析模块对文本进行分词，确定文本中与系统故障相关的关键词。例如，关键词可以包括“内存”、“中央处理器”、“网络”、“存储”、“温度”、“吞吐率”、“最大”、“流量”等。例如，关键词可以由后台系统事先进行定义，并存储在后台系统中。
在一些实施例中，文本解析模块可以分析文本中相关的操作指令，将文本分为“查询文本”、“操作文本”两类。例如，“查询文本”可以是查询故障相关的信息数据的请求。“操作文本”可以是对故障相关的资源(系统对象)进行的操作处理。
在一些实施例中，文本解析模块可以将“查询文本”解析为相应的故障信息查询逻辑。
在一些实施例中，故障信息查询逻辑可以包括：动作、对象、指标、时间、输出。例如，“动作”的值可以为“查询”；“对象”为需要查询的资源名称或ID；“指标”可以包括中央处理器使用率、网络流量等多种系统状态和数据指标；“时间”为一定的时间范围，默认值可由用户设定；“输出”为信息的返回格式，如文本、静态图像、动态图像等信息表达形式。
例如，“查询文本”为运维人员问“网络怎么样”，文本解析模块解析出关键词“网络”，并解析出该“查询文本”为“疑问、查询语句”。在这种情况下，可以形成相应的故障信息查询逻辑。例如，故障信息查询逻辑可以为“动作：查询，对象：故障节点，指标：周边网络连通状态，时间：默认，输出：文本”。
在一些实施例中，针对“操作文本”，文本解析模块可以确定其中的被操作客体、具体操作指令等。文本解析模块可以检查运维人员是否有操作的权限。
在一些实施例中，在执行操作之前，可以将处理逻辑发送给运维人员进行确认。在操作涉及到重大风险的情况下，发起审批流程。Iru，可以将运维人员要进行的某项操作的相关信息发送给有权限审批的人员或机构进行审批，审批通过后才能执行。
在一些实施例中，文本解析模块可以将“操作文本”解析为相应的故障操作逻辑。
在一些实施例中，故障操作逻辑包括：动作、对象、操作指令、时间、是否确认。例如，“动作”可以为“操作”；“对象”可以为需要查询的资源名称或ID；“操作指令”可以为需要进行的系统操作，如热迁移、数据迁移、IP(Internet Protocol，网络之间互连的协议)漂移等；“时间”可以为一段时间用于指定“操作指令”从当前开始后的一段时间开始执行，默认值可由用户设定；“是否确认”用于给运维人员确认是否执行操作，当首次生成操作逻辑时值为“空”。
例如，“操作文本”为运维人员发来的“热迁移云主机X001”信息。文本解析模块解析出关键字“热迁移”、“云主机X001”。在这种情况下，可以形成“动作：操作，对象：将ID或名称为X001的云主机，操作指令：热迁移，时间：默认，是否确认：空”的故障处理逻辑。
语音解析模块可以将运维人员输入的语音进行语言识别，并转化为文本信息。
在一些实施例中，转化的文本信息可以在终端上进行显示。流，在运维人员确认转化为文本的信息后，可以按照文本解析模块的方式进行相同处理。
在一些实施例中，语音解析模块可以用于识别运维用户的声纹，通过对比事先收录的运维人员声纹信息，确定运维人员身份的一致性。
语音转文字摘要模块可以将识别的语音形成的文字语句进行分词，并进一步进行摘要，将关键信息在终端界面展示出来。这样，可以将用户的语音生成摘要保存，作为历史记录以便查询。
AI交互模块可以对后台系统发来的各种信息进行预处理，以便向运维人员发送简洁、有效的信息。
在一些实施例中，AI交互模块可以将后台系统发送给运维用户的信息进行编排和组织以确定优先级，将优先级高的数据和信息排在前面。
在一些实施例中，AI交互模块可以将同一类的信息组合到一起，以便发送简洁、有效的信息。
在一些实施例中，AI交互模块可以根据运维人员选择的终端类型，选择反馈信息的表现形式。例如，运维人员选择使用短信进行交互，则AI交互模块将信息处理为简短的文字和数字；运维人员使用专用APP，则AI交互模块可以将信息输出为表格、动态图像等。
故障感知与分析系统(如包含确定单元和发送单元)用于收集数据并进行数据分析。例如，故障感知与分析系统可以包括数据收集模块、故障数据分析模块、
在一些实施例中，数据收集模块可以在故障发生前对云计算平台整体的数据进行收集。从而，可以在发生故障时保存故障前后一段时间内的各方面数据，形成可供故障规律数据分析的原始数据。
在一些实施例中，数据收集模块可以在故障发生后，根据运维人员的查询请求，为运维人员收集所需的数据。例如，网络连接状态，线程状态等。
在一些实施例中，数据收集模块重点收集日志数据、系统运行数据等。在云计算平台具有传感器等系统周边环境观测点的情况下，系统周边环境观测点的数据也需要同步进行采集。例如，可以重点观测温湿度异常、震动异常、进入机房的人员异常、灰尘异常、时钟异常等多种异常数据。
在一些实施例中，可以将异常的数据从海量的数据中过滤出来，挑选出非正常的数据，并进行记录。
在一些实施例中，故障数据分析模块用于分析故障链、故障关键点、影响范围，并评估故障恢复所需的资源、操作和恢复的时间。
在一些实施例中，故障数据分析模块可以将云上部署的系统(云计算平台)简化为图6，然后进行故障链分析，已确定各故障点(也可以称为故障实体、故障类型、故障资源等)。
图6示出本公开的故障处理方法的一些实施例的示意图。
如图6所示，故障数据分析模块可以根据故障发生的位置，将云上系统的故障分为源故障、节点故障、关联线路故障、终端线路故障、终端故障等不同的故障类型。
在一些实施例中，外部条件可以是支撑云计算平台运行的环境和软硬件资源。例如，源故障可以包括停电、降温系统故障、物理服务器故障、网络硬件设备故障等。
在一些实施例中，节点故障可以是运行业务系统的某个计算节点的故障。例如，系统节点x、系统节点y故障等。
在一些实施例中，关联线路故障可以还是不同节点之间的通信故障。例如，连接系统节点x和系统节点y之间的网络不通。
在一些实施例中，终端线路故障可以是云端的应用系统与终端相连的网络不通。
在一些实施例中，终端故障可以是访问系统的运维人员的终端软件崩溃等故障。
云计算平台的某处故障常常是和其它部分的故障相关联的。一般多个故障在同时或较短的一段时间内一起发生，而且往往有先后顺序和因果关系。
因此，故障分析时不止需要分析某个点的故障，而需要分析出整个故障链的情况。故障链分析重点是对源故障、节点故障、管理线路故障、终端线路故障等部分进行分析，得到导致关键故障的整体故障链。
云计算平台的某实体发生故障，是该实体发生了系统异常事件。该实体对外输出的能力在一段设定的时间内持续或反复低于应该达到的能力最低值。例如，设定5MB/s的网络线路，某个时间开始后都只有2MB/s的传输能力。如果该网络线路应达到的阈值是2.5MB/s，则该网络线路被认定为发生了系统异常事件。
在一些实施例中，正常状态下实体A的输出能力x的正常区间为[Xmin,Xmax]。系统异常事件可用符号表示为f(A)＝x，
Figure GDA0003582226960000171
Figure GDA0003582226960000172
在一些实施例中，故障链可以包括连续的(因果关系)故障类型。例如，由于空调故障导致的服务中止故障链：空调氟利昂量不足、空调降温能力不足、室温过高、物理硬件升温、内存高温、内存失灵、服务器宕机、服务程序中止、服务中止。
在一些实施例中，可以对系统异常事件序列进行分类。例如，可以根据利用机器学习模型确定的故障数值范围实现分类。
在一些实施例中，可以记录构造相似的云计算平台中每一次故障发生前后一段时间内所有监测对象的系统异常状态值、系统异常事件开始的时间；将系统异常事件按照时间进行排序，形成异常事件序列；利用分类算法对构造相似的系统上全部异常事件序列进行分类，抽取出不同故障类型的异常事件序列。
在一些实施例中，可以用“小写字母序列+数字序号”的方法标识一个系统异常事件。例如：对于系统异常事件“云主机宕机”，可以用yjj代表云主机，用001代表宕机，形成yjj001的异常事件标识；对于系统异常事件“云主机重启”，用yjj代表云主机，用008代表重启，形成yjj008的异常事件标识。
按照系统异常事件发生的时间顺序对异常事件标识排序，形成一个异常事件序列，如{aaa003,xxx007,kkk210,…,yjj001}。
在有监督的情况下，标识一个异常事件序列造成的故障类别，并用“大写字母序列+数字序号”的方法来标识。例如，可以用故障的影响程度来定义故障类别，也可以用最关键的系统异常事件来定义故障类别。若以关键系统异常事件作为标识，则上述异常事件序列可标识为：YJJ001。
利用有监督的训练集，训练机器学习模型，以形成故障类型与异常事件序列的对应关系。
利用该机器学习模型，对未分类的异常事件序列进行分类。如果未分类的异常事件序列与现有的故障类型的差异过大，可以提交给技术人员进行处理。例如，可为该异常事件序列定义新的故障类型，或将该异常事件序列分入到已有的故障类型中。
针对每一种类的异常事件序列，可以在专业技术人员的监督下选取故障关键点。可以计算故障关键点涉及的实体的能力数值范围作为故障数值范围。例如，故障关键点可以是对云计算平台造成实质性影响的某个实体的系统异常状态。
在一些实施例中，可以对当前故障的异常事件序列进行抽取。
例如，可以记录系统当前故障发生前后一段时间内系统监测的所有监测对象的系统异常状态值，系统异常状态开始的时间；将系统异常状态按照时间进行排序，形成异常事件序列；将异常事件序列中各故障关键点对应的故障实体的能力数值，与已有的故障数值范围进行比对，以确定故障类型。在无法归入某一故障类型的情况下，可以定义新的故障类型。
在一些实施例中，可以输出按照时间排序的故障关键点，以及故障关键点对应实体的异常能力数值，并输出故障类型。
在一些实施例中，可以对故障影响范围进行分析。例如，可以利用原始数据集分析的故障类型，确定在该故障类型情况下，云计算平台主要会被故障影响的资源情况。还可以检查相关的资源，查看是否出现异常状态，以确定故障中全部被影响到的资源。
在一些实施例中，可以通过故障所属的类别，根据以往记录的故障恢复的进程，预测当前发生的故障可能的恢复时间的区间。这样，可以帮助运维人员评估损失。
故障预警报警系统(可以包括发送单元)可以在关键资源(实体)发生故障之前或之后，向运维人员发送故障相关的信息。例如，故障预警信息可以是描述某些关键资源可能发生故障的情况；故障报警信息可以是描述已发生故障的关键资源的情况。
在一些实施例中，关键资源可以是虚拟机、网络、存储实例、数据库实例等对系统正常运行有关键影响的系统资源。
在一些实施例中，系统已探测到某些异常状态的发生，根据故障链分析，发现当前故障链属于某类故障链的一个前置的子链。若故障不被适当处置，则很可能继续发生该类故障链中后续的系统资源状态异常。
在这种情况下，故障预警系统可以通过交互系统向相关的运维人员发送预警信息。例如，预警信息可以包括当前已发生的异常状况，可能导致哪些重要系统资源近期会发生故障的提示等。
在一些实施例中，将已发生的系统关键资源的故障情况发送给运维人员，并通知已获得的故障链情况。
在一些实施例中，故障恢复通知模块在故障恢复之后，将已恢复正常状态的关键资源的恢复信息发送给运维人员。
在一些实施例中，故障修复链生成模块可以生成修复链。故障修复链可以是针对故障链中相关的故障资源，以能够最快恢复业务系统正常运行为目标，排列出逐个对系统资源异常进行修复的序列。
在一些实施例中，针对故障链：空调氟利昂量不足、空调降温能力不足、室温过高、物理硬件升温、内存高温、内存失灵、服务器宕机、服务程序中止、服务中止，修复链可以为：用保存的系统镜像在其它物理服务器上创建新的云主机；按照原有配置对系统进行配置；启动业务服务程序；向机房运维人员发送物理服务器宕机信息；向机房运维人员发送内存高温数据；向机房运维人员发送室温过高数据。
这样，可以消除故障链上所有异常状态，使系统恢复到正常运行状态。
在一些实施例中，修复过程为能够通过故障修复系统自身向云端发送指令序列，或通知运维人员后能够修复故障的系统操作指令序列，或发向运维人员的通知。发送给运维人员的通知信息最终能够使指定资源恢复到正常状态。
在一些实施例中，定位故障链(包含故障类B1到BI，I为大于1的整数)中导致业务系统故障的直接故障原因B0，并判断直接故障原因修复所依赖的上一级故障B1。判断B0的修复过程是否依赖于B1的修复。
若修复过程不依赖于B1的修复，则将修复过程加入到故障修复链；若修复过程依赖于B1的修复，则判断B1修复过程是否依赖于B2的修复；依次类推，直到找到修复过程没有其它依赖的故障点Bi，并将其修复过程加入到故障修复链，i为大于1小于I的整数；将Bi-1、Bi-2、…B1的修复过程依次加入到故障修复链中。
将故障链中除了已经加入到故障修复链中的节点按照故障链中的先后顺序的反序，按照上述的流程继续处理，将符合要求的故障修复过程加入到故障修复链；重复以上过程，直到故障链上所有节点的故障修复过程都加入到故障修复链中。
故障资源处置模块(可包括处理单元)负责实施故障修复过程的自动处理指令，对处在故障异常状态中的资源进行处理。例如，处理操作可以包括重启、迁移或转移部署、更改配置等各种能够使资源恢复为正常运行状态的操作。
在一些实施例中，在系统无法通过故障恢复系统进行自动处置时，可以通过通知运维人员实现故障的恢复。
在一些实施例中，在故障发生和故障修复过程中系统记录的重要事件可以形成事件记录的序列，可以作为为相关人员提供故障过程的故障报告。
在一些实施例中，故障处理装置还可以包括故障信息查询系统(可以与AI交互系统合并为一个系统)。例如，故障信息查询系统分为关键词解析与系统查询、查询结果展示模块。故障信息的查询，不仅支持对发生故障的资源、环境探测点进行查询，也支持指定名称的资源和探测点的状态查询。
在一些实施例中，关键词解析与查询模块基于交互系统对运维人员发来的文本、语音的解析，通过与系统预置的关键词词典进行比对，识别需要查询的关键词。关键词主要包括，查询的对象、查询的方法、查询的时间段、结果返回的形式。
在一些实施例中，运维人员的查询请求为X节点南北向的网络流量情况。查询请求可以被解析为“动作：查询，对象：X节点，指标：南北向网络流量，时长：默认，输出：文本”
在一些实施例中，运维人员的查询请求为查询云主机Y所在物理机的温度。查询请求可以被解析为“动作：查询，对象：Y云主机，指标：物理服务器温度，时长：默认，输出：文本”。
在一些实施例中，根据系统已有的经验，查询X节点的输出文本格式为：对象名称、时间、流量值；查询Y节点的输出文本格式为：对象名称、时间、温度值。
在一些誓死力争，资源信息查询模块根据解析出的语句，转化为对资源对象进行查询的系统命令或接口调用命令，实现对相关信息的查询。
在一些实施例中，查询结果处理模块，按照查询模块查询的资源信息，并对运维用户要求的内容信息进行提取，按照固定的格式组织成运维用户终端能够清晰展示的格式。
在上述实施例中，在计算机系统发生故障的情况下，本公开不但向运维人员发送警报，还发送故障相关数据以便运维人员进行故障判断；并且能够根据判断结果对系统故障进行自动处理。这样，运维人员无需登录系统即可实现故障相关数据的自动获取和系统故障的自动处理，从而提高了故障处理效率。
图7示出本公开的故障处理装置的一些实施例的框图。
如图7所示，故障处理装置7包括发送单元71、确定单元72、处理单元73。
发送单元71响应于计算机系统发生故障，向运维人员的终端发送报警信息，根据终端返回的数据查询请求，向终端发送获取的故障相关数据，数据查询请求根据报警信息确定；确定单元72根据终端返回的故障处理请求和获取的故障相关数据，确定计算机系统的故障类型，故障处理请求根据故障相关数据确定；处理单元73根据故障类型，对计算机系统的故障进行处理。
在一些实施例中，确定单元72根据故障相关数据和故障处理请求，确定计算机系统的各系统异常事件；根据各系统异常事件的发生时间顺序，生成各系统异常事件组成的异常事件序列，根据异常事件序列，确定故障类型。
在一些实施例中，确定单元72确定异常事件序列中各异常事件对应的故障相关数据，根据各故障相关数据落入哪个故障类型的故障数值范围，判断该异常时间序列属于哪个故障类型。
在一些实施例中，确定单元72根据各历史异常事件序列，利用机器学习模型确定对应的故障类型，根据各历史异常事件序列与各故障类型的对应关系，以及获取的各历史异常事件序列相应的各历史故障相关数据，确定各故障类型对应的故障数值范围。
在一些实施例中，异常事件序列为多个；处理单元73根据每个异常事件序列，确定每个故障类型，根据各故障类型之间的因果关系，生成各故障类型组成的故障链，根据故障链，对计算机系统的故障进行处理。
在一些实施例中，处理单元73判断故障链中各故障类型的修复是否依赖于故障链中其他故障类型，根据判断结果，确定故障链中各故障类型的修复顺序。
在一些实施例中，处理单元73判断故障链中的当前故障类型的修复是否依赖于前一个故障类型。
在依赖于前一个故障类型的情况下，处理单元73将该前一个故障类型作为新的当前故障类型重复进行上述判断。
在不依赖于前一个故障类型的情况下，处理单元73将当前故障类型从故障链中删除后加入到修复链中，将该前一个故障类型作为当前故障类型重复进行上述判断直到故障链中所有的故障类型均加入到修复链中。修复链为判断结果，修复链中的各故障类型按照加入的时间从早到晚排列。
在一些实施例中，发送单元71根据数据查询请求，在获取的故障发生前后的系统运行数据中确定故障相关数据。
在一些实施例中，发送单元71在运维人员具有故障相关数据的获取权限的情况下，向终端发送故障相关数据，获取权限根据运维人员的身份信息判断。
在一些实施例中，装置7还包括解析单元74用于：对数据查询请求进行解析，以确定数据查询请求中的查询关键词；根据查询关键词，生成数据查询指令；故障相关数据根据数据查询指令获取。
在一些实施例中，解析单元74对故障处理请求进行解析，以确定故障处理请求中的处理关键词；根据处理关键词，生成故障处理指令；故障类型根据故障处理指令确定。
在上述实施例中，在计算机系统发生故障的情况下，本公开不但向运维人员发送警报，还发送故障相关数据以便运维人员进行故障判断；并且能够根据判断结果对系统故障进行自动处理。这样，运维人员无需登录系统即可实现故障相关数据的自动获取和系统故障的自动处理，从而提高了故障处理效率。
图8示出本公开的故障处理装置的另一些实施例的框图。
如图8所示，该实施例的故障处理装置8包括：存储器81以及耦接至该存储器81的处理器82，处理器82被配置为基于存储在存储器81中的指令，执行本公开中任意一个实施例中的故障处理方法。
其中，存储器81例如可以包括系统存储器、固定非易失性存储介质等。系统存储器例如存储有操作系统、应用程序、引导装载程序、数据库以及其他程序等。
图9示出本公开的故障处理装置的又一些实施例的框图。
如图9所示，该实施例的故障处理装置9包括：存储器910以及耦接至该存储器910的处理器920，处理器920被配置为基于存储在存储器910中的指令，执行前述任意一个实施例中的故障处理方法。
存储器910例如可以包括系统存储器、固定非易失性存储介质等。系统存储器例如存储有操作系统、应用程序、引导装载程序以及其他程序等。
故障处理装置9还可以包括输入输出接口930、网络接口940、存储接口950等。这些接口930、940、950以及存储器910和处理器920之间例如可以通过总线960连接。其中，输入输出接口930为显示器、鼠标、键盘、触摸屏等输入输出设备提供连接接口。网络接口940为各种联网设备提供连接接口。存储接口950为SD卡、U盘等外置存储设备提供连接接口。
本领域内的技术人员应当明白，本公开的实施例可提供为方法、系统、或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用非瞬时性存储介质上实施的计算机程序产品的形式。
至此，已经详细描述了根据本公开的故障处理方法、故障处理装置和故障处理装置。为了避免遮蔽本公开的构思，没有描述本领域所公知的一些细节。本领域技术人员根据上面的描述，完全可以明白如何实施这里公开的技术方案。
可能以许多方式来实现本公开的方法和系统。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本公开的方法和系统。用于方法的步骤的上述顺序仅是为了进行说明，本公开的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本公开实施为记录在记录介质中的程序，这些程序包括用于实现根据本公开的方法的机器可读指令。因而，本公开还覆盖存储用于执行根据本公开的方法的程序的记录介质。
虽然已经通过示例对本公开的一些特定实施例进行了详细说明，但是本领域的技术人员应该理解，以上示例仅是为了进行说明，而不是为了限制本公开的范围。本领域的技术人员应该理解，可在不脱离本公开的范围和精神的情况下，对以上实施例进行修改。本公开的范围由所附权利要求来限定。

Claims (13)

1.一种故障处理方法，包括：
响应于计算机系统发生故障，向运维人员的终端发送报警信息；
根据所述终端返回的数据查询请求，向所述终端发送获取的故障相关数据，所述数据查询请求根据所述报警信息确定；
根据所述终端返回的故障处理请求和所述获取的故障相关数据，确定所述计算机系统的故障类型，所述故障处理请求根据所述故障相关数据确定；
根据所述故障类型，对所述计算机系统的故障进行处理。
2.根据权利要求1所述的故障处理方法，其中，所述根据所述故障相关数据和所述终端返回的故障处理请求，确定所述计算机系统的故障类型包括：
根据所述故障相关数据和所述故障处理请求，确定所述计算机系统的各系统异常事件；
根据所述各系统异常事件的发生时间顺序，生成所述各系统异常事件组成的异常事件序列；
根据所述异常事件序列，确定所述故障类型。
3.根据权利要求2所述故障处理方法，其中，所述根据所述异常事件序列，确定所述故障类型包括：
确定异常事件序列中各异常事件对应的故障相关数据；
根据各故障相关数据落入哪个故障类型的故障数值范围，判断该异常事件序列属于哪个故障类型。
4.根据权利要求3所述故障处理方法，其中，
所述故障类型的故障数值范围通过如下步骤确定：
获取各历史异常事件序列相应的各历史故障相关数据；
根据所述各历史异常事件序列，利用机器学习模型确定对应的故障类型；
根据所述各历史异常事件序列与各故障类型的对应关系，以及所述各历史故障相关数据，确定所述各故障类型对应的故障数值范围。
5.根据权利要求2所述故障处理方法，其中，
所述异常事件序列为多个；
所述根据所述故障类型，对所述计算机系统的故障进行处理包括：
根据每个异常事件序列，确定每个故障类型；
根据各故障类型之间的因果关系，生成所述各故障类型组成的故障链；
根据所述故障链，对所述计算机系统的故障进行处理。
6.根据权利要求5所述故障处理方法，其中，所述根据所述故障链，对所述计算机系统的故障进行处理包括：
判断所述故障链中各故障类型的修复是否依赖于所述故障链中其他故障类型；
根据判断结果，确定所述故障链中各故障类型的修复顺序。
7.根据权利要求6所述故障处理方法，其中，所述判断所述故障链中各故障类型的修复是否依赖于所述故障链中其他故障类型包括：
判断所述故障链中的当前故障类型的修复是否依赖于前一个故障类型；
在依赖于前一个故障类型的情况下，将该前一个故障类型作为新的当前故障类型重复进行上述判断；
在不依赖于前一个故障类型的情况下，
将所述当前故障类型从所述故障链中删除后加入到修复链中，将该前一个故障类型作为当前故障类型重复进行上述判断直到所述故障链中所有的故障类型均加入到所述修复链中，所述修复链为所述判断结果，所述修复链中的各故障类型按照加入的时间从早到晚排列。
8.根据权利要求1-7任一项所述故障处理方法，其中，所述根据所述终端返回的数据查询请求，向所述终端发送获取的故障相关数据包括：
获取故障发生前后的系统运行数据；
根据所述数据查询请求，在所述系统运行数据中确定所述故障相关数据。
9.根据权利要求1-7任一项所述故障处理方法，其中，所述根据所述终端返回的数据查询请求，向所述终端发送获取的故障相关数据包括：
根据所述运维人员的身份信息，确定所述运维人员是否具有获取所述故障相关数据的权限；
在具有所述故障相关数据的权限的情况下，向所述终端发送所述故障相关数据。
10.根据权利要求1-7任一项所述故障处理方法，其中，所述根据所述终端返回的数据查询请求，向所述终端发送获取的故障相关数据包括：
对所述数据查询请求进行解析，以确定所述数据查询请求中的查询关键词；
根据所述查询关键词，生成数据查询指令；
根据所述数据查询指令，获取所述故障相关数据；
和或
所述根据所述故障相关数据和所述终端返回的故障处理请求，确定所述计算机系统的故障类型包括：
对所述故障处理请求进行解析，以确定所述故障处理请求中的处理关键词；
根据所述处理关键词，生成故障处理指令；
根据所述故障处理指令，确定所述故障类型。
11.一种故障处理装置，包括：
发送单元，用于响应于计算机系统发生故障，向运维人员的终端发送报警信息，根据所述终端返回的数据查询请求，向所述终端发送获取的故障相关数据，所述数据查询请求根据所述报警信息确定；
确定单元，用于根据所述终端返回的故障处理请求和所述获取的故障相关数据，确定所述计算机系统的故障类型，所述故障处理请求根据所述故障相关数据确定；
处理单元，用于根据所述故障类型，对所述计算机系统的故障进行处理。
12.一种故障处理装置，包括：
存储器；和
耦接至所述存储器的处理器，所述处理器被配置为基于存储在所述存储器中的指令，执行权利要求1-10任一项所述的故障处理方法。
13.一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现权利要求1-10任一项所述的故障处理方法。
CN201911111280.2A 2019-11-14 2019-11-14 故障处理方法、装置和故障处理装置 Active CN110855489B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911111280.2A CN110855489B (zh) 2019-11-14 2019-11-14 故障处理方法、装置和故障处理装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911111280.2A CN110855489B (zh) 2019-11-14 2019-11-14 故障处理方法、装置和故障处理装置

Publications (2)

Publication Number Publication Date
CN110855489A CN110855489A (zh) 2020-02-28
CN110855489B true CN110855489B (zh) 2022-08-12

Family

ID=69600378

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911111280.2A Active CN110855489B (zh) 2019-11-14 2019-11-14 故障处理方法、装置和故障处理装置

Country Status (1)

Country Link
CN (1) CN110855489B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111861221A (zh) * 2020-07-22 2020-10-30 海尔优家智能科技（北京）有限公司 设备故障信息的推送方法和装置、存储介质及电子装置
CN115695142A (zh) * 2022-10-25 2023-02-03 浪潮通信信息系统有限公司 一种面向网络运维的事件监控方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105897487A (zh) * 2016-06-13 2016-08-24 北京百度网讯科技有限公司 用于运维系统的设备管理方法和装置
CN108257659A (zh) * 2017-12-01 2018-07-06 深圳市新产业生物医学工程股份有限公司 故障处理方法、故障处理装置及电子终端
CN109767509A (zh) * 2018-12-07 2019-05-17 广东优世联合控股集团股份有限公司 一种设备运维管理方法、装置、可读介质及电子设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017211779A (ja) * 2016-05-24 2017-11-30 株式会社リコー 情報処理装置、システム、応急処置指示方法及びプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105897487A (zh) * 2016-06-13 2016-08-24 北京百度网讯科技有限公司 用于运维系统的设备管理方法和装置
CN108257659A (zh) * 2017-12-01 2018-07-06 深圳市新产业生物医学工程股份有限公司 故障处理方法、故障处理装置及电子终端
CN109767509A (zh) * 2018-12-07 2019-05-17 广东优世联合控股集团股份有限公司 一种设备运维管理方法、装置、可读介质及电子设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
AFC设备运维信息管理平台的开发与应用;郭瑞丽等;《都市快轨交通》;20171218(第06期);全文 *

Also Published As

Publication number Publication date
CN110855489A (zh) 2020-02-28

Similar Documents

Publication Publication Date Title
US20200293946A1 (en) Machine learning based incident classification and resolution
KR101545215B1 (ko) 데이터 센터 장애 이벤트 관리 자동화 시스템 및 방법
CN109362235B (zh) 对网络可访问存储装置处的事务进行分类的方法
EP3663919B1 (en) System and method of automated fault correction in a network environment
CN110855489B (zh) 故障处理方法、装置和故障处理装置
Tang et al. An integrated framework for optimizing automatic monitoring systems in large IT infrastructures
CN112308126A (zh) 故障识别模型训练方法、故障识别方法、装置及电子设备
AU2021218159B2 (en) Utilizing machine learning models to determine customer care actions for telecommunications network providers
US11722380B2 (en) Utilizing machine learning models to determine customer care actions for telecommunications network providers
CN112492567B (zh) 一种应急指挥通信中的故障分析和解决方法及装置
CN113505044B (zh) 数据库告警方法、装置、设备和存储介质
CN112783682B (zh) 一种基于云手机服务的异常自动修复方法
CN115357450A (zh) 基于人工智能的节点维护方法、装置、计算机设备及介质
KR20210011822A (ko) 인공 지능 기반 비정상 로그를 탐지하는 방법 및 이를 구현하는 시스템
JPWO2007007410A1 (ja) メッセージ解析装置、制御方法および制御プログラム
KR102509374B1 (ko) 언어학적 분석 기법을 이용한 it 인프라 장애 학습 및 분석 시스템
CN108039971A (zh) 一种告警方法及装置
US20210027254A1 (en) Maintenance management apparatus, system, method, and non-transitory computer readable medium
JP5435225B2 (ja) 運用管理装置、運用管理方法、及びプログラム
CN115186001A (zh) 一种补丁处理方法和装置
US11461406B2 (en) System and method for identifying newly trending topics in a data stream
CN114157553A (zh) 一种数据处理方法、装置、设备及存储介质
CN113568887A (zh) 一种基于大数据平台的运维操作监控方法及装置
JP3682778B2 (ja) 故障措置システム、及び、故障要因特定方法
CN111835566A (zh) 一种系统故障管理方法、装置及系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant