CN116361081A - 一种故障处理方法、装置、电子设备及存储介质 - Google Patents

一种故障处理方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
CN116361081A
CN116361081A CN202111574524.8A CN202111574524A CN116361081A CN 116361081 A CN116361081 A CN 116361081A CN 202111574524 A CN202111574524 A CN 202111574524A CN 116361081 A CN116361081 A CN 116361081A
Authority
CN
China
Prior art keywords
service
fault
event
business
fault event
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.)
Pending
Application number
CN202111574524.8A
Other languages
English (en)
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.)
ZTE Corp
Original Assignee
ZTE Corp
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 ZTE Corp filed Critical ZTE Corp
Priority to CN202111574524.8A priority Critical patent/CN116361081A/zh
Priority to PCT/CN2022/132370 priority patent/WO2023116276A1/zh
Publication of CN116361081A publication Critical patent/CN116361081A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2205Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested
    • G06F11/221Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested to test buses, lines or interfaces, e.g. stuck-at or open line faults
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26Functional testing

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明实施例涉及移动通讯技术领域,公开了一种故障处理方法、装置、电子设备及存储介质。上述故障处理方法包括:获取各业务服务节点提供的业务服务;根据所述各业务服务节点提供的业务服务编排各故障事件对应的业务服务节点;其中,所述故障事件与多个业务服务节点相对应;在检测到故障事件的情况下,调度与所述检测到的故障事件对应的所述多个业务服务节点分别对所述故障事件进行检测;获取所述多个业务服务节点分别对所述故障事件进行检测的结果;根据所述多个业务服务节点分别对所述故障事件进行检测的结果,确定故障原因,旨在实现各厂家/专业网的业务服务的解耦和独立设计,可以进行未知故障的定位,以高效地处理故障。

Description

