CN105868876A - 一种基于过程监视的集中运维故障闭环处理方法 - Google Patents

Abstract

本发明涉及一种基于过程监视的集中运维故障闭环处理方法，包括：监视数据源：包括处理数据源和过程监视故障分析；故障诊断：包括故障定位和初步诊断；故障处理：监管故障处理的状态；故障处理结果的确认和评价。本发明提供的技术方案实现运维工作的精益化管理，研究集中运维模式下先进的技术支撑手段，实现资源优化配置，减少人力成本，提升远程集中运维能力。

Description

一种基于过程监视的集中运维故障闭环处理方法

技术领域

本发明涉及一种电力系统中的故障处理方法，具体讲涉及一种基于过程监视的集中运维故障闭环处理方法。

背景技术

国家电网公司发展方式的转变迫切要求创新调度技术支持系统的运维机制。推动公司发展方式转变的根本途径就是落实“四化工作”，即集团化运作、集约化发展、精益化管理、标准化建设，需要按照“创新管理模式、优化业务流程”的要求，科学合理的优化和配置公司现有的资源。当前国家电网公司系统调度自动化专业普遍存在结构性缺员的问题，尤其是运行维护人员，需要改变现有的运维模式，集约化地管理和使用人力、技术和设备资源，提高运维工作的质量和效率。

大运行体系的建设给运维工作赋予更为艰巨的任务。按照“三集五大”的战略要求，国家电网公司将建立大运行体系，实现各级调度的调控一体化和调度一体化，调度技术支持系统在采集范围、服务对象、功能要求等方面都有了很大的拓展，承担了更大的运行风险，给运维工作赋予了更为艰巨的任务，迫切需要探索系统运维工作的新模式，实现运维工作的精益化管理，研究集中运维模式下先进的技术支撑手段，实现资源优化配置，减少人力成本，提升远程集中运维能力。

发明内容

为解决上述现有技术中的不足，本发明的目的是提供一种基于过程监视的集中运维故障闭环处理方法，实现运维工作的精益化管理，研究集中运维模式下先进的技术支撑手段，实现资源优化配置，减少人力成本，提升远程集中运维能力。为了对披露的实施例的一些方面有一个基本的理解，下面给出了简单的概括。该概括部分不是泛泛评述，也不是要确定关键/重要组成元素或描绘这些实施例的保护范围。其唯一目的是用简单的形式呈现一些概念，以此作为后面的详细说明的序言。

本发明的目的是采用下述技术方案实现的：

本发明提供一种基于过程监视的集中运维故障闭环处理方法，所述方法用于智能电网调度控制系统的远程集中运维，其改进之处在于，所述方法包括下述步骤：

(1)监视数据源：包括处理数据源和过程监视故障分析；

(2)故障诊断：包括故障定位和初步诊断；

(3)故障处理：监管故障处理的状态；

(4)故障处理结果的确认和评价。

进一步地，所述步骤(1)中，处理数据源包括：

定义告警信息的类型：

1)监视数据源分类：包括电网重要监视数据、设备运行状态、应用运行状态、网络通信状态和本地机房环境监视数据；

2)告警数据源包括：

①调控中心直接转发的告警直传数据：包括设备运行状态故障、应用运行状态故障和网络通信状态故障；

②集中运维中心本地监视到的故障进行实时告警：包括电网重要监视数据越限、传输数据中断、跳变、不刷新、应用故障超时、链路中断超时、本地机房环境异常、远程浏览中断超时、数据网中断和热线电话紧急告警；其中传输数据中断和跳变按照监视数据源类型细分到下一个级别；

③根据历史数据进行分析的系统风险告警：包括系统资源重载(包括CPU、服务器和内存重载监视)、应用故障率越限、应用持续(分为单次故障时间和日故障总时间)故障时间越限、传输数据中断次数越限、数值数据连续跳变、系统更新的持续时间越限、CORE文件过多(包括某一进程和某一目录)和进程连续产生CORE文件；

④故障处理流程监视到的流程告警信息：包括故障处理超时告警、故障处理延时警告和故障处理结果评价不合格告警；

根据告警信息类别，进行故障分级和定义响应时间：

故障级别包括：

I级：属于紧急响应；其具体现象为：智能电网调度控制系统崩溃导致业务停止和数据丢失，其对应的响应时间为：启动紧急处理预案，并在10分钟内提交故障处理方案；

II级：属于故障处理；其具体现象为：出现部件失效、系统性能下降但能正常运行，不影响正常业务运作；其对应的响应时间为：协同产品生产商，并在1小时内提交故障处理方案；

III级：属于常规维护；其具体现象为：出现系统报错或警告，但业务系统能继续运行且性能不受影响；其对应的响应时间为：先由集中运维中心进行故障定位和处理，并在6小时 内提交故障处理方案。

进一步地，所述步骤(1)中，过程监视故障分析包括下述情况：

<1>正常-故障-正常：

方式：理想状态下采集到上述三个状态过程的最短时间为15s，即在15s内采到一次故障状态；实际情况是事件从正常变为故障后，集中运维系统中的告警模块开始每5秒连续采集事件的状态，在300秒周期内时刻S(S的定义范围需要由各调控中心定义，这里只是用于说明时间起点用)监视到事件状态由故障又变回到正常状态时，不发送告警信息；

标记：不标记：

告警监视周期：从S时刻起进入下一新的告警监视周期：

统计方式：记录事件故障一次，同时故障恢复一次：从监视到故障时刻起，集中运维系统中的计时器开始记录故障时间，直到状态变为正常时，计时器确认故障持续时长；

