一种异常检测方法与流程

1.本技术涉及通信领域，并且更具体地，涉及一种异常检测方法和装置。


背景技术：

2.随着第五代移动通信技术(5th generation，5g)相关技术的引入，网络变得更加的复杂。网络异常检测功能作为网络运维的核心，在更多的不同场景下面临着巨大的挑战。传统的异常检测通过监控网络的关键kpi来发现异常。然而传统场景假设当前网络中有大量的用户和大量的业务量，因此关键绩效指标(key performance indicator，kpi)(如，成功率，业务量，失败原因等)具有全局统计特性，即可以有效体现当前网络的状态。
3.除了传统的场景，异常检测仍需要支撑5g网络技术带来的更多特殊场景。如灰度验证、秒级监控、新业务上线以及企业级业务场景中，对异常检测提出了更高的要求，在上述场景的异常检测中，检测的颗粒度需要细化到少量用户群甚至单用户群，由于在单个用户或少量用户行为场景下，单个周期的业务数量很少，导致kpi不具备统计规律，此种情况下，传统的异常检测算法几乎无法适用。
4.当前针对单个用户或少量用户的行为场景的方法基本为人工测试和排查，但是这种方法的验证量非常小，而且测试周期很长，无法满足当前的需求，本技术针对上述单个用户或少量用户的行为场景中出现的问题，提出了一种异常检测方法。


技术实现要素：