一种故障处理方法、装置、电子设备及存储介质
技术领域
本申请实施例涉及移动通讯技术领域,特别涉及一种故障处理方法、装置、电子设备及存储介质。
背景技术
在数字化经济高速发展的背景下,网络运维的自动化、数字化、智能化已成为通信行业的共识。近些年,各大运营商和标准组织等先后推出了自智网络白皮书,即自智网络水平分为L0-L5六个等级。例如,“单域自治、跨域协同”的三层框架与四个闭环的自智网络参考框架。通过将运维任务进行拆分,各厂家各专业提供运维能力,运营商可以根据运维流程进行流程组装,实现运维/运营的自动化,并强化运维知识,推进运维能力的自主沉淀,激发运维转型活力和核心能力的掌控力。
然而,目前的框架中同厂家的各专业网将自己的能力产品化,造成专业单域自治的局面,以及各厂家之间存在壁垒,造成厂家单域自治的局面,而故障定位是通过领域间一段段的人工方式进行,则业务流程的拉通就会受限于各厂家之间的壁垒,以及各专业领域之间的配合。在面对故障变化比较复杂的业务场景或者未知故障时,例如自智网络中的故障事件,存在开发难度大、周期长、以及协同的效率低的问题,导致无法有效地实现故障的处理工作。
发明内容
本申请实施例的主要目的在于提出一种故障处理方法、装置、电子设备及存储介质,实现各厂家/专业网的业务服务的解耦和独立设计,可以进行未知故障事件的定位,并高效地处理故障事件。
为至少实现上述目的,本申请实施例提供了一种故障处理方法,包括:获取各业务服务节点提供的业务服务;根据所述各业务服务节点提供的业务服务编排各故障事件对应的业务服务节点;其中,所述故障事件与多个业务服务节点相对应;在检测到故障事件的情况下,调度与所述检测到的故障事件对应的所述多个业务服务节点分别对所述故障事件进行检测;获取所述多个业务服务节点分别对所述故障事件进行检测的结果;根据所述多个业务服务节点分别对所述故障事件进行检测的结果,确定故障原因。
为至少实现上述目的,本申请实施例还提供一种故障处理装置,包括:第一获取模块,用于获取各业务服务节点提供的业务服务;编排模块,用于根据所述各业务服务节点提供的业务服务编排各故障事件对应的业务服务节点;其中,所述故障事件与多个业务服务节点相对应;调度模块,用于在检测到故障事件的情况下,调度与所述检测到的故障事件对应的所述多个业务服务节点分别对所述故障事件进行检测;第二获取模块,用于获取所述多个业务服务节点分别对所述故障事件的检测结果;确定模块,用于根据所述多个业务服务节点分别对所述故障事件的检测结果,确定故障原因。
为至少实现上述目的,本申请实施例还提供了一种电子设备,包括:至少一个处理器;以及,与所述至少一个处理器通信连接的存储器;其中,所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行上述的故障处理方法。
为至少实现上述目的,本申请实施例还提供了一种计算机可读存储介质,存储有计算机程序,所述计算机程序被处理器执行时实现上述的故障处理方法。
本申请实施例提出的故障处理方法,通过获取各业务服务节点提供的业务服务,并根据各业务服务节点提供的业务服务编排各故障事件对应的业务服务节点,其中,故障事件与多个业务服务节点相对应,在检测到故障事件的情况下,调度与检测到的故障事件对应的多个业务服务节点,对故障事件进行检测,并获取多个业务服务节点分别对故障事件的检测结果,然后根据多个业务服务节点分别对故障事件的检测结果,确定故障原因。通过编排各故障事件对应的业务服务节点,即根据故障事件预先定义各厂家/专业网的业务服务之间的协作关系,保证了各厂家/专业网的业务服务的解耦和独立设计,使得业务流程不易中断和重组,在实际的自智网络故障处理场景中可以依据实际需要的业务服务进行灵活自由的组合,从而进行未知故障事件的定位,并高效地处理故障事件。
附图说明
一个或多个实施例通过与之对应的附图中的图片进行示例性说明,这些示例性说明并不构成对实施例的限定,附图中具有相同参考数字标识的元件表示为类似的元件,除非有特别的申明,附图中的图不构成比例限制。
图1是根据本发明一个实施例提供的一种EDA的工作机制的示意图;
图2是根据本发明一个实施例提供的一种编排/执行引擎的整体架构图;
图3是根据本发明一个实施例提供的一种故障处理方法事务流程图;
图4是根据本发明一个实施例提供的一种实现步骤301的交互图;
图5是根据本发明一个实施例提供的一种的处理业务流的示意图;
图6是根据本发明一个实施例提供的一种实现步骤302的交互图;
图7是根据本发明一个实施例提供的一种实现步骤303和步骤304的交互图;
图8是根据本发明一个实施例提供的一种RPC模型的结构图;
图9是根据本发明一个实施例提供的一种组件全景图;
图10是根据本发明一个实施例提供的一种实际应用示意图;
图11是根据本发明一个实施例提供的一种故障处理装置的示意图;
图12是根据本发明一个实施例提供的一种电子设备的结构图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合附图对本申请的各实施例进行详细的阐述。然而,本领域的普通技术人员可以理解,在本申请各实施例中,为了使读者更好地理解本申请而提出了许多技术细节。但是,即使没有这些技术细节和基于以下各实施例的种种变化和修改,也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便,不应对本申请的具体实现方式构成任何限定,各个实施例在不矛盾的前提下可以相互结合相互引用。
为了便于理解,现对本发明实施例的相关技术进行以下说明:
各厂家/专业网业务服务架构应用的系统把大而复杂的业务系统拆分成许多高内聚的业务服务,每个业务服务负责相对独立的逻辑。当一个系统被拆分成了很多新的业务服务后,原有的业务处理逻辑可能并没有发生变化,但是要实现业务价值,不是看单个服务的能力,而是要通过各业务服务之间的协作来实现完整的端到端业务流程。
通常情况下,业务流程会预先定义好,即在设计阶段会根据业务流程提前确定好各服务之间的协作关系,在运行阶段通过在领域层或应用层提前预置好服务的依赖关系和调用顺序,服务部署后,按照预先定义的业务流程运行即可。这种将服务之间关系预置的方式,在业务流程和场景确定的情况下,实现简单,成本低。然而,实际的业务流程和场景往往存在很多的不确定性,一般都会根据用户需要和故障处理的不断变化。那么,提前预置业务流程的方式就无法灵活快速应对业务流程和场景的变化,从而带来了额外的成本,包括重新开发测试,现场重新部署验证等;随着故障处理场景的变化的不断复杂化,会变得难以维护。
同时专业领域的业务流程和场景的不断变化,业务处理能力实际下沉到各厂家/专业网领域,为了使得跨域/跨厂家的业务流程更灵活的组合和协作,打破一般业务流的固定流程组合方式,本发明实施例通过编排各故障事件对应的业务服务节点,即根据故障事件预先定义各厂家/专业网的业务服务之间的协作关系,保证了各厂家/专业网的业务服务的分离解耦,业务服务只实现自己原子处理逻辑,服务之间的协作关系通过专门的服务协作关系程序来维护,即本发明实施例中根据各业务服务节点提供的业务服务编排的各故障事件对应的业务服务节点。同时本发明实施例的故障处理方法提供了一种低代码的能力开放方式,可以直接让用户方便快捷的进行应用场景的组合与叠加,从而达到高效的智能运维/智慧运营的目标。
本发明的一个实施例涉及一种故障处理方法,应用于事件驱动架构(EventDriven Architecture,EDA),其中,EDA的工作机制的示意图如图1所示,包括:业务编排/执行引擎,以实现本发明实施例的故障处理方法。
在一个例子中,编排/执行引擎的整体架构图如图2所示,包括:应用程序编程接口(Application Programming Interface,API),服务模块,存储模块。
具体而言,API包括:管理任务队列,元数据,以及执行任务队列。
其中,管理任务队列用于启动并管理任务;元数据,例如,性能数据,告警数据等,用于定义任务,即业务流程;执行任务队列,用于获取任务并执行。
服务模块,包括:业务流服务,任务服务,状态机服务,以及队列服务。
具体地,当业务流事件发生时,例如,任务失败或任务完成,状态机服务匹配任务与当前的任务状态,根据识别到的任务状态调度任务,或者更新任务状态。
其中,状态机服务与队列服务还用于管理和调度任务。
存储模块,用于存储持久化数据。
本发明实施例的应用场景包括但不限于以下场景:
专业通信领域下的故障定位和全流程的业务处理,例如,核心网侧,无线侧;自智通讯网络跨专业领域下的同厂家下的故障定位和全流程得端到端业务处理,例如,无线侧-核心网侧-承载侧;自智通讯网络跨专业领域下的异厂家下的故障定位和全流程得端到端业务处理,例如,无线侧-核心网侧-承载侧;服务于企业用户(To Business,ToB)场景的业务处理能力的低代码开放。
下面对本实施例的故障处理方法的实现细节进行具体的说明,以下内容仅为方便理解提供的实现细节,并非实施本方案的必须。本实施例的故障处理方法的实现流程如图3所示,具体包括:
步骤301,获取各业务服务节点提供的业务服务。
具体而言,接收各业务服务节点的注册信息,注册信息包括业务服务的名称,或业务服务的唯一标识。其中,业务服务包括以下之一或任意组合:通讯领域的规划、建设、运维和优化过程中的组件、数据、业务、算法以及脚本。通过获取各业务服务节点提供的业务服务的注册信息,以使得业务服务能够在编排/执行引擎中被编排。
在一个例子中,注册信息还包括:服务启动接口、事件监听接口和发送事件定义接口,则在获取各业务服务节点提供的业务服务之后,会统一封装服务启动接口、事件监听接口和发送事件定义接口。在注册信息中增加服务启动接口、事件监听接口和发送事件定义接口,以使编排/执行引擎在封装三个接口供业务服务节点调用,因此,业务服务节点只需关注自身的业务逻辑实现。
需要说明的是,注册信息需要符合编排引擎的规范。另外,服务启动接口、事件监听接口和发送事件定义接口参照服务插件的做法,由公共插件安装包支持解析和发送,各业务服务节点只需要按照文件和目录规范定义打包即可。
在一个例子中,步骤301还可以通过如图4的方式实现,具体包括:
S401,业务服务节点向消息中间件发起注册请求。
S402,消息中间件监听注册请求,并将注册信息更新存储至服务透视,供服务透视呈现注册信息。
S403,将注册请求更新缓存至编排/执行引擎,供编排/执行引擎编排各故障事件对应的业务服务节点。
步骤302,根据各业务服务节点提供的业务服务编排各故障事件对应的业务服务节点;其中,故障事件与多个业务服务节点相对应。
具体而言,在人机交互界面(User Interface,UI)上展示各业务服务节点提供的业务服务,接收用户针对各故障事件选择的各业务服务的操作信息,并根据用户选择的各业务服务的操作信息,生成各故障事件的处理业务流,其中,所述处理业务流包括用户选择的业务服务所在的业务服务节点,以及各业务服务节点的调度顺序。调度顺序包括:并发调度和/或上下游调度。通过获取各故障事件的处理业务流,以开始业务流程。
在一个例子中,业务编排/执行引擎根据用户选择的各业务服务的操作信息,生成的各故障事件的处理业务流的示意图如图5所示,包括:业务服务节点A,业务服务节点B,业务服务节点C,业务服务An,业务服务Bn,以及业务服务Cn。
在一个例子中,步骤302还可以通过如图6的方式实现,具体包括:
S601,从UI上获取用户针对各故障事件选择的各业务服务的操作信息。
S602,将操作信息发送给编排转换,以进行格式转换。
S603,编排转换将经过格式转换后的操作信息发送给服务编排,以生成处理业务流。
S604,将处理业务流通过编排转换返回至UI。
其中,UI界面的主要操作及展示逻辑如表1所示,包括:
Figure BDA0003424814640000041
Figure BDA0003424814640000051
步骤303,在检测到故障事件的情况下,调度与检测到的故障事件对应的多个业务服务节点分别对故障事件进行检测。
具体而言,通过统一封装的服务启动接口,启动检测到的故障事件对应的多个业务服务节点,通过统一封装的发送事件定义接口,将检测到的故障事件通知给对应的多个业务服务节点,触发多个业务服务节点分别对故障事件进行检测。
在一个例子中,根据检测到的故障事件的处理业务流,调度处理业务流的多个业务服务节点分别对故障事件进行检测。具体为:当检测到的故障事件的处理业务流包括并发调度的业务服务节点,并发调度各业务服务节点分别对故障事件进行检测;当检测到的故障事件的处理业务流包括上下游调度的的业务服务节点,优先调度上游的业务服务节点,并根据上游的业务服务节点的执行结果决策结束处理业务流或调度下游的业务服务节点。根据调度顺序,调度处理业务流的多个业务服务节点分别对故障事件进行检测,以更精准的进行故障定位。
步骤304,获取多个业务服务节点分别对故障事件进行检测的结果。
具体而言,通过监听与多个业务服务节点分别对应的信道,获取多个业务服务节点分别对故障事件进行检测的结果。通过建通信道来获取多个业务服务节点分别对故障事件进行检测的结果,以确认业务服务的执行状态,进而决定是否继续调度下游服务,或者结束当前业务流。
在本实施例中,步骤303和步骤304还可以通过如图7所示的方式实现,具体包括:
S701,编排/执行引擎启动业务流,具体为:下发业务服务的操作信息,例如,业务服务A,业务服务B。
S702,消息中间件监听业务流并启动业务流。具体为:监听业务服务A,并在业务服务节点A启动业务服务A,然后监听业务服务B,并在业务服务节点B启动业务服务B。
S703,业务服务节点A和业务服务节点B分别向消息中间件返回业务服务A和业务服务B的执行结果。
S704,编排/执行引擎下发业务服务C的操作信息。
S705,消息中间件监听业务服务C,并在业务服务节点C启动业务服务C。
S706,业务服务节点C向消息中间件返回业务服务C的执行结果。
S707,消息中间件向编排/执行引擎返回业务流的执行结果。
步骤305,根据多个业务服务节点分别对故障事件进行检测的结果,确定故障原因。
具体而言,将故障事件的检测结果发送给提供组合服务节点,触发组合服务节点基于故障事件的检测结果进行综合评估,获取组合服务节点对故障事件的综合评估结果,得到故障原因。
其中,组合服务节点具体依据专家库规则,或者机器学习的分析结果对故障事件的检测结果进行综合评估,以得到故障事件的综合评估结果,确定故障原因。
本领域技术人员可以理解的是,在本实施例中,业务服务由业务服务节点实现,通过API进行通信。具体可以通过以下两种方式实现:一种是由流程引擎调用的表述性状态传递(Representational State Transfer,REST)接口,另一种是通过定期检查挂起的业务服务的状态。
其中,API通过超文本传输协议(Hypertext Transfer Protocol,HTTP)提供,使用HTTP可以与不同客户端集成,或者添加其他协议。
在一个例子中,本实施例基于远程过程调用(Remote Procedure Call,RPC)的通信模型来实现,其中业务服务在不同的服务器上运行,并通过HTTP与服务器进行通信,采用轮询模型管理业务服务队列。其中,RPC模型的结构如图8所示,包括:业务服务节点1,业务服务节点2,业务服务节点3,APIHTTP,业务服务队列,管理和执行服务模块,编排/执行引擎,数据库以及索引。
在一个例子中,本实施例的组件全景图如图9所示,包括:流程、任务、历史、监控、客户端、通信以及后台。
其中,流程包括流程引擎,流程引擎用领域专用语言(Domain SpecifiedLanguage,DSL)来编写流程定义文件,流程定义文件是一种数据交换格式的文件,支持手写定义,同时也支持通过界面拖拽生成。
任务,包括任务创建、任务删除、任务撤销、任务列表,以及并行计算任务等功能。
历史,包括历史任务,历史活动和查询流程等功能。
监控,包括监控引擎和任务调度功能,其中,监控引擎用于在业务流的流程冗长时,对每个业务服务节点的业务服务运行情况状态做出相应决策;任务调度用于进行分布式定时调度。
客户端及通信,包括业务服务队列,业务服务请求,业务服务节点以及跨语言功能。其中,业务服务实现过程中支持跨语言,例如,JAVA、Python、go等语言。
后台,包括后台管理功能。
本申请实施例在自智通讯网络的端到端业务处理/故障定位的实际应用如图10所示,包括:资产服务,领域业务服务,设计与和执行域。
其中,资产服务包括:布局组件集,场景模板集,行业模型集,数据集,业务服务,以及脚本/软件开发工具包/API。
领域业务服务包括:规划应用服务,建设应用服务,运维应用服务,以及优化应用服务。
设计域包括:界面编排,脚本功能增强,业务逻辑编排,数据编排,商业智能(Business Intelligence,BI)分析,AI算法编排,以及数据接入、治理。
执行域包括:执行引擎,编排引擎以及统一数据平台。
本实施例中,通过获取各业务服务节点提供的业务服务,并根据各业务服务节点提供的业务服务编排各故障事件对应的业务服务节点,其中,故障事件与多个业务服务节点相对应,在检测到故障事件的情况下,调度与检测到的故障事件对应的多个业务服务节点,对故障事件进行检测,并获取多个业务服务节点分别对故障事件的检测结果,然后根据多个业务服务节点分别对故障事件的检测结果,确定故障原因。通过编排各故障事件对应的业务服务节点,即根据故障事件预先定义各厂家/专业网的业务服务之间的协作关系,保证了各厂家/专业网的业务服务的解耦和独立设计,使得业务流程不易中断和重组,在实际的自智网络故障处理场景中可以依据实际需要的业务服务进行灵活自由的组合,从而进行未知故障事件的定位,并高效地处理故障事件。
需要说明的是,本实施方式中的上述各示例均为方便理解进行的举例说明,并不对本发明的技术方案构成限定。
上面各种方法的步骤划分,只是为了描述清楚,实现时可以合并为一个步骤或者对某些步骤进行拆分,分解为多个步骤,只要包括相同的逻辑关系,都在本专利的保护范围内;对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计,但不改变其算法和流程的核心设计都在该专利的保护范围内。
本发明的另一个实施例涉及一种故障处理装置,下面对本实施例的故障处理装置的细节进行具体的说明,以下内容仅为方便理解提供的实现细节,并非实施本例的必须,图11是本实施例所述的故障处理装置的示意图,包括:第一获取模块1101、编排模块1102、调度模块1103、第二获取模块1104以及确定模块1105。
具体而言,第一获取模块1101,用于获取各业务服务节点提供的业务服务。
在一个例子中,第一获取模块1101,还用于接收各业务服务节点的注册信息;其中,注册信息包括所述业务服务的名称。
在一个例子中,第一获取模块1101,还用于在注册信息还包括:服务启动接口、事件监听接口和发送事件定义接口的情况下,在获取各业务服务节点提供的业务服务之后,统一封装服务启动接口、事件监听接口和发送事件定义接口。
编排模块1102,用于根据各业务服务节点提供的业务服务编排各故障事件对应的业务服务节点;其中,故障事件与多个业务服务节点相对应。
在一个例子中,编排模块1102,还用于在人机交互界面上展示各业务服务节点提供的业务服务;接收用户针对各故障事件选择的各业务服务的操作信息;根据用户选择的各业务服务的操作信息,生成各故障事件的处理业务流,其中,处理业务流包括用户选择的业务服务所在的业务服务节点,以及各业务服务节点的调度顺序。
调度模块1103,用于在检测到故障事件的情况下,调度与检测到的故障事件对应的多个业务服务节点分别对故障事件进行检测。
在一个例子中,调度模块1103,还用于通过统一封装的所述服务启动接口,启动检测到的故障事件对应的多个业务服务节点;通过统一封装的发送事件定义接口,将检测到的故障事件通知给对应的多个业务服务节点,触发多个业务服务节点分别对故障事件进行检测。
在一个例子中,调度模块1103,还用于根据检测到的故障事件的处理业务流,调度处理业务流的多个业务服务节点分别对故障事件进行检测。
在一个例子中,调度模块1103,还用于在度顺序包括:并发调度和/或上下游调度的情况下,当检测到的故障事件的处理业务流包括并发调度的业务服务节点,并发调度各业务服务节点分别对故障事件进行检测;当检测到的故障事件的处理业务流包括上下游调度的的业务服务节点,优先调度上游的业务服务节点,并根据上游的业务服务节点的执行结果决策结束处理业务流或调度下游的业务服务节点。
第二获取模块1104,用于获取多个业务服务节点分别对故障事件的检测结果。
在一个例子中,第二获取模块1104,还用于通过监听与多个业务服务节点分别对应的信道,获取多个业务服务节点分别对故障事件的检测结果。
在一个例子中,第二获取模块1104,还用于通过统一封装的所述事件监听接口,获取所述多个业务服务节点分别对所述故障事件的检测结果。
确定模块1105,用于根据多个业务服务节点分别对故障事件的检测结果,确定故障原因。
在一个例子中,确定模块1105,还用于将故障事件的检测结果发送给提供组合服务节点,触发组合服务节点基于故障事件的检测结果进行综合评估;获取组合服务节点对故障事件的综合评估结果,得到故障原因。
不难发现,本实施例为与上述方法实施例对应的装置实施例,本实施例可以与上述方法实施例互相配合实施。上述实施例中提到的相关技术细节和技术效果在本实施例中依然有效,为了减少重复,这里不再赘述。相应地,本实施例中提到的相关技术细节也可应用在上述实施例中。
值得一提的是,本实施例中所涉及到的各模块均为逻辑模块,在实际应用中,一个逻辑单元可以是一个物理单元,也可以是一个物理单元的一部分,还可以以多个物理单元的组合实现。此外,为了突出本发明的创新部分,本实施例中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入,但这并不表明本实施例中不存在其它的单元。
本发明另一个实施例涉及一种电子设备,如图12所示,包括:至少一个处理器1201;以及,与所述至少一个处理器1201通信连接的存储器1202;其中,所述存储器1202存储有可被所述至少一个处理器1201执行的指令,所述指令被所述至少一个处理器1201执行,以使所述至少一个处理器1201能够执行上述各实施例中的故障处理方法。
其中,存储器和处理器采用总线方式连接,总线可以包括任意数量的互联的总线和桥,总线将一个或多个处理器和存储器的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件,也可以是多个元件,比如多个接收器和发送器,提供用于在传输介质上与各种其他装置通信的单元。经处理器处理的数据通过天线在无线介质上进行传输,进一步,天线还接收数据并将数据传送给处理器。
处理器负责管理总线和通常的处理,还可以提供各种功能,包括定时,外围接口,电压调节、电源管理以及其他控制功能。而存储器可以被用于存储处理器在执行操作时所使用的数据。
本发明另一个实施例涉及一种计算机可读存储介质,存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。
即,本领域技术人员可以理解,实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,该程序存储在一个存储介质中,包括若干指令用以使得一个设备(可以是单片机,芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-OnlyMemory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域的普通技术人员可以理解,上述各实施方式是实现本发明的具体实施例,而在实际应用中,可以在形式上和细节上对其作各种改变,而不偏离本发明的精神和范围。

Claims (11)

1.一种故障处理方法,其特征在于,包括:
获取各业务服务节点提供的业务服务;
根据所述各业务服务节点提供的业务服务编排各故障事件对应的业务服务节点;其中,所述故障事件与多个业务服务节点相对应;
在检测到故障事件的情况下,调度与所述检测到的故障事件对应的所述多个业务服务节点分别对所述故障事件进行检测;
获取所述多个业务服务节点分别对所述故障事件进行检测的结果;
根据所述多个业务服务节点分别对所述故障事件进行检测的结果,确定故障原因。
2.根据权利要求1所述的故障处理方法,其特征在于,所述获取所述多个业务服务节点分别对所述故障事件的检测结果,包括:
通过监听与所述多个业务服务节点分别对应的信道,获取所述多个业务服务节点分别对所述故障事件的检测结果。
3.根据权利要求1所述的故障处理方法,其特征在于,所述获取各业务服务节点提供的业务服务,包括:
接收各业务服务节点的注册信息;
其中,所述注册信息包括所述业务服务的名称或业务服务的唯一标识。
4.根据权利要求3所述的故障处理方法,其特征在于,所述注册信息还包括:服务启动接口、事件监听接口和发送事件定义接口;
所述方法还包括:
在所述获取各业务服务节点提供的业务服务之后,统一封装所述服务启动接口、所述事件监听接口和所述发送事件定义接口;
所述调度与所述检测到的故障事件对应的所述多个业务服务节点分别对所述故障事件进行检测,包括:
通过统一封装的所述服务启动接口,启动所述检测到的故障事件对应的所述多个业务服务节点;
通过统一封装的所述发送事件定义接口,将所述检测到的故障事件通知给对应的所述多个业务服务节点,触发所述多个业务服务节点分别对所述故障事件进行检测;
所述获取所述多个业务服务节点分别对所述故障事件的检测结果,包括:
通过统一封装的所述事件监听接口,获取所述多个业务服务节点分别对所述故障事件的检测结果。
5.根据权利要求1至4中任一项所述的故障处理方法,其特征在于,所述根据所述各业务服务节点提供的业务服务编排各故障事件对应的业务服务节点,包括:
在人机交互界面上展示所述各业务服务节点提供的业务服务;
接收用户针对各故障事件选择的各业务服务的操作信息;
根据所述用户选择的各业务服务的操作信息,生成各故障事件的处理业务流,其中,所述处理业务流包括所述用户选择的所述业务服务所在的业务服务节点,以及各所述业务服务节点的调度顺序。
6.根据权利要求5所述的故障处理方法,其特征在于,所述调度与所述检测到的故障事件对应的所述多个业务服务节点分别对所述故障事件进行检测,包括:
根据所述检测到的故障事件的处理业务流,调度所述处理业务流的多个业务服务节点分别对所述故障事件进行检测。
7.根据权利要求6所述的故障处理方法,其特征在于,所述调度顺序包括:并发调度或上下游调度;
所述根据所述检测到的故障事件的处理业务流,调度所述处理业务流的多个业务服务节点分别对所述故障事件进行检测,包括:
当所述检测到的故障事件的处理业务流包括并发调度的业务服务节点,并发调度各业务服务节点分别对所述故障事件进行检测;
当所述检测到的故障事件的处理业务流包括上下游调度的的业务服务节点,优先调度上游的业务服务节点,并根据所述上游的业务服务节点的执行结果决策结束所述处理业务流或调度下游的业务服务节点。
8.根据权利要求1至4中任一项所述的故障处理方法,其特征在于,所述根据所述多个业务服务节点分别对所述故障事件的检测结果,确定故障原因,包括:
将所述故障事件的检测结果发送给组合服务节点,触发所述组合服务节点基于所述故障事件的检测结果进行综合评估;
获取所述组合服务节点对所述故障事件的综合评估结果,得到所述故障原因。
9.一种故障处理装置,其特征在于,包括:
第一获取模块,用于获取各业务服务节点提供的业务服务;
编排模块,用于根据所述各业务服务节点提供的业务服务编排各故障事件对应的业务服务节点;其中,所述故障事件与多个业务服务节点相对应;
调度模块,用于在检测到故障事件的情况下,调度与所述检测到的故障事件对应的所述多个业务服务节点分别对所述故障事件进行检测;
第二获取模块,用于获取所述多个业务服务节点分别对所述故障事件的检测结果;
确定模块,用于根据所述多个业务服务节点分别对所述故障事件的检测结果,确定故障原因。
10.一种电子设备,其特征在于,包括:
至少一个处理器;以及,
与所述至少一个处理器通信连接的存储器;其中,
所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行如权利要求1至8中任一项所述的故障处理方法。
11.一种计算机可读存储介质,存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1至8中任一项所述的故障处理方法。
CN202111574524.8A 2021-12-21 2021-12-21 一种故障处理方法、装置、电子设备及存储介质 Pending CN116361081A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202111574524.8A CN116361081A (zh) 2021-12-21 2021-12-21 一种故障处理方法、装置、电子设备及存储介质
PCT/CN2022/132370 WO2023116276A1 (zh) 2021-12-21 2022-11-16 故障处理方法、装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111574524.8A CN116361081A (zh) 2021-12-21 2021-12-21 一种故障处理方法、装置、电子设备及存储介质

Publications (1)

Publication Number Publication Date
CN116361081A true CN116361081A (zh) 2023-06-30

Family

ID=86901257

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111574524.8A Pending CN116361081A (zh) 2021-12-21 2021-12-21 一种故障处理方法、装置、电子设备及存储介质

Country Status (2)

Country Link
CN (1) CN116361081A (zh)
WO (1) WO2023116276A1 (zh)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108306748B (zh) * 2017-01-12 2021-03-30 阿里巴巴集团控股有限公司 网络故障定位方法、装置及交互装置
CN108833184B (zh) * 2018-06-29 2020-10-27 腾讯科技(深圳)有限公司 服务故障定位方法、装置、计算机设备及存储介质
US10784955B2 (en) * 2018-11-13 2020-09-22 Infinera Corporation Method and apparatus for rapid recovery of optical power after transient events in C+L band optical networks
US12034600B2 (en) * 2019-06-19 2024-07-09 Hewlett Packard Enterprise Development Lp Method for federating a cluster from a plurality of computing nodes from different fault domains
CN113435846A (zh) * 2021-06-30 2021-09-24 深圳平安智汇企业信息管理有限公司 业务流程编排方法、装置、计算机设备及存储介质

Also Published As

Publication number Publication date
WO2023116276A1 (zh) 2023-06-29

Similar Documents

Publication Publication Date Title
US20100064184A1 (en) Web Service Management
CN101009004A (zh) 告警装置及告警方法
CN111367643A (zh) 一种算法调度系统、方法及装置
CN102497453A (zh) 远端程序的调用装置和调用方法
CN101834750A (zh) 一种通用业务监控方法
JP4452211B2 (ja) データ不整合検出装置および検出方法
CN109558239A (zh) 一种任务调度方法、装置、系统、计算机设备和存储介质
CN114020368A (zh) 基于状态机的信息处理方法、装置和存储介质
CN116661978B (zh) 一种分布式的流程处理方法、装置及分布式业务流程引擎
CN116881040A (zh) 一种业务操作处理方法、装置、电子装置和存储介质
US9323509B2 (en) Method and system for automated process distribution
CN115333942B (zh) 事件重试方法及装置、存储介质及电子设备
CN116361081A (zh) 一种故障处理方法、装置、电子设备及存储介质
CN105335145A (zh) 操作结果处理方法、装置及系统
CN116193384A (zh) 容灾倒换方法、系统、电子设备和存储介质
CN114564249A (zh) 推荐调度引擎、推荐调度方法及计算机可读存储介质
JP2001265603A (ja) 自動振分ソフトウエア配布システム及びその方法
CN112561593A (zh) 积分发放控制方法及其装置、设备、介质
CN112862500A (zh) 用户权益处理机动态装配方法及其装置、设备与介质
JP2004523809A (ja) 製造施設サービスリクエスタをサービスプロバイダと関連付けるためのディスパッチング構成要素
CN116109112B (zh) 基于聚合接口的业务数据处理方法、装置、介质和设备
CN104298750B (zh) 用于实时系统通信的更新处理方法及装置
CN112016115B (zh) 基于区块链的事件订阅系统
CN115378792B (zh) 告警处理方法、装置及存储介质
CN116244099B (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