CN116468423A - 一种运维应急协同方法、系统和终端设备 - Google Patents

Abstract

本申请实施例提供一种运维应急协同方法、系统和终端设备，涉及计算机技术领域，该运维应急协同系统包括运维数据模块和运维治理模块；运维数据模块用于采集各个设备的数据信息，对数据信息进行预处理得到原始数据，并对原始数据进行存储；运维治理模块用于从原始数据中获取相应的数据集；通过预设分类模型确定数据集中的异常数据；根据异常数据的故障类型确定相应的故障处理方案并执行。本申请不仅能够显著加快风险事件的发现速度，为应急协同工作提能增效，从而有力的保障系统稳定、高效、安全运行，还可以持续观察与复盘团队应急处置能力，从而可以不断提升公司团队的应急能力，以更好的应对高风险事件。

Description

一种运维应急协同方法、系统和终端设备

技术领域

本发明涉及应急管理技术领域，具体而言，涉及一种运维应急协同方法、系统和终端设备。

背景技术

近年来，随着时代的发展和金融科技的应用不断深入，金融机构信息化建设的内外部环境发生了深刻的变化。为充分保障业务连续性，各机构的IT部门都在发力运维应急指挥系统的建设。故障管理包括事前、事中、事后三个闭环，其中应急管理系统关注事中环节，目标是最大限度地增加TBF(无故障时长)和缩短TTR(故障修复时长)。运维应急管理系统需要涵盖故障发现、故障响应、故障定位、故障恢复等处置流程，其中的每个流程都需要联动多个平台和团队，协同多个职能角色来进行。

随着系统架构及业务功能日益复杂，应用程序版本迭代频度日益提升，影响业务连续性的因素越来越复杂，不确定性越来越高。系统安全运行风险已由原来的保障业务连续性，扩展到保障“业务连续性、数据正确性、逻辑完整性”三个层次，而现有技术方案的存在较多缺陷：

1、现有运维应急处置流程缺少标准化，同一部门的不同群组对不同紧急事件的处置流程可能截然不同，增加了应急处置的成本，并且部分参与处置的人员没有留痕意识，增加了处置后的复盘溯源的难度。

2、现有运维应急管理系统往往是烟囱式建设的孤岛系统，缺乏与其他系统的联动性，这将导致当异常发生后，运维应急管理系统与应急处置相关的各平台、各职能角色间的组织松散、信息流通不畅、以及应急处置效率低下的问题。

3、现有运维应急管理系统数字化程度低，处置过程大多依赖经验驱动。在异常出现后，主要依靠运维专家经验，以及现场IMS经理、值班经理临时决策推动故障恢复。在生产故障出现后，应急现场高度紧张，容易出现关键步骤遗漏、信息不透明、通知不到位、协同不畅、执行缺少复核、执行不到位、延迟恢复、复盘信息不完整等问题。

发明内容

本发明的目的在于提供一种运维应急协同系统、方法、终端设备和可读存储介质。

第一方面，本发明提供一种运维应急协同系统，所述运维应急协同系统包括运维数据模块和运维治理模块；

所述运维数据模块用于采集各个设备的数据信息，对所述数据信息进行预处理得到原始数据，并对所述原始数据进行存储；

所述运维治理模块用于从所述原始数据中获取相应的数据集；通过预设分类模型确定所述数据集中的异常数据；根据所述异常数据的故障类型确定相应的故障处理方案并执行。

第二方面，本发明提供一种运维应急协同方法，所述方法包括：

采集各个设备的数据信息，对所述数据信息进行预处理得到原始数据，并对所述原始数据进行存储；

从所述原始数据中获取相应的数据集；通过预设分类模型确定所述数据集中的异常数据；根据所述异常数据的故障类型确定相应的故障处理方案并执行。

第三方面，本发明提供一种终端设备，包括存储器和处理器，所述存储器存储有计算机程序，所述计算机程序在所述处理器上运行时执行前述实施方式所述的运维应急协同方法。

第四方面，本发明提供一种可读存储介质，其存储有计算机程序，所述计算机程序在处理器上运行时执行前述实施方式所述的运维应急协同方法。

本发明实施例的有益效果是：

本申请实施例提供一种运维应急协同系统，该运维应急协同系统包括运维数据模块和运维治理模块；运维数据模块用于采集各个设备的数据信息，对数据信息进行预处理得到原始数据，并对原始数据进行存储；运维治理模块用于从原始数据中获取相应的数据集；通过预设分类模型确定数据集中的异常数据；根据异常数据的故障类型确定相应的故障处理方案并执行。本申请不仅能够显著加快风险事件的发现速度，为应急协同工作提能增效，从而有力的保障系统稳定、高效、安全运行，还可以持续观察与复盘团队应急处置能力，从而可以不断提升公司团队的应急能力，以更好的应对高风险事件。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对本发明保护范围的限定。在各个附图中，类似的构成部分采用类似的编号。

图1示出了本申请实施例提出的一种运维应急协同系统的第一结构示意图；

图2示出了本申请实施例提出的一种运维应急协同系统实现运维应急协同运的第一流程示意图；

图3示出了本申请实施例提出的一种运维应急协同系统中运维数据模块的结构示意图；

