一种基于保护组的批量倒换与回切方法和装置

技术领域

本发明涉及网络管理技术领域，特别是涉及一种基于保护组的批量倒换与回切方法和装置。

背景技术

随着传输网络规模越来越大，网管系统中设备越来越多，业务数也逐渐增加。针对保护组的倒换与回切操作也越来越多。但目前各大厂商均只提供了单次保护组倒换操作和回切流程，在单个保护组倒换时需要人为的去分析倒换场景，判断是否需要可进行倒换与回切。针对大量保护组需要倒换场景时需要更多的人力以及时间去逐个分析与操作，对后续倒换场景与流程的优化缺少一个标准的报表统计。而目前随着通信设备集约化的进程，对多线程、高并发、自动场景分析的标准化、智慧型、可拓展的倒换流程需求愈发迫切。

现有的单次保护组倒换操作和回切流程具有以下缺点：

(1)手动单条保护组的倒换，效率比较低，需要更多的人工与时间。

(2)缺少保护组可执行倒换/回切的一个标准，均由人工去判断，按照经验分析存在某些场景时不能进行倒换与回切。

(3)多次执行操作后，缺少一个报表进行复盘，分析原因从而进行对流程和场景的优化。

有鉴于此，如何克服现有技术所存在的缺陷，解决现有的单次保护组倒换操作和回切流程所存在的问题，是本技术领域待解决的难题。

发明内容

针对现有技术中的缺陷或改进需求。本发明提供一个定时可批量执行保护倒换与回切的任务，设计一个可配置的保护组倒换前后状态分析的规则，根据该规则在倒换前后自动分析当前保护组的状态以及给予一个可执行倒换与回切的状态。对各倒换任务执行和回切中的状态分析结论以及后续操作进行统计与存储，提供可导出报表和查看的功能。

本发明实施例采用如下技术方案：

第一方面，本发明提供了一种基于保护组的批量倒换与回切方法，包括：

创建定时的批量保护倒换与回切任务；

获取保护倒换前状态分析规则；

进行保护倒换前状态分析，执行批量保护倒换；

获取保护倒换后状态分析规则；

进行保护倒换后状态分析，判断保护倒换是否成功，若未成功则执行批量保护回切。

进一步的，所述创建定时的批量保护倒换与回切任务具体包括：

创建一个定时的批量保护倒换与回切任务，选择需要倒换的单个或者多个保护组，选择定时执行，且选择执行时间，并选择性勾选二次确认和自动回切。

进一步的，所述获取保护倒换前状态分析规则具体包括：

获取保护倒换前的状态分析规则中的第一告警规则；

获取保护倒换前的状态分析规则中的第一性能规则；

获取保护倒换前的状态分析规则中的第一保护组配置规则。

进一步的：

所述第一告警规则包括第一异常告警规则，当保护组对应设备端口的告警信息与所述第一异常告警规则相匹配时，判断为不适合进行倒换；

所述第一性能规则包括对性能门限值的判断，当保护组对应设备端口的性能值相较于所述性能门限值过低、过高或丢失时，判断为不适合进行倒换；

所述第一保护组配置规则包括对原宿端口配置信息是否一致的判断，当保护组对应设备的原宿端口的配置信息不一致时，判断为不适合进行倒换。

进一步的，所述进行保护倒换前状态分析具体包括：

获取保护组对应设备端口的告警信息，与获取的所述第一告警规则进行匹配计算，若存在与所述第一告警规则中第一异常告警规则相匹配的告警信息，则判断为不适合进行倒换，否则判断为适合进行倒换；

获取保护组对应设备端口的性能值，与获取的所述第一性能规则中的性能门限值进行比较，判断是否有性能值过低、过高或丢失的现象，若存在任一现象，则判断为不适合进行倒换，否则判断为适合进行倒换；

若当前保护组为双端的保护组，则根据所述第一保护组配置规则比较原宿端口的各项配置信息，若存在任意一项配置信息不一致，则判断为不适合进行倒换，否则判断为适合进行倒换；