<2>正常—持续故障:

方式：事件状态从正常变为故障后，如果在300秒内事件状态不发生变化，而持续保持故障状态，则说明事件在最大监视周期时间内出现故障，且没有自行恢复的能力，为系统在第300秒时发出的告警；

标记：事件产生告警，并推送到故障处理流程中进行诊断和处理；等处理完成后返回告警，标记事件故障消除；

告警监视周期：告警模块每5秒继续采集状态，直到采集到正常时，则开始进入下一个新事件的监视周期；

统计方式：记录事件故障一次：从监视到故障时刻起，计时器开始记录故障时间，直到状态变为正常时，计时器确认故障持续时长；

<3>正常-故障-退出：

方法：事件状态从正常变为故障后，如果在300秒内时刻S监视到事件状态由故障又变为退出状态时，说明事件在300秒内出现故障，标志事件处于故障状态中，并发出告警，报告值班人员事件发生故障并且系统无法自愈，需要人为参与故障处理；

标记：事件产生告警，并推送到故障处理流程中进行诊断和处理；等处理完成后返回告警，标记该事件故障消除；

告警监视周期：告警模块每5秒继续采集状态，直到采集到正常时，则开始进入下一个新事件的监视周期；

统计方法：记录事件故障一次：从监视到故障时刻起，计时器开始记录故障时间，直到 状态变为正常时，计时器确认故障持续时长；

<4>正常-(故障-退出：即连续闪变5次)-异常，即非正常永久退出：

方式：当系统发生故障时，集中运维系统监视模块首先将相关进程重启，如果连续重启5次都失败，事件最终显示异常状态，即状态从故障到退出闪变5次，则监视模块放弃将相关进程重启，永久退出；如果在300秒内某时刻S监视到事件状态变成由正常或故障变成异常时，则在S秒时发出告警，说明事件发生异常，需要人工处理才能重新恢复该事件正常运行；

标记：事件产生告警，并推送到故障处理流程中进行诊断和处理；等处理完成后返回告警，标记事件故障消除；

告警监视周期：等故障处理流程返回事件故障被消除后，确认事件恢复正常时，开始进入下一个新事件的监视周期；

统计方式：记录事件异常一次：从监视到异常时刻起，计时器开始记录故障时间，直到状态变为正常时，计时器确认故障持续时长；

<5>正常-退出-正常：

方式：某事件状态从正常变为退出后，从退出时刻开始，告警模块在后续时间内第S秒监视到事件状态恢复正常运行，系统不发出告警；

标记：不标记；

告警监视周期：从S时刻起进入下一新的告警监视周期；

统计方式：记录事件重新启动一次；计时器不统计故障时间；

<6>正常-退出-故障：

方式：事件状态从正常变为退出，从退出时刻开始，告警模块在后续时间内第S秒时监视到进程故障状态，告警模块在第S秒发出告警，需要人为关注此事件，并且告警模块继续监视，直到捕捉到事件恢复正常；

标记：标记事件产生告警，并推送到故障处理流程中进行诊断和处理；如果在300秒内故障恢复，则提示事件在重启时发生一次故障，处理完成后返回告警，标记该事件故障消除；

告警监视周期：从告警模块监视到事件恢复正常时刻起，进入下一新的告警监视周期；

统计方式：记录事件故障一次，计时器从事件发生故障开始计时，直到状态变为正常时，计时器确认故障持续时长。

进一步地，所述步骤(2)的故障诊断包括下述步骤：

1>建立故障分析模型进行故障定位，包括：

关联分析模型：根据告警信息的两个源头建立事件的关联分析模型，所述告警信息的两个源头包括调控中心直接给集中运维中心通过通信协议直接发送各地的系统告警信息和集中运维中心根据实时采集的系统运行状态采用过程分析法发送的告警信息；

递归分析模型：在同源故障中建立递归分析模型；所述递归分析模型采用排除法进行分析；

2>故障识别及告警确认，包括：

对于设备、应用和通信链路发生故障时，首先根据告警信息的类型采用关联故障模型去搜索故障源，确认同源事件后，对同源事件标注同一个告警ID号；

对于数值类监视数据发生异常时，通过相应的递归模型进行故障定位，定位后如果属于日常故障则由运维值班员依据故障处理预案进行日常维护处理，如果属于较复杂的故障(较复杂的故障指的是软件本身的缺陷问题，或底层服务出现问题等，运维人员无法进行定位的情况)，需要及时联系产品生产商进行协作处理；

当告警发生后都会建立故障处理任务，所述故障处理任务直到故障被消除后才被标记完成状态，任务完成后会发出一个告警消除消息，此消息会加载告警ID号，根据告警ID号，同时消除一个或多个同源告警事件。

进一步地，所述步骤(3)的故障处理包括下述步骤：

A、接收故障告警并建立故障处理任务；

B、故障处理及状态监视。

进一步地，所述步骤A包括：由调控中心将监视数据实时发送给集中运维中心，集中运维中心接收到实时监视数据后首先进行分类处理，采用过程监视对事件状态进行监视和分析，并对发生的故障进行告警；

每个告警信息对应一个ID号，引起同一个告警的事件源均标记上述告警ID号；当告警发出时，建立新的处理任务，并对新建处理任务的受理状态进行流程管控。

进一步地，所述步骤B包括：产生新的告警后，根据告警级别启动不同的处理流程，严重极别的故障启动应急预案，所述应急预案要求调控中心、集中运维中心和产品生产商之间定位故障并协同处理，边处理边通告，及时解除对智能电网调度控制系统运行造成重大的影响的事故；