图4示出了本申请实施例提出的一种运维应急协同系统中运维数据模块的流程示意图；

图5示出了本申请实施例提出的一种运维应急协同系统中运维治理模块的结构示意图；

图6示出了本申请实施例提出的一种运维应急协同系统中运维治理模块执行故障处理方案的流程示意图；

图7示出了本申请实施例提出的一种运维应急协同系统的第二结构示意图；

图8示出了本申请实施例提出的一种运维应急协同系统实现运维应急协同运的第二流程示意图；

图9示出了本申请实施例提出的一种运维应急协同方法的流程示意图。

主要元件符号说明：

100-运维应急协同系统；110-运维数据模块；120-运维治理模块；130-运维工具模块；111-数据采集单元；112-数据清洗单元；113-数据分类单元；114-数据持久单元；121-特征描述单元；122-监控诊断单元；123-异常标记单元；125-模型自训练单元；124-智能排障单元；131-应急显示工具；132-异常上报工具；133-异常管理工具；134-应急预案工具；135-应急通知工具。

具体实施方式

下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。

通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

在下文中，可在本发明的各种实施例中使用的术语“包括”、“具有”及其同源词仅意在表示特定特征、数字、步骤、操作、元件、组件或前述项的组合，并且不应被理解为首先排除一个或更多个其它特征、数字、步骤、操作、元件、组件或前述项的组合的存在或增加一个或更多个特征、数字、步骤、操作、元件、组件或前述项的组合的可能性。

此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

除非另有限定，否则在这里使用的所有术语(包括技术术语和科学术语)具有与本发明的各种实施例所属领域普通技术人员通常理解的含义相同的含义。所述术语(诸如在一般使用的词典中限定的术语)将被解释为具有与在相关技术领域中的语境含义相同的含义并且将不被解释为具有理想化的含义或过于正式的含义，除非在本发明的各种实施例中被清楚地限定。

实施例1

请参考图1，本申请实施例提出一种数字化运维应急协同系统100，该数字化运维应急协同系统100包括运维数据模块110和运维治理模块120，应用于终端设备，该终端设备将分别与各个物理设备、各孤岛系统等连接，各个物理设备可以为服务器、存储设备、网络设备等。

其中，协同网络常指一种将多个节点连接起来的网络，通过协同运作实现信息共享、数据传递、资源共享等功能。在该数字化运维应急协同系统100中，通过协同网络将各个物理设备、各孤岛系统、以及设置有数字化运维应急协同系统100的终端设备等联系起来，以实现数据的及时采集、共享与处理。

协同网络不仅可以使运维应急指挥系统内部的不同部分(例如监控、故障诊断、数据处理和数据存储等)相互协同，快速反馈信息，以便及时发现故障并进行响应，从而解决信息孤岛、数据不共享等问题；还可以跨越多个不同的技术领域，例如，数据分析和机器学习等，从而可以实现不同的业务需求。

示范性地，如图2所示，数字化运维应急协同系统100中实现运维应急协同运作具体包括步骤S100～S200。

步骤S100：运维数据模块110采集各个设备的数据信息，对数据信息进行预处理得到原始数据，并对原始数据进行存储。

可以理解的是，运维数据模块110将作为运维应急系统的数据中台，将各个服务器、存储设备、网络设备及孤岛系统的数据进行统一接入和统一处理，换言之，运维数据模块110采集各类设备和系统所产生的数据信息，并对数据信息进行相应的清洗处理得到清洗数据，再根据实际需求对清洗数据进行分类处理，得到至少一组分类数据，即得到原始数据，并将原始数据存储至相应的预设存储介质中。其中，数据信息包括但不限于性能指标、日志、事件、物理信息以及告警等。

在一种实施方式中，如图3所示，运维数据模块110包括数据采集单元111、数据清洗单元112、数据分类单元113和数据持久单元114，如图4所示，步骤S100包括子步骤S110～S140。

子步骤S110：数据采集单元111采集各个设备的数据信息。

在本申请中，数据采集单元111具有自动化采集能力和多样性数据采集能力，数据采集单元111将采集各个设备的数据信息，并将采集到的数据信息发送至数据清洗单元112。其中，数据采集单元111中预先设置有至少一种数据采集方式，不同的数据采集方式将用于采集不同的数据。

示范性地，第一种数据采集方式：通过AIDC(Auto Identification and DataCollection，自动标识数据采集)采集方式获取在交易与运维关键节点所在的机房内，所部署的气敏、声敏、温敏等各类工业传感器的数据。第二种数据采集方式：通过Zabbix等中间件和SNMP(Simple Network Management Protocol—SNMP，简单网络管理协议)协议获取服务器、网络设备等硬件的物理信息，其中，Zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案，物理信息包括各个硬件的各个部件的实时温度、风扇的状态、逻辑磁盘的健康度等信息。

第三种数据采集方式：采用“无埋点”技术，通过在重要服务和软件应用的底层部署预先构建的数据采集基础SDK(Software Development Kit，软件开发工具包)，实时监测重要服务和软件应用的运行过程，监测时捕获和发送尽可能多的事件和信息，由运维数据模块110进行触发条件匹配和统计计算等工作，从而可以更好地支持关注点变更和历史数据回溯。第四种数据采集方式：当运维数据模块110接入孤岛系统提供的API(ApplicationProgramming Interface，应用程序编程接口)，通过定时任务或轮询的方式，获取孤岛系统内部的关键数据指标。