当所述第一告警规则、所述第一性能规则、所述第一保护组配置规则均判断为适合进行倒换时，认定对应保护组可以执行保护倒换，否则认定对应保护组不可以执行保护倒换。

进一步的，所述执行批量保护倒换具体包括：针对当前遍历的且经过分析认定可以执行保护倒换的保护组，进行保护倒换，发送强制倒换的命令给设备，并开启监听告警与性能流程。

进一步的，所述获取保护倒换后状态分析规则具体包括：

获取保护倒换后的状态分析规则中的第二告警规则；

获取保护倒换后的状态分析规则中的第二性能规则；

获取保护倒换后的状态分析规则中的第二保护组配置规则。

进一步的，所述进行保护倒换后状态分析，判断保护倒换是否成功，若未成功则执行批量保护回切具体包括：

获取保护组对应设备端口的告警信息，与获取的所述第二告警规则进行匹配计算，若超时未收到告警信息或收到的告警信息存在与所述第二告警规则中第二异常告警规则相匹配的告警信息，则判断为倒换失败，否则判断为倒换成功；

获取保护组对应设备端口的性能值，与获取的所述第二性能规则中的性能门限值进行比较，判断是否有性能值过低、过高或丢失的现象，若存在任一现象，则判断为倒换失败，否则判断为倒换成功；

若当前保护组为双端的保护组，则根据所述第二保护组配置规则比较原宿端口的各项配置信息，若存在任意一项配置信息不一致，则判断为倒换失败，否则判断为倒换成功；

当所述第二告警规则、所述第二性能规则、所述第二保护组配置规则均判断为倒换成功时，认定对应保护组的保护倒换成功，否则认定对应保护组的保护倒换失败，失败时，若事先勾选自动回切，则自动执行回切操作。

进一步的，还包括：针对保护倒换前以及保护倒换后的保护组状态出具分析报告，所述分析报告详细记录保护组状态分析中引起保护组不能进行倒换的各项值和相关结论。

另一方面，本发明提供了一种基于保护组的批量倒换与回切装置，具体为：包括至少一个处理器和存储器，至少一个处理器和存储器之间通过数据总线连接，存储器存储能被至少一个处理器执行的指令，指令在被处理器执行后，用于完成第一方面中的基于保护组的批量倒换与回切方法。

与现有技术相比，本发明的有益效果在于：

(1)提供自动批量可执行的任务来进行倒换和回切。现有技术方案中执行倒换和回切需要人工值守，维护人员按时按点的操作，需要大量的人力和工时。而本发明的方案只需要新建一个定时的任务，设置定时或者立即执行任务，倒换任务则会定时自动执行。

(2)建立一套标准的分析规则，自动分析判断当前保护组状态。现有方案中对结论的判断需要人工来处理，而本发明的方案在设置了标准的分析规则后，后台自动进行判断，并存储。

(3)执行过程中保存各个流程的分析结论和对应操作，提供可回溯的报表，可用于后期复盘，分析并优化标准的分析规则。现有方案中无法提供一个可回溯可复盘的数据，用于优化操作或者优化告警性能信息等，而本发明的方案提供了过程报表，存储各流程节点的分析详情和操作，可用于复盘分析。

(4)分析规则通过脚本配置的方式，具有通用性和可扩展性，适合不同的场景。现有方案中如果存在不同厂商的设备，则需要各个方面专业维护人员，对不同场景下的倒换与回切中的告警与性能进行分析，缺少不同场景的通用性。而本发明的方案则是通过脚本配置的方式，将不同场景下的配置以一个通用的方式进行配置，在具体分析时则会通过对配置的解析，做出相对应的判断结论。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为本发明实施例1提供的数据字典的设计示意图；

图2为本发明实施例1提供的一种基于保护组的批量倒换与回切方法的流程图；

图3为本发明实施例1提供的步骤100扩展流程图；

图4为本发明实施例1提供的步骤200扩展流程图；

图5为本发明实施例1提供的步骤300扩展流程图；

图6为本发明实施例1提供的步骤400扩展流程图；

图7为本发明实施例1提供的步骤500扩展流程图；

