一种故障根因确定方法、装置及电子设备与流程

1.本发明涉及云平台故障定位技术领域，特别是涉及一种故障根因确定方法、装置及电子设备。


背景技术：

2.随着云技术的发展，云平台的应用场景也越来越广泛，越来越多的个人或企业愿意利用云平台来部署自身的业务。在云平台的使用过程中，稳定性是影响云平台使用体验的重要因素，因此，在云平台出现云平台故障时，如何快速处理云平台故障就显得尤为重要。
3.如何快速地确定云平台故障的故障根因是提高云平台故障处理效率的关键因素，然而由于云平台的业务实现多依赖于微服务，使得云平台内不同应用服务之间拓扑关系复杂，且云平台多采用分层架构，即应用服务的实现依赖于多个架构层的架构单元，如中间件层中的组件、操作系统层的主机或容器、基础资源层中的服务器等，导致出现云平台故障时，往往是多个应用服务以及不同架构层同时出现故障，从而很难快速地确定出云平台故障的故障根因。


技术实现要素：

4.本发明实施例的目的在于提供一种故障根因确定方法、装置及电子设备，以快速地确定故障根因。具体技术方案如下：
5.第一方面，本发明实施例提供一种故障根因确定方法，所述方法包括：
6.当监听到云平台出现云平台故障时，从至少一故障服务中确定底层故障服务；其中，所述故障服务为出现故障的应用服务，所述底层故障服务为处于所属调用链中最底层的故障服务；
7.从所述云平台的各架构层中，确定目标架构层；其中，所述目标架构层为：所述各架构层中，层位置不低于故障架构层的架构层，所述故障架构层为：在所述底层故障服务出现故障时的窗口期内，出现故障的各架构层中，层位置最低的架构层；
8.从所述目标架构层包含的层单元中，确定用于实现所述底层故障服务的层单元，作为目标层单元；
9.基于所述目标层单元的单元信息，确定所述云平台故障的故障根因。
10.可选的，所述从至少一故障服务中确定底层故障服务，包括：
11.基于所述云平台各应用服务之间的拓扑关系，确定故障调用链；其中，所述故障调用链为包含至少一故障服务的调用链；
12.从所述故障调用链包含的至少一故障服务中，确定在所述故障调用链中位置最低的故障服务，作为底层故障服务。
13.可选的，所述基于所述云平台各应用服务之间的拓扑关系，确定故障调用链，包括：
14.基于所述云平台各应用服务之间的拓扑关系，确定每一故障服务的上游应用服务和下游应用服务；
15.基于各故障服务的上游应用服务和下游应用服务，确定每一故障服务所处的调用链，作为故障调用链。
16.可选的，在所述当监听到云平台出现云平台故障时，从至少一故障服务中确定底层故障服务之后，且在所述从所述云平台的各架构层中，确定目标架构层之前，所述方法还包括：
17.确定所述底层故障服务发生故障时的窗口期内，针对所述底层故障服务所在的调用链内各应用服务的事件操作；其中，所述事件操作包括发布服务操作、变更服务操作以及配置服务操作中的至少一种；
18.针对所述事件操作执行回滚操作；
19.在所述回滚操作结束之后，确定所述云平台故障是否已消除；
20.若未消除，则执行所述从所述云平台的各架构层中，确定目标架构层的步骤。
21.可选的，所述从所述云平台的各架构层中，确定目标架构层，包括：
22.确定所述云平台的各架构层中，在所述底层故障服务发生故障时的窗口期内，出现故障且层位置最低的架构层，作为故障架构层；
23.将所述各架构层中，层位置不低于所述故障架构层的架构层，作为目标架构层。
24.可选的，所述确定所述云平台的各架构层中，在所述底层故障服务发生故障时的窗口期内，出现故障且层位置最低的架构层，作为故障架构层，包括：
25.确定所述云平台的各架构层中，在所述底层故障服务发生故障时的窗口期内，出现故障的架构层，作为预选架构层；
26.在所确定的预选架构层中，确定层位置最低的架构层，作为故障架构层。
27.可选的，所述确定所述云平台的各架构层中，在所述底层故障服务发生故障时的窗口期内，出现故障的架构层，作为预选架构层，包括：
28.确定所述底层故障服务发生故障时的窗口期对应时间段，作为故障时间段；
29.在所述云平台的各架构层中，确定在所述故障时间段内出现故障的架构层，作为预选架构层。
30.可选的，所述基于所述目标层单元的单元信息，确定所述云平台故障的故障根因，包括：
31.确定所述目标层单元的单元信息中，处于异常状态的单元信息，作为异常信息；
32.基于所述异常信息，确定所述云平台故障的故障根因。
33.可选的，所述单元信息包括：指标信息和部署信息；所述指标信息为描述层单元各项指标参数的信息，所述部署信息为描述层单元部署位置的信息。
34.可选的，在所述基于所述目标层单元的单元信息，确定所述云平台故障的故障根因之后，所述方法还包括：
35.生成展示所确定故障根因的可视化报告。
36.可选的，所述可视化报告还用于展示各故障调用链的拓扑图、所述云平台的分层架构图以及信息展示区域中的至少一种；
37.其中，所述故障调用链为包含至少一故障服务的调用链，每一故障调用链的拓扑
图突出展示故障服务，所述分层架构图像突出展示在所述底层故障服务出现故障时的窗口期内，出现故障的各架构层，所述信息展示区域用于展示所述目标层单元的单元信息。
38.第二方面，本发明实施例提供一种故障根因确定装置，所述装置包括：
39.服务确定模块，用于当监听到云平台出现云平台故障时，从至少一故障服务中确定底层故障服务；其中，所述故障服务为出现故障的应用服务，所述底层故障服务为处于所属调用链中最底层的故障服务；
40.架构层确定模块，用于从所述云平台的各架构层中，确定目标架构层；其中，所述目标架构层为：所述各架构层中，层位置不低于故障架构层的架构层，所述故障架构层为：在所述底层故障服务出现故障时的窗口期内，出现故障的各架构层中，层位置最低的架构层；
41.单元确定模块，用于从所述目标架构层包含的层单元中，确定用于实现所述底层故障服务的层单元，作为目标层单元；
42.根因确定模块，用于基于所述目标层单元的单元信息，确定所述云平台故障的故障根因。
43.第三方面，本发明实施例提供一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；
44.存储器，用于存放计算机程序；
45.处理器，用于执行存储器上所存放的程序时，实现第一方面任一所述的方法步骤。
46.第四方面，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现第一方面任一所述的方法步骤。
47.本发明实施例有益效果：
48.本发明实施例提供的故障根因确定方法、装置及电子设备，可以当监听到云平台出现云平台故障时，从至少一故障服务中确定底层故障服务，并从云平台的各架构层中，确定目标架构层，以及从目标架构层包含的层单元中，确定用于实现底层故障服务的层单元，作为目标层单元，并基于目标层单元的单元信息，确定云平台故障的故障根因，由于对于云平台而言，当发生云平台故障时，越底层的应用服务和越底层的架构层越可能是故障根因所在的位置，而本方案在确定底层故障服务之后，进一步的确定层位置不低于故障架构层的目标架构层，进而从目标层单元中确定实现底层故障服务的目标层单元，可以快速地定位出故障根因所在的位置，进而基于目标层单元的单元信息，确定云平台故障的故障根因，可见，通过本方案，可以快速地确定出故障根因。
附图说明
49.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的实施例。
50.图1为本发明实施例所提供的一种调用链的示意图；
51.图2为本发明实施例所提供的一种云平台的分层架构的示意图；
52.图3为本发明实施例所提供的故障根因确定方法的流程图；
53.图4为本发明实施例所提供的一种调用链的另一示意图；
54.图5为本发明实施例所提供的一种云平台的分层架构的另一示意图；
55.图6为本发明实施例所提供的一种云平台的分层架构的另一示意图；
56.图7为本发明实施例所提供的故障根因确定方法的另一流程图；
57.图8为本发明实施例所提供的一种事件操作查询的示意图；
58.图9为本发明实施例所提供的故障根因确定方法的另一流程图；
59.图10为本发明实施例所提供的一种可视化报告的示意图；
60.图11为本发明实施例所提供的故障根因确定装置的结构示意图；
61.图12为本发明实施例所提供的电子设备的结构示意图。。
具体实施方式
62.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员基于本技术所获得的所有其他实施例，都属于本发明保护的范围。
63.云平台的业务实现依赖于微服务，简单而言，业务在云平台中以业务流的形式存在，每一业务流包含多个应用服务，每一业务流上的多个应用服务组成一调用链，同一调用链上的多个应用服务共同作用实现业务功能。
64.示例性的，如图1所示，本发明实施例提供一种调用链示意图，包含应用服务a、应用服务b、应用服务c以及应用服务d，应用服务a应用接收用户端的业务请求，且在接收到业务请求之后，进行相应的业务处理，并将处理结果发送至应用服务b和应用服务c，应用服务b和应用服务c继续进行处理，并将处理结果共同发送给应用服务d，应用服务d根据应用服务b和应用服务c的处理结果，继续进行处理，从而实现业务请求所请求实现的业务功能。
65.同时，云平台多采用分层架构，如图2所示，本发明实施例提供一种云平台的分层架构示意图，从上至下依次为应用服务层-系统层-基础资源层，其中，上述应用服务层为云平台中应用服务所处架构层，上述系统层为应用服务所依赖的中间件/数据库、以及操作系统所处的架构层，系统层可以进一步细分为中间件/数据库层和操作系统层；上述基础资源层为基础资源(如网络、交换机)所处的架构层。
66.由于云平台的业务实现多依赖于微服务，使得云平台内不同应用服务之间拓扑关系复杂，且云平台多采用分层架构，导致出现云平台故障时，往往是多个应用服务以及不同架构层同时出现故障，示例性的，仍以前述示例为例进行说明，当云平台出现云平台故障时，可能应用服务层的应用服务a、应用服务b以及系统层均出现了错误，导致故障点位较多，从而很难快速地确定出云平台故障的故障根因。
67.为了快速地确定出故障根因，本发明实施例提供了故障根因确定方法、装置及电子设备。
68.需要说明的，在具体应用中，本发明实施例可以应用于各类电子设备，例如，个人电脑、服务器、手机以及其他具有数据处理能力的设备。并且，本发明实施例提供的故障根因确定方法可以通过软件、硬件或软硬件结合的方式实现。
69.一种实施例中，本发明实施例可以应用于云平台，此时云平台可以实时监听自身的运行状态，当监听到出现云平台故障时，可以执行本发明实施例所提供的故障根因确定方法，以确定云平台故障的故障根因。
70.另一种实施例中，本发明实施例还可以应用于独立于云平台的电子设备，此时，该电子设备可以与云平台实时通信，以实时监听云平台的运行状态，若监听到云平台出现云平台故障后，则执行本发明实施例所提供的故障根因确定方法，以确定云平台故障的故障根因。
71.其中，本发明实施例所提供的故障根因确定方法，可以包括：
72.当监听到云平台出现云平台故障时，从至少一故障服务中确定底层故障服务；其中，故障服务为出现故障的应用服务，底层故障服务为处于所属调用链中最底层的故障服务；
73.从云平台的各架构层中，确定目标架构层；其中，目标架构层为：各架构层中，层位置不低于故障架构层的架构层，故障架构层为：在底层故障服务出现故障时的窗口期内，出现故障的各架构层中，层位置最低的架构层；
74.从目标架构层包含的层单元中，确定用于实现底层故障服务的层单元，作为目标层单元；
75.基于目标层单元的单元信息，确定云平台故障的故障根因。
76.本发明实施例上述方案中，可以在确定底层故障服务之后，进一步的确定层位置不低于故障架构层的目标架构层，进而从目标层单元中确定实现底层故障服务的目标层单元，可以快速地定位出故障根因所在的位置，进而基于目标层单元的单元信息，确定云平台故障的故障根因，可见，通过本方案，可以快速地确定出故障根因。
77.下面将结合说明书附图，对本发明实施例所提供的故障根因确定方法进行详尽的阐述。
78.如图3所示，本发明实施例提供一种故障根因确定方法，包括步骤s301-s304，其中：
79.s301，当监听到云平台出现云平台故障时，从至少一故障服务中确定底层故障服务；其中，故障服务为出现故障的应用服务，底层故障服务为处于所属调用链中最底层的故障服务；
80.其中，本发明实施例执行主体可以实时监听云平台是否出现云平台故障，若监听到云平台出现云平台故障，则可以从至少一故障服务中确定底层故障服务。
81.如前述内容可知，当云平台出现故障时，往往多个应用服务或架构层同时出现故障，此时，可以从多个故障服务中确定底层故障服务。示例性的，如图4所示，本发明实施例所提供的一种调用链示意图，图4中包括两条调用链，其中左侧调用链包括应用服务a、应用服务b、应用服务c以及应用服务d，右侧调用链包括应用服务e、应用服务f以及应用服务g。在云平台出现云平台故障时，有应用服务b、应用服务d以及应用服务f出现故障，则应用服务b、应用服务d以及应用服务f为故障服务，且应用服务d和应用服务f为底层故障服务。
82.在监听到云平台出现云平台故障时，为了从至少一个故障服务中确定出底层故障服务，可以采用多种实现方式，示例性的，至少存在如下几种底层故障确定方式：
83.第一种底层故障服务确定方式中，在仅存在一个故障服务时，可以将该故障服务
直接作为底层故障服务；
84.第二种底层故障服务确定方式中，在存在多个故障服务时，可以将属于同一调用链的故障服务划分为一组，进而从每一组的各故障服务中确定最下游的故障服务，作为底层故障服务。
85.第三种底层故障服务确定方式中，可以基于云平台各应用服务之间的拓扑关系，确定故障调用链；进而从故障调用链包含的至少一故障服务中，确定在故障调用链中位置最低的故障服务，作为底层故障服务。
86.其中，故障调用链为包含至少一故障服务的调用链，可选的，可以基于云平台各应用服务之间的拓扑关系，确定每一故障服务的上游应用服务和下游应用服务，进而基于各故障服务的上游应用服务和下游应用服务，确定每一故障服务所处的调用链，作为故障调用链。示例性的，仍以图4示例中进行说明，应用服务b、应用服务d为故障服务，基于云平台各应用服务之间的拓扑关系可知：应用服务b的上游应用服务为应用服务a，下游应用服务为应用服务d；应用服务a无上游应用服务，下游应用服务包括应用服务b和应用服务c；应用服务c的上游应用服务为应用服务a，下游应用服务为应用服务d；应用服务d的上游应用服务为应用服务b和应用服务c，进而可以得到如图4所示的故障调用链。
87.s302，从云平台的各架构层中，确定目标架构层；其中，目标架构层为：各架构层中，层位置不低于故障架构层的架构层，故障架构层为：在底层故障服务出现故障时的窗口期内出现故障的各架构层中，层位置最低的架构层；
88.其中，不同的云平台可能存在不同的架构层，以图2为例，其包含应用服务层、系统层和基础资源层三个架构层。或者对系统层进一步进行划分，可得到如图5所示的分层架构示意图，从上至下依次包含为应用服务层-中间件/数据库层-操作系统层-基础资源层。上述应用服务层为云平台中各应用服务等层单元所处架构层；上述中间件/数据库层为应用服务所依赖的各种中间件等层单元所处的架构层；上述操作系统层为应用服务所在的主机/容器等层单元所处的架构层；上述基础资源层为应用服务所在的服务器硬件、网络环境等层单元所处的架构层。
89.一般而言，当层位置较低的架构层出现故障时，层位置较高的架构层也会出现故障，因此，一种实现方式中，可以直接将各出现故障的架构层作为目标架构层。或者，一种目标架构层的确定方式中，还可以包括步骤a1-步骤a2：
90.步骤a1，确定云平台的各架构层中，在底层故障服务发生故障时的窗口期内，出现故障且层位置最低的架构层，作为故障架构层；
91.其中，发生故障时的窗口期可以为故障发生时刻前指定时长内的时期，或故障发生时刻，前后指定时长内的时期。示例性的，底层故障服务发生故障时的时刻为9:00，则窗口期可以为8:45-10:15。
92.在底层故障服务发生故障时的窗口期出现故障的架构层，该架构层内的层单元的异常往往是导致底层故障服务发生故障的根因，因此，本发明实施例可以确定云平台的各架构层中，在底层故障服务发生故障时的窗口期内，出现故障且层位置最低的架构层，作为故障架构层。
93.一种故障架构层的确定方式中，可以确定云平台的各架构层中，在底层故障服务发生故障时的窗口期内，出现故障的架构层，作为预选架构层，进而在所确定的预选架构层
中，确定层位置最低的架构层，作为故障架构层。可选的，可以先确定底层故障服务发生故障时的窗口期对应时间段，作为故障时间段，进而在云平台的各架构层中，确定在故障时间段内出现故障的架构层，作为预选架构层。
94.步骤a2，将各架构层中，层位置不低于故障架构层的架构层，作为目标架构层。
95.在确定出底层架构层之后，可以将各架构层中，层位置不低于故障架构层的架构层，作为目标架构层。示例性的，如图6所示，本发明实施例所提供的一种云平台的分层架构示意图，从上至下依次包含为应用服务层-中间件/数据库层-操作系统层-基础资源层。其中，故障架构层为中间件/数据库层，则可以确定应用服务层和中间件/数据库层均为目标架构层。
96.s303，从目标架构层包含的层单元中，确定用于实现底层故障服务的层单元，作为目标层单元；
97.在确定出目标架构层之后，则可以从目标架构层包含的层单元中，确定用于实现底层故障服务的层单元，作为目标层单元。以图5所示架构层为例进行说明，应用服务层包含的层单元为应用服务，中间件/数据库层包含的层单元为各种中间件，操作系统层包含的层单元为主机、容器等，基础资源层包含的层单元为服务器硬件、网络环境等。
98.当应用服务层为目标架构层，则可以将底层故障服务自身作为目标层单元；
99.当中间件/数据库层为目标架构层，则可以将中间件/数据库层中，实现底层故障服务所依赖的中间件作为目标层单元。可选的，可以根据同报警窗口期内中间件/数据库层的报警，和cmdb(configuration management database，配置管理数据库)进行匹配，找到底层故障服务依赖的中间件，作为目标层单元。
100.当操作系统层为目标架构层，则可以将操作系统层中，底层故障服务所部署的主机、容器作为目标层单元；可选的，根据同报警窗口期内操作系统层的报警，与cmdb进行匹配，找到操作系统层中，底层故障服务部署所在的主机/容器，作为目标层单元。
101.当基础资源层为目标架构层，则可以将基础资源层中，实现底层故障服务所部署的服务器硬件、以及所需的网络环境资源作为目标层单元。可选的，根据同报警窗口期内基础资源的报警，与cmdb进行匹配，找到基础资源层中，底层故障服务部署所在的服务器硬件、网络环境资源，作为目标层单元。
102.s304，基于目标层单元的单元信息，确定云平台故障的故障根因。
103.由于目标层单元是实现底层故障服务所依赖的层单元，因此，云平台故障的故障根因可大概率锁定在目标层单元的异常中，基于此，在确定出目标层单元后，可以基于目标层单元的单元信息，确定云平台故障的故障根因。
104.可选的，可以先收集目标层单元的单元信息，进而基于所收集的单元信息，确定云平台故障的故障根因。上述单元信息可以包括：指标信息和部署信息；其中，指标信息为描述层单元各项指标参数的信息，部署信息为描述层单元部署位置的信息。
105.示例性的，当目标层单元为应用服务层中的层单元时，指标信息包括：接口的吞吐、耗时、错误率，full gc频率、线程堆积数等中的至少一种。其中，full gc指一次特殊gc的行为描述，这次gc会回收整个堆的内存，包含老年代，新生代等；部署信息包括：集群、机房、节点等中的至少一种。
106.当目标层单元为中间件/数据库层中的层单元时，指标信息包括：缓存命中率、数
据库慢查、消息队列堆积量等中的至少一种；部署信息包括：集群、机房、节点等中的至少一种。
107.当目标层单元为操作系统层中的层单元时，指标信息包括：cpu使用率、内存使用率、磁盘使用率等中的至少一种；部署信息包括：宿主机、容器等中的至少一种。
108.当目标层单元为基础资源层中的层单元时，指标信息包括：服务器内存坏损、磁盘坏损，共享存储异常等中的至少一种；部署信息包括：交换机异常，网络丢包率等中的至少一种。
109.在获取到目标单元的单元信息后可以确定目标层单元的单元信息中，处于异常状态的单元信息，作为异常信息，进而基于异常信息，确定云平台故障的故障根因。可选的，可以将异常信息对应的异常单元确认为故障根因。
110.本发明实施例上述方案中，可以在确定底层故障服务之后，进一步的确定层位置不低于故障架构层的目标架构层，进而从目标层单元中确定实现底层故障服务的目标层单元，可以快速地定位出故障根因所在的位置，进而基于目标层单元的单元信息，确定云平台故障的故障根因，可见，通过本方案，可以快速地确定出故障根因。
111.如图7所示，本发明实施例提供一种故障根因确定方法，包括步骤s701-s707，其中：
112.s701，当监听到云平台出现云平台故障时，从至少一故障服务中确定底层故障服务；其中，故障服务为出现故障的应用服务，底层故障服务为处于所属调用链中最底层的故障服务；
113.与步骤s301相同或相似，具体实现方式参见步骤s301的相关描述，在此不再赘述。
114.s702，确定底层故障服务发生故障时的窗口期内，针对底层故障服务所在的调用链内各应用服务的事件操作；其中，事件操作包括发布服务操作、变更服务操作以及配置服务操作中的至少一种；
115.其中，发布服务操作由发布系统执行，在发布系统中存在每一次执行发布服务操作的记录，变更服务操作由变更系统执行，在变更系统中存在每一次执行变更服务操作的记录，配置服务操作由配置系统执行，在配置系统中存在每一次执行配置服务操作的记录。故而，本发明实施例可以通过查询发布系统、变更系统以及配置系统的方式，确定底层故障服务发生故障时的窗口期内，针对底层故障服务所在的调用链内各应用服务的事件操作。如图8所示，本发明实施例所提供的一种事件操作查询示意图，包括针对每一应用服务，发布系统中记录有针对该应用服务的所有的发布记录，每一发布记录所发布的应用服务的信息以及发布时间，从而可以基于每一发布记录中的发布时间，确定底层故障服务发生故障时的窗口期内的每一发布记录对应的发布服务操作。变更系统中记录有关于该应用服务的所有变更记录，每一变更记录有所变更的应用服务的信息以及变更时间，从而基于每一变更记录中的变更时间，确定底层故障服务发生故障时的窗口期内的每一变更记录对应的变更服务操作。
116.可以基于多系统关联，查询底层故障服务发生故障时的窗口期内，针对底层故障服务所在的调用链内各应用服务的事件操作。
117.s703，针对事件操作执行回滚操作；
118.当查询到时间操作之后，可以对针对事件操作执行回滚操作。
119.s704，在回滚操作结束之后，确定云平台故障是否已消除，若未消除，则执行步骤s705，否则结束。
120.若云平台故障是由事件操作导致的，则在执行回滚操作后可以快速消除云平台故障，从而可以结束流程，否则说明，若说明云平台故障不是由事件操作所导致的，此时需要进一步的执行故障根因确定流程，即执行步骤s705。
121.s705，从云平台的各架构层中，确定目标架构层；其中，目标架构层为：各架构层中，层位置不低于故障架构层的架构层，故障架构层为：在底层故障服务出现故障时的窗口期内，出现故障的各架构层中，层位置最低的架构层；
122.与步骤s302相同或相似，具体实现方式参见步骤s302的相关描述，在此不再赘述。
123.s706，从目标架构层包含的层单元中，确定用于实现底层故障服务的层单元，作为目标层单元；
124.与步骤s303相同或相似，具体实现方式参见步骤s303的相关描述，在此不再赘述。
125.s707，基于目标层单元的单元信息，确定云平台故障的故障根因。
126.与步骤s304相同或相似，具体实现方式参见步骤s304的相关描述，在此不再赘述。
127.本发明实施例上述方案中，可以在确定底层故障服务之后，进一步的确定层位置不低于故障架构层的目标架构层，进而从目标层单元中确定实现底层故障服务的目标层单元，可以快速地定位出故障根因所在的位置，进而基于目标层单元的单元信息，确定云平台故障的故障根因，可见，通过本方案，可以快速地确定出故障根因。
128.如图9所示，本发明实施例提供一种故障根因确定方法，包括步骤s901-s905，其中：
129.s901，当监听到云平台出现云平台故障时，从至少一故障服务中确定底层故障服务；其中，故障服务为出现故障的应用服务，底层故障服务为处于所属调用链中最底层的故障服务；
130.与步骤s301相同或相似，具体实现方式参见步骤s301的相关描述，在此不再赘述。
131.s902，从云平台的各架构层中，确定目标架构层；其中，目标架构层为：各架构层中，层位置不低于故障架构层的架构层，故障架构层为：在底层故障服务出现故障时的窗口期内，出现故障的各架构层中，层位置最低的架构层；
132.与步骤s302相同或相似，具体实现方式参见步骤s302的相关描述，在此不再赘述。
133.s903，从目标架构层包含的层单元中，确定用于实现底层故障服务的层单元，作为目标层单元；
134.与步骤s303相同或相似，具体实现方式参见步骤s303的相关描述，在此不再赘述。
135.s904，基于目标层单元的单元信息，确定云平台故障的故障根因。
136.与步骤s304相同或相似，具体实现方式参见步骤s304的相关描述，在此不再赘述。
137.s905，生成展示所确定故障根因的可视化报告。
138.在确定出故障根因之后，可以进一步的生成展示所确定故障根因的可视化报告，从而可以更方便的提供给运维人员，以使运维人员更加直观、明了的确定故障根因。
139.进一步的，为了辅助运维人员的根因判断，一种实现方式中，可视化报告还用于展示各故障调用链的拓扑图、云平台的分层架构图以及信息展示区域中的至少一种；其中，故障调用链为包含至少一故障服务的调用链，每一故障调用链的拓扑图突出展示故障服务，
分层架构图像突出展示在底层故障服务出现故障时的窗口期内，出现故障的各架构层，信息展示区域用于展示目标层单元的单元信息。示例性的，如图10所示，为本发明实施例所提供的一种可视化报告的示意图，从而可以辅助运维人员的根因判断。
140.本发明实施例上述方案中，可以在确定底层故障服务之后，进一步的确定层位置不低于故障架构层的目标架构层，进而从目标层单元中确定实现底层故障服务的目标层单元，可以快速地定位出故障根因所在的位置，进而基于目标层单元的单元信息，确定云平台故障的故障根因，可见，通过本方案，可以快速地确定出故障根因。
141.相应于本发明上述实施例所提供的故障根因确定方法，如图11所示，本发明实施例还提供了一种故障根因确定装置，所述装置包括：
142.服务确定模块1101，用于当监听到云平台出现云平台故障时，从至少一故障服务中确定底层故障服务；其中，所述故障服务为出现故障的应用服务，所述底层故障服务为处于所属调用链中最底层的故障服务；
143.架构层确定模块1102，用于从所述云平台的各架构层中，确定目标架构层；其中，所述目标架构层为：所述各架构层中，层位置不低于故障架构层的架构层，所述故障架构层为：在所述底层故障服务出现故障时的窗口期内，出现故障的各架构层中，层位置最低的架构层；
144.单元确定模块1103，用于从所述目标架构层包含的层单元中，确定用于实现所述底层故障服务的层单元，作为目标层单元；
145.根因确定模块1104，用于基于所述目标层单元的单元信息，确定所述云平台故障的故障根因。
146.可选的，所述服务确定模块，包括：
147.调用链确定子模块，用于基于所述云平台各应用服务之间的拓扑关系，确定故障调用链；其中，所述故障调用链为包含至少一故障服务的调用链；
148.服务确定子模块，用于从所述故障调用链包含的至少一故障服务中，确定在所述故障调用链中位置最低的故障服务，作为底层故障服务。
149.可选的，所述调用链确定子模块，具体用于基于所述云平台各应用服务之间的拓扑关系，确定每一故障服务的上游应用服务和下游应用服务；基于各故障服务的上游应用服务和下游应用服务，确定每一故障服务所处的调用链，作为故障调用链。
150.可选的，所述装置还包括：故障消除模块，用于在所述服务确定模块执行当监听到云平台出现云平台故障时，从至少一故障服务中确定底层故障服务之后，且在所述架构层确定模块执行从所述云平台的各架构层中，确定目标架构层之前，确定所述底层故障服务发生故障时的窗口期内，针对所述底层故障服务所在的调用链内各应用服务的事件操作；针对所述事件操作执行回滚操作；在所述回滚操作结束之后，确定所述云平台故障是否已消除；若未消除，则调用所述架构层确定模块执行所述从所述云平台的各架构层中，确定目标架构层的步骤；其中，所述事件操作包括发布服务操作、变更服务操作以及配置服务操作中的至少一种。
151.可选的，所述架构层确定模块，包括：
152.第一确定子模块，用于确定所述云平台的各架构层中，在所述底层故障服务发生故障时的窗口期内，出现故障且层位置最低的架构层，作为故障架构层；
153.第二确定子模块，用于将所述各架构层中，层位置不低于所述故障架构层的架构层，作为目标架构层。
154.可选的，所述第一确定子模块，包括：
155.第一确定单元，用于确定所述云平台的各架构层中，在所述底层故障服务发生故障时的窗口期内，出现故障的架构层，作为预选架构层；
156.第二确定单元，用于在所确定的预选架构层中，确定层位置最低的架构层，作为故障架构层。
157.可选的，所述第一确定单元，具体用于确定所述底层故障服务发生故障时的窗口期对应时间段，作为故障时间段；在所述云平台的各架构层中，确定在所述故障时间段内出现故障的架构层，作为预选架构层。
158.可选的，所述根因确定模块，具体用于确定所述目标层单元的单元信息中，处于异常状态的单元信息，作为异常信息；基于所述异常信息，确定所述云平台故障的故障根因。
159.可选的，所述单元信息包括：指标信息和部署信息；所述指标信息为描述层单元各项指标参数的信息，所述部署信息为描述层单元部署位置的信息。
160.可选的，所述装置还包括：报告生成模块，用于在所述根因确定模块执行基于所述目标层单元的单元信息，确定所述云平台故障的故障根因之后，生成展示所确定故障根因的可视化报告。
161.可选的，所述可视化报告还用于展示各故障调用链的拓扑图、所述云平台的分层架构图以及信息展示区域中的至少一种；其中，所述故障调用链为包含至少一故障服务的调用链，每一故障调用链的拓扑图突出展示故障服务，所述分层架构图像突出展示在所述底层故障服务出现故障时的窗口期内，出现故障的各架构层，所述信息展示区域用于展示所述目标层单元的单元信息。
162.本发明实施例上述方案中，可以在确定底层故障服务之后，进一步的确定层位置不低于故障架构层的目标架构层，进而从目标层单元中确定实现底层故障服务的目标层单元，可以快速地定位出故障根因所在的位置，进而基于目标层单元的单元信息，确定云平台故障的故障根因，可见，通过本方案，可以快速地确定出故障根因。
163.本发明实施例还提供了一种电子设备，如图12所示，包括处理器1201、通信接口1202、存储器1203和通信总线1204，其中，处理器1201，通信接口1202，存储器1203通过通信总线1204完成相互间的通信，
164.存储器1203，用于存放计算机程序；
165.处理器1201，用于执行存储器1203上所存放的程序时，实现如下步骤：
166.当监听到云平台出现云平台故障时，从至少一故障服务中确定底层故障服务；其中，所述故障服务为出现故障的应用服务，所述底层故障服务为处于所属调用链中最底层的故障服务；
167.从所述云平台的各架构层中，确定目标架构层；其中，所述目标架构层为：所述各架构层中，层位置不低于故障架构层的架构层，所述故障架构层为：在所述底层故障服务出现故障时的窗口期内，出现故障的各架构层中，层位置最低的架构层；
168.从所述目标架构层包含的层单元中，确定用于实现所述底层故障服务的层单元，作为目标层单元；
169.基于所述目标层单元的单元信息，确定所述云平台故障的故障根因。
170.上述电子设备提到的通信总线可以是外设部件互连标准(peripheral component interconnect，pci)总线或扩展工业标准结构(extended industry standard architecture，eisa)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
171.通信接口用于上述电子设备与其他设备之间的通信。
172.存储器可以包括随机存取存储器(random access memory，ram)，也可以包括非易失性存储器(non-volatile memory，nvm)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。
173.上述的处理器可以是通用处理器，包括中央处理器(central processing unit，cpu)、网络处理器(network processor，np)等；还可以是数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
174.在本发明提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一故障根因确定方法的步骤。
175.在本发明提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例中任一故障根因确定方法。
176.在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solid state disk(ssd))等。
177.需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
178.本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部
分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、电子设备、计算机可读存储介质、计算机程序产品实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
179.以上所述仅为本发明的较佳实施例，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。