子步骤S120：数据清洗单元112对数据信息进行清洗处理，得到清洗数据。

可以理解的是，数据清洗单元112中预先设置有至少一种数据清洗方式，以用于对采集到的数据信息中的数据进行清洗处理，得到清洗数据，即清洗数据包括数据信息中经过清洗处理的数据。其中，至少一种数据清洗方式包括但不限于数据去重处理、数据格式化处理、数据异常处理和数据合并处理。

示范性地，第一种：数据去重处理，对于采集到的重复数据进行去重处理，避免重复计算和分析。第二种：数据格式化处理，对于采集到的数据进行统一的格式化处理，例如将各渠道获得的温度值统一为摄氏度等，以便于后续进行分析处理和模型训练。第三种：数据异常处理，对于采集到的异常数据进行处理，异常数据可以为存在缺失值、错误值、异常值等，当存在缺失值时，数据清洗单元112将默认以插值法进行数据修复，若存在错误值和离群的异常值，则该错误值和异常值将会被删除。第四种：数据合并处理，将数据信息中来自不同数据源的数据进行合并处理，使其具有相同的维度和度量，以便于进行联合分析和综合评估。

在本申请中，当数据采集单元111从不同的设备和系统中采集到数据信息后，这些数据信息往往存在各种各样的问题，例如，格式不规范、数据缺失、异常值等问题。数据清洗单元112将通过预先设置的至少一种数据清洗方式对采集到的数据信息进行清洗处理，换言之，数据清洗单元112不仅可以对数据进行清洗，还可以进行数据过滤、去重、异常检测等处理，可以确保数据质量和准确性，从而可以提高后续分类和分析的准确度和效率。其中，数据信息中数据对应的清洗方式通常将根据具体情况确定，即根据数据的类型、来源、格式等因素判断对应的清洗方式。

例如，数据清洗单元112在处理服务器的日志数据时，需要过滤掉无关的日志数据，提取出与故障相关的关键数据，同时进行数据格式化处理和数据去重处理等操作。在处理传感器数据时，则需要进行异常值检测和修复、数据插值和平滑处理等。在来自不同数据库的数据时，清洗方式可能会有所不同，需要针对不同的数据库进行相应的处理，例如从关系型数据库(MySQL)和非关系型数据库(MongoDB)所获得的数据格式是不同的，则需要分别进行处理。

子步骤S130：数据分类单元113基于预设分类角度对清洗数据进行分类处理，得到至少一组分类数据。

在本申请中，数据分类单元113将接收数据清洗单元112输送的清洗数据，并将根据预设分类角度对清洗数据进行分类，得到至少一组分类数据，以用于将至少一组分类数据存储到相应的数据库或数据仓库中，从而有效地管理和维护海量的数据，提高数据的可用性和可分析性，为后续的数据分析和应用提供可靠的数据基础。

其中，数据分类单元113中预先设置有至少一种数据分类角度，预设分类角度为至少一种数据分类角度中任意一种或多种。当运维应急协同系统100处于不同的应用场景时，将从不同的角度对数据信息进行分类，换言之，预设分类角度将由工作人员根据实际情况从至少一种数据分类角度确定。

可以理解的是，至少一种数据分类角度包括但不限于数据类型分类、设备分类、时间分类以及应用分类。数据类型分类，将上述清洗数据中不同类型的数据进行分类，例如性能数据、日志数据、异常数据等，得到至少一组分类数据，以便于后续对不同类型的数据进行存储和针对性分析。设备分类，将清洗数据中从不同设备(如服务器、存储设备、网络设备等)采集的数据进行分类，得到至少一组分类数据，以便于对不同设备的性能和状态进行分析。时间分类，将清洗数据中不同时间点对应的数据进行分类，便于对不同交易时段(例如盘前、盘中、盘后等)进行针对性分析。应用分类，将清洗数据中从不同应用程序(例如数据库、Web服务器、中间件等)采集的数据进行分类。

子步骤S140：数据持久单元114将至少一组分类数据存储至相应的预设存储介质中。

可以理解的是，运维应急协同系统100中有预设存储介质，预设存储介质可以为预设数据库或预设数据仓库等。数据持久单元114将接收至少一组分类数据，并将分类后的至少一组分类数据存储至相应的预设数据库，或存储至预设数据仓库中，换言之，将至少一组分类数据写入到预设数据库或分布式文件系统等存储介质中，以便后续进行分析和查询。其中，分布式文件系统则具有高可靠性、高扩展性、容错能力强等优势，适用于海量数据的存储和管理。

数据库通常是指关系型数据库(如MySQL、Oracle等)，数据仓库则是指用于大数据存储与分析的专用系统(如Hadoop、Spark等)。存储到数据仓库中的数据可以更方便地进行后续的分析操作，支持更复杂的数据挖掘和处理方式，而存储到数据库中的数据则更适合实时的数据操作和管理。本申请中将至少一组分类数据存储至预设数据库，或是存储至预设数据仓库中，将根据实际的业务需求决定，换言之，将由工作人员根据实际情况确定预设存储介质为预设数据仓库或预设数据库。示范性地，在本申请中可采取分布式文件系统作为存储介质，即将至少一组分类数据存储至预设数据仓库中。