图8为本发明实施例4提供的智能批量保护倒换与回切时序图；

图9为本发明实施例5提供的一种基于保护组的批量倒换与回切装置结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

本发明是一种特定功能系统的体系结构，因此在具体实施例中主要说明各结构模组的功能逻辑关系，并不对具体软件和硬件实施方式做限定。

此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合，各个步骤在符合逻辑、不冲突的情况下也可以调换先后顺序。下面就参考附图和实施例结合来详细说明本发明。

另外还需先说明的是，批量主要是指用户的操作，选取很多个保护组创建出一个或者多个任务，每个任务存在数个保护组。在执行任务的时候，是采用计算机多线程、高并发的方式，近乎同时执行倒换流程。而不是需要人为的一个一个的执行。在本文中解释常用单个保护组流程举例，实际上是多个保护组同时进行。另外，现有的批量任务执行，仅仅只是批量下发命令，这会产生很多不可控的风险，例如一些设备具备倒换条件，会因批量操作而出现异常。本发明提供的批量倒换则不会存在这个问题。

本发明为了解决背景技术中的问题，提出如下几点方案：

(1)针对同类型、同场景的保护组建立一个批量任务，设置任务的相关信息应用于任务中所有保护组倒换流程中。

(2)采用多线程、高并发的自动调度方案，建立线程守护，保证各保护组独立完成倒换流程。

(3)优化倒换流程，进行倒换前后场景，保护组的状态分析。构建可扩展的、基于配置文件的状态分析规则体系，使得流程的适应性和扩展性更强。

(4)自动记录倒换流程中各个环节的分析和执行结果，输出标准化的报表。用于后续复盘以及流程优化，是流程更加智能和效率。

实施例1：

本发明实施例中，针对批量保护组的保护倒换设计定时任务和流程，需要满足如下几个设计要求：

(1)批量保护组的选取支持多维度的过滤选择，按网元设备、逻辑域、线缆、保护组等维度过滤选择。

(2)因为保护组的保护倒换操作为高危操作，需要自定义来确定是否进行二次确认。

(3)任务可分为立即执行和定时执行。

(4)任务可按照时间需求指定是否自动回切。

本实施例中定时批量任务的设计为了满足如上需求，采用如图1所示的数据字典的设计。其中，任务的属性包括任务ID、任务名称、任务类型、任务状态、二次确认、执行时间、创建时间、创建者、关联任务、自动回切、保护组信息；每项属性又包括对应的数据类型、格式、长度以及属性说明，例如任务ID的数据类型为数字、格式为1-9999、长度为对应长度(因未给出具体任务ID，所以表中长度空着显示)、属性说明为数据库自增ID；其它属性的数据类型、格式、长度以及属性说明参见表格，在此就不一一赘述。

基于上述设计，如图2所示，本发明实施例提供一种基于保护组的批量倒换与回切方法，该方法包括如下步骤。

步骤100：创建定时的批量保护倒换与回切任务。

步骤200：获取保护倒换前状态分析规则。

步骤300：进行保护倒换前状态分析，执行批量保护倒换。

步骤400：获取保护倒换后状态分析规则。

步骤500：进行保护倒换后状态分析，判断保护倒换是否成功，若未成功则执行批量保护回切。

采用上述步骤，即可实现自动批量执行保护倒换和保护回切的目的。

具体的，如图3所示，对于步骤100，本实施例可将其扩展为如下步骤。

步骤101：创建一个定时的批量保护倒换与回切任务，选择需要倒换的单个或者多个保护组，选择定时执行，且选择执行时间，并选择性勾选二次确认和自动回切。需说明，该步骤中，二次确认为可选操作，由操作人员自定义是否选取该操作。