如果是日常维护流程，则根据故障分析模型进行故障诊断与定位，由运维值班员统一处理；

如果在处理过程中遇到较复杂的问题，要求产品生产商协同处理，并监视故障处理的时 间；

如果在规定的时间内无法完成任务或需要延时，则请求调控中心是否同意延时处理，如果调控中心同意延时，则由调控中心定义延时时长，如果在延时过程中完成任务，则不影响考评结果，如果无法完成任务则在考评中会考虑处理效率的得分；如果任务在申请延时时未得到调控中心的同意，则任务由于处理超时则在考评中评分酌减。

进一步地，所述步骤(3)包括：当故障任务处理完成后，返回告警模块进行标记，提示此事件引起的故障已经消除，并解除告警，即标记同一事件告警ID的故障源解除告警状态，标志该事件已经处理完成，不存在风险；由集中运维中心提交故障处理结果，由调控中心进行确认；

如果遇重大故障则由集中运维中心同产品生产商共同提交重大故障的报告，并由调控中心根据处理时间，响应速度，处理结果及服务态度四个项目进行打分，最终得分计入当月的考评。

与最接近的现有技术相比，本发明提供的技术方案具有的优异效果是：

(1)本发明提供的一种基于过程监视的集中运维故障闭环处理方法，基于集中运维模式，综合监视智能电网调度控制系统运行状态，对告警信息进行分类监视和告警，降低告警误告率，提高故障处理效率；

(2)采用过程监视的方法，可以判断系统各种运行状态发生变化的过程，能更准确地发出告警信息，可以对告警进行分级处理，并根据告警信息的类别和级别采用多种显示方式，提示运维值班人员快速处理故障；

(3)通过对告警信息的分类，实现快速定位故障，通过故障关联分析模型，能够合并告警信息，解决重复告警的问题，通过故障递归模型可以快速定位故障源，降低误告率；

(4)建立了一套完整的故障处理流程，从而对故障处理过程进行监管，保障集中运维模式运转流畅，职责清晰，节省技术成本和人力成本，提高运维管理效率；

(5)建立了一套完整的运维服务评价指标和机制，对故障处理的效率和结果进行约束，提高故障处理率，完善运行管理机制，使调控中心、集中运维中心和生产商三方协作处理故障，及时处理系统出现的各种问题，保障系统运行稳定性和可靠性；

(6)建立了故障信息知识库，从而减少了值班员处理故障时人为失误率，为各级调控中心自动化部门提供运维技术的建议和实施方法，提高了系统故障处理的正确性；并为系统软件研发技术人员提供历史数据，以便于优化系统性能。

为了上述以及相关的目的，一个或多个实施例包括后面将详细说明并在权利要求中特别指出的特征。下面的说明以及附图详细说明某些示例性方面，并且其指示的仅仅是各个实施例的原则可以利用的各种方式中的一些方式。其它的益处和新颖性特征将随着下面的详细说明结合附图考虑而变得明显，所公开的实施例是要包括所有这些方面以及它们的等同。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1是本发明实施例中基于集中运维和过程监视的故障处理功能图；

图2是本发明实施例中三大机构的职责分工及故障处理流程图。

具体实施方式

下面结合附图对本发明的具体实施方式作进一步的详细说明。

以下描述和附图充分地示出本发明的具体实施方案，以使本领域的技术人员能够实践它们。其他实施方案可以包括结构的、逻辑的、电气的、过程的以及其他的改变。实施例仅代表可能的变化。除非明确要求，否则单独的组件和功能是可选的，并且操作的顺序可以变化。一些实施方案的部分和特征可以被包括在或替换其他实施方案的部分和特征。本发明的实施方案的范围包括权利要求书的整个范围，以及权利要求书的所有可获得的等同物。在本文中，本发明的这些实施方案可以被单独地或总地用术语“发明”来表示，这仅仅是为了方便，并且如果事实上公开了超过一个的发明，不是要自动地限制该应用的范围为任何单个发明或发明构思。

如图1所示，图1是本发明实施例中基于集中运维和过程监视的故障处理功能图，包括四大部分，第一部分就是监视数据源，包括对数据源的处理方法和过程监视故障分析法；第二部分是故障诊断，基于对数据源的分析处理后，可以初步定位故障，对日常故障进行日常维护处理，如果遇到比较复杂的问题，将联合产品生产商共同诊断故障，协调处理；第三部分是故障处理过程中对故障处理的状态进行监管，主要是为了提高故障处理的效率，提升系统在线运行的稳定性，对各种操作流程和步骤进行有序管控，保障系统的稳定运行；第四部分是故障处理结果的确认和评价，当故障处理完成后，由调控中心进行确认，并对服务质量和效果进行评价，一方面可以促进集中运维工作的有序有效开展，另一方面建立故障处理的闭环机制，掌握调控中心对运维工作的需求，不断提升远程集中运维的技术手段。

如图2所示，图2是本发明实施例中三大机构的职责分工及故障处理流程图，包括下述步骤：

(1)监视数据源：

一、定义告警信息的类型、级别和时限

1)监视数据源分类：包括电网重要监视数据、设备运行状态、应用运行状态、网络通信状态和本地机房环境监视数据五大类。

2)告警数据源主要包括：

调控中心直接转发的告警直传数据：包括、设备运行状态故障、应用运行状态故障、网络通信状态故障。