其中，数据库和数据仓库区别在于数据结构不同、数据来源不同和数据处理方式不同，具体如下：

1.数据结构不同：数据库是用于存储和管理数据的系统，数据结构比较简单，一般采用关系型结构，即表格形式；数据仓库是一个面向主题的、集成的、相对稳定的数据集合，采用多维度的数据结构来存储数据，适合进行大规模、复杂的数据分析和处理。

2.数据来源不同：数据库主要用于存储和管理应用程序产生的实时数据，如交易数据、用户信息等；而数据仓库主要用于存储历史数据、批处理数据和大数据等，如销售数据、流量数据等。

3.数据处理方式不同：数据库通常用于实时处理数据，对数据的增删改查具有高效性；而数据仓库则更多地关注数据的分析和处理，如数据挖掘、报表生成等。

在本申请，数据持久单元114还将每间隔预设时间段对至少一组分类数据进行数据备份，并提供相应的恢复工具和流程，以完成数据的备份和恢复，从而保障运维数据模块110中数据的安全性和可用性，预设时间段可根据实际需求进行设置。

在一种实施方式中，运维数据模块110还提供有灵活的预设数据接口，预设数据接口包括至少一个接口，用于外部获取运维数据模块110中已处理完毕的结构化信息，换言之，运维治理模块120通过调用至少一个接口，基于每个接口获取经过预处理的原始数据中所需的数据。

其中，至少一个接口包括分类查询接口、统计接口和实时监控接口中的任意一个或多个，每个分类查询接口、统计接口和实时监控接口对应的筛选条件可根据实际需求进行设置，换言之，不同的接口对应不同的筛选条件。

分类查询接口，用于提供基础的数据查询能力，例如，可以查询某一特定时间段内某个服务器的CPU(Central Processing Unit，CPU)使用率，或者查询某个应用程序的错误日志，还可以根据不同的分类条件对查询到的数据进行划分，例如按照应用程序、服务器类型、错误类型等分类。统计接口，用于对已有数据进行统计分析，使用平台算力进行相关工作，减轻调用方(即运维治理模块120)的运算压力。例如可以对某个服务器的CPU、内存、磁盘等指标进行统计分析，得出它们的平均值、方差、标准差等统计指标。实时监控接口，调用方可以通过该实时监控接口实时获取被监控对象强时效性的数据，可用于数据实时性分析等场景。

步骤S200：运维治理模块120从原始数据中获取相应的数据集；通过预设分类模型确定数据集中的异常数据；根据异常数据的故障类型确定相应的故障处理方案并执行。

可以理解的是，运维治理模块120将通过调用运维数据模块110相应的接口从运维数据模块110存储的原始数据中获取相应的数据集，运维治理模块120将根据预设分类模型确定获取的数据集中是否存在异常数据，即判断数据集中存在异常状况的数据和该数据的上下文作为异常数据，当存在异常数据时，将确定异常数据的故障类型，并根据异常数据的故障类型确定相应的故障处理方案。

故障类型包括自处理故障和待人工接入故障，自处理故障和待人工接入故障分别包括故障内容可由工作人员根据实际情况进行设置，例如，自处理故障包括服务器磁盘空间满、某个进程意外退出等。其中，不同的故障类型对应不同的预先设置的故障处理方案，当故障类型为自动处理故障时，执行自动处理故障对应的故障处理方案；当故障类型为待人工介入故障时，运维治理模块120将执行待人工介入故障对应的故障处理方案。

在一种实施方式中，如图5所示，运维治理模块120包括特征描述单元121、监控诊断单元122、异常标记单元123、模型自训练单元125和智能排障单元124，如图6所示，步骤S200包括子步骤S210～S240。

子步骤S210：特征描述单元121调用运维数据模块110中的预设数据接口从原始数据中获取相应的数据集，并从数据集中的数据确定目标特征值。

可以理解的是，特征描述单元121将原始数据转换为可供机器学习算法使用的特征向量，以用于为后续的故障诊断和预测提供数据基础。在本申请中，特征描述单元121将调用运维数据模块110的预设数据接口从运维数据模块110获取相应的数据集，换言之，通过不同的分类查询接口、统计接口等获取相应的数据集，数据集可以包括各种指标、日志等。

特征描述单元121将使用不同的特征提取算法将获取到的数据集中的数据转换为特征向量，以用于提取出最具有代表性的特征值，例如基于频域的快速傅里叶变换(FFT)等提取算法。再根据预设因素从特征向量中选择最具有代表性的特征值作为目标特征值，预设因素可以根据实际需求进行设置，如特征重要性等，特征重要性可基于信息增益、方差分析等确定。在本申请中，对于高维的数据集，将使用特征降维算法将维度降低，以便于特征向量更好地训练预设分类模型。其中，特征提取算法和特征降维算法为本领域技术人员所熟知的，在此不做过多赘述。