步骤102：逐个遍历任务中的保护组信息，在距离任务的定时执行时间小于预设的二次确认提前时间时，进行二次确认操作。该步骤对应于选取了二次确定后的步骤，例如预设的二次确认提前时间为5分钟，那么在距离定时任务执行小于5分钟，通知用户界面弹窗显示，进行二次确认操作。需说明，二次确认主要是针对存在高风险的保护组，监控任务会逐个遍历任务中的保护组信息，在距离任务的定时执行时间小于预设的二次确认提前时间时，进行二次确认操作。同时在创建结束时候会立即开始逐个对任务中保护组的二次确认操作进行计算和监控。任务中的部分保护组可能存在高风险，这个由维护人员进行判定。如果存在风险，在执行前需要二次确认则会设置这个二次确认操作。一旦任务创建后，会直接对二次确认信息进去监控。二次确认的结果会影响当前保护组倒换流程后续的执行。如果二次确认的结果为否，在定时时间到了之后，也不会执行该保护组的倒换。该步骤为非必须，只有设置了二次确认的才会进行。

如图4所示，对于步骤200，本实施例可将其扩展为如下步骤。

步骤201：获取保护倒换前的状态分析规则中的第一告警规则。在本实施例的该步骤中，因为不同厂家对于告警的描述可能存在不一样，但是在同一个网管内会将设备抽象成网管内的网元，盘子会抽象成单盘，相关业务均会按照网管内的设计方式分别设置保护类型与告警号，而且即使是在同一个厂家中，不同的设备所表现出来的告警也不是一样的，因加载告警规则需要按照对应的设备和业务类型进行区分加载，因此在获取告警规则时，会以当前保护组的网元类型、单盘类型、保护类型为条件，从告警规则的配置脚本中获取相对应的告警规则。该告警规则即包含告警正常的规则，也包含告警异常的规则。通常在倒换前分析规则只配置告警异常的规则即可，如果存在异常则不建议进行保护倒换操作。需说明，本实施例将保护倒换前的告警规则称为第一告警规则，将保护倒换后的告警规则称为第二告警规则，以示区分。在本步骤201中，涉及的告警规则是第一告警规则，也即保护倒换前的告警规则。本实施例中的告警规则的具体设计参考实施例2，在此不做赘述。

步骤202：获取保护倒换前的状态分析规则中的第一性能规则。在本实施例的该步骤中，性能主要是基于设备端口，从设备上获取性能时不同的设备大多数获取的性能类型是一样的，但是也存在少量的差异。因此获取性能规则时需要以设备和端口类型作为条件进行获取。同一个性能类型可能存在几种性能规则，例如输入和输出光功率，存在输入/输出的过低/过高/丢失门限值。因此在获取规则时主要是获取当前业务关联的设备端口的性能值和其计算方法。需说明，本实施例将保护倒换前的性能规则称为第一性能规则，将保护倒换后的性能规则称为第二性能规则，以示区分。在本步骤202中，涉及的性能规则是第一性能规则，也即保护倒换前的性能规则。本实施例中的性能规则的具体设计参考实施例2，在此不做赘述。

步骤203：获取保护倒换前的状态分析规则中的第一保护组配置规则。在本实施例的该步骤中，保护组配置规则中的配置字段主要是网管中根据实际业务保护组情况抽象出来的字段，按照实际情况进行配置，例如双端保护组的原宿端口中的端口属性内的恢复方式需要保持一致。需说明，本实施例将保护倒换前的保护组配置规则称为第一保护组配置规则，将保护倒换后的保护组配置规则称为第二保护组配置规则，以示区分。在本步骤203中，涉及的保护组配置规则是第一保护组配置规则，也即保护倒换前的保护组配置规则。本实施例中的保护组配置规则的具体设计参考实施例2，在此不做赘述。

基于上述设计，本实施例所述第一告警规则包括第一异常告警规则，当保护组对应设备端口的告警信息与所述第一异常告警规则相匹配时，判断为不适合进行倒换；所述第一性能规则包括对性能门限值的判断，当保护组对应设备端口的性能值相较于所述性能门限值过低、过高或丢失时，判断为不适合进行倒换；所述第一保护组配置规则包括对原宿端口配置信息是否一致的判断，当保护组对应设备的原宿端口的配置信息不一致时，判断为不适合进行倒换。需说明，本实施例规则中门限值有三个值：过高门限值、过低门限值、丢失门限值，过高：指的是某个值高于某一个阈值，则表明这个值太大，会产生一个性能过高的告警；正常：指的是某个值在过高和过低阈值之前，表明这个值比较正常，不会产生任何告警；过低：指的是低于过低阈值，高于丢失的阈值，则表明该值比较小，会产生性能过低的告警；丢失：低于或等于丢失的阈值，该值不具备实际价值，则表明该值非常小，几乎在正常场景中可用忽略，此时会产生性能丢失的告警。