集中运维中心本地监视到的故障进行实时告警：包括电网重要监视数据越限、各类传输数据中断、跳变、不刷新、应用故障超时、链路中断超时、本地机房环境异常、远程浏览中断超时、数据网中断、热线电话紧急告警。其中传输数据中断和跳变按照监视数据源类型细分到下一个级别。

根据历史数据进行分析的系统风险告警：包括系统资源重载(包括CPU、服务器和内存重载监视)、应用故障率越限、应用持续(分为单次故障时间和日故障总时间)故障时间越限、传输数据中断次数越限、数值数据连续跳变、系统更新的持续时间越限、CORE文件过多(包括某一进程和某一目录)、进程连续产生CORE文件七大类。

故障处理流程监视到的流程告警信息：包括故障处理超时告警、故障处理延时警告、故障处理结果评价不合格三大类

具体告警数据源分类如下表1所示。

3)根据告警信息类别，进行告警分级和定义响应时间，如下表2所示：

表2 告警分级和定义响应时间

告警信息分类表中所列举的故障依据故障级别定义进行分级。分级如图二告警数据源分类及告警级别定义表中数字编号所示。

二、集中运维系统过程监视分析法：

结合历史数据和实时信息，通过对一个监视事件发生的各种状态进行分析，判定系统是否属于故障情况。一个事件的状态分为“正常”、“故障”、“退出”三种情况，状态信息在本地的刷新周期为1-3s,远程监视数据采集周期为5s，一个事件状态为“正常”状态，因此我们假定从“正常”状态做为一个过程的起始状态，并且定义300秒为系统最大自愈等待时间——即故障告警模块在监视到“故障”后等待300秒，并在此时间内不发出告警，根据300秒内监视的状态变化再决定是否告警。事件状态变化过程的实际情况和具体分析方法如下，可以分为以下六种情况。

1)正常-故障-正常

方法：采集到这三个状态过程的最短时间应为15s，即在15s内采到一次故障状态，但是这是理想状态。实际情况是某状态从“正常”变为“故障”后，告警模块开始每5秒连续采集事件的状态，在300秒周期内某时刻S监视到事件状态由“故障”又变回到“正常”状态时，这时不发送告警信息。原因是该事件在很短的时间内出现过故障，但是又迅速恢复到正常，说明该事件能够自愈，不涉及人工处理的过程。因为在300秒内该事件的故障状态得到恢复，有可能是本地值班员重启相关进程，或者本地系统的监视程序在某种情况下对相关进程进行了重启，因此远程监视时集中运维系统不用发出故障告警。只是提示值班员故障已经自行恢复，因此不需要推送告警信息。

标记：不标记。

告警监视周期：从S时刻起进入下一新的告警监视周期。

统计方法：记录该事件故障一次，同时故障恢复一次。从监视到“故障”这一时刻起，计时器开始记录故障时间，直到状态变为“正常”时，计时器确认故障持续时长。

2)正常—持续故障

方法：某事件状态从“正常”变为“故障”后，如果在300秒内事件状态不发生变化，而持续保持“故障”状态，则说明该事件在最大监视周期时间内出现了故障，并且没有自行恢复的能力，这是系统在第300秒时发出告警。

标记：该事件产生告警，并推送到故障处理流程中进行诊断和处理。等处理完成后返回告警，标记该事件故障消除。

告警监视周期：由于这个事件进入到持续故障状态，并且标记产生告警，因此告警模块每5秒继续采集状态，直到采集到“正常”时，则开始进入下一个新事件的监视周期。

统计方法：记录事件故障一次。从监视到“故障”这一时刻起，计时器开始记录故障时间，直到状态变为“正常”时，计时器确认故障持续时长。

3)正常-故障-退出

方法：某事件状态从“正常”变为“故障”后，如果在300秒内某时刻S监视到事件状态由“故障”又变为“退出”状态时，说明该事件在短时间内出现了故障，标志该事件处于故障状态中，并发出告警，报告值班人员该事件发生了故障并且系统无法自愈，需要人为参与故障处理。

标记：该事件产生告警，并推送到故障处理流程中进行诊断和处理。等处理完成后返回告警，标记该事件故障消除。

告警监视周期：由于事件进入到退出状态，并且标记产生告警，因此告警模块每5秒继续采集状态，直到采集到“正常”时，则开始进入下一个新事件的监视周期。

统计方法：记录事件故障一次。从监视到“故障”这一时刻起，计时器开始记录故障时间，直到状态变为“正常”时，计时器确认故障持续时长。

4)正常-(故障-退出(连续闪变5次))-异常(非正常永久退出)

方法：当系统发生故障时，系统监视程序会首先将相关进程重启，如果连续重启5次都失败，该事件最终显示“异常”状态(实际上是状态从“故障”到“退出”闪变了5次)，则监视程序放弃将相关进程重启，而永久退出。如果在300秒内某时刻S监视到事件状态变成由“正常或故障”变成“异常”时，则在S秒时发出告警，说明事件发生了异常,和简单的故障状态是有所区别的，需要人工处理才能重新恢复该事件正常运行。

标记：该事件产生告警，并推送到故障处理流程中进行诊断和处理。等处理完成后返回告警，标记该事件故障消除。

告警监视周期：由于事件进入到“异常”状态，并且标记产生告警，因此没有人工处理 这个事件不可能恢复正常，因为相关进程已经永久退出服务，这时需要等故障处理流程返回该事件故障被消除后，确认事件恢复正常时，才则开始进入下一个新事件的监视周期。

统计方法：记录事件异常一次。从监视到“异常”这一时刻起，计时器开始记录故障时间，直到状态变为“正常”时，计时器确认故障持续时长。