子步骤S220：监控诊断单元122将目标特征值输入预设分类模型进行分类，得到相应的故障诊断结果；当故障诊断结果为异常情况时，将目标特征值对应的数据和数据在预设范围内的上下文数据作为异常数据。

在本申请中，监控诊断单元122将接收特征描述模块提取出的目标特征，使用预先训练好的预设分类模型对目标特征值进行分类，并输出相应的故障诊断结果，故障诊断结果可以为正常或异常。在得到故障诊断结果后，判断故障诊断结果可以为正常情况或异常情况，当故障诊断结果为异常情况时，将数据集中目标特征值对应的数据和数据在预设范围内的上下文数据作为异常数据，并且将该异常数据传输至异常标记单元123，其中，上下文数据包括但不限于数据的类型、时间、位置等。

当故障诊断结果为正常情况时，监控诊断单元122将继续接收特征描述单元121输入的目标特征值，同时将该正常情况对应的数据和数据在预设范围内的上下文数据作为普通数据，将该普通数据标记为正常，即为正常数据，并将该正常数据传入模型自训练单元125，以加入预设分类模型训练集。

例如，预先使用承担某一类业务程序的服务器的CPU利用率、内存利用率、磁盘速度等指标数据进行模型训练，得到用于判断服务器是否出现性能异常情况的预设分类模型。监控诊断单元122将利用该训练好的预设分类模型持续分类相关特征值的实时信息，当这些特征值发生不合常规的异动，该预设分类模型将判断出有异常状况，将数据集中该异常状况对应的数据作为异常信息，并将异常信息和该异常信息的上下文传入异常标记模块进行进一步处理。

可以理解的是，基于运维的场景特点，本申请中将通过半监督学习算法来构造预测模型，如预设分类模块和预设相似度模型。在运维应急故障诊断领域中，标记数据通常难以获得或者成本较高，比如运维故障频次较低，仅使用故障期相关数据去训练模型会导致过拟合，削弱模型预测能力。半监督学习算法可以通过利用未标记数据和少量标记数据进行训练，从而获得更好的泛化性能和更高的准确率。在实际应用中，半监督学习算法可以大大降低数据标记的成本，提高运维故障诊断的效率和准确性。

子步骤S230：异常标记单元123通过预设相似度模型确定异常数据是否处于异常状态，若是，则确定异常数据的故障类型，若否，则将异常数据标记为误报。

可以理解的是，异常标记单元123用于对监控诊断单元122检测出的异常状况进行自动化或人工标记，以便更好地为预设分类模型训练提供标记样本。异常标记单元123可以对监控诊断单元122识别出来的异常数据进行再次分类，进一步确定异常数据的故障类型，并为异常数据提供相应的标签，即对异常数据进行相应标记，异常数据的故障类型包括自处理故障和待人工介入故障。

异常标记单元123将接收监控异常单元传来的异常数据，并使用预训练好的预设相似度模型判断本次异常数据与历史异常之间的关联度，即确定当前的异常数据是否为异常状态。如果此时预设相似度模型判断异常数据为误报状态，则将会复原此次异常，将该异常数据标记为误报，即无异常，并且将把该异常数据的相关资料传输至模型自训练单元125，以加入上述预设分类模型的训练集。

当异常数据为异常状态时，则将直接标记该异常数据为异常，并判断该异常数据是否为已知异常状态。当异常数据为已知异常状态时，异常标记单元123，并确定其故障类型为自处理故障。异常标记单元123在对异常数据完成标记后，将异常数据传入智能排障单元124进行故障处置，同时将传入模型自训练单元125，以加入预设分类模型训练集。

当异常数据部位不为已知异常状态时，异常标记单元123将确定该异常数据的故障类型为待人工介入故障，则将会请求工作人员对该异常数据进行介入排查，在工作人员排查后，若确认该异常数据是新的故障类型，则工作人员将输入相应的标记命令，以将该异常数据人工标记为新标签。

子步骤S240：智能排障单元124接收标记为异常的异常数据，根据标记为异常的异常数据的故障类型确定相应的故障处理方案，并执行故障处理方案。

可以理解的是，智能排障单元124将根据异常标记单元123提供的标记为异常的异常数据，为故障排查和解决提供自动化能力。智能排障单元124将从异常标记单元123接收已完成标记异常的异常数据，并判断标记为异常的异常数据对应的故障类型，根据该标记为异常的异常数据的故障类型确定相应的故障处理方案。

其中，自处理故障是指已经能够自动化处理的故障，若故障类型为自处理故障，智能排障单元124将直接触发自动处理流程，即一些简单明确的故障，智能排障单元124将执行相应的预先设置的故障处理方案。例如，服务器磁盘空间满、某个进程意外退出等，智能排障单元124可以自动采取预先设置的相应措施进行处理，例如清理磁盘垃圾、重启服务进程。

待人工介入故障是指需要人工介入的故障，例如多种故障因素同时作用导致的故障，若故障类型为自处理故障，则智能排障单元124将执行相应的故障处理方案。