如图5所示，对于步骤300，本实施例可将其扩展为如下步骤。

步骤301：获取保护组对应设备端口的告警信息，与获取的所述第一告警规则进行匹配计算，若存在与所述第一告警规则中第一异常告警规则相匹配的告警信息，则判断为不适合进行倒换，否则判断为适合进行倒换。本实施例的该步骤中，从设备上或者存量库中获取保护组对应设备端口的告警信息，与步骤201中获取的第一告警规则进行计算，如果经过匹配计算存在与第一异常告警规则的相符合的告警，则不适合进行倒换，如果不存在则适合进行倒换。

步骤302：获取保护组对应设备端口的性能值，与获取的所述第一性能规则中的性能门限值进行比较，判断是否有性能值过低、过高或丢失的现象，若存在任一现象，则判断为不适合进行倒换，否则判断为适合进行倒换。本实施例的该步骤中，从设备上或者存量库中获取保护组对应设备端口的输入和输出光功率，并与步骤202中获取的门限值进行比较，判断是否有门限过低、过载、光丢失的现象，存在符合条件得项目，则不适合进行倒换，即如果存在性能值光功率过低、过载或者光丢失的现象，则均不适合进行倒换，该比较项目中没有符合条件项则适合进行倒换。

步骤303：若当前保护组为双端的保护组，则根据所述第一保护组配置规则比较原宿端口的各项配置信息，若存在任意一项配置信息不一致，则判断为不适合进行倒换，否则判断为适合进行倒换。本实施例的该步骤中，如果当前保护组为单站的保护组可以忽略此步骤，如果为双端的则比较原宿端口的保护模式、恢复模式、等待恢复时间、拖延时间等配置信息是否一致，各项检查配置一致时，则适合进行倒换，存在一项配置检查项不一致，则不适合进行倒换。

步骤304：当所述第一告警规则、所述第一性能规则、所述第一保护组配置规则均判断为适合进行倒换时，认定对应保护组可以执行保护倒换，否则认定对应保护组不可以执行保护倒换。本实施例的该步骤中，需要综合上述步骤301、步骤302、步骤303的分析结论进行最终判断，只有以上三个步骤的规则同时满足进行保护倒换的条件才能得出可进行保护倒换结论，至少一项不符合则不可进行保护倒换。该步骤在最终确认后，还将分析的详细信息存储入库，便于后续回溯分析。在步骤304的最终判断为认定对应保护组可以执行保护倒换时，所述执行批量保护倒换具体包括如下步骤305。

步骤305：针对当前遍历的且经过分析认定可以执行保护倒换的保护组，进行保护倒换，发送强制倒换的命令给设备，并开启监听告警与性能流程。需说明的是，监听告警与性能流程即向网管采集服务订阅告警和性能值，间接从设备增量获取发送倒换命令后设备的告警和性能，以及网管由性能值或者设备状态分析计算出来的告警信息。即：采集服务一直接收着设备主动发送上报的告警，同时也会定时的去同步设备告警和相关性能值。在接收到相关性能值，会按照一定规则计算出新的由网管本身定义的告警信息。当前监听即时向采集服务订阅保护组相关设备的告警与性能信息，增量获取相关信息。

如图6所示，对于步骤400，本实施例可将其扩展为如下步骤。

步骤401：获取保护倒换后的状态分析规则中的第二告警规则。

步骤402：获取保护倒换后的状态分析规则中的第二性能规则。

步骤403：获取保护倒换后的状态分析规则中的第二保护组配置规则。