5)正常-退出-正常

方法：某事件状态从“正常”变为“退出”后，从“退出”时刻开始，告警模块在后续时间内第S秒监视到事件状态恢复“正常”运行，这时系统不发出告警，仅说明该事件在某种情况下正常重启了一次，例如程序开发人员对程序进行消缺或升级，这种情况在程序员操作前应提前通知集中运维中心，并允许监视系统对程序员的操作进行追踪，防止重大责任事故的发生，这种情况也属于系统安全防护的范畴。

标记：不标记。

告警监视周期：从S时刻起进入下一新的告警监视周期。

统计方法：记录事件重新启动一次。计时器不统计故障时间。

6)正常-退出-故障

方法：某事件状态从“正常”变为“退出”，从“退出”时刻开始，告警模块在后续时间内第S秒时监视到进程“故障”状态，正常情况下这种状态是不应该存在的，因为显然一个事件的状态从“正常”变为“退出”再变为“正常”时是事件正常重启了一次，但是重启后迅速进入“故障”状态，则说明本地系统的运行环境可能存在某种错误，这时告警模块在第S秒发出告警，需要人为关注这一事件，并且告警模块继续监视，直到捕捉到事件恢复正常。

标记：标记事件产生告警，并推送到故障处理流程中进行诊断和处理。如果在很短的时间内故障恢复，则提示值班员该事件在重启时发生了一次故障，等处理完成后返回告警，标记该事件故障消除。(该事件的故障原因需要根据告警关联分析法，故障快速诊断和定位，以及采用其它的分析方法进行诊断。如果由于故障时间非常短造成的没有诊断结果，则在统计分析时标注该事件发生过错误重启过程，在进行风险预警环节提示该事件重启过程有风险。)

告警监视周期：从告警模块监视到该事件恢复“正常”时刻起，进入下一新的告警监视周期。

统计方法：记录事件故障一次，计时器从事件发生“故障”开始计时，直到状态变为“正常”时，计时器确认故障持续时长。

(2)3.故障定位和初步诊断

根据过程监视分析法，可以提高告警正确率，在接收到告警消息之后，就需要进行故障定位和初步诊断。以下是故障定位和诊断的过程。

1>建立典型的故障分析模型进行故障定位：

通过过程监视分析法可以确定告警信息中的故障类型、告警时间、故障级别等信息，因此故障告警的类型很容易被确定，因此故障分析模型首先要按告警信息的类型进行分类，并且不同类型的故障直接采用不同的故障模型，以此来减少分析时间，实现故障快速定位的要求。实际上对集中运维中心的快速定位要求并不是要求像开发人员一样去解决问题，只需要初步确定故障类型、可能引起故障的原因和故障时间就可以了，具体的问题要到故障处理流程中解决，如果定位到日常维护工作，由集中运维中心的运维人员就可以按照知识库中提供的解决方案进行日常维护处理，如果是比较复杂的问题，则直接提交产品生产厂家协同处理，这样可以将任务分级，提高故障处理的效率，节省人力资源。以下是对几种故障模型的说明。

关联分析模型——告警信息存在两个源头，一个是调控中心直接给集中运维中心通过通信协议直接发送各地的系统告警信息，另一个是集中运维中心根据实时采集的系统运行状态采用过程分析法发送告警，事实上这两个告警源所发出的告警信息有可能是同一事件的故障问题，因此为了减少重复告警次数，我们需要对这两个告警源进行确认，如果是同一个事件的故障告警，则只推送一次即可。根据上述要求，我们需要依据告警信息分类的基础上建立事件的关联分析模型，例如实时分析告警中发现一个事件发生了故障，在推送告警之前需要在告警直传中对应类型的事件告警中进行搜索，搜索方式根据类别，告警时标和GPS对时推算同源事件，这样可以实现精确定位，定位后便可以推送告警，并在告警直传模块中标记该事件已经被关注。告警模块同时还要定时扫描调控中心发送过来的所有告警信息是否都一一被标记已经关注或处理中。

递归分析模型——类似于故障树模型，不同的是比故障树要简单，因为我们之前已经对告警信息进行了分类，只需要在同源故障中建立递归分析模型，就可以快速定位故障。递归分析模型主要采用排除法进行分析，例如集中运维中心接收到一条实时告警消息，发现数据中断，于是运维值班员首先查看通信链路是否中断，如果是链路中断，则说明是由链路故障引起和系统事件，标注这两个故障为同一个告警源，当链路恢复后，数据就能够正常显示；如果此时链路是正常的，则查看是否前置数据有问题，如果前置数据没有问题，则继续查看是否画面数据不刷新，人机系统是否正常，依此类推，引起故障的严重原因定位在第一层，逐层分析，最终找到引起故障的原因，进行处理。些类模型主要用于数值类数据的中断、跳变、不刷新分析。

2>故障识别及告警确认

对于设备、应用和通信链路发生故障时，首先根据告警类别采用关联故障模型去搜索故障源，确认同源事件后，对同源事件标注同一个告警ID号。

对于数值类监视数据发生异常时，通过相应的递归模型进行故障定位，定位后如果属于日常故障则由运维值班员依据故障处理预案进行日常维护处理，如果属于较复杂的故障，需要及时联系产品生产商进行协作处理。

当告警发生后都会建立一个故障处理任务，该任务直到故障被消除后才被标记完成状态，任务完成后会发出一个告警消除消息，此消息会加载告警ID号，根据告警ID号，同时消除一个或多个同源告警事件。

(3)故障处理：