智能排障单元124还将根据异常数据的故障类型，结合故障历史数据，提供相应的排查建议。例如，对于网络故障，智能排障单元124可以建议排查网络拓扑结构、路由配置、防火墙设置等方面的问题；与此同时，在排查过程中，智能排障单元124将结合故障历史数据和现有规则，给出相应的解决方案。例如，针对某个数据库故障，智能排障单元124可以建议增加内存、优化查询语句等方案。

智能排障单元124在完成故障排查和解决自处理故障后，将留存本次异常处置流程，同时将根据本次自处理故障对应的故障处理流程和结果，更新自处理故障对应的故障处置规则，从而提高自动化处理的通用性和效率。

在一种实施方式中，步骤S200还包括子步骤S250。

子步骤S250：模型自训练单元125用于采集运维治理模块120中各个单元产生的标签数据，并根据标签数据对预设分类模型进行再训练；其中，标签数据包括标记为正常的异常数据、标记为异常的异常数据和误报数据。

可以理解的是，模型自训练单元125将持续收集运维治理模块120中各个单元产生的标签数据，并且将根据采集到的标签数据对预设分类模型进行再训练，以实现调整模型参数，改善因标签数据较少引发的潜在过拟合现象，从而可以提高故障诊断的准确性和鲁棒性。其中，标签数据包括正常数据、标记为异常的异常数据和标记为误报的异常数据，正常数据为标记为正常的普通数据，标记为误报的异常数据即为误报数据。

模型自训练单元125还将使用预设测试数据集对更新后的预设分类模型新参数性能进行评估，以检测性能是否比原本预设分类模型更优秀，即判断预设测试数据集的分类正确率是否有所提升。此外，模型自训练单元125将完成训练和评估的更新后的预设分类模型部署至监控诊断单元122中，以用于进行实时的监控和诊断。

在一种实施方式中，故障类型包括待人工介入故障，如图7所示，该运维应急协同系统100还包括运维工具模块130，如图8所示，运维应急协同系统100实现运维应急协同运作还包括步骤S300～S400。

步骤S300：运维治理模块120当故障类型为待人工介入故障时，根据异常数据生成异常工单并发送至运维工具模块130。

可以理解的是，当运维治理模块120中异常标记单元123将异常数据标记为异常，确定异常数据的故障类型为待人工介入故障或自处理故障后，将把该异常数据输入智能排障单元124，智能排障单元124在确定异常数据为待人工介入故障时，将生成相应的异常工单并将该异常工单发送至运维工具模块130，以便于请求工作人员对该异常数据进行介入处理。

步骤S400：运维工具模块130确定是否预先存储有与异常工单相对应的异常处置预案，若否，则基于预先存储的历史数据提供相应的解决建议，若是，则根据异常处置预案对异常工单进行处置。

在本申请中，运维工具模与运维治理模块120和运维数据模块110连接，用于加强应急流程各关联方的协作能力并提供决策辅助，从而更好更快的推动应急处置流程。如图7所示，运维工具模130包括应急集结工具、应急显示工具131、异常上报工具132、异常管理工具133、应急预案工具134和应急通知工具135。

可以理解的是，应急显示工具131将设置于相应的显示装置，该显示装置位于应急指挥中心，以用于实时展示应急处置流程的各项关键指标和数据，从而以可视化的形式帮助应急指挥工作人员快速了解当前的进展。此外，应急显示工具131可以显示当前异常状态的地域分布情况、影响范围、异常指标的变化趋势等信息，并且该应急显示工具131可以通过显示预警提示等方式提醒应急指挥工作人员注意异常情况的发展趋势，显示装置还可以通过与警报装置连接，以通过报警声音进行提醒，从而帮助工作人员更加迅速地做出相应的应急决策。

异常上报工具132作为运维治理模块120中监控诊断单元122的补充，用于人工上报异常情况，接收工作人员在上报表格中的输入的异常上报信息。在异常上报工具132中预先设置有多种风格的上报表格，例如，详细表单和简介表单，详细表单主要由技术人员和运维人员使用，表单设计的较为完整和专业，包含异常类型、异常时间、异常影响范围等信息。简介表单则主要由一线业务人员使用，表单内容相对简洁，用于业务人员快速反馈在系统使用中遇到的问题(如无法登陆，交易失败等问题)。

其中，异常通常分为内部故障(内部可处置)和外部故障(内部不可处置，需要通报关联厂商或合作方)。若异常需要进行进一步处置，则异常上报工具132将进入应急申请步骤并接收工作人员输入异常上报信息，在接收输入的异常上报信息，即确认异常上报后，该异常上报信息将会推送给技术和运维部门的群组经理进行审核，在审核完成后，异常上报工具132接收到完成指令则将把异常上报信息推送至异常管理工具133。

异常管理工具133作为运维应急工具平台的核心，主要用于统一管理异常处置工单。异常管理工具133将接收运维治理模块120识别并发送的异常工单，以及将把工作人员通过异常上报工具132上报的异常上报信息转化为异常工单，异常工单包括异常详细信息、异常等级以及紧急程度等信息。

异常管理工具133根据预先设置的各种异常工单及对应的处理人员，并将接收到的异常工单指派给相应的处理人员；或由指挥值班管理员根据实际情况对异常工单进行分派。