5.本技术提供一种异常检测方法，通过使用状态检测模型，对单用户或少量用户场景下的kpi进行系统检测并进一步进行异常判断，克服了单用户或少量用户场景下的kpi无统计特性的问题，有利于提高系统检测的准确性，避免了误判。
6.第一方面，提供了一种异常检测方法，该方法包括：获取第一时刻对应的至少一个关键性能指标kpi，其中，所述kpi包括尝试次数、成功次数或失败次数中的至少一项；根据所述至少一个kpi和状态检测模型，对所述第一时刻的系统状态进行系统异常判断，所述异常判断的结果包括正常状态和异常状态，其中，所述状态检测模型包括不同的定义系统状态，所述正常状态对应的定义系统状态包括：系统正常或偶发异常；其中，所述状态检测模型是基于至少一个训练kpi和多个初始状态参数值训练得到的，所述初始状态参数值包括初始泊松分布参数值和初始状态转移概率值，所述初始状态参数值为根据业务逻辑定义的对应于不同的定义系统状态的初始值。
7.通过使用状态检测模型，对单用户或少量用户场景下的kpi进行系统检测进一步进行异常判断，克服了单用户或少量用户场景下的kpi无统计特性的问题，有利于提高系统检测的准确性，避免了误判。
8.结合第一方面，在第一方面的某些实现方式中，所述至少一个kpi与至少一个泊松分布参数一一对应，所述不同的定义系统状态对应于所述至少一个泊松分布参数的不同的参数值，所述第一时刻的定义系统状态转移到另一定义系统状态的转移概率对应于第一状
态转移概率值，定义系统状态之间的转移概率对应于不同的状态转移概率值。
9.本技术实施例的状态检测模型基于泊松分布参数和状态转移概率值，对在线数据进行检测，可以提高系统状态检测的准确性。
10.结合第一方面，在第一方面的某些实现方式中，所述状态检测模型为泊松隐藏马科夫phmm模型。
11.本技术实施例的模型符合泊松分布，更加符合现实情况，本技术实施例的模型可以采用hmm模型，或者也可以采用神经网络模型等。
12.结合第一方面，在第一方面的某些实现方式中，所述状态转移概率包括以下任意两种定义系统状态之间的转移概率：系统正常、偶发异常、持续异常、系统宕机。
13.本技术实施例的模型可以定义不同的系统状态，不同的系统状态之间有不同的状态转移概率，通过将状态转移概率同时进行考虑，可以提高模型检测的准确性，避免误判。
14.结合第一方面，在第一方面的某些实现方式中，所述定义系统状态包括系统正常、偶发异常、持续异常、系统宕机，以及所述根据所述至少一个kpi和状态检测模型，对所述第一时刻的系统状态进行系统异常判断包括：将所述至少一个kpi输入所述状态检测模型；通过维特比viterbi算法对输入所述状态检测模型的所述至少一个kpi进行解码，并对所述第一时刻的系统状态进行系统异常判断。
15.可选地，本技术实施例中的模型可以为4阶的phmm模型，此时，可以对模型检测之后的数据进行解码得到系统的定义系统状态，从而可以进一步判断系统是否异常。
16.结合第一方面，在第一方面的某些实现方式中，所述通过维特比viterbi算法对输入所述状态检测模型的所述至少一个kpi进行解码，并对所述第一时刻的系统状态进行系统异常判断包括：当通过所述维特比算法解码得到的对应于所述第一时刻的定义系统状态为系统正常或偶发异常时，确定对应于所述第一时刻的系统状态处于正常状态，或者，当通过所述维特比算法解码得到的对应于所述第一时刻的定义系统状态为持续异常或系统宕机时，确定所述第一时刻的系统状态处于异常状态。
17.本技术实施例中的模型可以基于在线检测得到的定义系统状态进一步判断系统是否异常，可选地，在线检测模型还可以输出判断得到的定义系统状态。
18.结合第一方面，在第一方面的某些实现方式中，所述方法还包括：确定所述至少一个训练kpi对应的定义系统状态包括：系统正常、偶发异常、持续异常以及系统宕机。
19.应理解，在训练模型之前，需要先确认训练数据是否完备，如，是否包括对应于上述4种状态的训练数据，若数据完备，则基于训练数据，训练得到4阶的phmm模型。
20.结合第一方面，在第一方面的某些实现方式中，所述定义系统状态包括系统正常和偶发异常，以及，所述根据所述至少一个kpi和状态检测模型，对所述第一时刻的系统状态进行系统异常判断包括：通过所述状态检测模型，对多个时刻对应的至少一个kpi进行滑动窗口判断，其中，所述多个时刻包括所述第一时刻，以获取第一数据，其中，所述第一时刻对应所述滑动窗口的结束时刻；通过所述状态检测模型，利用前向forward算法对所述第一数据进行拟合概率计算；根据所述第一数据的拟合概率，对所述第一时刻的系统状态进行系统异常判断。
21.可选地，本技术实施例的在线检测模型可以为2阶的phmm模型，此时，定义的系统状态可以包括系统正常和偶发异常，由于此时不能直接对phmm模型检测得到的数据进行解
码，可以通过对检测得到的数据与模型中的数据进行拟合概率计算，判断系统是否异常，从而可以满足不同情况下检测数据的需求。
22.结合第一方面，在第一方面的某些实现方式中，所述根据所述第一数据的拟合概率，对所述第一时刻的系统状态进行系统异常判断包括：当所述第一数据的拟合概率小于第一阈值时，确定对应于所述第一时刻的系统状态处于异常状态，或者，当所述第一数据的拟合概率大于或等于第一阈值时，确定对应于所述第一时刻的定义系统状态为系统正常或偶发异常，并进一步确定对应于所述第一时刻的系统状态处于正常状态。
23.由于2阶的phmm模型中只定义了两种系统状态，但是，实际的在线检测数据很可能包括除模型定义的两种系统状态的其他状态，通过判断在线检测数据与模型中数据的拟合概率，判断在线检测数据与模型中数据的匹配程度，从而进一步确定系统的状态。
24.结合第一方面，在第一方面的某些实现方式中，所述方法还包括：确定所述至少一个训练kpi对应的定义系统状态包括：系统正常和偶发异常。
25.应理解，在训练模型之前，需要先确认训练数据是否完备，如，若只包括对应于上述2种状态的训练数据，若训练数据不完备，则基于不完备的训练数据，训练得到2阶的phmm模型，并在2阶phmm模型的基础上，采取不同的状态判断方法，从而适应了不同情形的需求。
26.结合第一方面，在第一方面的某些实现方式中，所述方法还包括：输出对应于所述第一时刻的定义系统状态，所述定义系统状态包括以下中的至少一种：系统正常、偶发异常、持续异常、系统宕机。
27.可选地，本技术实施例中的状态检测模型还可以输出检测得到的，对应于在线数据的定义系统状态。
28.结合第一方面，在第一方面的某些实现方式中，在所述任意两个定义系统状态之间的转移概率中，所述偶发异常到偶发异常、持续异常到偶发异常、系统宕机到偶发异常、系统正常到持续正常、系统宕机到持续异常、系统正常到持续宕机、偶发异常到系统宕机之间的转移概率强制为0。
29.应理解，本技术实施例的状态检测模型将定义系统状态之间的转移概率考虑在内，可以进一步提高状态检测的准确性，而且，根据业务逻辑，某些状态之间的转移概率应该强制为0。
30.结合第一方面，在第一方面的某些实现方式中，当所述系统异常判断的结果为异常状态时，所述方法还包括：发送第一消息，所述第一消息包括所述异常判断的结果。
31.可选地，当本技术实施例的状态检测模型检测到某一时刻的在线数据对应的系统状态处于异常状态时，可以上报异常结果，使得可以对系统异常进行进一步的处理。
32.第二方面，提供了一种异常检测装置，该装置包括：获取模块，用于获取第一时刻对应的至少一个关键性能指标kpi，其中，所述kpi包括尝试次数、成功次数或失败次数中的至少一项；处理模块，用于根据所述至少一个kpi和状态检测模型，对所述第一时刻的系统状态进行系统异常判断，所述异常判断的结果包括正常状态和异常状态，其中，所述状态检测模型包括不同的定义系统状态，所述正常状态对应的定义系统状态包括：系统正常或偶发异常；其中，所述状态检测模型是基于至少一个训练kpi和多个初始状态参数值训练得到的，所述初始状态参数值包括初始泊松分布参数值和初始状态转移概率值，所述初始状态参数值为根据业务逻辑定义的对应于不同的定义系统状态的初始值。
33.结合第二方面，在第二方面的某些实现方式中，所述至少一个kpi与至少一个泊松分布参数一一对应，所述不同的定义系统状态对应于所述至少一个泊松分布参数的不同的参数值，所述第一时刻的定义系统状态转移到另一定义系统状态的转移概率对应于第一状态转移概率值，定义系统状态之间的转移概率对应于不同的状态转移概率值。
34.结合第二方面，在第二方面的某些实现方式中，所述状态检测模型为泊松隐藏马科夫phmm模型。
35.结合第二方面，在第二方面的某些实现方式中，所述状态转移概率包括以下任意两种定义系统状态之间的转移概率：系统正常、偶发异常、持续异常、系统宕机。
36.结合第二方面，在第二方面的某些实现方式中，所述定义系统状态包括系统正常、偶发异常、持续异常、系统宕机，以及，所述处理模块具体用于：将所述至少一个kpi输入所述状态检测模型；通过维特比viterbi算法对输入所述状态检测模型的所述至少一个kpi进行解码，并对所述第一时刻的系统状态进行系统异常判断。
37.结合第二方面，在第二方面的某些实现方式中，所述处理模块具体用于：当通过所述维特比算法解码得到的对应于所述第一时刻的定义系统状态为系统正常或偶发异常时，确定对应于所述第一时刻的系统状态处于正常状态，或者，当通过所述维特比算法解码得到的对应于所述第一时刻的定义系统状态为持续异常或系统宕机时，确定所述第一时刻的系统状态处于异常状态。
38.结合第二方面，在第二方面的某些实现方式中，所述处理模块还用于：确定所述至少一个训练kpi对应的定义系统状态包括：系统正常、偶发异常、持续异常以及系统宕机。
39.结合第二方面，在第二方面的某些实现方式中，所述定义系统状态包括系统正常和偶发异常，以及，所述处理模块具体用于：通过所述状态检测模型，对多个时刻对应的至少一个kpi进行滑动窗口判断，其中，所述多个时刻包括所述第一时刻，以获取第一数据，其中，所述第一时刻对应所述滑动窗口的结束时刻；通过所述状态检测模型，利用前向forward算法对所述第一数据进行拟合概率计算；根据所述第一数据的拟合概率，对所述第一时刻的系统状态进行系统异常判断。
40.结合第二方面，在第二方面的某些实现方式中，所述处理模块具体用于：当所述第一数据的拟合概率小于第一阈值时，确定对应于所述第一时刻的系统状态处于异常状态，或者，当所述第一数据的拟合概率大于或等于第一阈值时，确定对应于所述第一时刻的定义系统状态为系统正常或偶发异常，并进一步确定对应于所述第一时刻的系统状态处于正常状态。
41.结合第二方面，在第二方面的某些实现方式中，所述处理模块还用于：确定所述至少一个训练kpi对应的定义系统状态包括：系统正常和偶发异常。
42.结合第二方面，在第二方面的某些实现方式中，所述装置还包括：输出模块，用于输出对应于所述第一时刻的定义系统状态，所述定义系统状态包括以下中的至少一种：系统正常、偶发异常、持续异常、系统宕机。
43.结合第二方面，在第二方面的某些实现方式中，在所述任意两个定义系统状态之间的转移概率中，所述偶发异常到偶发异常、持续异常到偶发异常、系统宕机到偶发异常、系统正常到持续正常、系统宕机到持续异常、系统正常到持续宕机、偶发异常到系统宕机之间的转移概率强制为0。
44.结合第二方面，在第二方面的某些实现方式中，当所述系统异常判断的结果为异常状态时，所述装置还包括：发送模块，用于发送第一消息，所述第一消息包括所述异常判断的结果。
45.第三方面，提供了一种通信装置，该通信装置具有实现上述各个方面所述的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
46.第四方面，提供了一种通信装置，包括：处理器；所述处理器用于与存储器耦合，用于从所述存储器中调用并运行计算机程序，以执行上述各个方面或各个方面的任意可能的实现方式中的方法。
47.第五方面，提供了一种通信装置，包括，处理器，存储器，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得该通信设备执行上述各个方面或各个方面的任意可能的实现方式中的方法。
48.第六方面，提供了一种装置(例如，该装置可以是芯片系统)，该装置包括处理器，用于支持通信装置实现上述各个方面中所涉及的功能。在一种可能的设计中，该装置还包括存储器，该存储器，用于保存通信装置必要的程序指令和数据。该装置是芯片系统时，可以由芯片构成，也可以包含芯片和其他分立器件。
49.第七方面，提供了一种计算机可读存储介质，用于存储计算机程序，该计算机程序包括用于执行如上述各个方面或各个方面的任意可能的实现方式中的方法的指令。
50.第八方面，提供了一种计算机程序产品，包括计算机程序，当其在计算机设备上运行时，使得所述计算机设备执行如上述各个方面所述的方法。
51.本技术的这些方面或其他方面在以下实施例的描述中会更加简明易懂。
附图说明
52.图1是本技术实施例的异常检测方法的示意图。
53.图2是本技术实施例的一个异常检测的架构图。
54.图3是本技术实施例的一个系统正常状态下对应的泊松参数分布曲线示意图。
55.图4是本技术实施例的一个偶发异常状态下对应的泊松参数分布曲线示意图。
56.图5是本技术实施例的一个持续异常状态下对应的泊松参数分布曲线示意图。
57.图6是本技术实施例的一个系统宕机状态下对应的泊松参数分布曲线示意图。
58.图7是本技术实施例的一个hmm模型中的状态转移图。
59.图8是本技术实施例的另一个hmm模型中的状态转移图。
60.图9是本技术实施例的一种4阶模型异常检测的架构图。
61.图10是本技术实施例的另一种异常检测的架构图。
62.图11是本技术实施例的一种异常检测装置的结构示意图。
63.图12是本技术实施例的一种异常检测装置的另一结构示意图。
具体实施方式
64.下面将结合附图，对本技术中的技术方案进行描述。
65.本技术实施例的技术方案可以应用于各种计算机网络系统、通信网络系统，例如
电信网(telecommunication network)，业务网(service network)，传输网(transmission network)，分组交换网(packet switching network)、2g/3g/4g核心网(core network)，第五代(5th generation，5g)网络通信系统，以及未来演进的通信网络系统等。
66.随着5g相关技术的引入，网络变得更加的复杂。网络异常检测功能作为网络运维的核心，在更多的不同场景下面临着巨大的挑战。传统的异常检测通过监控网络的关键kpi来发现异常。然而传统场景假设当前网络中有大量的用户和大量的业务量，因此kpi具有全局统计特性，即可以有效体现当前网络的状态。
67.除了传统的场景，异常检测仍需要支撑5g网络技术带来的更多特殊场景。如灰度验证、秒级监控、新业务上线以及企业级业务场景中，对异常检测提出了更高的要求。下面列举了一些本技术可能涉及的单用户或少量用户行为的场景：(1)灰度验证
68.当需要上线新业务时，需要引入小部分用户来测试验证。为了保证业务验证覆盖的全面性，需要对用户进一步分群进行验证检测。例如，根据不同手机品牌进行分群，苹果手机用户数量会远远比其他手机品牌用户数量更多。当验证那些小众品牌手机业务时，用户量会更少，甚至单用户。
69.(2)秒级监控
70.为了满足低时延等要求，网络会部署切片来快速满足不用业务需求，因此需要高频的数据统计和采集，保证秒级监控。然而随着数据统计的时间间隔缩短，在统计周期内发生的业务量也会急剧减少，即统计周期内用户量很少，甚至单用户。
71.(3)新业务上线
72.新的业务上线后，用户会慢慢接入。在上线以后的初期，用户量很少，甚至单用户。此时，需要尽快发现问题，减少故障影响范围，快速进行回退，重置等止损操作。
73.(4)企业级业务
74.在企业级业务中，用户数本身较少，然而一旦出现问题，影响极大。
75.上述场景对异常检测提出了更高的要求：
76.1)实时性：异常检测的周期更短；
77.2)细粒度：异常检测的颗粒度需要细化到少量用户群甚至单用户。
78.在上述单个用户或少量用户行为的场景下，由于单个周期的业务数量很少，导致kpi不具备统计规律。例如，业务量统计趋近个位数，甚至长时间为0，成功率的计算也没有意义。此种情况下，传统的异常检测算法几乎无法适用，因为传统的方法基本通过拟合kpi后进行预测，然后进行阈值判断。但是，上述场景下的kpi无统计特性，传统拟合没有任何意义，阈值判断就更加无法使用。
79.当前针对单个用户或少量用户的行为场景的方法基本为人工测试和排查，但是这种方法的验证量非常小，而且测试周期很长，无法满足当前的需求，本技术针对上述单个用户或少量用户的行为场景中出现的问题，提出了一种异常检测方法。
80.本技术提供了一种异常检测方法，利用基于业务相关知识训练得到的包括泊松分布参数和状态转移概率的状态检测模型，对单个用户或少量用户行为场景下的kpi进行检测，继而可以对对应于一定时刻的至少一个kpi的系统状态进行判断并进一步进行异常判断，克服了单用户或少量用户场景下的kpi无统计特性的问题，有利于提高系统检测的准确性，避免了误判。
81.本技术的实施例提供的异常检测方法可以应用于上述描述的各种单用户或少量用户行为下的场景，本技术对此不做限定。
82.应理解，本技术的实施例提供的异常检测方法可以由各种网络系统中的网络管理平台或网络监控平台来执行，或者可选地，本技术实施例的异常检测方法也可以内嵌到业务本身的模块中，通过对在线数据进行检测之后，可以根据检测结果做自动化的处理进行自愈或者进行规避，申请对此不作限定。
83.图1示出了本技术实施例的一个异常检测方法的示意图。如图1所示：
84.s101，获取第一时刻对应的至少一个关键性能指标kpi。
85.作为一个实施例，其中，所述kpi包括尝试次数、成功次数或失败次数中的至少一项。
86.可选地，本技术实施例可以采用单kpi输入，也可以采用多kpi输入进行综合判断，应理解，本技术实施例中的kpi可以包括与次数相关的其他kpi，并不仅仅限于上述三种情况。
87.s102，根据所述至少一个kpi和状态检测模型，对所述第一时刻的系统状态进行系统异常判断。
88.作为一个实施例，所述异常判断的结果包括正常状态和异常状态，其中，所述状态检测模型包括不同的定义系统状态，所述正常状态对应的定义系统状态包括：系统正常或偶发异常，所述至少一个kpi与至少一个泊松分布参数一一对应，所述不同的定义系统状态对应于所述至少一个泊松分布参数的不同的参数值，所述第一时刻的定义系统状态转移到另一定义系统状态的转移概率对应于第一状态转移概率值，定义系统状态之间的转移概率对应于不同的状态转移概率值。
89.本技术实施例中的状态检测模型定义了不同的定义系统状态，例如系统正常和偶发异常，可选地，还可以包括持续异常和系统宕机。状态检测模型在进行在线检测时，可以判断在线检测数据与模型中的定义系统状态对应的数据的匹配程度，从而确定第一时刻的系统状态，其中，最终确定的系统状态可以包括正常状态或者异常状态。例如，状态检测模型检测到第一时刻对应的kpi与系统正常的数据匹配时，可以确定第一时刻的系统状态为正常状态。
90.其中，对应于不同的kpi，可以有不同类型的泊松分布参数与之对应，例如，对于成功次数来说，其对应的参数可以为成功发生密度，对于失败次数来说，其对应的参数可以为失败发生密度。进一步地，由于本技术实施例中的状态检测模型定义了不同的定义系统状态，每种kpi的不同的泊松分布参数值可以对应于不同的定义系统状态，例如，当状态检测模型在线检测的kpi包括成功次数和失败次数，当定义系统状态为系统正常时，kpi成功次数对应的泊松分布参数值可以为4，失败次数对应的泊松分布参数可以为0.2，又例如，当定义系统状态为偶发异常时，失败次数对应的泊松分布参数值可以为2，成功次数对应的泊松分布参数值可以为6；当定义系统状态为持续异常时，失败次数对应的泊松分布参数值可以为3，成功次数对应的泊松分布参数值可以为8；当定义系统状态为系统宕机时，失败次数对应的泊松分布参数值可以为0.1，成功次数对应的泊松分布参数值可以为0.2，状态检测模型在对在线数据进行在线检测时，可以将在线检测数据与每个定义系统状态下的各个kpi对应的泊松分布参数进行匹配，若匹配成功，则可以确定该时刻的定义系统状态，从而可以
进一步确定最终的系统状态，其中，每种状态下的数值仅仅为举例，实际应用中可以根据训练数据进行调整，本技术实施例对此不做限定。
91.本技术实施例中，状态检测模型对系统状态进行判断的最终结果不仅与泊松分布参数相关，与在线检测数据的序列前后关系有关，更进一步地，也与定义系统状态之间的转移概率相关，如，状态检测模型检测到多个时刻的对应于成功次数和失败次数的泊松分布参数值基本一致，该数值可以对应到偶发异常和持续异常两个状态，但是，根据业务逻辑来判断，偶发异常的状态是不可能连续出现的，在这种情况下，状态检测模型就会将该多个时刻的系统定义状态判断为持续异常，相比于仅仅根据泊松分布参数值进行判断的方式，本技术实施例还增加了将状态转移概率作为判断依据，进一步提高了系统状态判断的准确性，避免了误判。
92.作为一个实施例，本技术实施例中的状态检测模型可以为泊松隐藏马科夫phmm模型，或者可选地，也可以为神经网络模型等，本技术实施例对此不作限定。
93.作为一个实施例，所述状态转移概率包括以下任意两种定义系统状态之间的转移概率：系统正常、偶发异常、持续异常、系统宕机。
94.应理解，任意两种定义系统状态之间的转移概率不仅包括不同定义系统状态之间的转移概率的情形，也包括同一种定义系统状态保持当前定义系统状态的情形。
95.作为一个实施例，其中，所述状态检测模型是基于至少一个训练kpi和多个初始状态参数值训练得到的，所述初始状态参数值包括初始泊松分布参数值和初始状态转移概率值，所述初始状态参数值为根据业务逻辑定义的对应于不同的定义系统状态的初始值。
96.本技术实施例中的状态检测模型可以涵盖不同的情况，不同情况下的状态检测模型在进行在线检测并判断系统状态的过程有所不同。
97.作为一个实施例，当状态检测模型定义了4种定义系统状态时，状态检测模型在对数据进行在线检测后，可以根据现有技术中的对于hmm模型的处理方式，确定系统状态，具体地，所述定义系统状态包括系统正常、偶发异常、持续异常、系统宕机，以及所述根据所述至少一个kpi和状态检测模型，对所述第一时刻的系统状态进行系统异常判断包括：将所述至少一个kpi输入所述状态检测模型；通过维特比viterbi算法对输入所述状态检测模型的所述至少一个kpi进行解码，并对所述第一时刻的系统状态进行系统异常判断。
98.其中，在对第一时刻的系统状态进行系统异常判断之前，状态检测模型还需要确定第一时刻对应的定义系统状态，具体地，所述通过维特比viterbi算法对输入所述状态检测模型的所述至少一个kpi进行解码，并对所述第一时刻的系统状态进行系统异常判断包括：当通过所述维特比算法解码得到的对应于所述第一时刻的定义系统状态为系统正常或偶发异常时，确定对应于所述第一时刻的系统状态处于正常状态，或者当通过所述维特比算法解码得到的对应于所述第一时刻的定义系统状态为持续异常或系统宕机时，确定所述第一时刻的系统状态处于异常状态。
99.应理解，由于本技术实施例中的不同的定义系统状态对应于不同的泊松分布参数值，状态检测模型在进行在线检测时，会将第一时刻的kpi数据与模型中的各个定义系统状态下的数据进行匹配，若匹配成功，则确定当前第一时刻对应的定义系统状态。
100.针对这种情况的状态检测模型，在得到定义了4中定义系统状态的状态检测模型之前，会先对训练数据进行判断，具体地，所述方法还包括：确定所述至少一个训练kpi对应
的定义系统状态包括：系统正常、偶发异常、持续异常以及系统宕机。
101.作为另一个实施例，当状态检测模型仅仅定义了两种不同的定义系统状态时，但是，在线检测的实际数据中，可能包含了与定义系统状态不同的状态，此时，若还是按照现有技术对于hmm模型的处理方式，最终确定的系统状态很可能与实际情况不符，例如，当状态检测模型仅仅定义了系统正常和偶发异常两种定义系统状态，但是，在线检测数据实际上也包括了持续异常或系统宕机的情形，此时，若仍然对状态检测模型检测的数据进行解码然后判断系统状态，其最后得到的结果很可能与实际情况不符，这种情况下，可以采用对检测数据进行拟合的方式来确定系统所处的状态。
102.具体地，所述定义系统状态包括系统正常和偶发异常，以及所述根据所述至少一个kpi和状态检测模型，对所述第一时刻的系统状态进行系统异常判断包括：通过所述状态检测模型，对多个时刻对应的至少一个kpi进行滑动窗口判断，其中，所述多个时刻包括所述第一时刻，以获取第一数据，其中，所述第一时刻对应所述滑动窗口的结束时刻；通过所述状态检测模型，利用前向forward算法对所述第一数据进行拟合概率计算；根据所述第一数据的拟合概率，对所述第一时刻的系统状态进行系统异常判断。
103.状态检测模型会检测在线数据与模型中的各个定义系统状态对应的数据的拟合概率，当拟合概率大于阈值时，则判定第一时刻对应的定义系统状态与状态检测模型中的定义系统状态相匹配，否则不匹配，并进一步判断系统所处的状态。
104.具体地，所述根据所述第一数据的拟合概率，对所述第一时刻的系统状态进行系统异常判断包括：当所述第一数据的拟合概率小于第一阈值时，确定对应于所述第一时刻的系统状态处于异常状态，或者当所述第一数据的拟合概率大于或等于第一阈值时，确定对应于所述第一时刻的定义系统状态为系统正常或偶发异常，并进一步确定对应于所述第一时刻的系统状态处于正常状态。
105.应理解，该第一阈值可以是在训练阶段时，利用训练好的状态检测模型对对训练数据进行所有滑动窗口的拟合概率计算，例如，训练数据长l，滑动窗口为w，可以得到l-w 1个拟合概率p1，
…
，p(l-w 1)。假定训练数据为正常数据，然后计算正常数据的拟合概率范围，均值为p
mean
，标准差为p
std
，p
threshold
＝p
mean-k*p
std
，其中k为控制参数，k越小，算法越敏感；k越大，算法越不敏感。其中，拟合概率应该转化为db(即假设得到的拟合概率为x，则转化为db之后的拟合概率为10*logx)，因为原始概率只是在[0，1]之间，但是转化为db之后,其范围就是在[-∞,0]之间。这样，就不存在k值较大超出范围的问题，应理解，上述拟合概率的转化方式可以参考现有技术，本技术在此不做过多赘述。
[0106]
应理解，本技术涉及多种不同的定义系统状态，不同的定义系统状态之间的转移概率值有所不同，但是需要对某些状态的转移概率进行强制限定，比如，按照业务逻辑定义，设定系统宕机不能直接跳转到偶发异常和持续异常，或者持续异常根据定义也不可能回到偶发异常，这两种情况下，需要强制其转移概率为0。
[0107]
具体地，在所述任意两个定义系统状态之间的转移概率中，所述偶发异常到偶发异常、持续异常到偶发异常、系统宕机到偶发异常、系统正常到持续正常、系统宕机到持续异常、系统正常到持续宕机、偶发异常到系统宕机之间的转移概率强制为0。
[0108]
当状态检测模型判断对应于第一时刻的系统状态处于异常状态时，可以将异常状态上报，从而可以进一步对系统进行下一步处理，具体地，当所述系统异常判断的结果为异
常状态时，所述方法还包括：发送第一消息，所述第一消息包括所述异常判断的结果。
[0109]
可选地，状态检测模型还可以将判断得到的定义系统状态输出，具体地，所述方法还包括：输出对应于所述第一时刻的定义系统状态，所述定义系统状态包括以下中的至少一种：系统正常、偶发异常、持续异常、系统宕机。
[0110]
本技术实施例利用基于业务相关知识训练得到的包括泊松分布参数和状态转移概率的状态检测模型，对单个用户或少量用户行为场景下的kpi进行检测，继而可以对对应于一定时刻的至少一个kpi的系统状态进行检测并进一步进行异常判断，克服了单用户或少量用户场景下的kpi无统计特性的问题，有利于提高系统检测的准确性，避免了误判。
[0111]
图2示出了本技术实施例的一个异常检测的架构图。如图2所示，该架构图包括离线训练模块210和在线检测模块220。
[0112]
1.离线训练模块210
[0113]
在离线训练模块210中，利用离线数据进行模型训练，应理解，可以基于抽象的原始模型对离线数据进行训练，训练phmm模型可以采用鲍姆韦尔奇baum-welch算法。
[0114]
应理解，本技术实施例中的离线训练数据可以是单指标，也可以是多指标输入，kpi的类型可以包括：尝试次数，成功次数，失败次数等，但本技术并不限于此。
[0115]
本技术实施例可以基于hmm模型，对当前检测的系统进行建模，为当前系统定义不同的系统状态，此处定义的系统状态也可以称为定义系统状态，可选地，本技术定义的定义系统状态可以包括：系统正常、偶发异常、持续异常或系统宕机，应理解，本技术中定义的系统状态可以根据实际训练数据来确定，如，在训练数据完备的情况下，可以得到每个状态下对应的足够的数据进行训练，此时可以得到对应于全部定义系统状态的模型，如，可以是4阶的模型，定义系统状态包括：系统正常、偶发异常、持续异常或系统宕机；或者，在训练数据不完备的情况下，因为持续异常和系统宕机的发生概率本身十分小，无法得到这两个状态的训练数据，导致无法很好的训练4阶的hmm隐藏马科夫模型。因此，需要把原有的4阶hmm模型简化为2阶hmm模型，可以只定义系统正常和偶发异常两个系统状态。
[0116]
本技术实施例中涉及的kpi分布服从poisson泊松分布，因此，本技术实施例的状态检测模型可以为泊松隐藏马科夫模型(poisson hidden markov model，phmm)。
[0117]
其中，具体的论证过程如下：
[0118]
先对训练数据进行建模。训练数据可以包括尝试次数，成功次数，失败次数等。因为次数类kpi的建模方法和结果类似，这里只展示失败次数的建模过程，其他可依次类推。
[0119]
假设，用户的业务成功概率为p，失败的概率为q＝1-p，在系统的参数不变的情况下，用户总共接入n次，则失败k次的概率符合二项分布b(n,p)，表示如下：
[0120][0121]
然而由于用户总共接入n次不可知，所以用故障发生密度λ＝nq来替代，则：
[0122][0123]
根据泊松极限定理poisson limit theorem，可使n
→
∞来得到通用的概率分布。
已知以下极限：
[0124][0125][0126][0127]
所以，可以得到：
[0128][0129]
因此失败次数服从泊松分布，其中泊松分布参数λ为失败发生密度。成功次数和尝试次数的结果可依此类推，λ则分别为成功发生密度和尝试发生密度。
[0130]
一般来说，λ越大，概率分布整体越趋向右方，且越来越矮胖，可理解为业务量增大，单位统计周期内相应的失败发生密度等也越高，失败次数等值的覆盖面积也越大。
[0131]
相比其他分布，如高斯分布，泊松分布最合理的地方为，其定义的范围始终为正值(0, ∞)，即失败次数等不可能为负数。例如，高斯分布的定义域是(-∞, ∞)，且高斯泊松分布一定为对称的，假如用高斯分布进行数据建模，在业务量趋近0的情况下，均值也趋近0，高斯分布会覆盖大量负值的区域。这是明显不合理的，然而泊松分布就不存在相应问题。
[0132]
为了更好的理解定义系统状态的定义，下面给出了具体的示例，其中，本技术实施例以训练数据为2维kpi(失败次数和成功次数)为例进行说明，但是，本技术的2维kpi训练仅仅为示例性的说明，本技术并不限于此：
[0133]
在训练模型的过程中，会得到相应的成功次数和失败次数对应的λ值，由于本技术实施例中对系统定义了不同的定义系统状态，因此，本技术实施例可以得到对应于不同的定义系统状态的对应于成功次数和失败次数的λ值(如，可以是λ1和λ2)，应理解，本技术训练得到的模型中对应于各个定义系统状态的λ参数值需要给定合理的初始值(λ3和λ4)，该初始值是根据业务逻辑定义的对应于不同的定义系统状态的值，如，可以是下述表1-表4中对应的λ的初始值，如，对应于系统正常的定义系统状态，其(λ3，λ4)可以为(0.2，4)，对应于偶发异常的定义系统状态，其((λ3，λ4)可以为(2，6)，对应于持续异常的定义系统状态，其(λ3，λ4)可以为(3，8)，对应于系统宕机的定义系统状态，其(λ3，λ4)可以为(0.1，0.2)，其具体值可以根据实际情况和业务逻辑进行调整，本技术对此不作限定。
[0134]
下面对各个定义系统状态下的kpi对应的泊松分布参数进行描述：
[0135]
1)系统正常
[0136]
系统正常时，偶尔会有少量失败次数，成功次数维持在正常范围。表1示出了系统正常状态下的kpi与时刻的对应关系，系统一直处于正常状态，失败次数λ＝0.2，成功次数λ＝4，其中，图3示出了对应于失败次数λ＝0.2，成功次数λ＝4时的泊松分布曲线，应理解，该曲线是根据泊松分布概率密度函数绘制得到的，具体可以参考现有技术，本技术实施例中的失败次数和成功次数对应的λ可以是根据业务逻辑定义的数值，该λ也可以根据实际训练数据做适当的调整，本技术对此不作限定。
[0137]
表1 kpi和时刻对应关系表
[0138]
abc时间戳失败次数成功次数10:3003010:3112410:3201010:3313310:3402310:3501910:3602310:3711110:3802210:39032
[0139]
2)偶发异常
[0140]
偶发异常时，失败次数相比正常会突然增高；由于用户会重试，成功次数会略高。由于偶发异常，多为系统抖动且快速自愈，所以无需上报异常，认为系统处于无异常状态。表2示出了偶发异常状态下的kpi与时刻的对应关系表，如表2所示，在10：35处，出现偶发异常，此时失败次数λ＝2，成功次数λ＝6，其中，图4示出了对应于失败次数λ＝2，成功次数λ＝6时的泊松分布曲线，应理解，该曲线是根据泊松分布概率密度函数绘制得到的，具体可以参考现有技术。
[0141]
表2 kpi和时刻对应关系表
[0142]
abc时间戳失败次数成功次数10:3003010:3112010:3202310:3313210:3402710:35106010:3614010:3702310:3801110:39136
[0143]
3)持续异常：持续异常时，失败次数相比平时明显升高且持续；由于用户多次重试，成功次数明显升高。此时系统明显出现问题需要上报异常。表3示出了持续异常状态下的kpi与时刻的对应关系表，如表3所示，从10：32至10：37，出现持续异常，此时失败次数λ＝3，成功次数λ＝8，其中，图5示出了对应于失败次数λ＝3，成功次数λ＝8时的泊松分布曲线，应理解，该曲线是根据泊松分布概率密度函数绘制得到的，具体可以参考现有技术。
[0144]
表3 kpi和时刻对应关系表
[0145]
abc时间戳失败次数成功次数10:3003010:3112010:3212310:33113210:34142710:35106010:36154010:37202310:3801110:39136
[0146]
4)系统宕机：系统宕机时，系统已经无法正常运作或者用户已经不再使用业务，成功次数和失败次数皆趋近0。此时系统明显出现问题需要上报异常。表4示出了持续异常状态下的kpi与时刻的对应关系表，如表4所示，系统一直处于宕机状态，失败次数λ＝0.1，成功次数λ＝0.2，其中，图6示出了对应于失败次数λ＝0.1，成功次数λ＝0.2时的泊松分布曲线，应理解，该曲线是根据泊松分布概率密度函数绘制得到的，具体可以参考现有技术。
[0147]
表4 kpi和时刻对应关系表
[0148]
abc时间戳失败次数成功次数10:300010:310010:320010:330110:340010:351010:360010:370110:380010:3900
[0149]
应理解，上述相应的泊松分布参数值为对应于训练数据完备时的4阶状态检测模型的参数值，上文有提到，当训练数据不完备时，可以将模型进行简化，得到2阶的状态检测模型，此时，对应于2阶模型的定义系统状态的泊松分布参数值也可以发生相应的变化，本技术对此不作限定。
[0150]
在训练模型的过程中，除了要考虑kpi对应的泊松分布参数λ之外，本技术实施例还进一步考虑了任意两个定义系统状态之间的转移概率，从而提高了系统状态判断的准确性，避免了误判。以偶发异常和持续异常为例说明，如表2和表3以及其对应的λ值所示，在偶发异常和持续异常状态下，其对应的次数以及相应的λ值相差不大，如果仅仅靠泊松分布参数对系统状态进行判断，那么模型最终判断出的结果很可能会出现错误，即偶发异常判断
为持续异常，或者持续异常误判为偶发异常，本技术实施例进一步将表4中的训练数据的序列前后关系考虑进去，因为根据业务逻辑，在数据序列中，偶发异常是不可能连续出现的，如表3中，10:33-10:37时段内所示，其失败次数都是超出正常水平的，此时，将序列的前后关系(进一步地，即本技术实施例中的状态转移概率)考虑进去，就可以避免误判的情况，具体地，下面对各个系统状态之间的转移概率进行示例性的描述：
[0151]
图7示出了本技术实施例的一个状态检测模型中的状态转移图，如图7所示，本技术实施例的系统在四个定义系统状态之间转换，不同定义系统状态对应的泊松分布参数不同。如图7中的状态转移图所示，用单向箭头以及概率值代表状态转移的方向和转移概率，每个状态转出的概率加和为1。
[0152]
表5为根据图7中的状态转移图整合的状态转移概率矩阵a，用a_(i,j)代表a的元素，即状态转移概率a_1,2代表从系统正常到偶发异常的转移概率。基于业务知识，进行以下设定：
[0153]
表5状态转移概率矩阵a
[0154] 系统正常偶发异常持续异常系统宕机系统正常0.90.100偶发异常0.800.20持续异常0.200.70.1系统宕机0.2000.8
[0155]
注：其中的加粗部分为强制为0的情形
[0156]
1)系统正常时，下一个时刻，维持系统正常的概率较大a_1,1＝0.9，但有小概率转移到偶发异常a_1,2＝0.1。我们设定系统正常需经过偶发异常才能跳转到持续异常，不能直接跳转，即a_1,3＝0。同时，系统正常也不能直接跳转到系统宕机，即a_1,4＝0。
[0157]
2)偶发异常时，下一个时刻，大概率回到系统正常状态a_2,1＝0.8，但仍有一定概率变成持续异常a_2,3＝0.2，这里我们设定持续异常一定从偶发异常转入。根据偶发异常的定义，偶发异常状态不能持续，即a_2,2＝0。同时，偶发异常也不能直接跳转到系统宕机a_2,4＝0。
[0158]
3)持续异常时，下一个时刻，根据定义大概率还是持续异常a_3,4＝0.7；持续异常有一定概率回到系统正常a_3,1＝0.2；但也有一定概率导致系统宕机a_3,4＝0.1。同时，持续异常根据定义也不可能回到偶发异常，即a_3,2＝0。
[0159]
4)系统宕机时，大概率维持系统宕机a_4,4＝0.8，有一定概率回到系统正常a_4,1＝0.2。我们设定系统宕机不能直接跳转到偶发异常和持续异常a_4,2＝a_4,3＝0。
[0160]
以上转移概率为a_(i,j)＝0的为强制转移概率，即在训练模型的时候，强制为0，因为按照业务逻辑定义，某些定义系统状态之间的转移概率为0。其他的转移概率，根据训练数据训练可得。这里跟训练状态输出的泊松分布参数(λ1,λ2)一样，需要给定合理的初始值，可以参考表6中状态转移概率矩阵a。
[0161]
上述的图7为训练数据完备的情况下的状态转移图，根据上文描述，当训练数据不完备，如不能得到对应于持续异常以及系统宕机状态下的训练数据时，需要将模型简化为2阶hmm模型，此时，其定义系统状态对应的状态转移也会发生变化，具体地，图8示出了2阶模型下的状态转移图，表6示出了与图8对应的状态转移概率矩阵a：
[0162]
表6状态转移概率矩阵a
[0163] 系统正常偶发异常系统正常0.90.1偶发异常0.80
[0164]
注：其中的加粗部分为强制为0的情形
[0165]
具体内容与4阶模型中的状态转移概率类似，本技术实施例在此不做过多赘述。
[0166]
本技术实施例在训练模型中，使用泊松分布进行数据建模，与其他分部相比，如高斯分布，本技术实施例的模型中定义的范围始终为正值，模型设计更加合理，进一步地，本技术实施例在模型训练过程中，不仅将泊松分布参数考虑在内，同时考虑了序列前后关系，将系统状态之间的转移概率进一步考虑在内，从而提高了系统状态判定的准确性，避免了状态误判。
[0167]
2.在线检测模块220
[0168]
在在线检测模块220中，还可以进一步包括检测模块221和判断模块222，检测模块221可以利用训练好的状态检测模型，对在线数据进行检测，判断模块222对在线检测数据进行处理，判断系统所处的状态是否异常，系统状态可以包括正常状态和异常状态。
[0169]
可选地，状态检测模型还可以输出中间状态的判断结果(即上文中的定义系统状态)，如，系统处于系统正常或偶发异常或持续异常或系统宕机等。
[0170]
应理解，本技术实施例中的在线检测模块在进行检测时，会将在线数据与模型中的数据进行匹配，然后进一步确定系统所处的状态。
[0171]
作为一种可能的实现方式，当训练好的状态检测模型为4阶模型时，可以对在线检测的数据进行解码，继而得到在线数据对应的定义系统状态。
[0172]
其中，图9给出了本技术实施例的一种4阶模型异常检测的架构图，如图9所示，与图2中的架构类似，本技术实施例在4阶模型中，对上述架构做了进一步的细化。具体地，训练好的phmm模型可以通过维特比viterbi算法把在线检测的数据解码成为隐藏状态，即定义的系统状态。然后由判断模块922对系统状态进行判断，确定系统是否处于异常状态。
[0173]
应理解，本技术实施例中的状态检测模型最终确定的某一时刻的系统状态与模型中定义的定义系统状态不同，本技术实施例会基于模型检测出的在线数据对应的定义系统状态最终确定系统状态，例如，本技术实施例中最终确定的某一时刻的系统状态可以为正常状态和异常状态，可选地，当在线数据对应的定义系统状态为系统正常或偶发异常时，最终确定的系统状态可以为正常状态，相应的，当在线数据对应的定义系统状态为持续异常或系统宕机时，最终确定的系统状态可以为异常状态。
[0174]
具体地，判断模块922会基于检测出的定义系统状态判定系统是否异常，其中对应持续异常和系统宕机的数据可直接判定为异常。如表7所示，10:30-10:32的数据可以为系统正常；10:33被判定为偶发异常；10:34-10:37的数据被判定为持续异常，需要上报；10:38-10:41的数据被判定系统宕机，需要上报；10:42之后系统恢复正常。
[0175]
可选地，本技术实施例中的phmm模型对在线数据检测之后，可以将异常状态的数据进行上报，以使得可以对异常状态的系统进行进一步的处置，可选地，本技术实施例还可以将检测得到的在线数据的定义系统状态输出，以便对系统的具体状态做进一步了解。
[0176]
表7和时刻对应关系表
[0177]
abcd时间戳失败次数成功次数隐藏状态10:30030系统正常10:31120系统正常10:32123系统正常10:331132偶发异常10:341427持续异常10:351060持续异常10:361540持续异常10:372023持续异常10:3801持续异常10:3910持续异常10:4001持续异常10:4110持续异常10:42023系统正常10:43011系统正常10:44123系统正常10:45033系统正常
[0178]
注：其中的加粗部分对应于异常状态，需要进行上报
[0179]
作为另一种可能的实现方式，当训练数据不完备，得到的模型为2阶phmm模型时，例如训练数据只有对应于系统正常和偶发异常的数据时，此时得到的2阶phmm模型中没有对持续异常和系统宕机进行定义，所以在进行异常判断时，无法像4阶phmm模型那样直接解码输出隐藏状态。在2阶phmm模型的异常判断中，需要对在线数据进行滑动窗口判断，然后采用前向forward算法对滑动窗口中的检测数据进行拟合概率计算，当拟合概率小于设定的阈值时，则判断为异常。
[0180]
如图10示出了本技术实施例的另一种异常检测的架构图，如图10所示，与图9中的解码不同，本实施例中的模型在做在线检测时，需要利用窗口滑动对在线数据做拟合概率的计算。
[0181]
具体地，如表8所示的至少一个kpi与各个时刻对应关系表，可以设置滑动窗口宽度每次为6个时刻(窗口滑动设置宽度可以根据实际情况指定)，然后，对每个窗口的数据与模型中的数据进行拟合概率的计算，根据预设的阈值，判断在线数据与模型数据的匹配程度，如表8所示，可以设定阈值为-50db，在滑动窗口10:30-10:35内数据拟合概率为-33db，可以判定为正常，不上报异常；当窗口滑动到10:37-10:43时，拟合概率为-117.2db，小于阈值，则上报异常。
[0182]
上述对至少一个kpi和其对应的时刻进行拟合概率计算时，可以采用前向forward算法，利用滑动窗口内，多个时刻对应的至少一个kpi的数据与hmm模型进行拟合，具体地，按照滑窗内的时刻先后，依次对每个时刻对应的kpi数据与定义的系统状态进行匹配，依次计算所有时刻的匹配概率。滑窗内所有时刻的匹配概率计算完了之后，可以最终计算出一个综合的所有序列匹配到系统状态的概率。其中，上述计算每个时刻的匹配概率的方法可
以参考现有技术中计算匹配概率的方法，本技术对此不做限定。
[0183]
表8 kpi和时刻对应关系表
[0184]
序号abc1时间戳失败次数成功次数210:30030310:31120410:32123510:33132610:34027710:35160810:361533910:3720231010:3830321110:3922521210:4015311310:4123421410:42001510:43001610:44111710:45011810:46001910:47102010:4800
[0185]
注：窗口宽度可以设置为6，计算的拟合概率(取对数之后)越小，拟合概率越低
[0186]
本技术实施例中预设的阈值可以是利用训练好的phmm模型对训练数据进行所有滑动窗口的拟合概率计算，例如，训练数据长l，滑动窗口为w，可以得到l-w 1个拟合概率p1,
…
,p(l-w 1)。其中，训练数据为正常数据，计算正常数据的拟合概率范围，均值为p
mean
，标准差为p
std
。计算阈值p
threshold
(db)如下：
[0187]
p
threshold
＝p
mean-k*p
std
[0188]
其中k为控制参数，k越小，算法越敏感；k越大，算法越不敏感。
[0189]
应理解，本技术实施例中的对在线检测数据与模型中的数据进行拟合概率计算使用的方法可以参考现有技术，本技术实施例在此不做限定。
[0190]
图11示出了本技术实施例的一个异常检测装置的示意图，如图11所示，该装置1100包括获取模块1101和处理模块1102。该装置1100可以用于实现上述任一方法实施例中涉及的系统在线检测和异常判断的功能。
[0191]
该装置1100可以作为异常检测装置对kpi进行处理，并执行上述方法实施例中由异常检测装置对kpi进行在线检测和异常判断的步骤。所述获取模块1101可用于支持该装置110011进行通信，例如执行图1中异常检测装置执行的接收的动作，所述处理模块1102可用于支持装置1100执行上述方法中的处理动作，例如执行图1中由异常检测装置执行的处
理动作。该装置1100还可以包括输出模块和发送模块，例如执行图1中由异常检测装置执行的输出和发送动作。具体地，可以参考如下描述：
[0192]
获取模块1101，用于获取第一时刻对应的至少一个关键性能指标kpi，其中，所述kpi包括尝试次数、成功次数或失败次数中的至少一项；处理模块1102，用于根据所述至少一个kpi和状态检测模型，对所述第一时刻的系统状态进行系统异常判断，所述异常判断的结果包括正常状态和异常状态，其中，所述状态检测模型包括不同的定义系统状态，所述正常状态对应的定义系统状态包括：系统正常或偶发异常；其中，所述状态检测模型是基于至少一个训练kpi和多个初始状态参数值训练得到的，所述初始状态参数值包括初始泊松分布参数值和初始状态转移概率值，所述初始状态参数值为根据业务逻辑定义的对应于不同的定义系统状态的初始值。
[0193]
可选地，所述至少一个kpi与至少一个泊松分布参数一一对应，所述不同的定义系统状态对应于所述至少一个泊松分布参数的不同的参数值，所述第一时刻的定义系统状态转移到另一定义系统状态的转移概率对应于第一状态转移概率值，定义系统状态之间的转移概率对应于不同的状态转移概率值。
[0194]
可选地，所述状态检测模型为泊松隐藏马科夫phmm模型。
[0195]
可选地，所述状态转移概率包括以下任意两种定义系统状态之间的转移概率：系统正常、偶发异常、持续异常、系统宕机。
[0196]
可选地，所述定义系统状态包括系统正常、偶发异常、持续异常、系统宕机，以及，所述处理模块具体用于：将所述至少一个kpi输入所述状态检测模型；通过维特比viterbi算法对输入所述状态检测模型的所述至少一个kpi进行解码，并对所述第一时刻的系统状态进行系统异常判断。
[0197]
可选地，所述处理模块具体用于：当通过所述维特比算法解码得到的对应于所述第一时刻的定义系统状态为系统正常或偶发异常时，确定对应于所述第一时刻的系统状态处于正常状态，或者，当通过所述维特比算法解码得到的对应于所述第一时刻的定义系统状态为持续异常或系统宕机时，确定所述第一时刻的系统状态处于异常状态。
[0198]
可选地，所述处理模块还用于：确定所述至少一个训练kpi对应的定义系统状态包括：系统正常、偶发异常、持续异常以及系统宕机。
[0199]
可选地，所述定义系统状态包括系统正常和偶发异常，以及，所述处理模块具体用于：通过所述状态检测模型，对多个时刻对应的至少一个kpi进行滑动窗口判断，其中，所述多个时刻包括所述第一时刻，以获取第一数据，其中，所述第一时刻对应所述滑动窗口的结束时刻；通过所述状态检测模型，利用前向forward算法对所述第一数据进行拟合概率计算；根据所述第一数据的拟合概率，对所述第一时刻的系统状态进行系统异常判断。
[0200]
可选地，所述处理模块具体用于：当所述第一数据的拟合概率小于第一阈值时，确定对应于所述第一时刻的系统状态处于异常状态，或者，当所述第一数据的拟合概率大于或等于第一阈值时，确定对应于所述第一时刻的定义系统状态为系统正常或偶发异常，并进一步确定对应于所述第一时刻的系统状态处于正常状态。
[0201]
可选地，所述处理模块还用于：确定所述至少一个训练kpi对应的定义系统状态包括：系统正常和偶发异常。
[0202]
可选地，所述装置还包括：输出模块，用于输出对应于所述第一时刻的定义系统状
态，所述定义系统状态包括以下中的至少一种：系统正常、偶发异常、持续异常、系统宕机。
[0203]
可选地，在所述任意两个定义系统状态之间的转移概率中，所述偶发异常到偶发异常、持续异常到偶发异常、系统宕机到偶发异常、系统正常到持续正常、系统宕机到持续异常、系统正常到持续宕机、偶发异常到系统宕机之间的转移概率强制为0。
[0204]
可选地，当所述系统异常判断的结果为异常状态时，所述装置还包括：发送模块，用于发送第一消息，所述第一消息包括所述异常判断的结果。
[0205]
图12示出了本技术实施例的一种异常检测装置的另一结构示意图。该通信装置1200可用于实现上述方法实施例中描述的关于异常检测的方法。该通信装置1200可以是芯片或网络设备。
[0206]
通信装置1200包括一个或多个处理器1201，该一个或多个处理器1201可支持通信装置1200实现图1中的异常检测方法。处理器1201可以是通用处理器或者专用处理器。例如，处理器1201可以是中央处理器(central processing unit，cpu)或基带处理器。基带处理器可以用于处理通信数据，cpu可以用于对通信装置(例如，网络设备、终端设备或芯片)进行控制，执行软件程序，处理软件程序的数据。通信装置1200还可以包括收发单元1205，用以实现信号的输入(接收)和输出(发送)。
[0207]
例如，通信装置1200可以是芯片，收发单元1205可以是该芯片的输入和/或输出电路，或者，收发单元1205可以是该芯片的通信接口，该芯片可以作为终端设备或网络设备或其它无线通信设备的组成部分。
[0208]
通信装置1200中可以包括一个或多个存储器1202，其上存有程序1204，程序1204可被处理器1201运行，生成指令1203，使得处理器1201根据指令1203执行上述方法实施例中描述的方法。可选地，存储器1202中还可以存储有数据。可选地，处理器1201还可以读取存储器1202中存储的数据，该数据可以与程序1204存储在相同的存储地址，该数据也可以与程序1204存储在不同的存储地址。
[0209]
处理器1201和存储器1202可以单独设置，也可以集成在一起，例如，集成在单板或者系统级芯片(system on chip，soc)上。
[0210]
该通信装置1200还可以包括收发单元1205。收发单元1205可以称为收发机、收发电路或者收发器。
[0211]
应理解，上述方法实施例的各步骤可以通过处理器1201中的硬件形式的逻辑电路或者软件形式的指令完成。处理器1201可以是cpu、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field programmable gate array，fpga)或者其它可编程逻辑器件，例如，分立门、晶体管逻辑器件或分立硬件组件。
[0212]
在本技术所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
[0213]
本技术实施例中的方法，如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在计算机可读存储介质中，基于这样的理解，本技术的技术方案或技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本
申请各个实施例所述方法的全部或部分步骤。该存储介质至少包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。