A、故障告警接收与建立故障处理任务：

由各调控中心将监视数据发送给集中运维中心进行监视和分析，集中运维中心接收到实时监视数据后首先进行分类处理，采用过程监视法对事件状态进行监视和分析，并对发生的故障进行告警，每个告警信息都有一个ID号，而引起同一个告警的事件源都标记上这个告警ID号。当告警发出时，便建立了一个新的任务，这个任务需要进行人工处理，并对新建任务的受理状态进行流程管控，即对这个故障处理的过程要进行监管。

B、故障处理及状态监视：

产生一个新的告警后，根据告警级别启动不同的处理流程，严重极别的故障必须启动应急预案，如附图2中的流程，预案要求调控中心、集中运维中心和产品生产商之间快速高效地定位故障并协同处理，边处理边通告，及时解除对系统运行造成重大的影响的事故。如果是日常维护流程，则可以根据故障分析模型进行故障诊断与定位，由运维值班员统一处理，如果在处理过程中遇到较复杂的问题，可以要求产品生产商协同处理，并监视故障处理的时间，如果在规定的时间内无法完成任务或遇到特殊情况需要延时，则请求调控中心是否同意延时处理，如果调控中心同意延时，则由调控中心定义延时时长，如果在延时过程中完成任务，则不影响考评结果，如果仍然无法完成任务则在考评中会考虑处理效率的得分。如果任务在申请延时时未得到调控中心的同意，则该任务由于处理超时则在考评中会在相应项目中酌减。

(4)处理结果确认及评价：

当任务处理完成后，首先要返回告警模块进行标记，提示此事件引起的故障已经消除，并解除告警，即标记同一事件告警ID的故障源解除告警状态，标志该事件已经处理完成，不 存在风险。由集中运维中心提交故障处理结果，由调控中心进行确认。如果遇重大故障需要则由集中运维中心会同产品生产商共同提交重大故障的报告，并由调控中心根据处理时间，响应速度，处理结果及服务态度四个项目进行打分，最终的得分计入当月的考评。

运维服务评价指标：

集中运维工作的考评总分共计20分，按照下述表3定义的标准由调控中心进行打分。单次故障的处理结果进行累计得到月度考评结果，提交上级主管部门审核后公示。

表3 运维服务评价指标

本发明提供的一种基于过程监视的集中运维故障闭环处理方法及其系统，在集中运维模式下对智能电网调度控制系统监视信息进行分类，对系统的运行状态的变化过程进行分析，正确触发告警，降低告警误报率，对监视信息的分类，根据发生的故障对系统产生的影响程度进行分级告警，采用典型的故障分析模型对故障进行初步诊断，每个告警事件建立一个新任务，该任务即对告警事件进行处理，并对处理过程进行实时跟踪，对故障处理超时、延时等情况进行管控，直至任务完成后返回消除告警事件，生成故障报告，提交调控中心，并为调控中心提供整体运维服务评价平台，形成从故障发现、故障诊断到故障处理再到处理结果反馈的闭环机制，建立完整的系统状态过程监视、故障告警和故障处理的流程；同时建立故障信息知识库，为运行维护人员提供故障诊断的辅助手段，减少人为误操作对系统产生的额外影响。

本发明实现对国调、分调及省调智能电网调度控制系统的软、硬件集中监视、集中维护、集中管理；提供高效的远程维护技术手段，协助各地调度自动化部门快速诊断、处理系统应用软件的异常和故障；建立与生产厂家、科研机构和检测中心的联动接口，为科研开发、仿 真试验及系统检测提供了技术支撑；建立厂家横向联动机制，大大突显了集中运维系统应急响应的优越性。加强智能电网调度技术支持系统的统一运维管理，规范调度技术支持系统运维工作流程，保障调度技术支持系统安全可靠运行，提高调度技术支持系统整体运维水平，统一监视调度自动化系统运行的关键设备、数据和软件功能，能及时发现系统运行问题，减少问题造成的影响，为各级调度中心提供更好的运维技术服务。

除非另外具体陈述，术语比如处理、计算、运算、确定、显示等等可以指一个或更多个处理或者计算系统、或类似设备的动作和/或过程，所述动作和/或过程将表示为处理系统的寄存器或存储器内的物理(如电子)量的数据操作和转换成为类似地表示为处理系统的存储器、寄存器或者其他此类信息存储、发射或者显示设备内的物理量的其他数据。信息和信号可以使用多种不同的技术和方法中的任何一种来表示。例如，在贯穿上面的描述中提及的数据、指令、命令、信息、信号、比特、符号和码片可以用电压、电流、电磁波、磁场或粒子、光场或粒子或者其任意组合来表示。

应该明白，公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好，应该理解，过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素，并且不是要限于所述的特定顺序或层次。

在上述的详细描述中，各种特征一起组合在单个的实施方案中，以简化本公开。不应该将这种公开方法解释为反映了这样的意图，即，所要求保护的主题的实施方案需要清楚地在每个权利要求中所陈述的特征更多的特征。相反，如所附的权利要求书所反映的那样，本发明处于比所公开的单个实施方案的全部特征少的状态。因此，所附的权利要求书特此清楚地被并入详细描述中，其中每项权利要求独自作为本发明单独的优选实施方案。