处理人员通过异常管理工具133接收到异常工单后，可以查看异常详细信息、异常等级、紧急程度等。异常管理工具133将判断应急预案工具134中是否预先存储有与异常工单相对应的异常处置预案，换言之，如果异常管理工具133中记录了历史故障的异常工单和对应解决方案，那么当新的异常工单上报后，异常管理工具133可以根据异常工单的类型、严重程度、发生时间等信息与历史异常工单案进行匹配，即确定是否有类似异常的异常处置预案。

若是，则异常管理工具133将根据与异常工单相对应的异常处置预案对该异常工单进行处置，即默认以异常处置预案设置的流程对异常工单展开处置。若否，则将根据历史数据提供相应的排查诊断和解决方案对异常工单进行处置，以用于处理人员对该异常工单进行处置。

例如，对于一台服务器出现的性能异常，异常管理工具133可以提供排查建议，如检查是否存在大量占用资源的进程，或者是否存在磁盘空间不足的情况，同时也可以提供已知的解决方案，如通过升级内存或者增加硬盘容量来解决。

在异常处理流程中，异常管理工具133可以记录异常工单的处理的进度、处理人员的操作记录、工单状态等处理信息，并可以对异常工单进行分类、搜索、排序、筛选等操作，以便于快速定位异常工单。在异常工单处理完成后，异常管理工具133将记录的处置流程、处理信息等传送至应急预案工具134进行留存，同时异常管理工具133支持对处置流程、处理信息进行总结和分析，以便于对异常处理过程进行优化和改进。

可以理解的是，应急预案工具134用于分析异常处置流程，抽象出通用的异常处置预案，为后续的异常处置提供参考，使处置流程标准化。应急预案工具134将收集已完成流程，换言之，将从异常管理工具133和运维治理模块120的智能排障单元124中获取已处理的异常处置流程，还将对收集到的异常处置流程进行智能分析，识别出相似的流程步骤，提取出共性内容并抽象出通用的异常处置预案，并且将根据各个异常处置预案的预案类型、异常类型等信息进行分类。

应急预案工具134将对抽象出的异常处置预案进行存储，以供后续异常处置使用，同时随着异常处置流程的演化和升级，应急预案工具134会持续更新异常处置预案的预案内容，保持预案的准确性和实用性。

此外，应急预案工具134也将接收工作人员输入的手动配置信息，即支持工作人员手动配置异常处置预案。目前针对每个正在运行或待上线的系统，都需要相关的负责群组(工作人员)对内容进行维护，包含主机异常预案、应用异常预案等。

可以理解的是，在异常处理流程中，由于牵涉多平台、多群组联动，往往会给信息对齐与协同处置带来困难。运维工具模块130的应急通知工具135将深入异常处置流程的每一个步骤，辅助人员协作与通知。在本申请中，应急通知工具135将根据异常数据从预设通讯录中确定对应的应急人员名单，并通过预设方式向应急人员名单中每个应急人员发送异常信息。其中，预设通讯录包括多个应急人员名单，每组异常数据对应一个应急人员名单，每个应急人员名单包括多个与异常数据相关联的应急人员。

示范性地，应急通知工具135将通过多渠道进行通知，例如，电话、短信、企业微信公众号、企业微信自动拉协作群、企业微信机器人通知等多种通知方式，以确保所有关联得到应急人员都能及时接收到异常信息。在运维工具模块130接收到异常工单或异常工单生成后，应急通知工具135可以拉入跟进人、申报人、申报人的上级、值班经理、发生异常系统的运维人员等相关应急人员，形成一个企业微信协作群，方便协作处理异常。

应急通知工具135可以荣光企微应用号进行简短通知，通知异常相关的其他人员(开发、测试)和下游系统的相关人员，确保所有关联应急人员全程知悉异常处置流程。指挥者通过应急通知工具135可以查看所有参与应急处置的人员，以及他们的联系方式和职责，换言之，可以查看每个异常数据对应的应急人员名单，以在在需要时迅速联系并指挥应急人员进行相应的操作。同时，指挥者可以通过应急通知工具135发布重要的通知或指令，让所有相关应急人员可以及时看到并响应。

在本申请中，由于处置异常期间的消息推送量较大，牵涉渠道和平台较多，因此需要保证服务的高可用。在后端程序设计上，可以采用分布式消息队列Kafka来将消息推送功能微服务化。

本申请创新性的建立了覆盖了故障预防、故障发现、故障响应、故障定位、故障恢复、复盘改进的数字化应急指挥模型，将应急协同过程全数字化，基于多平台的在线协同网络推动异常处置的规范化和透明化，在实际工作中能够显著加快风险事件的发现速度，为应急协同的故障诊断、定位、决策、恢复提能增效，有力的保障了系统稳定、高效、安全运行，并且在实战过程中，可以持续观察与复盘团队应急处置能力，从而可以不断提升公司团队的应急能力，以更好的应对高风险事件的应急管理。

基于上述运维应急协同系统100，请参照图9，本申请实施例还提出一种运维应急协同方法，示范性地，该方法包括步骤S10～S20。

步骤S10：采集各个设备的数据信息，对数据信息进行预处理得到原始数据，并对原始数据进行存储。

