一种通过自然语言处理进行运维排障的方法及系统与流程

1.本发明涉及运维排障技术领域，具体涉及一种通过自然语言处理进行运维排障的方法及系统。


背景技术：

2.随着信息化进程的飞速发展，计算机系统已经成为现代企业的一部分。近年来各行业信息化建设不断完善，业务的操作也越来越集中于信息系统或信息平台。保证系统正常运行的运维工作也日渐重要，如何在突发状况出现时及时修复解决是运维人员的工作重点之一。
3.目前针对突发故障，业界普遍采用逐步排查检测法，例如针对网络中断故障：当客户端发生网络中断的故障后，需要判断用户(或终端)到网关设备之间通道是否存在问题、三层核心路由器等设备是否正常、dns等外界环境是否正常、边界安全设备是否发生问题，查看多台设备相关告警，然后做出相应的处理。
4.这种逐步排查的工作方式需要耗费运维人员的大量精力进行人工排障，容易出现漏查等问题，在管理上不能做到准确的安全运维，存在漏洞。而且出现问题后逐步排查实时性较差，不能及时发现问题。此外，因为运维人员面对的故障原因多种多样，事后分析的结果很难明显的作用于下一次故障的预防或处理上。


技术实现要素：

5.本发明的目的在于，提供一种通过自然语言处理进行运维排障的方法，解决以上技术问题；
6.本发明的目的还在于，提供一种通过自然语言处理进行运维排障的系统，解决以上技术问题。
7.本发明所解决的技术问题可以采用以下技术方案来实现：
8.一种通过自然语言处理进行运维排障的方法，包括，
9.步骤s1，接收信息系统日志数据，将持续传入的非结构化日志数据转化为结构化日志数据；
10.步骤s2，对历史发生的故障日志进行日志模式聚类；
11.步骤s3，对每一类故障进行分析以及记录故障原因，建立故障知识库，记录每次所述故障发生后的故障信息，并提取所述故障日志的关键字，将所述故障与所述关键字匹配对应；
12.步骤s4，对后续传入的所述日志数据进行关键字匹配，若匹配成功则基于匹配结果确定故障类型，并关联到故障应对方案；否则，认定为新的故障类型，对新的所述故障日志进行聚类并加入到所述故障知识库。
13.优选的，其中，步骤s2中进行日志模式聚类的方式包括，
14.预处理和/或构建词袋模型和/或使用文档主题生成模型进行日志文本聚类；
15.所述预处理将所述故障日志中的特殊字符串转化为统一形式的标签表示；
16.所述词袋模型表示为m
×
v的矩阵，其中m为语料库长度，v为字典长度；
17.所述使用文档主题模型进行日志文本聚类：p(w|d)＝p(w|t)p(t|d)，其中d为所述日志文本，w为所述日志文本的词，t为所述日志本文的主题，p(w|t)为词分布，p(t|d)为主题分布。
18.优选的，其中，步骤s3还包括，于所述故障知识库内设置所述故障信息，所述故障信息包括所述故障原因，故障等级，故障影响范围，故障上下游关系，故障相关技术领域分类，故障相关责任人。
19.优选的，其中，步骤s3中，提取所述故障日志的所述关键字包括：所述故障的时间段关键字，所述故障的数据源关键字，所述故障的ip关键字，所述故障的等级关键字，所述故障的影响结果关键字以及所述故障涉及的网络协议。
20.优选的，其中，步骤s4中，还包括对所述故障应对方案进行审核，审核内容包括，
21.依据所述故障应对方案的处理时效性进行审核，对所述故障应对方案的操作权限进行审核，对所述故障应对方案的操作命令进行审核，对所述故障应对方案的上下游设备进行审核，对所述故障应对方案涉及的责任人进行审核，对所述故障应对方案的迭代维护进行审核。
22.优选的，其中，还包括，
23.步骤s5，将所述故障应对方案按推荐顺序进行排序，形成所述故障应对方案的方案推荐列表，于所述方案推荐列表中选择所述故障应对方案或采用全新的所述故障应对方案来应对所述故障；
24.步骤s6，基于步骤s5的所述故障应对方案的选择方式调整所述方案推荐列表中所述故障应对方案的推荐顺序。
25.优选的，其中，所述故障应对方案的推荐顺序评估内容包括：
26.所述故障应对方案的处理时长，所述故障应对方案的操作命令复杂度，所述故障应对方案的操作节点数量，所述故障应对方案中关键指令的使用频度，所述故障应对方案相关操作的可追溯性和可回退性。
27.优选的，其中，所述方案推荐列表中排列有包括：第一方案，第二方案，至第n方案共n个所述故障应对方案，其中所述第一方案为默认方案，其余所述故障应对方案为备选方案，所述故障应对方案注有所述故障信息，且所述故障应对方案匹配有所述故障日志，其中n为正整数。
28.优选的，其中，步骤s6具体包括：
29.若选择所述默认方案，所述方案推荐列表不改变推荐顺序；或；
30.若选择所述备选方案，将选择的所述备选方案升级为所述默认方案，将原本的所述默认方案降级为所述备选方案；或；
31.若采用新的所述故障应对方案，将新的故障应对操作过程记录为操作数据，并将所述操作数据纳入所述故障知识库，建立新的所述故障应对方案，将新的所述故障应对方案与所述信息系统关联，将新的所述故障应对方案加入所述方案推荐列表并调整为所述第一方案，将所述方案推荐列表中其余的所述故障应对方案降级或删除。
32.一种通过自然语言处理进行运维排障的系统，应用于所述的通过自然语言处理进
行运维排障的方法，包括，
33.采集模块，设于所述信息系统中，用于采集所述日志数据；
34.运维管理服务器，连接所述采集模块，用于对所述故障日志聚类，以及用于分析所述故障日志，记录所述故障信息并提取所述关键字，所述运维管理服务器内设有推荐模块，所述推荐模块用于依据历史处理经验为所述故障配置所述故障应对方案，以及用于更新所述故障应对方案并对所述故障应对方案配置推荐顺序；
35.所述故障知识库，连接所述推荐模块，所述故障知识库内存有所述故障应对方案。
36.本发明的有益效果：由于采用以上技术方案，本发明通过自然语言处理的方式，对信息系统中需要运维排障的问题事件进行故障知识库建设，围绕具体历史事件形成必要的详情分析体系，建立智能化的解决方案推荐机制。
附图说明
37.图1为本发明实施例中通过自然语言处理进行运维排障的方法的步骤示意图；
38.图2为本发明实施例中通过自然语言处理进行运维排障的方法的流程图；
39.图3为本发明实施例中通过自然语言处理进行运维排障的系统的架构图。
40.图4为本发明实施例中管理员采用全新故障应对方案时运维排障系统的架构图。
41.附图中：1、采集模块；2、推荐模块；3、故障知识库；4、运维管理服务器。
具体实施方式
42.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
43.需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。
44.下面结合附图和具体实施例对本发明作进一步说明，但不作为本发明的限定。
45.一种通过自然语言处理进行运维排障的方法，如图1，图2，图3所示，包括，
46.步骤s1，接收信息系统日志数据，将持续传入的非结构化日志数据转化为结构化日志数据；
47.步骤s2，对历史发生的故障日志进行日志模式聚类；
48.步骤s3，对每一类故障进行分析以及记录故障原因，建立故障知识库3，记录每次故障发生后的故障信息，并提取故障日志的关键字，将故障与关键字匹配对应；
49.步骤s4，对后续传入的日志数据进行关键字匹配，若匹配成功则基于匹配结果确定故障类型，并关联到故障应对方案；否则，认定为新的故障类型，对新的故障日志进行聚类并加入到故障知识库3。
50.具体地，本发明进行运维排障的故障应对方案依据来源于故障知识库3，故障知识库3收集了信息系统长时间以来的历史日志数据，将非结构化的各类软硬件设备的日志数据转化为格式化的日志数据，从而为对日志数据进行检索、统计、分析、标示和聚类奠定了基础。通过将格式化的日志数据进行聚类，区分出故障日志与正常日志，将故障日志的特征
进行关键字提炼和标示，合并出一类一类的具体故障并解释故障含义，如网络交换机电源类故障、防火墙主备切换类故障、网站遭遇大量攻击类故障、数据库进程锁死类故障等等，分析各类故障的成因、出现频率、影响范围、上下游关联等情况，依据历史处理经验，为各类故障配置故障应对方案，多方案的还可以配置推荐优先级。一旦运维中发现系统故障，并可以根据故障设备日志信息，从故障知识库3中匹配出故障类型，并获取故障应对方案。
51.本发明可以从多维度综合分析企业网络环境内的各信息系统软硬件设备运行状况，将众多不同厂家的软硬件设备中，编写规范各不相同的各类非结构化日志信息进行收集，转化成便于检索和再加工的结构化日志数据。类型一致的日志数据可以聚合成同类日志事件，对于我们关注的故障类日志事件，可以对其进行详细的故障分析及注解，将生硬的原始日志内容，转化为便于管理员理解的语言体系，帮助管理员在故障发生时，迅速定位故障准确信息，及时推荐故障应对方案帮助解决故障，从而有效缩短故障影响的时间，保障业务系统的可用性，并减少故障应对不当带来的次生灾害。
52.具体地，多维度接收分析系统设备日志数据，网络设备日志可以从核心交换机、接入交换机分别进行采集获取；安全设备日志可以从防火墙、入侵检测设备、负载均衡设备分别进行采集获取；网站日志可以从apachee和nginx中分别进行采集获取。多维度接收分析日志数据，增加对网络环境内重要系统设备日志获取的范围，将采集分析能力覆盖到信息系统所处的整个关键网络环境中，能够避免因为日志收集单一造成的故障成因分析能力不足、故障定位比较模糊、故障实际影响范围与真实影响范围不符、故障应对方案不是最佳选择等等问题。信息系统在网络中并非一个个孤岛，与其网络环境相关基础设施具有密不可分的关系，就好比网站遭受网络攻击时响应缓慢，此时仅从网站服务器自身进行检查是无法确认故障成因，并采取有效的解决方案的，必须要关联网络安全设备日志进行综合分析。
53.在一种较优的实施例中，步骤s1将持续传入的非结构化it日志数据转化为结构化it日志数据，抽取it日志数据中的时间戳、操作对象、操作时间、操作地点、操作类型、授权等级等字段信息。
54.对的非结构化it日志采集，具体包括：
55.网络设备日志：包括交换机日志、路由器日志、ap日志、wlc日志等；支持安全设备日志：包括防火墙日志、防毒墙日志、负载均衡设备日志、vpn设备日志、入侵检测设备日志、waf设备日志、恶意代码防范设备日志、网关设备日志、堡垒机日志等；
56.常见数据库系统日志数据的收集和解析，包括但不仅限于oracle、sql、mysql等常见数据库系统日志；支持从常规数据库(如oracle、sql、mysql等)的数据表中增量抽取数据。
57.从linux、windows等多种操作系统上获取操作系统日志，如windows系统的系统日志、安全日志、审核日志、wmi数据、以及系统服务附带的日志。
58.从信息系统服务器上采集应用软件的日志，包括.tar.gz，.tar，.zip格式的压缩文件形式日志，支持多种解码格式的数据，比如gbk、utf-8、utf-16等，支持从服务器指定本地路径采集日志。
59.具体地，本实施例中，网络设备日志采集具体包括：网络设备syslog服务器方式采集、网络设备syslog trap服务器方式采集、已有网络监控服务器api接口方式采集、已有网络监控服务器日志转发采集。采集的日志级别由管理员预先设置，考虑到设备大量日常包
转发信息类日志用处不大，可以适当提高日志发送级别，只采集重要级别的设备日志。
60.网络设备日志关注类别包括：设备登录/登出日志(web管理页面)、设备登录/登出日志(远程/本地命令行)、设备主备状态监控日志、设备端口启用/禁用日志、对象(ip组或策略组)变更日志、配置备份/还原日志、用户/ip流量监控日志、用户/ip会话监控日志等。
61.dhcp或者wlc类网络设备关注：管理节点上联核心的通讯日志、管理节点集群健康性监测日志、管理节点与用户验证服务器的同步日志、用户接入节点时身份验证成功/失败日志、用户接入质量监控日志、终端切换节点的漂移日志等。
62.安全设备日志关注类别包括：ddos攻击报警日志、网络入侵报警日志、僵木蠕类报警日志、边界敏感端口访问日志、设备非法外联日志、终端对恶意域名解析/访问日志、网络扫描日志、负载均衡健康状态监控日志。
63.防病毒或桌管类安全设备关注：服务端/客户端病毒库更新日志、服务端/客户端版本更新日志、客户端策略同步日志、客户端病毒报警日志、客户端更新状态日志、服务端策略变更日志、终端远程维护日志、计划任务执行日志、工作软件推送日志、补丁修复日志、补丁状态日志、漏洞扫描日志、安全防护策略触发日志等。
64.操作系统类日志关注：系统登录/登出/开机/关机类管理日志、系统服务启用/停用类日志、系统安全对象访问审核日志、系统账户管理日志、系统资源监控报警日志、系统计划任务执行日志、系统备份还原审核日志、系统安全防护报警日志等。
65.数据库类日志关注：数据库登录/登出类管理日志、数据库实例创建/删除日志、数据库查询日志、数据库备份/还原日志、数据库权限变更审核日志、数据库资源监控报警日志等。
66.网站类日志关注：apache日志、nginx日志、tomcat日志等。
67.应用软件类日志关注：软件前台/后台服务状态日志、用户登录/登出日志、用户权限变更日志、任务流转状态监控日志、组织架构变更日志、上下游软件同步验证日志、集群节点健康监控日志、连接数承载监控日志等。
68.在一种较优的实施例中，步骤s2中进行日志模式聚类的具体方式包括，预处理和/或构件词袋模型和/或使用文档主题模型进行日志文本聚类；
69.具体地，预处理：将特殊字符串转化为统一形式的标签表示，具体地，将ip地址，数字，百分比各转化为统一形式的标签表示，抽象化文本模式，减小字典的维度；
70.具体地，构建词袋模型：词袋模型表示为m
×
v的矩阵，其中m为语料库长度，v为字典长度；
71.具体地，使用文档主题模型(lda模型)进行日志文本聚类：p(w|d)＝p(w|t)p(t|d)，其中p为概率值，d为日志文本，w为日志文本的词，t为日志文本的主题，p(w|t)为词分布，p(t|d)为主题分布；
72.进一步地，预测新文本时，同样对新文本分词预处理成词袋向量，然后对其gibbs采样，直到doc-topic分布收敛，统计最终的topic分布即为所求；
73.由于每个词的所属主题最后是从分布中取样得到的，很可能取到小概率主题，当文本过短时，分布不容易收敛，且收敛效果不一定好，因此尽量避免只有三四个词的过短文本。
74.模型的超参数有主题数k，doc-topic分布的先验参数alpha和topic-word分布的
先验参数beta，后两个超参数直接设置为对称的1/topic_num，主题数k可以计算perplexity来选择。模型只需要保存k个topic-word分布用来预测新文本，即phi矩阵。模型的更新不依赖于原训练语料库，但新语料库转为bow的字典必须是一样的。
75.得到某一文本的主题分布后，本实施例中选择概率大于0.4的多个主题或最大概率的主题作为其标签，若没有主题概率高于0.2则归为未分类，较优的，本实施例中的概率值均可调整。
76.每个主题标签会对应一个词分布，取词分布概率较大的词可以作为主题的关键字。
77.在一种较优的实施例中，步骤s3还包括，于故障知识库3内设置故障信息，故障信息包括故障原因，故障等级，故障影响范围，故障上下游关系，故障相关技术领域分类，故障相关责任人等信息。
78.具体的，围绕故障日志本身所透露出来的数据信息，为其提供综合性的解释说明。例如，故障原因包括：磁盘空间不足、内存资源耗尽、cpu持续超过阀值、ha发生非预期切换等；故障等级包括：严重故障、高危故障、中等故障、低级故障等；故障影响范围包括：仅影响单一节点、影响整个服务器集群、影响整条网络链路、影响整个网络安全域；故障上下游关系包括：仅影响本业务、影响下游业务身份验证、影响上游业务任务流转、影响存储挂盘业务(存储设备)、影响代理业务(网络代理设备)。
79.在一种较优的实施例中，步骤s3中，提取故障日志的关键字包括：故障的时间段关键字，故障的数据源关键字，故障的ip关键字，故障的等级关键字(low、med、high、cri)，故障的影响结果关键字(up、down、change、success、failed)以及故障涉及的网络协议(http、https、smb、rdp、ssh)等信息。
80.步骤s4中，还包括对故障应对方案进行审核，审核内容包括，依据故障应对方案的处理时效性进行审核，对故障应对方案的操作权限进行审核，对故障应对方案的操作命令进行审核，对故障应对方案的上下游设备进行审核，对故障应对方案涉及的责任人进行审核，对故障应对方案的迭代维护进行审核。
81.具体的，对方案的时效性进行审核包括：实时切换生效、分钟级生效、小时级生效、次日生效等；对方案的操作权限进行审核包括：系统管理员权限、安全管理员权限、软件管理员权限、数据库管理员权限、网络管理员权限等；对方案的上下游设备进行审核包括：是否影响上游业务系统、是否影响下游业务系统、是否影响网络骨干、是否影响网络安全域、是否属于平台级影响等；对设备的责任人进行审核包括：运维团队、开发团队、值班团队、管理团队等。
82.在一种较优的实施例中，还包括，
83.步骤s5，将故障应对方案按推荐顺序进行排序，形成故障应对方案的方案推荐列表，于方案推荐列表中选择故障应对方案或采用全新的故障应对方案来应对故障；
84.步骤s6，基于步骤s5的故障应对方案的选择方式调整方案推荐列表中故障应对方案的推荐顺序。
85.在一种较优的实施例中，故障应对方案的推荐顺序评估内容包括：
86.故障应对方案的处理时长，故障应对方案的操作命令复杂度，故障应对方案的操作节点数量，故障应对方案中关键指令的使用频度，故障应对方案相关操作的可追溯性和
可回退性。
87.具体的，以处理时长作为推荐依据，时间短的推荐优先级高；以方案的操作命令复杂程度作为推荐依据，命令数量较少的推荐优先级高；以方案的操作节点数量作为推荐依据的，操作节点数量越少，推荐优先级越高；以方案中关键指令使用频度作为推荐依据的，频度越低推荐优先级越高；操作可追溯、可回退的推荐优先级高。
88.在一种较优的实施例中，方案推荐列表中排列有包括：第一方案，第二方案，至第n方案共n个故障应对方案，其中第一方案为默认方案，其余故障应对方案为备选方案，其中n为正整数。
89.在一种较优的实施例中，故障应对方案注有故障信息，且故障应对方案匹配有故障日志，用户可详细查看每个故障应对方案所匹配的日志信息。
90.在一种较优的实施例中，步骤s6具体包括：
91.若选择默认方案，方案推荐列表不改变推荐顺序；或；
92.若选择备选方案，将选择的备选方案升级为默认方案，将原本的默认方案降级为备选方案；或；
93.若采用新的故障应对方案，将新的故障应对操作过程记录为操作数据，并将操作数据纳入故障知识库3，建立新的故障应对方案，将新的故障应对方案与信息系统关联，将新的故障应对方案加入方案推荐列表并调整为第一方案，将方案推荐列表中其余的故障应对方案降级或删除。
94.一种通过自然语言处理进行运维排障的系统，应用于任意一项实施例中的通过自然语言处理进行运维排障的方法，如图3，图4所示，包括，
95.采集模块1，设于信息系统中，用于采集日志数据；
96.运维管理服务器4，连接采集模块1，用于对故障日志聚类，以及用于分析故障日志，记录故障信息并提取关键字，运维管理服务器4内设有推荐模块2，推荐模块2用于依据历史处理经验为故障配置故障应对方案，以及用于更新故障应对方案并对故障应对方案配置推荐顺序；
97.故障知识库3，连接推荐模块2，故障知识库内存有3故障应对方案。
98.在一种较优的实施例中，通过自然语言处理进行运维排障的方法，形成一套智能化的故障应对方案推荐模式。具体的，工作模式可以分为两类：顺序处理模式(按当前知识库方案进行故障应对)、迭代处理模式(采用新的方案进行故障应对，并对知识库中方案列表进行迭代)。
99.顺序处理模式：当信息系统发生故障，采集模块1将故障的日志信息发送给推荐模块2，推荐模块2调用故障知识库查询应对方案，获取故障应对方案的方案推荐列表，包括第一方案、第二方案、第三方案等应对方案。并将故障应对方案按照推荐级别提供给管理员。
100.如果管理员选择或验证默认排名第一的故障应对方案，则默认该方案继续保留，推荐级别不变。反之，如果管理员从方案推荐列表中选择其它的备选方案，则将降级默认排名第一的方案，将新的默认方案与信息系统关联，并且将对信息系统发生的故障实施所选方案。
101.迭代处理模式：该流程在管理员选择应对方案之前，与默认处理流程一致。当信息系统发生故障，采集模块1将故障日志信息发送给推荐模块2，推荐模块2调用故障知识库3
查询应对方案，获取故障应对方案方案推荐列表，获取第一方案(首选推荐)、第二方案、第三方案等应对方案。并将运维方案按照推荐级别提供给管理员。
102.请继续参照图4所示，如果管理员决定不采用任何推荐方案，而是决定采用全新的操作步骤来应对故障，则推荐模块2将其作为新的故障应对方案。推荐模块2将故障信息传递给管理员，管理员发起新的排障操作，相关操作过程转化为操作数据，反馈给推荐模块2，推荐模块2将操作数据纳入知识库，建立新的故障应对方案，将该方案与信息系统进行关联，并将其推荐级别调整为第一方案。原推荐方案降级或删除。
103.本发明的一个较佳的实施例中，本发明的技术方案用于进行突发事件运维排障，具体为某网站突然报警访问非常缓慢，通过采集攻击日志及网站服务器负载日志，将相关设备日志关键字与知识库中故障类型进行匹配，匹配出该故障符合遭受突发ddos攻击这一类型，并且匹配出该故障具有短时高频、大流量、攻击目标多、攻击源分布广泛等特征，推荐采取在边界防火墙设备上设置黑名单、在防火墙设备上设置白名单、在负载均衡设备上设置白名单、在防火墙上开启连接验证并限制单位时间的访问会话等多种处理方案，其中在防火墙上开启连接验证并限制会话为推荐第一方案。经过管理员确认，基于该故障相关特征，推荐方案为全局配置，效果最为直接和迅速。其余备选方案的防护作用起效慢于推荐方案，且各种黑白名单操作工作量较大，面对广泛的攻击源及攻击目标，需要长时间进行配置，当前时间端不适合如此操作。因此，管理员同意采用推荐方案执行排障。该排障方案执行后，ddos攻击流量迅速下降，网站系统很快恢复了正常。
104.本发明的另一个较佳的实施例中，本发明的技术方案用于新建系统交接后辅助运维团队，具体为项目组完成了某电视频道图文处理系统的建设工作，经过一段时间的试运行后，将该系统运维工作移交运维团队。运维团队由于实施经验及试运行期间参与运维工作相对项目组是比较少的，所以当该系统突发故障，前台响应正常，但是后台响应缓慢，导致用户编单任务进度条卡死。此时运维团队立即使用本发明提供的系统，获取故障知识库中针对该故障的应对方案，检索故障知识库中获知，出现该类故障是由于后台数据库有任务连接数过高，且长时间没有释放，连接数不断积累所致，当系统运行超过1个月没有进行重启维护时，可能发生该故障，推荐应对方案为强制停止该任务以迅速结束会话、重启数据库服务、重启后台服务器。运维团队管理员采用默认方案，强制停止该任务，后台响应迅速恢复了正常，业务得到恢复，并在晚些时候对后台服务器进行了重启维护。
105.以上所述仅为本发明较佳的实施例，并非因此限制本发明的实施方式及保护范围，对于本领域技术人员而言，应当能够意识到凡运用本发明说明书及图示内容所作出的等同替换和显而易见的变化所得到的方案，均应当包含在本发明的保护范围内。