故障分析方法、装置和电子设备与流程

1.本公开涉及应用发布领域或金融科技领域等，更具体地，涉及一种故障分析方法、装置和电子设备。


背景技术：

2.随着it技术的频繁更迭，应用部署架构复杂化、系统规模扩大化、发布故障分析复杂化的趋势愈加明显。应用发布例如是指将应用软件包部署到指定服务器，并可以正常提供服务的过程。
3.在应用的发布过程中，可能会出现各种故障而导致发布失败。相关技术中，例如可以给运维人员提供在线知识库，运维人员在进行故障分析时，可以首先根据目录选择故障分类，然后自行输入关键词搜索相关案例进行分析。例如还可以给运维人员提供专家支持，由运维人员通过线上或线下等渠道，将发生的故障现象描述给专家，而专家则根据现象分析出可能的原因，并远程指导运维人员进行逐一排查，最终给出故障原因。
4.在实现本公开构思的过程中，发明人发现相关技术中至少存在如下问题：
5.无论是在线知识库还是专家支持的方式，都依赖于人工进行故障分析，导致人工成本较高，故障分析效率较低，且不利于运维人员直观的了解故障出现的逻辑关系。


技术实现要素：

6.鉴于上述问题，本公开提供了一种采用人机交互的方式，提高故障分析效率，并直观展示故障出现的逻辑关系的故障分析方法、装置和电子设备。
7.本公开实施例的一个方面提供了一种故障分析方法，包括：获取应用在发布过程中出现的故障信息；基于所述故障信息从故障事件属性库中确定出对应的第一属性信息，其中，所述故障事件属性库包括与n个故障事件关联的属性信息，所述第一属性信息与所述n个故障事件中的m个故障事件相关联；将所述m个故障事件中至少一个故障事件的故障路径在故障树上进行展示，其中，所述故障树包括与所述n个故障事件一一对应的n个节点，n和m分别为大于或等于1的整数，m小于或等于n；响应于用户的选中操作，从所述至少一个故障事件中确定出目标故障事件，其中，所述选中操作包括所述用户基于展示的所述故障路径，选中所述至少一个故障事件中任一个故障事件的操作。
8.根据本公开的实施例，所述方法还包括：基于所述目标故障事件生成故障实例，其中，所述故障实例包括所述应用的该次发布故障的记录数据。
9.根据本公开的实施例，所述故障信息包括故障关键词，所述获取应用在发布过程中出现的故障信息包括：获取应用在发布过程中产生的日志文件；解析所述日志文件以获取所述故障关键词。
10.根据本公开的实施例，所述属性信息包括属性关键词，所述第一属性信息包括第一属性关键词，所述基于所述故障信息从故障事件属性库中确定出对应的第一属性信息包括：将所述故障关键词与所述故障事件属性库中的属性关键词进行匹配；将与所述故障关
键词匹配的属性关键词作为所述第一属性关键词。
11.根据本公开的实施例，所述获取应用在发布过程中产生的日志文件包括：获取应用发布任务的第一标识字段，其中，所述应用发布任务用于触发执行应用的发布流程；基于所述第一标识字段查询所述应用发布任务的执行结果；在所述执行结果为失败的情况下，获取所述日志文件。
12.根据本公开的实施例，所述第一标识字段包括至少一个第二标识字段，所述基于所述第一标识字段查询所述应用发布任务的执行结果包括：基于所述至少一个第二标识字段之间的第一层级关系，遍历每个第二标识字段以查询所述执行结果。
13.根据本公开的实施例，在所述将所述m个故障事件中至少一个故障事件的故障路径在故障树上进行展示之前，所述方法还包括生成所述故障树，具体包括：基于历史数据获得所述n个故障事件，以及所述n个故障事件之间的第二层级关系，其中，所述历史数据包括应用在历史发布过程中出现的至少一个历史故障事件；将所述n个故障事件作为所述n个节点，基于所述第二层级关系生成所述故障树。
14.根据本公开的实施例，所述基于历史数据获得所述n个故障事件，以及所述n个故障事件之间的第二层级关系包括：获得所述n个故障事件中的每个故障事件的要素信息，所述要素信息包括以下至少一种信息：事件名称、事件类型、事件描述、上级事件、属性信息。
15.本公开实施例的另一方面提供了一种故障分析装置，包括：信息获取模块、故障定位模块、故障展示模块和目标确定模块。信息获取模块用于获取应用在发布过程中出现的故障信息；故障定位模块用于基于所述故障信息从故障事件属性库中确定出对应的第一属性信息，其中，所述故障事件属性库包括与n个故障事件关联的属性信息，所述第一属性信息与所述n个故障事件中的m个故障事件相关联；故障展示模块用于将所述m个故障事件中至少一个故障事件的故障路径在故障树上进行展示，其中，所述故障树包括与所述n个故障事件一一对应的n个节点，n和m分别为大于或等于1的整数，m小于或等于n；目标确定模块，用于响应于用户的选中操作，从所述至少一个故障事件中确定出目标故障事件，其中，所述选中操作包括所述用户基于展示的所述故障路径，选中所述至少一个故障事件中任一个故障事件的操作。
16.本公开的另一方面提供了一种电子设备，包括：一个或多个处理器；存储器，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得一个或多个处理器执行如上所述的方法。
17.上述一个或多个实施例具有如下优点或有益效果：可以至少部分地解决故障分析效率较低，运维人员无法直观了解故障出现的逻辑关系的问题，通过获取应用在发布过程中出现的故障信息，然后基于故障信息确定出第一属性信息，从而得到与第一属性信息相关联的m个故障事件，并将m个故障事件中至少一个故障事件的故障路径在故障树上进行展示，在展示的故障路径基础上，向用户提供可交互的选中方式，以便基于用户的选中操作确定出目标故障事件。本公开实施例能够先进行自动故障分析，再通过人机交互的方式进行分析，避免了自动分析不准确的情况，提高了故障分析效率，形象的展示出了故障出现的逻辑关系，使运维人员能够自主分析故障原因，提前规避已知风险，从而降低故障分析过程中的人工成本。
附图说明
18.通过以下参照附图对本公开实施例的描述，本公开的上述内容以及其他目的、特征和优点将更为清楚，在附图中：
19.图1示意性示出了根据本公开实施例的故障分析方法的应用场景图；
20.图2示意性示出了根据本公开实施例的故障分析方法的流程图；
21.图3示意性示出了根据本公开实施例的在故障树展示故障路径的示意图；
22.图4示意性示出了根据本公开实施例的生成故障树的流程图；
23.图5示意性示出了根据本公开实施例的故障事件的要素信息示意图；
24.图6示意性示出了根据本公开实施例的配置逻辑关系的示意图；
25.图7示意性示出了根据本公开实施例的获取故障信息的流程图；
26.图8示意性示出了根据本公开实施例的日志内容示意图；
27.图9示意性示出了根据本公开实施例的获取日志文件的流程图；
28.图10示意性示出了根据本公开实施例的第一应用发布任务的流程架构图；
29.图11示意性示出了根据本公开实施例的确定出第一属性信息的流程图；
30.图12示意性示出了根据本公开的另一实施例的故障分析方法的流程图；
31.图13示意性示出了根据本公开的另一实施例的故障分析方法的流程图；
32.图14示意性示出了根据本公开实施例的故障分析装置的结构框图；
33.图15示意性示出了根据本公开的另一实施例的故障分析装置的应用场景图；
34.图16示意性示出了根据本公开实施例的适于实现故障分析方法的电子设备的方框图。
具体实施方式
35.以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。
36.在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。
37.在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。
38.在使用类似于“a、b和c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b和c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。
39.本公开的实施例提供了一种故障分析方法、装置和电子设备。该方法包括：获取应用在发布过程中出现的故障信息。基于故障信息从故障事件属性库中确定出对应的第一属
性信息，其中，故障事件属性库包括n个故障事件的属性信息，第一属性信息与n个故障事件中的m个故障事件相关联。将m个故障事件中至少一个故障事件的故障路径在故障树上进行展示，其中，故障树包括与n个故障事件一一对应的n个节点，n和m分别为大于或等于1的整数，m小于或等于n。响应于用户的选中操作，从所述至少一个故障事件中确定出目标故障事件，其中，所述选中操作包括所述用户基于展示的所述故障路径，选中所述至少一个故障事件中任一个故障事件的操作。
40.相关技术中，利用在线知识库的故障分析方式能够为运维人员提供自主分析故障的基础渠道，并不能很好地展现出各种故障原因之间的因果关系。并且运维人员进行分析会耗费较长时间，往往知其然而不知其所以然，不利于在日常的应用发布运维过程中提前从源头规避操作风险。利用专家支持的故障分析方式会严重依赖专家水平，受专家支持程度影响较大(如专家领域不匹配、能力不足或是响应不及时)，给企业带来较大的人力资源消耗，且不利于运维人员掌握故障原理。一旦失去专家支持，运维人员往往无法独立排除故障，拖延了项目生产进度。
41.根据本公开的实施例，在展示的故障路径基础上，向用户提供可交互的选中方式，以便基于用户的选中操作确定出目标故障事件。本公开实施例能够先进行自动分析，再通过人机交互的方式进行故障分析，避免了自动分析不准确的情况，提高了故障分析效率，并通过故障路径形象的展示出了故障出现的因果关系，使运维人员能够自主分析故障原因，提前规避已知风险，从而降低故障分析过程中的人工成本。
42.图1示意性示出了根据本公开实施例的故障分析方法的应用场景图。
43.如图1所示，根据该实施例的应用场景100可以包括终端设备101、102、103，网络104、106、第一服务器105、第二服务器107。第一服务器105可以包括n个服务器，如服务器1051、1052
……
105n。网络104、106用以在终端设备101、102、103、第一服务器105、第二服务器107之间提供通信链路的介质。网络104、106可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
44.用户可以使用终端设备101、102、103通过网络104、106与第一服务器105、第二服务器107交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。
45.终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
46.第一服务器105、第二服务器107可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。
47.根据本公开的实施例，首先，可以在第二服务器107中进行编程获得待发布的应用软件包。然后，由第二服务器107将应用软件包发送至第一服务器105进行发布。例如第一服务器105可以利用scp(secure copy)技术，使用ssh数据传输技术来进行远程文件拷贝。例如可以通过sshpass工具在第一服务器105中执行拷贝命令来从第二服务器107进行文件拷贝。接着，可以利用saltstack工具执行应用发布任务，并记录日志，该日志中可以包括运行
日志、脚本打印、操作系统报错等文本信息。
48.需要说明的是，本公开实施例所提供的故障分析方法一般可以由第二服务器107执行。相应地，本公开实施例所提供的故障分析装置一般可以设置于第二服务器107中。本公开实施例所提供的故障分析方法也可以由不同于第二服务器107且能够与终端设备101、102、103和/或第二服务器107通信的服务器或服务器集群执行。相应地，本公开实施例所提供的故障分析装置也可以设置于不同于第二服务器107且能够与终端设备101、102、103和/或第二服务器107通信的服务器或服务器集群中。
49.应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
50.以下将基于图1描述的场景，通过图2～图6对本公开实施例的故障分析方法进行详细描述。
51.图2示意性示出了根据本公开实施例的故障分析方法的流程图。图3示意性示出了根据本公开实施例的在故障树展示故障路径的示意图。
52.如图2所示，该实施例的故障分析方法可以包括操作s210～操作s240。
53.在操作s210，获取应用在发布过程中出现的故障信息。
54.参照图1，首先，第一服务器105可以主动获取或被动接收来自第二服务器107的应用软件包。然后，基于该应用软件包执行发布流程。在上述过程中，可能会由于应用软件包获取失败、发布执行脚本有错误、第一服务器105的系统环境与应用软件包不兼容等情况，出现应用发布失败的情况。在该种情况下，可以获取相关故障信息。其中，故障信息可以包括第一服务器105的状态信息、网络信息、文件传输回执信息、应用发布结果信息等。
55.在操作s220，基于故障信息从故障事件属性库中确定出对应的第一属性信息，其中，故障事件属性库包括与n个故障事件关联的属性信息，第一属性信息与n个故障事件中的m个故障事件相关联。
56.故障事件属性库可以是不同的故障信息分别与不同的属性信息的关联表。在该关联表中，属性信息也与相应的故障事件具有关联关系。例如属性信息可以包括对应故障事件的描述信息、出现故障的特征信息或按照一定规则设定的标识信息等。其中，所述与n个故障事件关联的属性信息包括第一属性信息。
57.在本公开的一些实施例中，故障事件属性库可以不是关联表的形式。例如故障事件库包括n个故障事件，其中每个故障事件可看做是故障分析的最小单位。每个故障事件可以包括属性信息、名称等内容，而这些内容是可以被搜索到的。因此，故障事件库可以包括故障事件属性库。通过故障信息在故障事件库中可以确定出对应的属性信息(例如第一属性信息)，从而以故障事件为单位提取出来，例如获取到m个故障事件。
58.在操作s230，将m个故障事件中至少一个故障事件的故障路径在故障树上进行展示，其中，故障树包括与n个故障事件一一对应的n个节点，n和m分别为大于或等于1的整数，m小于或等于n。
59.如图3所示，故障树300可以包括具有上下级关系的根节点、一级节点、二级节点、三级节点，每个节点对应于一个故障事件。例如根节点包括发布执行故障，一级节点包括发布环境不符合要求、版本获取与通用备份失败、发布脚本执行失败，其中，每个一级节点可以具有对应的二级节点。例如，版本获取与通用备份失败可以对应多个二级节点，如用户或
组不存在、版本包下载失败、家目录不存在和分发目录不存在等。其中，每个二级节点也可以具有对应的三级节点，例如版本包下载失败可以对应多个三级节点，如预校验失败、目标机器与中转机网络不通等。若某个节点具有对应的下级节点，可以用过点击该节点旁的“展开/收起全部子节点”按钮，以查看或收起下级节点。
60.根据本公开的实施例，故障路径例如通过m个故障事件中至少一个故障事件的上下级关系，与其上级节点逐级连接而获得。参照图3，例如m个故障事件包括用户或组不存在和预校验失败，可以将用户或组不存在和预校验失败的故障路径在故障树上进行展示。用户或组不存在的故障路径即为“用户或组不存在发布
→
版本获取与通用备份失败
→
发布执行故障”，预校验失败的故障路径即为“预校验失败
→
版本报下载失败
→
版本获取与通用备份失败
→
发布执行故障”。其中，将故障路径在故障树上展示例如是将故障路径与非故障路径以不同的方式展示，如连接线条的粗细、形式、颜色等不同，或者仅显示出故障路径。
61.需要说明的是，图3中所示的故障事件节点仅为示例，本公开的实施例不仅限于图3所示的故障事件。
62.例如m个故障事件仅包括用户或组不存在，即根据故障信息自动定位到本次故障事件为用户或组不存在。相关技术中，若采用专家支持的方式，运维人员首先向专家描述最终现象
→
发布执行故障。而后专家给出一些方法协助用户逐层向下推进，对图3中的二级节点逐个盘查，在一些存在多种原因的故障节点，往往需要专家亲自试验，才能确定其真实原因，再继续推进。最终专家找到根源
→
用户或组不存在。而一旦专家人员不能及时响应，则极有可能导致故障被搁置，给生产效率带来重大影响。若采用查找在线知识库的方式，首先运维人员对图3中的二级节点逐个盘查，先找到“版本获取与备份通用失败”分类。然后搜索具体案例，最后分析出原因为
→
用户或组不存在。在这一过程中，运维人员很难直观又快速地找到各个问题间的联系，效率较低。
63.在操作s240，响应于用户的选中操作，从所述至少一个故障事件中确定出目标故障事件，其中，所述选中操作包括所述用户基于展示的所述故障路径，选中所述至少一个故障事件中任一个故障事件的操作。
64.根据本公开的实施例，参照图3，在将m个故障事件中至少一个故障事件的故障路径在故障树上进行展示之后，运维人员可以直观的看到自动故障分析的结果，以及最终故障事件的逻辑关系。在一些情况下，可以直接准确的自动确定出唯一的故障事件。在另一些情况下，分析结果可能存在偏差，会出现自动确定出的故障事件并不唯一的情况，或出现了一种未知的新故障。
65.例如m个故障事件包括用户或组不符合要求，预校验失败，此时可以提供故障树与运维人员之间的交互接口。运维人员通过查看日志、连接目标机器实机操作等方式，然后查看节点的事件描述确定预校验失败为本次故障对应的事件，则选中该节点，并点击右下角按钮(仅为示例)，以将预校验失败确定为本次故障的目标故障事件。
66.根据本公开的实施例，能够在展示的故障路径基础上，向用户提供可交互的选中方式，以便在分析结果可能存在偏差的情况下，基于用户的选中操作确定出目标故障事件。本公开实施例能够先进行自动分析，再通过人机交互的方式进行故障分析，避免了自动分析不准确的情况，提高了故障分析效率，并通过故障路径形象的展示出了故障出现的逻辑关系，使运维人员能够自主分析故障原因，提前规避已知风险，从而降低故障分析过程中的
人工成本。
67.下面参照图4～图6，进一步说明生成故障树的流程。
68.图4示意性示出了根据本公开实施例的生成故障树的流程图。图5示意性示出了根据本公开实施例的故障事件的要素信息示意图。
69.如图4所示，在操作s230之前，该实施例的生成故障树的包括操作s410～操作s420。
70.在操作s410，基于历史数据获得n个故障事件，以及n个故障事件之间的第二层级关系，其中，历史数据包括应用在历史发布过程中出现的至少一个历史故障事件。
71.历史故障事件例如包括在本次发布应用之前，执行发布应用(例如其他应用、或该应用的其他版本)过程中出现的故障事件。可以对已知的历史故障事件进行记录并统计以形成历史数据，并进一步借助历史数据梳理出不同历史故障事件之间的因果关系，来获得n个故障事件，及第二层级关系。第二层级关系即n个故障事件之间的上下级关系，上下级关系可以包括因果关系，例如图3中预校验失败的事件会导致版本包下载失败的事件。
72.在操作s420，将n个故障事件作为n个节点，基于第二层级关系生成故障树。
73.根据本公开的实施例，故障树例如是指一种特殊的倒立树状逻辑因果关系图，它用事件符号、逻辑门符号和转移符号描述系统中各种事件之间的因果关系。在基于故障信息自动确定出m个故障事件之后，可以基于m个故障事件中每个故障事件所属的第二层级关系，快速获得对应的故障路径，并在故障树进行展示。
74.根据本公开的实施例，操作s420中基于历史数据获得n个故障事件，以及n个故障事件之间的第二层级关系包括：获得n个故障事件中的每个故障事件的要素信息，要素信息包括以下至少一种信息：事件名称、事件类型、事件描述、上级事件、属性信息。其中，应用发布过程中出现的故障事件类型例如可以包括系统环境、文件传输、命令或脚本执行等类型。
75.参照图5，以用户或组不存在的为例，其事件要素信息例如可以包括事件名称、上级事件、事件描述和属性信息。其上级事件即为版本获取与通用备份失败(在故障树上体现为上级节点)，事件描述例如可以包括该事件产生的原因“cfg文件中需要指定本次发布的执行账户或组，当填写的账户或组无时会出现此故障”，属性信息可以包括属性关键词“invalid user”、“no such group”。其中“上级事件”用于构建事件之间的上下级关系(即第二层级关系)来形成树状结构，“属性信息”可用于操作s220中的故障信息匹配，“事件描述”可以用于让运维人员提前预防故障发生。
76.在本公开的一些实施例中，第二层级关系不仅可以包括上下级关系，还可以包括同级事件之间的逻辑关系，下面参照图6进行介绍。
77.图6示意性示出了根据本公开实施例的配置逻辑关系的示意图。
78.如图6所示，例如故障事件“预校验失败”，可以对应有两个下级事件“版本包路径错误”、“中转机空间不足”。这两个下级事件之间没有联系，但都可以造成预校验失败的故障，可以定义“版本包路径错误”、“中转机空间不足”之间的逻辑关系为“或门”。因此，通过令输入事件为“版本包路径错误”、“中转机空间不足”，逻辑关系为“或门”，实现故障事件之间的逻辑运算，获得输出事件为“预校验失败”。
79.在本公开的一些实施例中，图5和图6可以通过交互界面的形式，展示给运维人员。由运维人员基于历史数据，获得n个故障事件，以及第二层级关系。
80.图7示意性示出了根据本公开实施例在操作s210中获取故障信息的流程图。图8示意性示出了根据本公开实施例的日志内容示意图。
81.如图7所示，在操作s210获取应用在发布过程中出现的故障信息可以包括操作s710～操作s720。其中，故障信息包括故障关键词。
82.在操作s710，获取应用在发布过程中产生的日志文件。
83.在操作s720，解析日志文件以获取故障关键词。
84.根据本公开的实施例，图8示出了通过解析得到的，在执行发布时日志文件中记录的发布脚本输出内容和操作系统警告等信息。参照图8，应用发布的流程可以包括开始文件下载、开始scp拷贝等流程，其中stderr是脚本自身打印信息，后续的su及chown是操作系统给出的错误提示。
85.在本公开的一些实施例中，可以基于故障事件属性库预先设置故障关键词库，然后获取故障关键词库中的每个关键词在日志文件中全文搜索，直至搜索到匹配的故障关键词。在本公开的另一些实施例中，可以通过分析历史故障日志文件的结构，确定关键行。例如通过字段“stderr”可以确定关键行，然后往下逐行搜索到字段“chown”，从而对该行内容进行解析，获得故障关键词“invalid user”。对于日志文件中包含成百上千行打印内容的情况而言，全文搜索的方式效率较低，先锁定关键行再获取故障关键词的方法具有更高的处理效率。
86.图9示意性示出了根据本公开实施例的获取日志文件的流程图。图10示意性示出了根据本公开实施例的第一应用发布任务的流程架构图。
87.如图9所示，获取应用在发布过程中产生的日志文件包括操作s910～操作s930。
88.在操作s910，获取应用发布任务的第一标识字段，其中，应用发布任务用于触发执行应用的发布流程。
89.在操作s920，基于第一标识字段查询应用发布任务的执行结果。
90.参照图1，例如在第二服务器107中可以设定多个应用发布任务，每个应用发布任务分配一个第一标识字段。其中，应用发布任务用于触发执行应用的发布流程例如是指依次按照应用发布任务的参数执行对应应用的发布流程。在第一服务器105中停止执行(如执行成功或出现故障无法执行)后，通过第一服务器105获得对应于第一标识字段的执行结果。
91.在操作s930，在执行结果为失败的情况下，获取日志文件。
92.根据本公开的实施例，第一标识字段包括至少一个第二标识字段，基于第一标识字段查询应用发布任务的执行结果包括：基于至少一个第二标识字段之间的第一层级关系，遍历每个第二标识字段以查询执行结果。
93.参照图10，例如多个应用发布任务包括第一应用发布任务，并且第一应用发布任务的第一标识字段为0100(仅为示例)。在该第一应用发布任务的参数中可以包括至少一个发布流程，并且每个发布流程分配有第二标识字段。例如第一应用发布任务包括a服务器单元发布流程0110、b服务器单元发布流程0120。其中，发布流程0110的下级流程包括拷贝文件流程0111、校验版本流程0112、校验环境流程0113。发布流程0120的下级流程包括拷贝文件流程0121、校验版本流程0122、校验环境流程0123。如图10所示的树状结构，第一层级关系即上述发布流程之间的上下级关系。
94.首先，获得第一应用发布任务0100的执行结果。
95.然后，在第一应用发布任务0100的执行结果为失败的情况下，查询a服务器单元发布流程0110的执行结果。
96.接着，在a服务器单元发布流程0110的执行结果为失败的情况下，继续分别查询拷贝文件流程0111、校验版本流程0112、校验环境流程0113的执行结果。
97.接着，查询b服务器单元发布流程0120的执行结果。
98.然后，在b服务器单元发布流程0120的执行结果为失败的情况下，继续分别查询拷贝文件流程0121、校验版本流程0122、校验环境流程0123的执行结果。
99.根据本公开的实施例，通过执行以上步骤来遍历每个第二标识字段，查询获得执行结果，从而可以在较大数量的日志文件中快速锁定本次故障对应的日志文件，提高了处理效率。
100.图11示意性示出了根据本公开实施例的操作s220中确定出第一属性信息的流程图。其中，属性信息包括属性关键词，第一属性信息包括第一属性关键词。
101.如图11所示，在操作s220中基于故障信息从故障事件属性库中确定出对应的第一属性信息可以包括操作s1110～操作s1120。
102.在操作s1110，将故障关键词与故障事件属性库中的属性关键词进行匹配。
103.在操作s1120，将与故障关键词匹配的属性关键词作为第一属性关键词。
104.参照图5和图8，以用户或组不存在为例，在获得其要素信息时，可以相应的配置属性关键词“invalid user”和“no such group”。通过图8中的日志文件获得故障关键词“invalid user”后，可以在故障事件属性库中搜索获得对应的属性关键词“invalid user”。因此，第一属性关键词即为“invalid user”，从而确定其关联的故障事件为用户或组不存在。
105.图12示意性示出了根据本公开的另一实施例的故障分析方法的流程图。
106.如图12所示，该实施例的故障分析方法可以包括操作s210～操作s240，还可以包括操作s1210。其中，操作s210～操作s240与图1中相同，在此不做赘述。在操作s1210，基于目标故障事件生成故障实例，其中，故障实例包括应用的该次发布故障的记录数据。
107.故障实例例如是指针对每次故障而生成的故障记录，例如故障实例可以包括本次应用发布任务的基本信息(如发布应用、涉及部署单元等)、目标故障事件、出现故障的发布流程、故障产生时间等。
108.根据本公开的实施例，在自动进行故障分析的基础上，结合人机交互功能，更加贴合发布运维的实际情况，令运维人员能够快速确定目标故障事件，提高了故障分析的准确性，以及故障实例的可靠性。
109.图13示意性示出了根据本公开的另一实施例的故障分析方法的流程图。
110.如图13所示，该实施例的故障分析方法可以包括操作s1310～操作s1313，
111.在操作s1301，可以创建一个或多个应用发布任务。
112.在操作s1302，执行发布脚本。该发布脚本例如用于按照每个应用发布任务执行具体发布流程的脚本。参照图1，例如在第一服务器105中执行拷贝文件、校验版本、检验环境等流程。
113.在操作s1303，在发布脚本执行发布流程的过程中，将相关内容记录并打印成日志
文件。
114.在操作s1304，在发布脚本执行停止后，输出执行结果。举例而言，若发布脚本执行完毕而停止，执行结果为成功。若发布脚本在某个发布流程出现故障而停止，执行结果为失败。
115.在操作s1305，进行执行结果查询。例如第二服务器107可以与第一服务器105进行数据交互，以获得发布脚本的执行结果。可以参照操作s910～操作s930，在此不做赘述。
116.在操作s1306，基于执行结果判断是否出现执行故障。若是，则执行操作s1307。若否，则结束本次操作。
117.在操作s1307，进行日志文件查询，以获取日志故障文件。例如基于第二标识字段获取执行失败的发布流程所产生的日志。
118.在操作s1308，进行关键词匹配。在日志文件中检索出故障关键词。其中，可以直接全文检索，也可以先确定出关键行，再进行检索。
119.在操作s1309，事件检索。例如可以基于故障事件库中每个故障事件的属性信息，获得独立的故障事件属性库。然后，基于故障关键词从故障事件库中检索出对应的属性关键词，从而确定关联的故障事件。
120.在操作s1310，将操作s1309中确定出的故障事件，及其故障路径在故障树展示。
121.在操作s1311，接收用户匹配。可以提供交互界面，由用户选中最终的目标故障事件。
122.在操作s1312，基于目标故障事件，以及本次应用发布任务的信息，生成故障实例。
123.在本公开的一些实施例中，可以先将操作s1312在操作s1311之前执行，例如检索到故障事件后即可生成故障实例，并同时将故障实例挂载到故障树上的节点上。然后，根据用户的匹配结果，动态的更新故障实例中的目标故障实例信息，并实时将故障实例挂载到目标故障事件的节点上。
124.在操作s1313，基于故障实例生成故障报告。
125.运维人员可以自起始故障开始，结合实际现象自顶向下分析，逐步找到该故障的根本原因。此外，在分析过程中运维人员可以参考其它下级故障节点，举一反三，避免以后因为其它原因引发相同的故障。在本公开的一些实施例中，可以基于故障实例结合故障路径。输出该次故障的故障报告，或基于一段周期内的故障实例输出故障报表。
126.根据本公开的实施例，采用引入故障树的分析方法，能够展现出应用发布各类故障之间的因果关系，使运维人员能够自主分析故障原因、充分理解发布过程、熟悉应用发布系统、提前规避已知风险。
127.基于上述故障分析方法，本公开还提供了一种故障分析装置。以下将结合图14～图15对故障分析装置进行详细描述。
128.图14示意性示出了根据本公开实施例的故障分析装置1400的结构框图。
129.如图14所示，该实施例的故障分析装置1400包括信息获取模块1410、故障定位模块1420、故障展示模块1430和目标确定模块1440。
130.信息获取模块1410例如可以执行操作s210，用于获取应用在发布过程中出现的故障信息。
131.故障定位模块1420例如可以执行操作s220，用于基于故障信息从故障事件属性库
中确定出对应的第一属性信息，其中，故障事件属性库包括与n个故障事件关联的属性信息，第一属性信息与n个故障事件中的m个故障事件相关联。
132.故障展示模块1430例如可以执行操作s230，用于将m个故障事件中至少一个故障事件的故障路径在故障树上进行展示，其中，故障树包括与n个故障事件一一对应的n个节点，n和m分别为大于或等于1的整数，m小于或等于n。
133.目标确定模块1440例如可以执行操作s240，用于响应于用户的选中操作，从所述至少一个故障事件中确定出目标故障事件，其中，所述选中操作包括所述用户基于展示的所述故障路径，选中所述至少一个故障事件中任一个故障事件的操作。
134.图15示意性示出了根据本公开的另一实施例的故障分析装置1500的应用场景图。
135.如图15所示，故障分析装置1500包括信息获取模块1410、故障定位模块1420和故障展示模块1430，还可以包括执行模块1510、故障树维护模块1520和故障统计模块1530。其中，故障定位模块1420可以包括故障匹配模块1421、实例生成模块1422。故障展示模块1430可以包括故障树交互模块1431。故障树维护模块1520可以包括事件管理模块1521和事件逻辑模块1522。故障统计模块1530可以包括故障报告模块1531和统计报表模块1532。
136.参照图15，执行模块1510可以用于执行应用发布任务，并输出故障日志。
137.信息获取模块1410可以用于从故障日志获取故障信息，例如还可以用于执行操作s910～操作s930、操作s710～操作s720。
138.故障树维护模块1520可以用于维护故障事件库，如维护各种故障事件的基本信息、故障事件之间的逻辑关系。例如事件管理模块1521可以用于执行操作s410～操作s420来生成故障树。事件逻辑模块1522可以用于维护同级事件之间的逻辑关系，以及上下级事件之间的逻辑运算关系。
139.故障定位模块1420可以用于接收信息获取模块确定的故障关键词，进行故障定位。例如故障匹配模块1421可以用于基于故障关键词从故障事件库中确定出第一属性关键词，然后获取与第一属性关键词关联的故障事件，具体可以参照操作s1110～操作s1120。实例生成模块1422可以用于首先基于自动分析的故障事件生成故障实例，然后可以执行操作s1220，动态更新故障实例。例如先将故障实例在故障树上初始化展示，而后借助故障树的逻辑关系，由运维人员自行进一步分析，逐层递进，直至该故障实例能够关联到最终的目标故障事件。
140.故障展示模块1430可以用于将自动分析的故障事件的故障路径在故障树上展示。故障树交互模块1431可以用于执行操作s1210，提供交互功能，用于获取用户基于故障路径确定出的目标故障事件。
141.故障统计模块1530可以用于基于每次出现的故障进行统计。例如故障报告模块1531可以基于在用户确定目标故障事件后，基于生成的故障实例输出故障报告。统计报表模块1532可以用于按照时间、应用、故障事件种类等至少一个为单位输出统计报表。
142.根据本公开的实施例，故障分析装置1500可以自动将某次发布故障关联到一个基础的故障事件上，能够方便运维人员快速定位故障原因，提高故障排查效率，还能够将故障报告或报表通过图表的形式列举出最常见的故障、最容易出故障的发布操作等，帮助提前规避故障风险。
143.根据本公开的实施例，信息获取模块1410、故障定位模块1420、故障展示模块
1430、目标确定模块1440、执行模块1510、故障树维护模块1520和故障统计模块1530中的任意多个模块可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，信息获取模块1410、故障定位模块1420、故障展示模块1430、目标确定模块1440、执行模块1510、故障树维护模块1520和故障统计模块1530中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，信息获取模块1410、故障定位模块1420、故障展示模块1430、目标确定模块1440、执行模块1510、故障树维护模块1520和故障统计模块1530中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。
144.图16示意性示出了根据本公开实施例的适于实现故障分析方法的电子设备的方框图。
145.如图16所示，根据本公开实施例的电子设备1600包括处理器1601，其可以根据存储在只读存储器(rom)1602中的程序或者从存储部分1608加载到随机访问存储器(ram)1603中的程序而执行各种适当的动作和处理。处理器1601例如可以包括通用微处理器(例如cpu)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(asic))等等。处理器1601还可以包括用于缓存用途的板载存储器。处理器1601可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。
146.在ram 1603中，存储有电子设备1600操作所需的各种程序和数据。处理器1601、rom 1602以及ram 1603通过总线1604彼此相连。处理器1601通过执行rom 1602和/或ram 1603中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，程序也可以存储在除rom 1602和ram 1603以外的一个或多个存储器中。处理器1601也可以通过执行存储在一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。
147.根据本公开的实施例，电子设备1600还可以包括输入/输出(i/o)接口1605，输入/输出(i/o)接口1605也连接至总线1604。电子设备1600还可以包括连接至i/o接口1605的以下部件中的一项或多项：包括键盘、鼠标等的输入部分1606。包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分1607。包括硬盘等的存储部分1608。以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分1609。通信部分1609经由诸如因特网的网络执行通信处理。驱动器1610也根据需要连接至i/o接口1605。可拆卸介质1611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1610上，以便于从其上读出的计算机程序根据需要被安装入存储部分1608。
148.本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的。也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。
149.根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器
(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的rom 1602和/或ram 1603和/或rom 1602和ram1603以外的一个或多个存储器。
150.本公开的实施例还包括一种计算机程序产品，其包括计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。当计算机程序产品在计算机系统中运行时，该程序代码用于使计算机系统实现根据本公开实施例的方法。
151.在该计算机程序被处理器1601执行时执行本公开实施例的系统/装置中限定的上述功能。根据本公开的实施例，上文描述的系统、装置、模块、单元等可以通过计算机程序模块来实现。
152.在一种实施例中，该计算机程序可以依托于光存储器件、磁存储器件等有形存储介质。在另一种实施例中，该计算机程序也可以在网络介质上以信号的形式进行传输、分发，并通过通信部分1609被下载和安装，和/或从可拆卸介质1611被安装。该计算机程序包含的程序代码可以用任何适当的网络介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
153.在这样的实施例中，该计算机程序可以通过通信部分1609从网络上被下载和安装，和/或从可拆卸介质1611被安装。在该计算机程序被处理器1601执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。
154.根据本公开的实施例，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例提供的计算机程序的程序代码，具体地，可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。程序设计语言包括但不限于诸如java，c ，python，“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
155.附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
156.以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实
施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。