上述步骤401-403分别获取倒换后的状态分析规则中第二告警规则、第二性能规则、第二配置规则的方式与步骤201-203相似，在此不再赘述。

如图7所示，对于步骤500，本实施例可将其扩展为如下步骤。

步骤501：获取保护组对应设备端口的告警信息，与获取的所述第二告警规则进行匹配计算，若超时未收到告警信息或收到的告警信息存在与所述第二告警规则中第二异常告警规则相匹配的告警信息，则判断为倒换失败，否则判断为倒换成功。

步骤502：获取保护组对应设备端口的性能值，该值在倒换过程中可能会改变，与获取的所述第二性能规则中的性能门限值进行比较，判断是否有性能值过低、过高或丢失的现象，若存在任一现象，则判断为倒换失败，否则判断为倒换成功。

步骤503：若当前保护组为双端的保护组，则根据所述第二保护组配置规则比较原宿端口的各项配置信息，防止在倒换中配置信息发生变化，若存在任意一项配置信息不一致，则判断为倒换失败，否则判断为倒换成功。

上述步骤501-503分别对告警、性能和配置进行分析，其中性能与配置的规则一般与倒换前的分析规则一致，但对于告警规则的倒换，不仅仅多了几个倒换成功的告警，而且可能因为网络问题、设备问题或者其他问题导致倒换后无法获取告警信息，因此会增加超时处理，如果超时未收到告警，则按倒换异常处理，需要进行回切。如此综合三项规则的结论判断当前保护倒换是否成功。并将分析的结论存储入库。需说明，虽然性能与配置的规则一般与倒换前的分析规则一致，但这两个步骤不可去除，必须存在，这是因为倒换操作会影响设备的相关性能值的输出。例如某个倒换失败，可能直接导致设备相关业务异常，从而导致部分性能值输出异常。同时也会存在受设备本身的设置影响，倒换中会将原配置信息修改，所以这两步是必须的。也就是说，倒换前和倒换后的判断告警信息规则，不完全一致，例如我们目前场景是从主倒换到备用，在倒换前，无异常告警即可判断可以执行倒换，此时规则主要是配置异常告警，但倒换后的状态，会新增主倒备的告警，和当前备用的告警，只要收到相关的告警即可判断倒换操作成功，但这些告警信息，倒换之前是没有的。

步骤504：当所述第二告警规则、所述第二性能规则、所述第二保护组配置规则均判断为倒换成功时，认定对应保护组的保护倒换成功，否则认定对应保护组的保护倒换失败，失败时，如果当前保护组根据所在的任务中配置了自动执行回切设置，则进行自动执行回切操作，即发送清除倒换操作命令。在一个批量任务中出现部分成功时，仅对失败的保护组进行回切操作。需说明，倒换操作与回切操作，是针对单个保护组进行的，在批量任务中可以存在部分成功和失败，针对失败的部分，如果允许自动回切，则会进行回切操作，回切操作本质是清除倒换，即发送清除倒换命令给设备，或者备用倒换到主用命令。需强调的是，回切主要是针对倒换失败的保护组，而且在创建任务时候设置了允许自动回切，才会进行。保护组倒换是在计算机中多线程、高并发场景中执行，设置同一时间的保护组近乎在同一时间执行，可能会尝试部分成功和失败的倒换操作，此时只针对允许自动回切和倒换失败的保护组进行回切操作。

上述倒换过程中，还针对保护倒换前以及保护倒换后的保护组状态出具分析报告，所述分析报告详细记录保护组状态分析中引起保护组不能进行倒换的各项值和相关结论，以提供可回溯的报表，可用于后期复盘，分析并优化标准的分析规则。