步骤S20：从原始数据中获取相应的数据集；通过预设分类模型确定数据集中的异常数据；根据异常数据的故障类型确定相应的故障处理方案并执行。

上述实施例所涉及的实施方案以及有益效果在本实施例中同样适用，在此不再赘述。

本申请实施例还提供一种终端设备，包括存储器和处理器，存储器存储有计算机程序，计算机程序在处理器上运行时执行上述的运维应急协同方法。

本申请实施例还提供一种计算机可读存储介质，其存储有计算机程序，计算机程序在处理器上执行时，实施上述的运维应急协同方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和结构图显示了根据本发明的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在作为替换的实现方式中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，结构图和/或流程图中的每个方框、以及结构图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本发明各个实施例中的各功能模块或单元可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或更多个模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是智能手机、个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。

Claims (10)

1.一种运维应急协同系统，其特征在于，所述运维应急协同系统包括运维数据模块和运维治理模块；

所述运维数据模块用于采集各个设备的数据信息，对所述数据信息进行预处理得到原始数据，并对所述原始数据进行存储；

所述运维治理模块用于从所述原始数据中获取相应的数据集；通过预设分类模型确定所述数据集中的异常数据；根据所述异常数据的故障类型确定相应的故障处理方案并执行。

2.根据权利要求1所述的运维应急协同系统，其特征在于，所述故障类型包括待人工介入故障，所述运维应急协同系统还包括运维工具模块，所述运维应急协同系统还包括：

所述运维治理模块还用于当所述故障类型为所述待人工介入故障时，根据所述异常数据生成异常工单并发送至所述运维工具模块；

所述运维工具模块用于确定是否预先存储有与所述异常工单相对应的异常处置预案，当存在所述异常处置预案时，根据所述异常处置预案对所述异常工单进行处置。

3.根据权利要求2所述的运维应急协同系统，其特征在于，所述运维工具模块还包括应急通知工具，所述运维应急协同系统还包括；

所述应急通知工具用于在异常处理流程中，根据所述异常数据从预设通讯录中确定对应的应急人员名单，并通过预设方式向所述应急人员名单中每个应急人员发送异常信息。

4.根据权利要求1所述的运维应急协同系统，其特征在于，所述运维数据模块包括数据采集单元、数据清洗单元、数据分类单元和数据持久单元，所述原始数据包括至少一组分类数据，所述采集各个设备的数据信息，对所述数据信息进行预处理得到原始数据，并对所述原始数据进行存储，包括；

所述数据采集单元用于采集各个设备的数据信息；

所述数据清洗单元用于对所述数据信息进行清洗处理，得到清洗数据；

所述数据分类单元用于基于预设分类角度对所述清洗数据进行分类处理，得到至少一组分类数据；

所述数据持久单元用于将所述至少一组分类数据存储至相应的预设存储介质中。

5.根据权利要求1所述的运维应急协同系统，其特征在于，所述运维治理模块包括特征描述单元、监控诊断单元、异常标记单元和智能排障单元，所述从所述原始数据中获取相应的数据集；通过预设分类模型确定所述数据集中的异常数据；根据所述异常数据的故障类型确定相应的故障处理方案并执行，包括；

所述特征描述单元用于调用所述运维数据模块中的预设数据接口从所述原始数据中获取相应的数据集，并从所述数据集中的数据确定目标特征值；

所述监控诊断单元用于将所述目标特征值输入预设分类模型进行分类，得到相应的故障诊断结果；当所述故障诊断结果为异常情况时，将所述目标特征值对应的数据和所述数据在预设范围内的上下文数据作为异常数据；

所述异常标记单元用于通过预设相似度模型确定所述异常数据是否为异常状态，若是，则将所述异常数据标记为异常，并确定所述异常数据的故障类型，若否，则将所述异常数据标记为误报；

所述智能排障单元用于接收标记为异常的异常数据，根据所述标记为异常的异常数据的故障类型确定相应的故障处理方案，并执行所述故障处理方案。

6.根据权利要求5所述的运维应急协同系统，其特征在于，所述运维治理模块还包括模型自训练单元；

所述模型自训练单元用于采集所述运维治理模块中各个单元产生的标签数据，并根据所述标签数据对所述预设分类模型进行再训练；其中，所述标签数据包括正常数据、所述标记为异常的异常数据和标记为误报的异常数据。

7.根据权利要求5所述的运维应急协同系统，其特征在于，所述预设数据接口包括至少一个接口，所述至少一个接口包括分类查询接口、统计接口和实时监控接口中的任意一个或多个。

8.一种运维应急协同方法，其特征在于，所述方法包括：

采集各个设备的数据信息，对所述数据信息进行预处理得到原始数据，并对所述原始数据进行存储；

从所述原始数据中获取相应的数据集；通过预设分类模型确定所述数据集中的异常数据；根据所述异常数据的故障类型确定相应的故障处理方案并执行。

9.一种终端设备，其特征在于，包括存储器和处理器，所述存储器存储有计算机程序，所述计算机程序在所述处理器上运行时执行权利要求8所述的运维应急协同方法。

10.一种可读存储介质，其特征在于，其存储有计算机程序，所述计算机程序在处理器上运行时执行权利要求8所述的运维应急协同方法。