本领域技术人员还应当理解，结合本文的实施例描述的各种说明性的逻辑框、模块、电路和算法步骤均可以实现成电子硬件、计算机软件或其组合。为了清楚地说明硬件和软件之间的可交换性，上面对各种说明性的部件、框、模块、电路和步骤均围绕其功能进行了一般地描述。至于这种功能是实现成硬件还是实现成软件，取决于特定的应用和对整个系统所施加的设计约束条件。熟练的技术人员可以针对每个特定应用，以变通的方式实现所描述的功能，但是，这种实现决策不应解释为背离本公开的保护范围。

上文的描述包括一个或多个实施例的举例。当然，为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的，但是本领域普通技术人员应该认识到，各个实施例可以做进一步的组合和排列。因此，本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围 内的所有这样的改变、修改和变型。此外，就说明书或权利要求书中使用的术语“包含”，该词的涵盖方式类似于术语“包括”，就如同“包括，”在权利要求中用作衔接词所解释的那样。此外，使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。

最后应当说明的是：以上实施例仅用以说明本发明的技术方案而非对其限制，尽管参照上述实施例对本发明进行了详细的说明，所属领域的普通技术人员依然可以对本发明的具体实施方式进行修改或者等同替换，这些未脱离本发明精神和范围的任何修改或者等同替换，均在申请待批的本发明的权利要求保护范围之内。

Claims (8)

1.一种基于过程监视的集中运维故障闭环处理方法，所述方法用于智能电网调度控制系统远程集中运维，其特征在于，所述方法包括下述步骤：

(1)监视数据源：包括处理数据源和过程监视故障分析；

(2)故障诊断：包括故障定位和初步诊断；

(3)故障处理：监管故障处理的状态；

(4)故障处理结果的确认和评价。

2.如权利要求1所述的集中运维故障闭环处理方法，其特征在于，所述步骤(1)中，处理数据源包括：

定义告警信息的类型：

1)监视数据源分类：包括电网重要监视数据、设备运行状态、应用运行状态、网络通信状态和本地机房环境监视数据；

2)告警数据源包括：

①调控中心直接转发的告警直传数据：包括设备运行状态故障、应用运行状态故障和网络通信状态故障；

②集中运维中心本地监视到的故障进行实时告警：包括电网重要监视数据越限、传输数据中断、跳变、不刷新、应用故障超时、链路中断超时、本地机房环境异常、远程浏览中断超时、数据网中断和热线电话紧急告警；其中传输数据中断和跳变按照监视数据源类型细分到下一个级别；

③根据历史数据进行分析的系统风险告警：包括系统资源重载、应用故障率越限、应用持续故障时间越限、传输数据中断次数越限、数值数据连续跳变、系统更新的持续时间越限、CORE文件过多和进程连续产生CORE文件；

④故障处理流程监视到的流程告警信息：包括故障处理超时告警、故障处理延时警告和故障处理结果评价不合格告警；

根据告警信息类别，进行故障分级和定义响应时间：

故障级别包括：

I级：属于紧急响应；其具体现象为：智能电网调度控制系统崩溃导致业务停止和数据丢失，其对应的响应时间为：启动紧急处理预案，并在10分钟内提交故障处理方案；

II级：属于故障处理；其具体现象为：出现部件失效、系统性能下降但能正常运行，不影响正常业务运作；其对应的响应时间为：协同产品生产商，并在1小时内提交故障处理方案；

III级：属于常规维护；其具体现象为：出现系统报错或警告，但业务系统能继续运行且性能不受影响；其对应的响应时间为：先由集中运维中心进行故障定位和处理，并在6小时内提交故障处理方案。

3.如权利要求1所述的集中运维故障闭环处理方法，其特征在于，所述步骤(1)中，过程监视故障分析包括下述情况：

<1>正常-故障-正常：

方式：理想状态下采集到上述三个状态过程的最短时间为15s，即在15s内采到一次故障状态；实际情况是事件从正常变为故障后，集中运维系统中的告警模块开始每5秒连续采集事件的状态，在300秒周期内时刻S监视到事件状态由故障又变回到正常状态时，不发送告警信息；

标记：不标记：

告警监视周期：从S时刻起进入下一新的告警监视周期：

统计方式：记录事件故障一次，同时故障恢复一次：从监视到故障时刻起，集中运维系统中的计时器开始记录故障时间，直到状态变为正常时，计时器确认故障持续时长；

<2>正常—持续故障:

方式：事件状态从正常变为故障后，如果在300秒内事件状态不发生变化，而持续保持故障状态，则说明事件在最大监视周期时间内出现故障，且没有自行恢复的能力，为系统在第300秒时发出的告警；

标记：事件产生告警，并推送到故障处理流程中进行诊断和处理；等处理完成后返回告警，标记事件故障消除；

告警监视周期：告警模块每5秒继续采集状态，直到采集到正常时，则开始进入下一个新事件的监视周期；

统计方式：记录事件故障一次：从监视到故障时刻起，计时器开始记录故障时间，直到状态变为正常时，计时器确认故障持续时长；

<3>正常-故障-退出：

方法：事件状态从正常变为故障后，如果在300秒内时刻S监视到事件状态由故障又变为退出状态时，说明事件在300秒内出现故障，标志事件处于故障状态中，并发出告警，报告值班人员事件发生故障并且系统无法自愈，需要人为参与故障处理；

标记：事件产生告警，并推送到故障处理流程中进行诊断和处理；等处理完成后返回告警，标记该事件故障消除；

告警监视周期：集中运维系统中的告警模块每5秒继续采集状态，直到采集到正常时，则开始进入下一个新事件的监视周期；

统计方法：记录事件故障一次：从监视到故障时刻起，计时器开始记录故障时间，直到状态变为正常时，计时器确认故障持续时长；

