本申请涉及灾备技术领域，尤其涉及一种灾备方案的确定方法、装置、设备及存储介质。
背景技术：
目前，监管机构对商业银行等金融机构业务连续性的监管愈发严格，银行核心业务7×24全天业务无间断运营已经成为的业务连续性管理基本要求。监管要求在数据中心发生应用系统或基础设施不可用时，关键业务系统能在业务连续性指标内完成切换，对外营业。目前大多数金融机构已按监管要求完成同城灾备、两地三中心甚至多数据中心建设，实现了关键应用系统的多活及主备模式的部署，确保主生产中心核心生产系统宕机后，备份数据中心可以快速恢复数据和应用。
然而，由于数据中心业务关联关系和基础设施架构体系的复杂度，数据中心发生故障时，灾备管控系统不能形成对业务关联关系、基础设施关联关系联动分析研判结果，不能将业务影响分析和故障根因分析等关键信息汇总并自动形成切换辅助决策，关键信息不能传导至灾备管控系统。因此无法准确评估底层故障对上层业务的影响，也就不能根据故障的严重程度进行处置的优先级排序。当同时发生多个故障，可能最严重的故障是最后被处理的。此外，灾备切换指挥调度困难，协同参与方众多，切换方案编制难度大，切换流程编排复杂，实施风险高，当选择执行故障处置措施或者灾备切换措施，无法准备估计步骤的执行时长。而且现有的故障处置措施或者灾备切换措施是标准的，无法根据故障的具体情况进行合理的编排。
技术实现要素：
本发明要解决的技术问题是现有的灾备管控系统无法对故障场景分析快速得到灾备方案的问题。
为解决上述技术问题，第一方面，本申请实施例公开了一种灾备方案的确定方法，所述方法包括：
确定告警信息，所述告警信息中含有告警对象的标识和告警描述信息；
根据所述告警对象的标识和所述告警描述信息从预先构建好的知识图谱确定出故障场景和与所述故障场景对应的历史故障处置方法；
根据所述历史故障处置方法确定灾备方案。
进一步的，所述确定告警信息，包括：
间隔预设时长向所述告警对象发送检测信号；所述检测信号用于获取所述告警对象的反馈信号；
根据所述反馈信号确定故障信息。
进一步的，所述根据所述告警对象的标识和所述告警描述信息从预先构建好的知识图谱确定出故障场景和与所述故障场景对应的历史故障处置方法，包括：
根据所述告警对象的标识确定告警对象；
根据所述告警对象和所述告警描述信息确定历史告警信息；
根据所述预先构建好的知识图谱确定与所述历史告警信息对应的故障场景以及所述故障场景对应的历史故障处置方法。
进一步的，所述根据所述历史故障处置方法确定灾备方案之前，还包括：
根据所述故障场景，通过配置数据管理库确定所述告警对象的业务关联信息；
根据所述业务关联信息确定所述告警对象所在框架的基础架构信息；
根据所述基础架构信息确定所述告警对象的根源故障对象。
进一步的，所述根据所述历史故障处置方法确定灾备方案，包括：
获取所述根源故障对象的故障处理方法；
根据所述历史故障处置方法和所述故障处理方法确定灾备方案。
进一步的，所述方法还包括构建所述知识图谱的步骤；
所述构建所述知识图谱，包括：
获取历史故障处理档案；
根据所述历史故障处置档案确定历史告警信息；
根据所述历史告警信息确定所述历史告警信息对应的所述故障场景；
根据所述故障场景确定所述故障场景对应的历史故障处理方法；
根据所述历史告警信息与所述故障场景对应的关系，以及所述故障场景与所述历史故障处理方法的对应关系构建知识图谱。
进一步的，所述根据所述历史故障处置方法确定灾备方案之后，还包括：
获取所述灾备方案的审核流程信息；
从所述审核流程信息中确定出目标终端；
向所述目标终端发送灾备审核指令，所述灾备审核指令中携带有所述灾备方案，所述灾备审核指令用于指示所述目标终端审核所述灾备方案，并基于所述灾备方案确定出审核决策。
第二方面，本申请实施例公开了一种灾备方案的确定装置，所述装置包括：
确定模块，用于确定告警信息，所述告警信息中含有告警对象的标识和告警描述信息；
历史故障处置方法确定模块，用于根据所述告警对象的标识和所述告警描述信息从预先构建好的知识图谱确定出故障场景和与所述故障场景对应的历史故障处置方法；
灾备方案确定模块，用于根据所述历史故障处置方法确定灾备方案。
在一个可选的实施例中，所述装置还包括：检测信号发送模块，用于间隔预设时长向所述告警对象发送检测信号；所述检测信号用于获取所述告警对象的反馈信号；故障信息确定模块，用于根据所述反馈信号确定故障信息。
在一个可选的实施例中，所述装置还包括：告警对象确定模块，用于根据所述告警对象的标识确定告警对象；历史告警信息确定模块，用于根据所述告警对象和所述告警描述信息确定历史告警信息；历史告警信息与历史故障处置方法确定模块，用于根据所述预先构建好的知识图谱确定与所述历史告警信息对应的故障场景以及所述故障场景对应的历史故障处置方法。
在一个可选的实施例中，所述装置还包括：业务关联信息确定模块，用于根据所述故障场景，通过配置数据管理库确定所述告警对象的业务关联信息；基础架构信息确定模块，用于根据所述业务关联信息确定所述告警对象所在框架的基础架构信息；根源故障对象确定模块，用于根据所述基础架构信息确定所述告警对象的根源故障对象。
在一个可选的实施例中，所述装置还包括：故障处理方法获取模块，用于获取所述根源故障对象的故障处理方法；灾备方案确定模块，用于根据所述历史故障处置方法和所述故障处理方法确定灾备方案。
在一个可选的实施例中，所述装置还包括：知识图谱构建模块，用于构建所述知识图谱。所述知识图谱构建模块包括：历史故障处理档案获取单元，用于获取历史故障处理档案；历史告警信息确定单元，用于根据所述历史故障处置档案确定历史告警信息；故障场景确定单元，用于根据所述历史告警信息确定所述历史告警信息对应的所述故障场景；历史故障处理方法单元，用于根据所述故障场景确定所述故障场景对应的历史故障处理方法；知识图谱构建单元，用于根据所述历史告警信息与所述故障场景对应的关系，以及所述故障场景与所述历史故障处理方法的对应关系构建知识图谱。
在一个可选的实施例中，所述装置还包括：审核流程信息获取模块，用于获取所述灾备方案的审核流程信息；目标终端确定模块，用于从所述审核流程信息中确定出目标终端；审核决策确定模块，用于向所述目标终端发送灾备审核指令，所述灾备审核指令中携带有所述灾备方案，所述灾备审核指令用于指示所述目标终端审核所述灾备方案，并基于所述灾备方案确定出审核决策。
第三方面，本申请实施例公开了一种电子设备，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行如上所述的灾备方案的确定方法。
第四方面，本申请实施例公开了一种计算机可读存储介质，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或至少一段程序由处理器加载并执行以实现如上所述的灾备方案的确定方法。
本申请实施例提供的灾备方案的确定方法、装置、设备及存储介质，具有如下技术效果：
利用知识图谱对告警信息进行识别确定出故障场景，然后通过知识图谱确定出故障场景所对应的历史故障处置方法，进而确定出应对当前告警信息处理的灾备方案。通过知识图谱对告警信息进行识别分析，可快速筛选并确定灾备方案和处理流程，暨此可缩短灾备应对时间，提升灾备时间的响应效率，确保业务连续性指标落地。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案和优点，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。
图1是本申请实施例提供的一种应用环境的示意图；
图2是本申请实施例提供的一种应用系统构架示意图；
图3是本申请实施例提供的一种灾备方案的确定方法的流程示意图；
图4是本申请实施例提供的一种构建知识图谱方法流程示意图；
图5是本申请实施例提供的一种知识图谱的构建流程示意图；
图6是本申请实施例提供的一个知识图谱的结构示意图；
图7是本申请实施例提供的一种确定故障场景和历史故障处置方法的流程示意图；
图8是本申请实施例提供的一种确定根源故障对象的流程示意图；
图9是本申请实施例提供的一种告警对象所在框架的基础架构示意图；
图10是本申请实施例提供的一种灾备方案的确定装置示意图；
图11是本申请实施例提供的一种灾备方案确定方法的服务器的硬件结构框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。
需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
相关技术中，灾备系统的整体部署方式为，通过同城灾备数据中心和异地灾备数据中心相结合的模式来构建“两地三中心”的灾备架构。其中，同城灾备数据中心用于发生局部灾难事件时，接管灾难所影响的生产业务；异地灾备数据中心则用于发生区域性灾难时，接管灾难所影响的生产业务。
然而，数据中心业务关联关系和基础设施架构体系的复杂度，使得灾备切换指挥调度困难，协同参与方众多，切换方案编制难度大，切换流程编排复杂，实施风险高。数据中心发生故障时，不能形成对业务关联关系、基础设施关联关系联动分析研判结果，不能将业务影响分析和故障根因分析等关键信息汇总并自动形成切换辅助决策。
要破除这些组织和操作上的难点，可有效利用知识图谱和配置管理数据库快速实现业务影响分析和故障根因分析，自动匹配相符的切换方案、切换流程、切换参数和切换对象，快速准确的实施切换和自动化业务验证，向用户提供不间断的业务，保证用户体验与业务持续性。本申请实施例致力于设计利用知识图谱和配置管理数据，快速定位故障点、分析业务影响，实现灾备辅助决策。
请参阅图1，图1是本申请实施例提供的一种应用环境的示意图，包括灾备管控系统101和终端102。灾备管控系统101为一台服务器或者多台服务器组成的服务器集群，灾备管控系统101用于监控各个应用系统的运行，当应用系统故障时进行灾备处理。应用系统由多个进行具体业务处理的应用程序组成。终端102为装载有一个或者多个进行具体业务处理应用程序的设备。终端102可以是台式电脑、笔记本电脑、手机、平板电脑、自动柜员机(atm)等装载有可以进行业务处理应用程序的设备。本申请实施例中，灾备管控系统101和终端102之间可以通过有线链路连接，也可以通过无线链路连接。通信链路类型的选择可以根据实际的应用情况和应用环境而定。
本申请实施例中，灾备管控系统101可以应用在各种各样的场景中，比如金融行业，工业，农业等等。应用系统由应用群、应用组、应用和程序中的一层或多层构成。以下以金融行业中的银行的应用系统为例进行说明。图2是本申请实施例提供的一种应用系统构架示意图，如图2所示，应用系统由渠道应用群、服务交付应用群、产品应用群、技术支撑应用群等应用群构成。渠道应用群为面向银行用户，为银行用户提供交互的界面，接收用户提交的指令，并展示处理结果。服务交付应用群接到渠道应用群送来的数据及服务请求，按照不同的服务类型，将相关数据送到后面产品应用群相应的应用组中进行处理。技术支撑应用群主要是一些配合其他应用群正常工作的公共功能模块，还有诸如企业总线服务等全局性技术。产品应用群就是负责银行具体业务处理的应用群，它下面有很多的应用组，比如个人业务应用组、对公业务应用组、内部管理应用组等，每一个应用组负责处理一类银行服务。在一个具体的实施例中，个人业务应用组主要负责处理个人客户的业务服务，而个人业务应用组下面又包含贷款、存款、银行卡等具体应用，他们所包含的程序，分别处理贷款业务、存款业务、银行卡业务。内部管理应用组，银行系统处理的不光是客户的服务，还要承担一些内部管理工作，比如设置一个服务参数，具体的，像一些利率的调整，在银行内部就是调整一下利率参数；比如内部用户的管理，具体的，如柜员因为级别和岗位不同，能够访问的系统和功能也就不同，这方面要做岗位和权限的管理，这些都是内部管理应用组的处理数据范围。
本申请实施例中，应用系统的运行还需要依托于一些硬件设备，如终端、网络设备、服务器、数据库等。上述应用系统的各个组成部分或运行应用系统的硬件设备中任何一个出现故障都会造成某个具体的业务无法进行下去。因此灾备管控系统101对涉及关键业务的硬件或软件指标进行监控，以确保某个故障发生时能够及时的处理对故障进行处理，确保业务的连续性。具体的，灾备管控系统101将监控要素(包括网络、主机、中间件、数据库、应用等)划分为相互联系的各个单元，颗粒度根据业务需要和实际环境而定，之后依据专家经验比较客观地将这些单元进行有效结合，根据上下层次之间的隶属关系以及同一层次内两两元素之间的依赖关系进行定量描述，构建出一个关系矩阵。最后通过对所有层次之间总排序计算所有元素的相对权重并进行总排序。全面覆盖应用系统、数据库、中间件、服务器、存储、网络和动力环境各个领域。确保任何一个领域出现风险隐患时，能够及时地发现、预警、分析和处置保证业务连续性。
本申请实施例中，灾备管控系统101实现的功能主要知识图谱辅助决策功能和灾备处理流程确定功能。知识图谱辅助决策功能主要是当监控指标出现告警时利用知识图谱得到辅助决策预案。灾备处理流程确定功能为解析辅助决策预案以得到详细的切换流程。具体的，灾备处理流程确定功能包括：处理场景解析、处理对象解析、处理流程解析、处理参数解析。实现流程为：故障场景映射解决方案主流程，解决方案主流程分解得到子流程，根据子流程进行调度，然后执行原子服务。其中，处理场景解析包括场景匹配模块和切换场景库模块，场景匹配模块包括场景库分类管理、场景与流程匹配、故障趋势映射场景等功能单元；切换场景库模块包括多活切换场景、单组件切换场景、多组件切换场景、整中心切换场景、分布式切换场景等功能单元。处理对象解析包括流程匹配模块和切换流程模块，流程匹配模块包括流程分类管理、模板组合定制、流程审核发布等功能单元，切换流程模块包括计划内切换流程、计划外切换流程、回切流程等功能单元。处理流程解析包括参数匹配模块和原子服务模块，参数匹配模块包括原子服务开发规范、原子服务版本管理维护、服务检测与执行等功能单元，原子服务模块包括流程最小单元、通用原子服务、定制原子服务等功能单元。
以下介绍本申请一种灾备方案的确定方法的具体实施例，为了描述方便，下文将以灾备管控系统为执行主语进行详细阐述。图3是本申请实施例提供的一种灾备方案的确定方法的流程示意图，本说明书提供了如实施例或流程图的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或服务器产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图3所示，该方法可以包括：
s301：确定告警信息，告警信息中含有告警对象的标识和告警描述信息。
本申请实施例中，灾备管控系统通过确定告警信息来应用系统的各个组成部分或运行应用系统的硬件设备中某个对象是否告警以及告警的具体情况。作为一种示例，甲网点柜台上进行业务处理的a终端设备发出“甲网点柜台上进行业务处理的a终端设备办理存款业务访问服务器失败”的告警信息，该告警信息中告警对象的标识为甲网点柜台上进行业务处理的a终端设备，告警描述信息为办理存款业务访问服务器失败。
本申请实施例中，灾备管控系统确定告警信息的技术方案有很多种，下面具体介绍几种可选的实施方式：
在一种可选的实施方式中，灾备管控系统间隔预设时长向待测试对象发送检测信号，检测信号用于获取待检测对象的反馈信号。然后待测试对象向灾备管控系统发送反馈信号，以反馈其工作状态，灾备管控系统从而确定待测试对象是否告警。待测试对象为灾备管控系统监控的某个具体的应用程序或某个硬件设施，预设时长可以为根据测试对象易出现告警的可能性，或承载数据的重要程度进行设置。可选的，预设时长还可以为0，这也意味着，灾备管控系统实时监控待测试对象。
在另一种可选的实施方式中，当待测试对象出现故障时可直接向灾备管控系统发送告警信息，此时，该待测试对象可以被认为是告警对象。
在另一种可选的实施方式中，还可以通过构建报警系统作为中间系统监控应用系统的各个组成部分或运行应用系统的硬件设备中是否发生故障，当报警系统监测到故障发生时向灾备管控系统发送告警信息。
s303：根据告警对象的标识和告警描述信息从预先构建好的知识图谱确定出故障场景和与故障场景对应的历史故障处置方法。
本申请实施例中，灾备管控系统中设置有预先构建好的知识图谱，知识图谱为根据历史故障处理档案构建。可选的，知识图谱可以为设置在灾备管控系统自身构建而成。在一些实施方式中，知识图谱可以为通过其他方式构建完成后导入灾备管控系统。图4是本申请实施例提供的一种构建知识图谱方法流程示意图，如图4所示，构建知识图谱的主要过程，可以包括：
s401：获取历史故障处理档案。
本申请实施例中，历史故障处理档案包括历史故障处置报告和历史灾备切换报告。历史故障处理档案可通过历史档案数据库获取，对于一些年代久远或为进行电子数据化处理的历史故障处理档案也可以通过人工的方式进行输入。
s403：根据历史故障处置档案确定历史告警信息。
本申请实施例中，灾备管控系统抽取历史故障处理档案中的历史告警信息，该历史告警信息包括历史告警对象的标识和历史告警描述信息。
s405：根据历史告警信息确定历史告警信息对应的故障场景。
本申请实施例中，灾备管控系统从历史故障处理档案中确定出上述步骤抽取到的历史告警信息相对应的故障场景。故障场景即为应用系统的各个组成部分或运行应用系统的硬件设备中某个或某些对象故障，导致告警对象发送告警信息。由上述描述可知，灾备管控系统监控应用系统的各个组成部分或运行应用系统的硬件设备，某个具体的应用程序或者设备出现告警时，并不一定是该程序或设备出现故障，也可能是底层的应用群组或底层设备发生了故障。
s407：根据故障场景确定故障场景对应的历史故障处理方法。
本申请实施例中，灾备管控系统在确定了历史告警信息和历史告警信息对应的故障场景之后，还需要从历史故障处理档案中确定出与故障场景对应的历史故障处理方法。
s409：根据历史告警信息与故障场景对应的关系，以及故障场景与历史故障处理方法的对应关系构建知识图谱。
本申请实施例中，灾备管控系统通过上述步骤可获得历史告警信息与故障场景的映射关系，以及故障场景与历史故障处理方法的映射关系，以此可构建出知识图谱。
在一个可选的实施方式中，知识图谱通过如下步骤构建：首先构建知识本体模型。将长期运维过程中积累的经验、知识分为事件本体、任务本体、对象本体，针对不同本体从高层至低层建立语义层次，层次之间用关系建立联系。其中，事件本体指灾备应急事件，任务本体指灾备应急事件所要解决的关键问题，对象本体指灾备应急事件的处置对象。然后建立知识图谱结构。将知识图谱的结构分为两大类，一类为概念层级关系、另一类为实体关系，概念层级关系表示的是知识本体概念层级结构，实体关系表示知识中实体及其之间的关系，以此建立知识图谱的基本结构。最后建立知识本体模型与知识图谱结构的映射匹配机制，把知识本体模型的概念层级结构当作树，顶层概念为根节点，多层子概念为孩子节点，概念最底层的实例为叶节点，将概念树结构完整的映射到知识图谱中，生成知识图谱的概念层次关系图，形成知识图谱。
在一个具体的实施方式中，构建知识图谱可通过以下方式实现，图5是本申请实施例提供的一种知识图谱的构建流程示意图，如图5所示，从历史的故障处置报告、灾备切换报告等文档中，采用nlp(自然语言处理)或者基于规则方式进行知识抽取，将告警、事件、灾备切换步骤等知识，用资源描述框架(resourcedeionframework，rdf)的三元组spo(subject，predicate，object)来进行知识表示，然后进行知识融合。因为知识来源广泛，存在知识质量良莠不齐、来自不同数据源的知识重复、层次结构缺失等问题，所以必须要进行知识的融合，提高知识的质量。等知识图谱构建好之后，在实际的应用中，利用知识推理来找到合理的故障处理流程。
图6是本申请实施例提供的一个知识图谱的结构示意图，如图6所示，该知识图谱表示了业务甲的监控指标a报警的情况下的灾备应急知识，其中包括了：业务甲相关联的微服务乙、丙，微服务相关联的交换机、数据库等it基础架构的告警事件，产品厂商的故障手册，故障处理方案，故障处理步骤的脚本、参数、维护人员和执行时间等信息。通过上述知识图谱，在发生告警时可快速确定故障场景和相应的历史故障处理方法，为确定当前告警的处理方案的确定提供参考，省去对当前故障场景的分析时间以及制定初步方案的时间，提升灾备处理响应效率，确保业务连续性指标落地。
本申请实施例中，灾备管控系统将告警对象的标识和告警描述信息输入知识图谱，通过知识图谱可以确定出故障场景以及与故障场景对应的历史故障处置方法。图7是本申请实施例提供的一种确定故障场景和历史故障处置方法的流程示意图，如图7所示，根据告警对象的标识和告警描述信息从预先构建好的知识图谱确定出故障场景和与故障场景对应的历史故障处置方法，包括：
s701：根据告警对象的标识确定告警对象。
本申请实施例中，灾备管控系统根据告警对象的标识可以确定出具体的告警对象。例如，某网点柜台上进行业务处理的某台终端设备发出告警信息，根据告警信息中的此台终端设备的标识可确定该终端设备的位置、型号等信息，用以确定此终端设备进行处理的业务联系和硬件信息等。
s703：根据告警对象和告警描述信息确定历史告警信息。
本申请实施例中，灾备管控系统将告警对象和告警描述信息输入知识图谱，可确定出历史告警信息。具体的，如果当前告警对象和对应的告警描述信息是历史故障处理档案中出现过的，则可以通过知识图谱直接确定历史告警信息。如果当前告警对象是历史故障处理档案中未出现过的，则可根据告警描述信息以及与当前告警对象接近的历史告警对象确定历史告警信息。作为一种示例，甲网点柜台上进行业务处理的a终端设备发出“甲网点柜台上进行业务处理的a终端设备办理存款业务访问服务器失败”的告警信息，该告警信息中告警对象的标识为甲网点柜台上进行业务处理的a终端设备，告警描述信息为办理存款业务访问服务器失败，由此，可确定告警对象为甲网点柜台上进行业务处理的a终端设备，以及a终端设备的位置、型号、配置等信息。将告警对象和告警描述信息输入知识图谱确定历史告警对象为“甲网点柜台上进行业务处理的a终端设备”以及历史告警描述信息为“办理存款业务访问服务器失败”的历史告警信息。如果知识图谱中未包含历史故障对象为“甲网点柜台上进行业务处理的a终端设备”，但含有历史故障对象为“甲网点柜台上进行业务处理的b终端设备”、历史告警描述信息为“办理存款业务访问服务器失败”的历史告警信息，且b终端设备的型号、配置等信息与a终端设备相似，历史告警描述信息为“办理存款业务访问服务器失败”的历史告警信息，则可确定该历史告警信息为与当前情景接近的历史告警信息。同理，还可以确定历史故障对象为“乙网点柜台上进行业务处理的c终端设备”、历史告警描述信息为“办理存款业务访问服务器失败”的历史告警信息为与当前情景接近的历史告警信息。
s705：根据预先构建好的知识图谱确定与历史告警信息对应的故障场景以及故障场景对应的历史故障处置方法。
本申请实施例中，灾备管控系统通过知识图谱确定出与当前情景接近的历史告警信息后，还需要通过知识图谱确定与历史告警信息对应的故障场景，以此来确定当前告警信息的故障根源、其他关联对象的表现等整体故障场景。并根据故障场景确定出相对应的历史故障处置方法，以此为参考确定出处理当前告警信息的灾备方案。
s305：根据历史故障处置方法确定灾备方案。
本申请实施例中，灾备管控系统对知识图谱确定的故障处置方法进行解析，对照配置管理解析结果将历史故障处置方法确定为灾备方案。根据告警信息通过知识图谱匹配历史故障处置方法，然后历史故障处置方法为依据确定灾备方案，能够实现重大故障场景下的快速准确的灾备辅助决策。作为一种示例，灾备管控系统通过知识图谱确定出由于a终端设备与业务服务器之间的交换机故障，导致了甲网点柜台上进行业务处理的a终端设备办理存款业务访问服务器失败。对此，基于知识图谱确定的历史故障处置方法为，对该发生故障的交换机进行检修以排除故障。根据历史故障处置方法确定的灾备方案为对发生故障的交换机进行检修以排除故障。
在一个可选的实施例中，灾备管控系统还可以利用知识图谱和配置管理数据库，快速定位故障点、分析业务影响和基础设施关联关系，实现灾备辅助决策。根据历史故障处置方法确定灾备方案之前，还包括确定根源故障对象的步骤。图8是本申请实施例提供的一种确定根源故障对象的流程示意图，如图8所示，确定根源故障对象，包括：
s801：根据故障场景，通过配置数据管理库确定告警对象的业务关联信息。
本申请实施例中，灾备管控系统利用配置管理数据库，对知识图谱识别的故障场景进行解析，从而判定故障系统类别及灾备部署情况。可选的，配置数据管理库为es数据库(elasticsearch)。利用知识图谱梳理es库中关键系统重大故障事件的事件等级、业务影响、应用部署方式、维护人员、恢复时间等关键信息，形成精简的可视化故障处置方案和处置流程，展示出故障关联配置管理库。根据故障场景中的告警对象的业务关联、告警对象所在的应用系统构架、硬件设备框架等信息，通过配置管理数据库对照查找当前告警对象的业务关联信息。
s803：根据业务关联信息确定告警对象所在框架的基础架构信息。
本申请实施例中，灾备管控系统根据业务关联信息可以确定出与告警对象所在软件架构和硬件架构组成的基础架构信息，以进一步确定导致当前告警的根源故障对象。图9是本申请实施例提供的一种告警对象所在框架的基础架构示意图，如图9所示，从上至下分别是应用服务层、系统资源层、网络服务层和基础设施层。全面覆盖了与告警对象相关的应用系统、数据库、中间件、服务器、存储、网络和动力环境各个方面的信息。
在一个可选的实施例中，应用服务层示出了告警对象的业务关联关系。在应用服务层面上可以分为交易进程类、交易数据类、批处理运行类和交易日志和报文类、错误信息类，能够实时反映交易应用进程的运行状态。其中交易进程类指标包括交易队列的使用情况、资源消耗情况。交易数据类指标包括交易笔数，交易并交易笔数、交易平均响应时间、在线用户数。与交易相关文件类指标包括交易报文数量、交易日志中的错误信息等。
在一个可选的实施例中，系统资源层示出了应用相关信息和平台相关信息。在系统资源层面可以分为数据库类、中间件、操作系统类和存储四大类。其中数据库类的指标可以分别反映服务器的运行状态、实例的运行状态、会话数、锁资源和监听器的运行状态。中间件类根据不同的使用特性，如业务中间件、消息中间件等。操作系统类可以按照使用环境分为windows、linux和unix等，客观反映各种主流操作系统的运行状态。存储系统类可分为光纤交换机、光纤交换机端口、存储系统、xp存储系统和光纤链路等，客观反映存储系统端到端的运行状况。
在一个可选的实施例中，网络服务层示出了网络相关信息。在网络服务层面按照管理特性可分为网络或安全设备的处理器、内存、风扇、温度、电源、系统、设备端口、运行协议等不同纬度客观反映网络环境的运行情况和运行质量。
在一个可选的实施例中，基础设施层示出了硬件相关信息。在基础设施层面可以按照管理设备种类分为电量仪、不间断电源(uninterruptiblepowersupply，ups)、空调等，反映机房基础设施的使用情况和运行质量。
s805：根据基础架构信息确定告警对象的根源故障对象。
本申请实施例中，根据上述基础架构信息可快速、准确地确定出导致告警对象告警的根源故障对象。
作为一种示例，根据告警信息“甲网点柜台上进行业务处理的a终端设备办理存款业务访问服务器失败”通过知识图谱识别出的故障场景，根据故障场景中的业务关联，对照当前配置管理数据库找出与存款业务相关的诸如贷款业务、银行卡业务等业务关联信息。作为一种可选的实施方式，还可以对照当前配置管理数据库找出与a终端设备处于在同一构架下进行同样业务处理的b终端设备，将b终端设备作为a终端设备的业务关联信息的一部分。
根据上述业务关联信息，灾备管控系统通过配置管理数据库确定出执行上述关联业务的全部软件对象和硬件设备，并根据各个对象的相互联系示出告警对象所在框架的基础架构信息，然后根据基础架构信息，确定出告警对象具有关联的对象进行进一步分析验证，可确定出导致当前告警的根源故障对象。上述示例中，a终端设备的关联的对象有贷款业务、银行卡业务和b终端设备等。验证a终端设备是否可以访问关联业务的服务器，如果a终端设备可以访问关联业务的服务器。则可以确定a终端设备所进行业务处理的应用系统无故障，故障可能是a终端设备与处理存款业务的服务器之间的网络连接出现故障。验证关联的b终端设备是否可以访问关联业务的服务器，如果b终端设备同样的无法访问处理存款业务的服务器，但可以访问关联业务的服务器，可以确定a终端设备和b终端设备与处理存款业务的服务器之间共同网络链路是根源故障对象。例如查看a终端设备与处理存款业务的服务器之间的交换机日志，若交换机日志出现非正常信息，则导致当前a终端设备报警的根源故障设备即为该交换机。
在一个可选的实施例中，灾备管控系统对知识图谱确定的故障处置方法进行解析，对照配置管理解析结果，匹配故障系统已纳管灾备切换方案。根据历史故障处置方法确定灾备方案包括：获取根源故障对象的故障处理方法。根据历史故障处置方法和故障处理方法确定灾备方案。该实施例中，由于it架构更新频率更高，且部分硬件设备升级更换较多，或者随着灾备系统的完善，新增了部分系统或部分设备的灾备切换对象，根据故障场景确定出的历史故障处置方法在某些具体的处理步骤上与当前的系统构架不一致，因此，需要依据当前的配置管理数据对历史故障处置方法进行调整。作为一种示例，历史故障处置方法中对根源故障设备交换机的处置方法为对该故障交换机进行检修以排除故障。但是，在当前的配置管理中，该交换机配置了灾备冗余备份交换机，因此，可将历史故障处置方法中对故障交换机进行检修以排除故障调整为将故障交换机切换为备份交换机。
本申请实施例中，灾备管控系统利用知识图谱、配置管理数据库联动分析，形成重大故障的业务和基础设施影响视图。故障场景分析对接输出灾备管控系统，匹配灾备切换方案，实现重大故障场景下的快速准确的灾备辅助决策。
在一个可选的实施例中，灾备管控系统根据历史故障处置方法确定灾备方案之后，还包括将灾备方案发送给决策层进行决策。具体的，灾备管控系统获取灾备方案的审核流程信息，灾备管控系统从审核流程信息中确定出目标终端，灾备管控系统向目标终端发送灾备审核指令，灾备审核指令中携带有灾备方案，灾备审核指令用于指示目标终端审核灾备方案，并基于灾备方案确定出审核决策。作为一种示例，灾备管控系统推送故障系统灾备切换预案、可用切换方案及相应的切换流程给相关人员复核确认，并推送人员到岗签到通知。灾备管控系统发起灾备环境可用性检查和切换前状态检查。整合复核确认意见、可用性检测结果和状态检查结果作为辅助决策意见提交决策人员。在主生产中心无法恢复故障时，灾备切换步骤如下：决策人员审核辅助决策意见，经审批授权发布切换指令。干系人在灾备管控系统签到，系统按选定的切换方案启动切换流程，将故障系统到切换到灾备中心运行。灾备应用系统启动完成，经自动化业务验证后接入生产。上述实施例中，经过对切换方案、切换流程及可用性检查的预调度、预审核、预实施，一旦宣告灾难即可快速实施切换，实现业务连续性指标落地。
本申请实施例提供的灾备方案的确定方法，针对快速准确的实现数据中心灾难切换的需求，本方案致力于提供一种利用知识图谱实现灾备切换辅助决策的方案，能实现对业务系统连续性指标的保护。利用承载数据中心在长期运维过程中积累的经验、知识的知识图谱、配置管理等产出，形成完整的业务影响分析、基础设施关联关系和架构视图。在关键业务系统出现严重故障时，可通过知识图谱的关联分析，筛选并推荐灾备切换方案和切换流程、切换参数和切换对象备选，暨此可缩短切换前准备时间，提升灾备切换响应效率，确保业务连续性指标落地。
本申请实施例还公开了一种灾备方案的确定装置，图10是本申请实施例提供的一种灾备方案的确定装置示意图，如图10所示，该装置包括：
确定模块1001，用于确定告警信息，告警信息中含有告警对象的标识和告警描述信息。
历史故障处置方法确定模块1003，用于根据告警对象的标识和告警描述信息从预先构建好的知识图谱确定出故障场景和与故障场景对应的历史故障处置方法。
灾备方案确定模块1005，用于根据历史故障处置方法确定灾备方案。
在一个可选的实施例中，该装置还包括：检测信号发送模块，用于间隔预设时长向告警对象发送检测信号。检测信号用于获取告警对象的反馈信号。故障信息确定模块，用于根据反馈信号确定故障信息。
在一个可选的实施例中，该装置还包括：告警对象确定模块，用于根据告警对象的标识确定告警对象。历史告警信息确定模块，用于根据告警对象和告警描述信息确定历史告警信息。历史告警信息与历史故障处置方法确定模块，用于根据预先构建好的知识图谱确定与历史告警信息对应的故障场景以及故障场景对应的历史故障处置方法。
在一个可选的实施例中，该装置还包括：业务关联信息确定模块，用于根据故障场景，通过配置数据管理库确定告警对象的业务关联信息。基础架构信息确定模块，用于根据业务关联信息确定告警对象所在框架的基础架构信息。根源故障对象确定模块，用于根据基础架构信息确定告警对象的根源故障对象。
在一个可选的实施例中，该装置还包括：故障处理方法获取模块，用于获取根源故障对象的故障处理方法。灾备方案确定模块，用于根据历史故障处置方法和故障处理方法确定灾备方案。
在一个可选的实施例中，该装置还包括：知识图谱构建模块，用于构建知识图谱。知识图谱构建模块包括：历史故障处理档案获取单元，用于获取历史故障处理档案。历史告警信息确定单元，用于根据历史故障处置档案确定历史告警信息。故障场景确定单元，用于根据历史告警信息确定历史告警信息对应的故障场景。历史故障处理方法单元，用于根据故障场景确定故障场景对应的历史故障处理方法。知识图谱构建单元，用于根据历史告警信息与故障场景对应的关系，以及故障场景与历史故障处理方法的对应关系构建知识图谱。
在一个可选的实施例中，该装置还包括：审核流程信息获取模块，用于获取灾备方案的审核流程信息。目标终端确定模块，用于从审核流程信息中确定出目标终端。审核决策确定模块，用于向目标终端发送灾备审核指令，灾备审核指令中携带有灾备方案，灾备审核指令用于指示目标终端审核灾备方案，并基于灾备方案确定出审核决策。
该申请实施例中的装置与方法实施例基于同样地申请构思。
本申请实施例还提供了一种电子设备，设备包括处理器和存储器，存储器中存储有至少一条指令或至少一段程序，至少一条指令或至少一段程序由处理器加载并执行如上所述的灾备方案的确定方法。
本申请实施例所提供的方法实施例可以在计算机终端、服务器或者类似的运算装置中执行。以运行在服务器上为例，图11是本申请实施例提供的一种灾备方案确定方法的服务器的硬件结构框图。如图11所示，该服务器1100可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessingunits，cpu)1110(处理器1110可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器1130，一个或一个以上存储应用程序1123或数据1122的存储介质1120(例如一个或一个以上海量存储设备)。其中，存储器1130和存储介质1120可以是短暂存储或持久存储。存储在存储介质1120的程序可以包括一个或一个以上模块，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1110可以设置为与存储介质1120通信，在服务器1100上执行存储介质1120中的一系列指令操作。服务器1100还可以包括一个或一个以上电源1160，一个或一个以上有线或无线网络接口1150，一个或一个以上输入输出接口1140，和/或，一个或一个以上操作系统1121，例如windowsservertm，macosxtm，unixtm，linuxtm，freebsdtm等等。
输入输出接口1140可以用于经由一个网络接收或者发送数据。上述的网络具体实例可包括服务器1100的通信供应商提供的无线网络。在一个实例中，输入输出接口1140包括一个网络适配器(networkinterfacecontroller，nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，输入输出接口1140可以为射频(radiofrequency，rf)模块，其用于通过无线方式与互联网进行通讯。
本领域普通技术人员可以理解，图11所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，服务器1100还可包括比图11中所示更多或者更少的组件，或者具有与图11所示不同的配置。
本申请的实施例还提供了一种存储介质，所述存储介质可设置于服务器之中以保存用于实现方法实施例中一种灾备方案的确定方法相关的至少一条指令、至少一段程序、代码集或指令集，该至少一条指令、该至少一段程序、该代码集或指令集由该处理器加载并执行以实现上述方法实施例提供的灾备方案的确定方法。
可选地，在本实施例中，上述存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
本申请实施例提供的灾备方案的确定方法、装置、设备及存储介质具有如下优点：
1、结合知识图谱，给出故障场景分析和趋势分析，提升事件响应效率。
2、在数据中心重要应用系统出现重大故障时，能够快速准确的对故障系统实施切换，尽可能降低业务影响，满足业务连续性的要求。
3、方案实现不改动应用架构，不增加系统资源需求。
4、方案不仅适用于私有云架构，还可扩展至分布式，适配性强。
需要说明的是：上述本申请实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。
1.一种灾备方案的确定方法，其特征在于，所述方法包括：
确定告警信息，所述告警信息中含有告警对象的标识和告警描述信息；
根据所述告警对象的标识和所述告警描述信息从预先构建好的知识图谱确定出故障场景和与所述故障场景对应的历史故障处置方法；
根据所述历史故障处置方法确定灾备方案。
2.根据权利要求1所述的灾备方案的确定方法，其特征在于，所述确定告警信息，包括：
间隔预设时长向所述告警对象发送检测信号；所述检测信号用于获取所述告警对象的反馈信号；
根据所述反馈信号确定故障信息。
3.根据权利要求2所述的灾备方案的确定方法，其特征在于，所述根据所述告警对象的标识和所述告警描述信息从预先构建好的知识图谱确定出故障场景和与所述故障场景对应的历史故障处置方法，包括：
根据所述告警对象的标识确定告警对象；
根据所述告警对象和所述告警描述信息确定历史告警信息；
根据所述预先构建好的知识图谱确定与所述历史告警信息对应的故障场景以及所述故障场景对应的历史故障处置方法。
4.根据权利要求3所述的灾备方案的确定方法，其特征在于，所述根据所述历史故障处置方法确定灾备方案之前，还包括：
根据所述故障场景，通过配置数据管理库确定所述告警对象的业务关联信息；
根据所述业务关联信息确定所述告警对象所在框架的基础架构信息；
根据所述基础架构信息确定所述告警对象的根源故障对象。
5.根据权利要求4所述的灾备方案的确定方法，其特征在于，所述根据所述历史故障处置方法确定灾备方案，包括：
获取所述根源故障对象的故障处理方法；
根据所述历史故障处置方法和所述故障处理方法确定灾备方案。
6.根据权利要求1-5任一所述的灾备方案的确定方法，其特征在于，所述方法还包括构建所述知识图谱的步骤；
所述构建所述知识图谱，包括：
获取历史故障处理档案；
根据所述历史故障处置档案确定历史告警信息；
根据所述历史告警信息确定所述历史告警信息对应的所述故障场景；
根据所述故障场景确定所述故障场景对应的历史故障处理方法；
根据所述历史告警信息与所述故障场景对应的关系，以及所述故障场景与所述历史故障处理方法的对应关系构建知识图谱。
7.根据权利要求6所述的灾备方案的确定方法，其特征在于，所述根据所述历史故障处置方法确定灾备方案之后，还包括：
获取所述灾备方案的审核流程信息；
从所述审核流程信息中确定出目标终端；
向所述目标终端发送灾备审核指令，所述灾备审核指令中携带有所述灾备方案，所述灾备审核指令用于指示所述目标终端审核所述灾备方案，并基于所述灾备方案确定出审核决策。
8.一种灾备方案的确定装置，其特征在于，所述装置包括：
确定模块，用于确定告警信息，所述告警信息中含有告警对象的标识和告警描述信息；
历史故障处置方法确定模块，用于根据所述告警对象的标识和所述告警描述信息从预先构建好的知识图谱确定出故障场景和与所述故障场景对应的历史故障处置方法；
灾备方案确定模块，用于根据所述历史故障处置方法确定灾备方案。
9.一种电子设备，其特征在于，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行如权利要求1-7任一所述的灾备方案的确定方法。
10.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或至少一段程序由处理器加载并执行以实现如权利要求1-7任一所述的灾备方案的确定方法。
技术总结