综上所述，本发明实施例提供自动批量可执行的任务来进行倒换和回切。现有技术方案中执行倒换和回切需要人工值守，维护人员按时按点的操作，需要大量的人力和工时。而本发明的方案只需要新建一个定时的任务，设置定时或者立即执行任务，倒换任务则会定时自动执行。本发明实施例建立一套标准的分析规则，自动分析判断当前保护组状态。现有方案中对结论的判断需要人工来处理，而本发明的方案在设置了标准的分析规则后，后台自动进行判断，并存储。本发明实施例执行过程中保存各个流程的分析结论和对应操作，提供可回溯的报表，可用于后期复盘，分析并优化标准的分析规则。现有方案中无法提供一个可回溯可复盘的数据，用于优化操作或者优化告警性能信息等，而本发明的方案提供了过程报表，存储各流程节点的分析详情和操作，可用于复盘分析。本发明实施例分析规则通过脚本配置的方式，具有通用性和可扩展性，适合不同的场景。现有方案中如果存在不同厂商的设备，则需要各个方面专业维护人员，对不同场景下的倒换与回切中的告警与性能进行分析，缺少不同场景的通用性。而本发明的方案则是通过脚本配置的方式，将不同场景下的配置以一个通用的方式进行配置，在具体分析时则会通过对配置的解析，做出相对应的判断结论。

实施例2：

基于实施例1提供的一种基于保护组的批量倒换与回切方法，本实施例2对状态分析规则中告警规则、性能规则、保护组配置规则的配置进行详细说明。

对于告警规则，本实施例在告警规则设计中主要是配置网元类型号、盘类型号、保护类型和告警信息。具体如下文所示。

/>

在服务运行时，会将该脚本提前加载，针对某同一个场景可能存在两份规则，一份正常，一份异常。正常的告警同时是主倒备、备倒主之类的倒换成功的告警。主要用于倒换后的状态分析。另外一份规则则是异常告警，例如上面样例，命令行设备F1KU5中Ok设备的光层保护组中异常的告警设置的有：输入光丢失(ILS,1729)、输入光功率过低(IOP_LOW，698)、输入光功率过高(IOP_HIGHT,906)三种告警。

针对倒换后的正常告警规则配置，可能会配置W_P与P_W即主用倒备用和备用倒主用，其可能如下示例：

/>

对于性能规则，性能规则主要是设计需要计算的性能值与阈值的获取渠道，例如下文示例：

Name为性能名，PMCode为性能码的类型，condition中1为大于，0为小于等于，-1则是按网管内逻辑计算。Value为门限值，如果为65535则表示按网管内设计计算；type为越限类型，1表示过载，0表示丢失，-1表示过低。

如下示例，表示命令行设备的性能规则需要比较PMcode为1046的性能，也就是输出光功率值。该值需要计算过低、过载和丢失三种情况。由于condition与value值为-1，表示均按照网管内的设置的值进行。

如果该项由脚本直接设置，不用网管内的设置条件计算。则按如下设置：

该设置表明性能规则中输出光功率在过载判断中需要将该性能值与门限值25进行判断，如果大于25则判断为过载；在判断光丢失时需要与门限值13进行判断，如果小于或等于13，在判断为光丢失；在判断过低时，需要与门限值20进行判断，如果小于或等于20则判断为过低，在如上三种情况时，对应的分析表中该值项会显示异常黄色。否则会分别显示绿色。

对于保护组配置规则，保护组配置规则主要是针对双端保护组设计的，需要对比保护组原宿两端在网管中的配置属性，如下文示例，需要检查端口中端口属性里面的恢复方式是否一致。

本实施例通过以上三个规则脚本的设置，建立起一套标准的分析规则，自动分析判断当前保护组状态。且分析规则通过脚本配置的方式，具有通用性和可扩展性，适合不同的场景。

实施例3：

在上述实施例1、2提供的基于保护组的批量倒换与回切方法的基础上，本实施例3对如何实现可回溯的报告分析进行详细的举例说明。

本实施例的报告分析主要是对倒换前或者倒换后，即实施例1流程中步骤300和步骤500实施时，针对保护组状态的一个分析报告。该报告详细记录保护组状态分析中引起保护组不能进行倒换的各项值和相关结论。且如果为异常值则为表格为黄色。问题总结主要有：包括正常和异常两种情况，正常时直接显示“正常”字样，且背景为绿色，如果为异常，则会显示具体的异常情况描述，且背景为黄色。(需说明，下面表格中各处绿色黄色是用文字表示，但在实际使用时，是直接使用相应颜色信息进行表示。)