<4>正常-(故障-退出：即连续闪变5次)-异常，即非正常永久退出：

方式：当系统发生故障时，集中运维系统监视模块首先将相关进程重启，如果连续重启5次都失败，事件最终显示异常状态，即状态从故障到退出闪变5次，则监视模块放弃将相关进程重启，永久退出；如果在300秒内某时刻S监视到事件状态变成由正常或故障变成异常时，则在S秒时发出告警，说明事件发生异常，需要人工处理才能重新恢复该事件正常运行；

标记：事件产生告警，并推送到故障处理流程中进行诊断和处理；等处理完成后返回告警，标记事件故障消除；

告警监视周期：等故障处理流程返回事件故障被消除后，确认事件恢复正常时，开始进入下一个新事件的监视周期；

统计方式：记录事件异常一次：从监视到异常时刻起，计时器开始记录故障时间，直到状态变为正常时，计时器确认故障持续时长；

<5>正常-退出-正常：

方式：某事件状态从正常变为退出后，从退出时刻开始，告警模块在后续时间内第S秒监视到事件状态恢复正常运行，系统不发出告警；

标记：不标记；

告警监视周期：从S时刻起进入下一新的告警监视周期；

统计方式：记录事件重新启动一次；计时器不统计故障时间；

<6>正常-退出-故障：

方式：事件状态从正常变为退出，从退出时刻开始，告警模块在后续时间内第S秒时监视到进程故障状态，告警模块在第S秒发出告警，需要人为关注此事件，并且告警模块继续监视，直到捕捉到事件恢复正常；

标记：标记事件产生告警，并推送到故障处理流程中进行诊断和处理；如果在300秒内故障恢复，则提示事件在重启时发生一次故障，处理完成后返回告警，标记该事件故障消除；

告警监视周期：从集中运维系统中的告警模块监视到事件恢复正常时刻起，进入下一新的告警监视周期；

统计方式：记录事件故障一次，集中运维系统中的计时器从事件发生故障开始计时，直到状态变为正常时，集中运维系统中的计时器确认故障持续时长。

4.如权利要求1所述的集中运维故障闭环处理方法，其特征在于，所述步骤(2)的故障诊断包括下述步骤：

1>建立故障分析模型进行故障定位，包括：

关联分析模型：根据告警信息的两个源头建立事件的关联分析模型，所述告警信息的两个源头包括调控中心直接给集中运维中心通过通信协议直接发送各地的系统告警信息和集中运维中心根据实时采集的系统运行状态采用过程分析法发送的告警信息；

递归分析模型：在同源故障中建立递归分析模型；所述递归分析模型采用排除法进行分析；

2>故障识别及告警确认，包括：

对于设备、应用和通信链路发生故障时，首先根据告警信息的类型采用关联故障模型去搜索故障源，确认同源事件后，对同源事件标注同一个告警ID号；

对于数值类监视数据发生异常时，通过相应的递归模型进行故障定位，定位后如果属于日常故障则由运维值班员依据故障处理预案进行日常维护处理，如果属于较复杂的故障，需要及时联系产品生产商进行协作处理；

当告警发生后建立故障处理任务，所述故障处理任务直到故障被消除后才被标记完成状态，任务完成后会发出一个告警消除消息，此消息会加载告警ID号，根据告警ID号，同时消除一个或多个同源告警事件。

5.如权利要求1所述的集中运维故障闭环处理方法，其特征在于，所述步骤(3)的故障处理包括下述步骤：

A、接收故障告警并建立故障处理任务；

B、故障处理及状态监视。

6.如权利要求5所述的集中运维故障闭环处理方法，其特征在于，所述步骤A包括：由调控中心将监视数据实时发送给集中运维中心，集中运维中心接收到实时监视数据后首先进行分类处理，采用过程监视对事件状态进行监视和分析，并对发生的故障进行告警；

每个告警信息对应一个ID号，引起同一个告警的事件源均标记上述告警ID号；当告警发出时，建立新的处理任务，并对新建处理任务的受理状态进行流程管控。

7.如权利要求5所述的集中运维故障闭环处理方法，其特征在于，所述步骤B包括：产生新的告警后，根据告警级别启动不同的处理流程，严重极别的故障启动应急预案，所述应急预案要求调控中心、集中运维中心和产品生产商之间定位故障并协同处理，边处理边通告，及时解除对智能电网调度控制系统运行造成重大的影响的事故；

如果是日常维护流程，则根据故障分析模型进行故障诊断与定位，由运维值班员统一处理；

如果在处理过程中遇到较复杂的问题，要求产品生产商协同处理，并监视故障处理的时间；

如果在规定的时间内无法完成任务或需要延时，则请求调控中心是否同意延时处理，如果调控中心同意延时，则由调控中心定义延时时长，如果在延时过程中完成任务，则不影响考评结果，如果无法完成任务则在考评中会考虑处理效率的得分；如果任务在申请延时时未得到调控中心的同意，则任务由于处理超时则在考评中评分酌减。

8.如权利要求1所述的集中运维故障闭环处理方法，其特征在于，所述步骤(3)包括：当故障任务处理完成后，返回告警模块进行标记，提示此事件引起的故障已经消除，并解除告警，即标记同一事件告警ID的故障源解除告警状态，标志该事件已经处理完成，不存在风险；由集中运维中心提交故障处理结果，由调控中心进行确认；

如果遇重大故障则由集中运维中心同产品生产商共同提交重大故障的报告，并由调控中心根据处理时间，响应速度，处理结果及服务态度四个项目进行打分，最终得分计入当月的考评。