部分场景如下示例：

例1：在步骤300中进行保护倒换前状态分析时，对一个双端的保护组经过保护组状态分析，无异常告警，无性能异常情况以及原宿端配置一致时，报表详细情况中告警规则项应该为空，性能中相关值均正常，且显示绿色，端口配置的两边值应该是相同的。详细的分析详情如下：

例2：在步骤300中进行保护倒换前状态分析时，对一个双端的保护组经过保护组状态分析，存在异常告警，有性能异常情况，原宿端配置不一致时，报表详细情况中告警规则项、性能规则项目、端口配置的两边值应该是不相同的。详细的分析详情如下：

例3：在步骤500中进行保护倒换后状态分析时，主要是针对倒换之后的保护组进行分析，该分析规则比倒换前的告警更加丰富，增加了许多倒换正常的告警，而且可能会存在没有告警的情况。如果存在异常告警或者没有任何告警，主要是没有成功告警，告警规则分析项可确定为倒换失败，需要进行回切。详细的分析详情如下示例。

该实例中没有任何告警，表示在倒换之后指定的时间内，没有获取到任何告警信息，尤其是没有告警成功信息，则告警规则分析部分存在异常，该倒换失败。

例4：与例3不一样的是，如果告警规则中不存在异常告警，且存在倒换成功告警，例如主倒备的告警，则告警规则分析结果为正常，在其他规则也正常时，则问题结论为正常，即倒换成功，不需要进行回切，详细的分析详情如下示例：

通过上述方式，本实施例在执行过程中保存各个流程的分析结论和对应操作，提供可回溯的报表，可用于后期复盘，分析并优化标准的分析规则。

实施例4：

在上述实施例1、2、3提供的基于保护组的批量倒换与回切方法的基础上，本实施例4提供一种基于保护组的批量倒换与回切系统，参考图8所示，系统包括客户端、定时任务系统、采集服务以及设备。

在具体进行操作时，由维护人员在客户端进行创建任务的指令下达，客户端在定时任务系统中创建任务，定时任务系统创建任务成功后，等待定时执行，在定时执行的前一时间段，定时任务系统发出请求二次确认的消息到客户端，由维护人员在客户端对二次确认提示进行二次确认，二次确认后，定时任务系统在定时执行时间获取任务中保护组告警和性能信息(该过程由采集服务向设备获取，任务系统向采集服务同步订阅获取)，定时任务系统获取到信息后，分析倒换前的保护组状态，如果满足要求，就像设备发出保护组倒换命令；之后，定时任务系统再次获取任务中保护组告警和性能信息，然后分析倒换后的保护组状态，如果倒换不成功就向设备发出保护组回切命令。

实施例5：

在上述实施例1提供的基于保护组的批量倒换与回切方法的基础上，本发明还提供了一种可用于实现上述方法及系统的基于保护组的批量倒换与回切装置，如图9所示，是本发明实施例的装置架构示意图。本实施例的基于保护组的批量倒换与回切装置包括一个或多个处理器21以及存储器22。其中，图9中以一个处理器21为例。

处理器21和存储器22可以通过总线或者其它方式连接，图9中以通过总线连接为例。

存储器22作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如实施例1中的基于保护组的批量倒换与回切方法。处理器21通过运行存储在存储器22中的非易失性软件程序、指令以及模块，从而执行基于保护组的批量倒换与回切装置的各种功能应用以及数据处理，即实现实施例1的基于保护组的批量倒换与回切方法。

存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其它非易失性固态存储器件。在一些实施例中，存储器22可选包括相对于处理器21远程设置的存储器，这些远程存储器可以通过网络连接至处理器21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

程序指令/模块存储在存储器22中，当被一个或者多个处理器21执行时，执行上述实施例1中的基于保护组的批量倒换与回切方法，例如，执行以上描述的图2-图7所示的各个步骤。

本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ReadOnlyMemory，简写为：ROM)、随机存取存储器(RandomAccessMemory，简写为：RAM)、磁盘或光盘等。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。