精华内容
下载资源
问答
  • 根因分析调研

    千次阅读 2019-07-09 12:01:33
    根因分析调研 相对异常检测来说,根因分析的资料相对来说比较稀少,以下是整理了相对来说资料比较详细的内容。 通过这些资料可以了解到,根因分析具体需要做哪些工作? 故障根因分析是指根据故障传播图快速找到...

    根因分析调研【7-10】


    相对异常检测来说,根因分析的资料相对来说比较稀少,以下是整理了相对来说资料比较详细的内容。
    通过这些资料可以了解到,根因分析具体需要做哪些工作?
    故障根因分析是指根据故障传播图快速找到当前应用服务 KPI 异常的根本触发原因。故障根因分析系统找出异常事件可能的根因以及故障传播链后,运维专家可以对根因分析的结果
    进行确定和标记,从而帮助机器学习方法更好地学习领域知识。这一系统最终达到的效果是当故障发生时,系统自动准确地推荐出故障根因,指导运维人员去修复或者系统自动采取修复措施

    实例分析1——清华aiops竞赛网站

    根因定位赛题

    实例分析2——美团根因分析文章

    根因分析初探:一种报警聚类算法在业务系统的落地实施

    实例分析3——腾讯

    每天5万条告警和900万的监控指标,腾讯AIOps怎么破?

    实例分析4——清华

    清华AIOps新作:蒙特卡洛树搜索定位多维指标异常

    实例分析5——微软亚洲研究院

    MSRA AIOps多维指标突变定位: iDice

    实例分析6——乌普萨拉大学

    Root-cause analysis through machine learning in the
    cloud

    实例分析7——论文

    Survey on Models and Techniques for Root-Cause
    Analysis

    基于机器学习的智能运维
    HotSpot: Anomaly Localization for Additive KPIs
    With Multi-Dimensional Attributes

    实例分析8——频繁项集开源

    python开源

    单维属性kpi异常定位

    单维属性kpi异常定位,由于单维的指标已经无法再往下进行细化,但是我们可以把多个单维指标组合起来,来用一个组合数据表述某个模块的状态,一旦发生异常,随即进行根因分析。

    单维指标如果发生异常,往往也并非是单维指标自身发生了异常,也可能是由于其他指标发生了异常,比如其调用关系链上的指标集合以及依赖关系上的指标集合,另外我们还可以人为进行指标集合划分。

    那么,我们如何在单维指标kpi上进行异常定位了??

    如何落地?

    [外链图片转存失败(img-Pph6GexH-1562902812849)(./1562743189446.png)]
    比如说,我们针对我们已经有了的异常数据,这个数据是10.1.10.113主机异常;

    针对这个数据,我们如何进行处理操作?

    制作频繁项集

    频繁项集 经常一起出现异常的指标集合

    时间窗口 频繁项集
    2019-07-09 19:39 cpu.iowait.avg1
    2019-07-09 19:40 net.if.in.bytes,net.if.out.bytes
    2019-07-09 19:41 cpu.system.avg1,net.if.in.bytes.net.out.bytes
    2019-07-09 19:42 net.if.out.bytes

    通过对历史异常数据进行窗口划分,得到频繁项集数据

    支持度

    通过对频繁项集的集合进行遍历,我们可以得到以下支持度:

    集合 支持度
    cpu.iowait.avg1 1/4
    net.if.in.bytes 2/4
    net.if.in.bytes,net.if.out.bytes 2/4
    net.if.out.bytes 3/4

    也就是说一个集合子集在所有频繁项集中出现的次数占项集个数的比例

    可信度计算

    可信度计算就是最终求得关联关系强弱的评判标准,
    比如{net.if.in.bytes}–>{net.if.out.bytes} 这条关联规则的可信度就是用二者的支持度除以前者的支持度,公式就是
    s(net.if.in.bytesnet.if.out.bytes)=s(net.if.in.bytesnet.if.out.bytes)s(net.if.in.bytes) s(net.if.in.bytes \rightarrow net.if.out.bytes)=\frac{s( net.if.in.bytes\cup net.if.out.bytes)}{s(net.if.in.bytes)}

    通过对可信度的计算,我们就大概知道从一个指标异常导致另外一个指标异常的可信度是多少,这样就能够在寻找某一个指标异常根因的时候,减少人工耗时,而选用这种方式。

    频繁项分析两种实现方式

    1. Apriori算法
    2. FP-growth算法
      第二种算法是对第一种算法的性能上优化,减少搜索以及计算成本,提高性能。

    具体资料详见:
    算法详解

    HotSpot-多维属性的kpi异常定位

    这篇论文讲的,在多维kpi上进行根因定位,如果某一个多维kpi发生异常,你怎么知道具体是哪些属性发生了变化,是哪些属性导致了最终的异常的发生了?

    这也就是这篇文章要解决的问题。

    HotSpot: Anomaly Localization for Additive KPIs With Multi-Dimensional Attributes

    这篇文章是裴丹老师他们发表的一篇文章,时间在2018年。

    两个挑战

    1、不同组合的多维指标相互依赖,对于定位多维指标异常是在哪一个聚合层次导致了多维指标发生改变是困难的;
    2、当多维指标的纬度大到一定程度,会有成千上万的不同组合是可能导致异常发生的原因,其搜索空间巨大,找到导致异常发生的组合也是困难的;

    整体思路

    针对以上两个挑战,该论文提出了两个主要的解决办法,
    1、基于异常传播的波动影响力计算可能性分值,来解决第一类问题;
    2、用蒙特卡罗搜索树算法以及分级(hierarchical)剪枝策略来解决第二类问题;

    效果

    百分之九十五类型的根因分析,F值能够超过0.9,运维人员的体验显示,该算法能够把根因定位时间从人工1个小时降低到20s。

    主要内容

    基本概念介绍

    pv -page view

    术语 定义 标记 例子
    属性 每一个pv记录的信息类别 ---- 省份(P),ISP(I),数据中心(D),频道(C)
    属性值 每一个属性可能的值 ---- 比如对于省份(北京,上海,广东)
    元素 对于每一个属性的不同值组合向量 e=(p,i,d,c) 例如(北京,* ,* ,*)
    PV 值 一个元素的访问数量 v(ei) v(beijing,* ,* ,*)
    预测值 用历史值预测一个元素未来数值 f(ei) f(beijing, * ,* ,* )
    数据立方体 多维数据的数据结构 n-d 立方体 一个4维数据立方体(p,i,d,c)
    立方体 所给纬度的子集 Bi 比如(Bi,Bp,j,Bp,i,d,w)
    可能性分值 用来衡量一组元素是根本原因的可能性 ps ps(S),S={(beijing, * , * , * ),(* ,mobile, * , *)}

    PV 记录

    一段时间内的pv日志记录
    通过对这些日志记录的统计,比如说,按照每分钟的统计,我们可以得到下边的统计结果:
    在这里插入图片描述
    通过对一段时间内的如上日志统计,我们会得到下边的数据结构
    在这里插入图片描述
    针对四维的PV数据立方体,我们看一下,它可以表示为两个三维立体
    在这里插入图片描述
    对于我们目前一直在谈论的page views的子集组合以及其层次,我们可以分为四个层次

    在这里插入图片描述

    问题再表述
    对于多维kpi,异常定位问题,就是找到导致总kpi数值发生异常变化的最有可能的组合子集。

    在这里插入图片描述

    挑战

    1、如何衡量一个组合会成为根本原因的方式,这种方式并不容易,
    如上面图所示,直觉的会感觉用变化比例,但是这个并不好用。
    文中用h(e)来表示一组组合变化
    比如h(total)=25
    之所以不用变化比例,是因为有的不同组合有可能变化比例相同,难以分清两个,那个可能是根因的可能性大
    2、有很多集合需要被比对,
    之所以很多集合需要被计算,去比对,因为ps这个指标不具备可分解特性,比如ps({e1,e2})!=ps({e1})+ps({e2})

    蒙特卡罗搜索以及分级剪枝

    论文作者受到MCTS在alphaGo上的优秀表现启发,所以准备使用这种方法来在搜索空间中进行最可能根因搜索,而分级剪枝则是受到以下直觉启发:
    如果父亲组成集合不可能是根因组合,那么说明它的每一个孩子组合都不可能是是根因组合。

    hotspot架构全览

    在这里插入图片描述

    依赖

    这种方法依赖异常检测以及预测,虽然有了对于不同组合的统计,但是如果没有相对应的预测值以及检测方法,那就不知道异常是什么,那就无法针对该异常进行根因分析。

    三大核心步骤

    可能性分数计算

    在这里插入图片描述
    我们可以看到这个整体的变化都是由于(beijing,*)造成的,
    v(xi)=f(xi)h(x)×f(xi)f(x),(f(x)0) v\left(x_{i}^{\prime}\right)=f\left(x_{i}^{\prime}\right)-h(x) \times \frac{f\left(x_{i}^{\prime}\right)}{f(x)},(f(x) \neq 0)
    x是一个完整的集合,x‘ 是一个集合中的子集,如果一个组合发生了变化,那么其子集肯定对这个整体的变化有变化贡献,通过以上方式可以计算不同子集的变化贡献。

    可能性分数计算
    1、假设某个组合是根因
    2、新降低的pv数值,
    3、比对新降低的pv值与实际的pv值,越相近,是异常的可能性越大

     Potential Score =max(1d(v,a)d(v,f),0) \text { Potential Score }=\max \left(1-\frac{d(\vec{v}, \vec{a})}{d(\vec{v}, \vec{f})}, 0\right)

    可能性分数的范围就是0-1,分数值越高,是根因的可能性越大

    蒙特卡罗搜索

    在这里插入图片描述

    1. 选择
      先计算每一个组合的可能性分数,然后进行排名,
      Q(s,a)=maxu{s}descendent(s)ps(S(u)) Q(s, a)=\max _{u \in\left\{s^{\prime}\right\} \cup d e s c e n d e n t\left(s^{\prime}\right)} p s(S(u))
      a=argmaxaA(s){Q(s,a)+ClnN(s)N(s,a)} a=\underset{a \in A(s)}{\arg \max }\left\{Q(s, a)+C \sqrt{\frac{\ln N(s)}{N(s, a)}}\right\}
      Q(s, a)执行步骤a的数值,数值越大,执行步骤a的可能性越大

    2. 扩展
      当一个状态s被选择之后,开始进行扩展,增加新的节点S’
      S(s)=S(s){e} S\left(s^{\prime}\right)=S(s) \cup\left\{e^{*}\right\}
      e=maxe{e1,e2,,en}S(s)ps(e) e^{*}=\max _{e \in\left\{e_{1}, e_{2}, \ldots, e_{n}\right\}}-S(s) p s(e)

    扩展标准就是选择一个最大的e* 使得余下的组合有最大的ps(S)

    1. 评估
      初始化扩展后新的节点,计算ps,Q,N
    2. 回溯

    进行以上四步骤,直到满足以下三个条件之一:

    1. 一个最好的组合找到了
    2. 所有可用的节点都被扩展了
    3. 迭代次数已经超过限制,

    分级剪枝

    之前我们就说过了这个剪枝策略,其实这个策略确实和apriori 频繁项集的确实很像,
    为了降低计算成本,我们看个例子
    在这里插入图片描述
    假设在第一层,有两个数据
    BSet1.Bp={(Fujiang, ),(Jiangsu, )} ps(BSet1.Bp)=0.5
    BSet1,Bi={(
    ,Mobile),(
    ,Unicom)} ps(BSet1,Bi)=0.32

    当在我搜索第二层的时候,{(Zhejiang,Unicom)} 就不用再计算了,因为{(Zhejiang, *)} 不在BSet中

    在这里插入图片描述

    在这里插入图片描述

    展开全文
  • 告警根因分析

    2020-11-10 17:22:27
    关于根因分析的一些知识梳理

    关于根因分析的一些知识梳理

    展开全文
  • 故障根因分析告警数据。无线侧故障根因分析,针对现网告警、工单数量大,故障原因定位困难的痛点,将现网历史告警数据和工单中的故障原因定位标注数据相关联,训练分类出停电、软件故障、硬件故障、误告警、传输故障...
  • 【华为云技术分享】根因分析

    千次阅读 2020-01-19 11:46:17
    1. 什么是根因分析 在工作中我们经常会遇到根因分析的提法,有时也称作根原因分析或简称RCA(Root Cause Analysis),那什么是根因分析呢?目前还没有一个公认的定义,一般都是从操作层面来解释怎么进行根因分析的...

    1.  什么是根因分析

    在工作中我们经常会遇到根因分析的提法,有时也称作根原因分析或简称RCA(Root Cause Analysis),那什么是根因分析呢?目前还没有一个公认的定义,一般都是从操作层面来解释怎么进行根因分析的,缺少方法论框架性说明。有些书籍将发现问题和寻找解决方案也纳入根因分析的范围,使什么是根因分析变得更模糊。本文通过梳理相关知识,完善概念和模型,希望能在思维方法层面提供一个理解根因分析的新视角。

    做为思维方法论,会涉及大量抽象概念和逻辑方法,本文把容易混淆的概念重新定义,而对比较清晰的,可以在网上查询到的概念和方法为了行文简洁就不一一列出了。

    根因分析的定义:指在现代管理、科学研究等领域中,带有主观目的性,为彻底解决问题或解释问题而使用的系统的逻辑思维方法以及一套相应的工具。根因分析包括两个步骤,首先通过溯因推理找到造成问题的各种原因,之后再根据原因之间关系,按照需要确定根本原因。

    根因分析的主观目的性是指根因不是一个客观的事物,而是根据人的需要来确定的,同一个事情,根据需要完全可以确定不同的根因。例如,一次车祸的根因既可以是人为操作错误,也可以是车辆质量,这取决于分析的角度。

    根因分析的系统性是指根因分析有明确的思维步骤和工具,并且要求结果可信。我们在日常生活中遇到问题有时也会刨根问底,但主要是基于经验的,没有严格步骤的,得出结论可能是不可靠的。

    根因分析是一种逻辑思维方法,可以做为知识解释和传播,但更重要的,逻辑思维方法也是一种技能,需要长期训练才能得心应手的使用,这点是很多人忽略的。

    根因分析做为现代管理手段,已有很多成型工具,主要有两类,一类是思维激发型工具,例如头脑风暴,一类是展示型工具,帮助梳理思路,例如因果图。这些工具使用效果的好坏和文化习惯有很大关系,要根据情况灵活使用。对激发型工具最核心的要点是通过观点碰撞激发灵感,对展示型工具最核心的要点是要符合麦肯锡的MECE原则,即列举要素时做到“互相独立,完全穷尽”,抓到这些要点后就可以根据情况创造性地使用工具了。比约恩·安德森的《根原因分析:简化的工具和技术》是目前比较受欢迎的关于RCA的书,已经出了第二版,虽然内容还有很多可以商榷的地方,比如根因分析的范围是什么。故障树的名称也有歧义,应该是故障原因树,错误的名字会误导分析。但书中的一些工具方法还是很有参考价值,例如创新型工具TRIZ。

    根因分析做为系统的思维方法和工具,虽然在现代管理、科学研究中应用较多,但日常生活等领域也一样可以使用。

    逻辑思维涉及的一些概念目前定义也比较模糊或深奥难懂,为了帮助理解根因分析,本文也重新进行定义如下:

    因果关系,事物间具有先后顺序的确定性联系称作因果关系。前者为“因”后者为“果”。

    概率关系,事物间具有先后顺序的具有统计特征的随机性联系称作概率关系。抛硬币的动作和结果就是概率关系。

    现象,事物表现出来的,可以观察到或体验到的情况称作现象。

    解释,没有经过验证的原因,一般和结果、现象等词一起使用。比如感冒是身体不舒服的原因之一,如果某一天真的身体不舒服了,感冒可以做为一种解释,经医院确诊后成为病因。

    问题-原因,特指当因果关系中结果是负面的,不好的情况。这对名词在根因分析中经常一起使用。

    2.  问题溯因阶段

    问题溯因指通过对事物现象系统的观察和控制,经过逻辑分析和必要的验证,从而找出原因的过程。找到原因有三类方法:

    1、穆勒五法,是英国哲学家穆勒1843年根据当时的科学实践经验总结的,包含求同法、求异法,共变法,剩余法,求同求异法等五种归纳推理方法。主要是通过观察不同条件下现象的差异来确定原因,详见百度百科:穆勒五法。这里以非典肺炎流行病源调查的例子给大家一个根因分析的感性认识,在非典流行病病源调查中,发现最初得非典的病人都和果子狸有关,那么按照求同法推断,果子狸就是非典病源,不过又花了几年时间,科学家发现蝙蝠的SARS病毒DNA与人传播的有高度相似性,蝙蝠应该经过果子狸把SARS病毒传播给人类造成非典肺炎,蝙蝠可能才是真正病源。这个案例揭示了求同法这类归纳推理结论的局限性,所以确定复杂现象的原因要审慎地验证。

    穆勒五法主要应用在可以对条件和现象进行比较分析的场合,当只有最后结果而没有各种现象可以对比时,可以用下面假说的方法确定原因。

    2、假说,根据已有知识通过类推或者没有类似知识而通过顿悟等方式合理猜测原因或规律的思维方法,这些结果可以通过验证手段检验真假。1910年,德国气象学家魏格纳偶然发现大西洋两岸的轮廓极为相似。此后经研究、推断,1915年发表《海陆的起源》,提出了大陆漂移学说。假说的提出有时是顿悟的结果,这种方法强依赖于个人。

    归纳法的结果天然存在以偏概全的可能性,黑天鹅效应就是最经典的示例。另外有些原因与问题是概率关系,例如器件故障的原因完全可能是量子效应引起的随机故障,所以上述两种方法发现的原因都需要验证,验证方法有三种:

    1.原因可以解释全部已知事实,并且可以预见未知事实。前面说的大陆漂移理论有一点无法解释,大陆漂移的动力在哪?从这个不能解释的疑点出发,1968年法国地质学家勒皮雄又提出板块构造学说,提供了动力的新解释,进一步发展了假说。

    2.发现更深层次的原理,例如在确定非典病源的过程中,科学家通过DNA测序发现蝙蝠和人类的SARS病毒有高度相似性,从而确认病源。

    3.通过数理统计验证,一般用卡方检验。主要用于科学研究这类可以产生大量条件-结果数据的场景。

    3、规则逆推,在软件应用这类可控系统中,一般会预置一些原因定位手段,应用这些手段也可以确定原因,这是一种比较特殊的情况,属于通过规则溯因。

    上述这些查找原因的方法可以统称溯因推理。不过要注意的是溯因推理有时也指1900年代由哲学家皮尔士引入的逻辑方法。因为逻辑学从各个分支逐渐发展,所以问题溯因并没有一个统一的定义,这里只取前者的一般意义,以便沟通。

    利用上面的方法分析一个重大问题时,往往会得到一个复杂的原因树,下面通过例子感受一下。

    某化工公司发生了一次小型爆炸事故,现场人员重伤,设备损坏,生产停产,附近的居民人心惶惶。

    首先,我们要确定探讨的是哪一个结果,工厂减产,社会影响,人员受伤都是这次爆炸的结果,这里我们主要关心人身受伤。之后我们要对现场情况进行观察,了解爆炸的强度,现场的布局,人身的防护情况,受伤的部位。我们会对类似的场景进行比较分析,这期间会采用各种专业方法,如与先进的生产流程比较,查看别人是怎么控制这种安全事故的。经过这些步骤,完成了下面的原因分析树。

    这个原因树有几个特点:

    1.  原因是多层的、链状的,原因与现象是相对而言的,一个原因对上层是原因而对下层而言却是现象。如采购质量差是装备质量差的原因,却是管理失控的现象。

    2.  原因可以有很多分支,如爆炸直接原因就有三类,装备质量差,操作不当,生产工艺差。

    3.  原因是有颗粒度的,比如爆炸这个动作还可以再细分为点火、化学反应等几个阶段。颗粒度的大小取决于实际需要。

    4.  主要原因,次要原因要根据实际情况确定。

    3.   确定根因阶段

    找到了原因树,那怎么确定根因呢?在哲学的定义中,根因是指多种原因中深层次,起决定性作用的原因。不幸的是定义中“深层次”,“决定性作用”的含义是模糊的,很难实际操作。最简单的说,根因就是原因的原因,按照这个定义,其实除了直接原因外,所有的原因都是根因,只是根有深浅而已。不过管理实践中的根因分析是希望找到彻底的解决方案,获取最大的改进效益,有很强的目的性,所以可以把在业务管理范围内,能够实施相应改进方案的最深层原因指定为根因。例如上面的爆炸的例子,采购部可以指定采购质量差做为根因,从而改良管理活动获得举一反三的效益。如果把装备质量差做根因,也可以改进,但不是最大的改进效益,而确定上级管理失控做为根因会造成自己无法形成改进方案。

    对科学研究的根因分析而言,目的是获得最佳解释,根因分析越深入越好,只会受限于技术能力。

    根因分析的注意事项

    观察者的知识、技能,背景不同,对同一现象观察的主观认知也会不同

    现象是由人观察得出的,这就不可避免地造成因对事物的敏感性不同,同一事情会有不同观察结论。对观察者而言,在思考时往往会忽略某些常见或不言而喻的现象,这有助于简化思考的复杂度,但有时这些现象中却隐含着造成问题的关键原因。杰克韦尔奇的自传中有个例子,在他检查工厂时,发现地上有一滩水,对工厂管理者而言,这滩水可能已经习以为常了,对他们而言是正常现象。而韦尔奇从不同层面思考从而发现了工厂管理上的漏洞。所以管理者不能只在屋子里听报告,报告受报告人的影响,即使看起来再全面也难以反映事物的全部。

    原因的探索象一个侦探故事,既要脉络清晰,也要细心,不放过蛛丝马迹。借用罗胖的话:“不抽象,就不能深入思考,不还原,就不知道本来面目”,原因分析既是技术,也是艺术,要不断平衡抽象和细节考察的关系。

    观察者的关注点不同,对同一现象得出的根因也会不同

    在实际工作中,我们最常遇到的是几种原因共同作用,才能产生某种结果的情况,这些原因都有可能分析出自身的根本原因,至于选取哪一个领域进行分析,取决于分析人员所关心的领域。

    例如,因为产品故障引起的大范围电信网络中断事故,网络设计人员从网络设计方面去探求网络可靠性的问题,研发人员会关心到底是什么原因造成产品故障,而产品维护人员会从维护管理角度探讨为什么预防性维护措施没有发挥作用。

    原因所处层级越深,解决难度越大,需要的时间越长,最后的效益越大

    原因是多层级的,原因所处层级越深,解决的难度越大,所花费时间越长,最后效益就越大。根因分析层级要适可而止,根因一般分析到分析者可控的程度即可。但可有意识进行更深入的根因分析,这样有利于对事物的理解。例如下面这个上世纪80年代电视机质量不良的例子,当我们理解这个技术问题背后有管理,社会等深层原因时,对事物就有了新认知。

    问题现象

    电视质量不良

    技术原因

    可能原因是:器件质量不过关,工艺不过关,质量检测不严格。

    管理原因

    出现器件质量不过关的原因:缺乏采购管理流程,或是流程有缺陷,或是降低成本而忽视了质量。

    社会原因

    在80年代中国社会环境整体缺乏管理人才和实施环境。

    地理历史原因

    历史上四面隔离的地理环境造成了中国独特社会环境,闭关锁国,不能引入先进思想。

     

     

     

     

     

     

    作者:华为云专家  秦广溥

     

    华为开发者大会 2020(Cloud)将于 2020 年 2 月 11 日 -12 日在深圳举办,这是华为面向 ICT(信息与通信)领域全球开发者的年度顶级旗舰活动。想要了解更多请戳→传送门

    展开全文
  • 运营商告警数据根因分析方案和代码示例

    千次阅读 多人点赞 2020-06-17 11:09:05
    运营商告警数据根因分析方案和代码示例背景特征工程nlp特征告警标题tfidf告警标题做word2vec词向量挖掘统计特征告警历史统计特征故障历史统计特征小时展开表特征比率特征故障时间rank特征 背景 AIIA巡回赛中国移动赛...

    源码路径:https://github.com/lilihongjava/leeblog_python/tree/master/root_cause_analysis
    数据集:https://download.csdn.net/download/qq_33873431/14944100

    1. 背景

    AIIA巡回赛中国移动赛,无线侧故障根因分析
    无线侧故障根因分析,针对现网告警、工单数量大,故障原因定位困难的痛点,希望选手通过机器学习手段建立模型,将现网历史告警数据和工单中的故障原因定位标注数据相关联,训练分类出停电、软件故障、硬件故障、误告警、传输故障等原因,从而减少实际派单数量并进行优化策略派单。

    2. 数据预处理

    告警数据展示:
    在这里插入图片描述

    故障工单数据展示
    在这里插入图片描述

    去重、故障原因定位(大类)转换为数字、时间格式转换

        label = label.drop_duplicates(['故障发生时间', '涉及告警基站或小区名称', '故障原因定位(大类)']).reset_index(drop=True)  # 去重
        label['故障发生时间'] = pd.to_datetime(label['故障发生时间'])
        label = label.sort_values(by=['涉及告警基站或小区名称', '故障发生时间']).reset_index(drop=True)
        # 故障原因定位(大类)转换为数字
        label['故障原因定位(大类)'] = label['故障原因定位(大类)'].map(cc_label)
    
        data = data[~data['涉及告警基站或小区名称'].isnull()]
        data = data.drop_duplicates().reset_index(drop=True)
        data['告警发生时间'] = data['告警发生时间'].apply(lambda x: x.replace('FEB', '02'))
        data['告警发生时间'] = data['告警发生时间'].apply(lambda x: x.replace('MAR', '03'))
        data['告警发生时间'] = pd.to_datetime(data['告警发生时间'], format="%d-%m-%Y %H:%M:%S")
    

    3. 特征工程

    3.1 nlp特征

    3.1.1 告警标题tfidf

    涉及告警基站或小区名称分组,每组标题join一起
    在这里插入图片描述
    通过tf_idf.fit_transform(feat[‘Product_list’].values.tolist()) , 提取关键词

    3.1.2 告警标题做word2vec词向量挖掘

    对告警标题采用word2vec词向量挖掘,小区分组后按时间排序告警标题,然后按周对告警标题进行训练;
    sentences是一系列sentence,每一个sentence又是一系列word。
    sentences为[[‘SCTP链路故障告警’], …, [‘射频单元交流掉电告警’, ‘射频单元维护链路异常告警’]]
    sentence为:[‘射频单元交流掉电告警’, ‘射频单元维护链路异常告警’]

    word ->   每一个告警标题就是一个词
    doc  ->   根据每一个小区每周按时间排序标题,生成一篇文章
    

    3.2 统计特征

    3.2.1 告警历史统计特征

    按告警发生时间提取统计特征,再通过make_feature按小区名称分组统计,最后按小区名并到故障历史数据中。

    # 告警统计特征
    def alarm_statistics_feature(data):
        # pandas.Period.XX
        data['告警发生时间_mon'] = data['告警发生时间'].dt.month  # 获取时间的月份部分
        data['告警发生时间_day'] = data['告警发生时间'].dt.day  # 获取时间发生月份中的一天。
        data['告警发生时间_dayofyear'] = data['告警发生时间'].dt.dayofyear  # 获取时间在一年中哪一天,1到365
        data['告警发生时间_hour'] = data['告警发生时间'].dt.hour  # 获取时间的小时部分
        data['告警发生时间_weekday'] = data['告警发生时间'].dt.weekday  # 获取该时间所在星期几,星期一=0,星期日=6
        data['告警发生时间_wy'] = data['告警发生时间'].dt.weekofyear  # 获取时间在一年当中的第几周
        data['告警发生时间_是否周末'] = data['告警发生时间_weekday'].apply(lambda x: 1 if x >= 5 else 0)
        data['告警发生时间_int'] = data['告警发生时间'].apply(lambda x: x.value // 10 ** 9)
        data['告警发生时间_diff'] = data.groupby(['涉及告警基站或小区名称'])['告警发生时间_int'].diff()
        return data
    
        data = alarm_statistics_feature(data)
        aggs = {
            '告警标题': ['count', 'nunique'],
            '告警发生时间_是否周末': ['mean'],
            '告警发生时间_hour': ['nunique'],
            '告警发生时间_weekday': ['nunique'],
            '告警发生时间_day': ['nunique'],
            '告警发生时间_wy': ['nunique'],
            '告警发生时间_dayofyear': ['nunique', 'max', 'min', np.ptp],
            '告警发生时间_diff': ['min', 'max', 'mean', 'std'],
        }
        agg_df = make_feature(data, aggs, "_告警")  # groupby小区名称
        label = label.merge(agg_df, on='涉及告警基站或小区名称', how='left')
    

    3.2.2 故障历史统计特征

    对于故障工单历史数据的故障发生时间统计挖掘

    # 故障统计特征
    def failure_statistics_feature(label):
        label['故障发生时间_mon'] = label['故障发生时间'].dt.month
        label['故障发生时间_day'] = label['故障发生时间'].dt.day
        label['故障发生时间_dayofyear'] = label['故障发生时间'].dt.dayofyear
        label['故障发生时间_hour'] = label['故障发生时间'].dt.hour
        label['故障发生时间_weekday'] = label['故障发生时间'].dt.weekday  # 该时间段所在星期几
        label['故障发生时间_wy'] = label['故障发生时间'].dt.weekofyear  # 计算一年当中的第几周
        label['故障发生时间_是否周末'] = label['故障发生时间_weekday'].apply(lambda x: 1 if x >= 5 else 0)
    
        label['故障发生时间_day_count'] = label.groupby(['涉及告警基站或小区名称', '故障发生时间_dayofyear'])['工单编号'].transform('count')
        label['故障发生时间_week_count'] = label.groupby(['涉及告警基站或小区名称', '故障发生时间_wy'])['工单编号'].transform('count')
        label['故障发生时间_hour_count'] = label.groupby(['涉及告警基站或小区名称', '故障发生时间_hour'])['工单编号'].transform('count')
        label['故障发生时间_周末_count'] = label.groupby(['涉及告警基站或小区名称', '故障发生时间_是否周末'])['工单编号'].transform('count')
        label['故障发生时间_weekday_count'] = label.groupby(['涉及告警基站或小区名称', '故障发生时间_weekday'])['工单编号'].transform('count')
        label['故障发生时间_故障发生时间_count'] = label.groupby(['涉及告警基站或小区名称', '故障发生时间'])['工单编号'].transform('count')
    
        label['小区故障时间_min'] = label.groupby(['涉及告警基站或小区名称'])['故障发生时间_dayofyear'].transform('min')
        label['小区故障时间_max'] = label.groupby(['涉及告警基站或小区名称'])['故障发生时间_dayofyear'].transform('max')
        label['小区故障时间_ptp'] = label.groupby(['涉及告警基站或小区名称'])['故障发生时间_dayofyear'].transform(np.ptp)
    
        label['故障发生时间_int'] = label['故障发生时间'].apply(lambda x: x.value // 10 ** 9)
        label['故障发生时间_diff'] = label.groupby(['涉及告警基站或小区名称'])['故障发生时间_int'].diff()
        label['故障发生时间_diff_min'] = label.groupby(['涉及告警基站或小区名称'])['故障发生时间_diff'].transform('min')
        label['故障发生时间_diff_max'] = label.groupby(['涉及告警基站或小区名称'])['故障发生时间_diff'].transform('max')
        label['故障发生时间_diff_mean'] = label.groupby(['涉及告警基站或小区名称'])['故障发生时间_diff'].transform('mean')
        label['故障发生时间_diff_std'] = label.groupby(['涉及告警基站或小区名称'])['故障发生时间_diff'].transform('std')
        return label
    
    
        # 故障历史统计特征
        label = failure_statistics_feature(label)
        aggs = {
            '故障发生时间_是否周末': ['mean'],
            '故障发生时间_hour': ['nunique'],
            '故障发生时间_weekday': ['nunique'],
            '故障发生时间_day': ['nunique'],
            '故障发生时间_wy': ['nunique'],
            '故障发生时间_dayofyear': ['nunique', 'max', 'min', np.ptp]
        }
        agg_df = make_feature(label, aggs, "_故障")
        label = label.merge(agg_df, on='涉及告警基站或小区名称', how='left')
    

    3.2.3 告警标题统计特征

    按涉及告警基站或小区名称,告警发生时间(一年中同一天,一年当中同一周,同小时,同周末和非周末,同星期)分组,统计告警标题次数和唯一值的个数

    def alarm_title_features(label, data):
        # 告警标题统计特征,分组统计'_dayofyear', '_wy', '_hour', '_是否周末', '_weekday'告警标题个数
        for i in ['_dayofyear', '_wy', '_hour', '_是否周末', '_weekday']:
            alarm_happen = data.groupby(['涉及告警基站或小区名称', '告警发生时间' + i])['告警标题'].count().reset_index(
                name='告警发生时间' + i + '_count')
            alarm_happen.columns = ['涉及告警基站或小区名称', '故障发生时间' + i, '告警发生时间' + i + '_count']
            label = label.merge(alarm_happen, on=['涉及告警基站或小区名称', '故障发生时间' + i], how='left')
        # 计算每个唯一值的个数
        for i in ['_dayofyear', '_wy', '_hour', '_是否周末', '_weekday']:
            alarm_happen = data.groupby(['涉及告警基站或小区名称', '告警发生时间' + i])['告警标题'].nunique().reset_index(
                name='告警发生时间' + i + '_nunique')
            alarm_happen.columns = ['涉及告警基站或小区名称', '故障发生时间' + i, '告警发生时间' + i + '_nunique']
            label = label.merge(alarm_happen, on=['涉及告警基站或小区名称', '故障发生时间' + i], how='left')
        return label
    

    3.2.4 小时展开表特征

    通过pivot_table 透视表,值为工单编号,提取每个小区小时(0~23)区间工单数。

     pivot = pd.pivot_table(label, index='涉及告警基站或小区名称', columns='故障发生时间_hour', values=['工单编号'],
                               aggfunc='count').reset_index().fillna(0)
    

    3.2.5 比率特征

    统计故障数据和告警数据的比率特征,发生时间针对小时部分(hour)、所在星期几(weekday)、月份中哪一天(day)、一年当中的第几周(wy)、一年中哪一天(dayofyear)

        for i in ['hour_nunique', 'weekday_nunique', 'day_nunique', 'wy_nunique', 'dayofyear_nunique']:
            label[i + '_ratio'] = label['故障发生时间_' + i + '_故障'] / (label['告警发生时间_' + i + '_告警'] + 1)
    

    3.2.6 故障时间rank特征

     label['rank'] = label.groupby('涉及告警基站或小区名称')['故障发生时间'].rank(method='dense')
    

    4. 训练

    通过xgboost训练数据

     f1_list, logsocre, accuracy_list = xgb_train(X_train, y_train)
    

    5. 模型评估

    print("mean_accuracy=", np.mean(accuracy_list), np.std(accuracy_list))
        print("mean_f1=", np.mean(f1_list), np.std(f1_list))
        print("mean_mlog=", np.mean(logsocre), np.std(logsocre))
    
    展开全文
  • 根因分析(RCA)是一项结构化的问题处理法,用以逐步找出问题的根本原因并加以解决, 而不是仅仅关注问题的表征。在实际工作中,最难的部分是什么叫做根本原因,这一点,没有一个可量化的标准供大家参考,因此很多...
  • 根因分析car

    2019-03-22 16:00:22
    也就是说要对公共原因进行原因分析,并有实际的改善效果,让企业更有能力,而且最好有过程及技术方面的原因分析证据。这些都是在4级的基础上的进一步要求。 SG:Specific Goal SP:Specific Practices...
  • 最近公司有这方面的需求,所以,就找一些论文和资料来了解一下在异常检测基础之上,如何做到对异常或者故障的根因分析。 有两种根因分析的需要,一种就是单指标异常检测,就是指标就是一维的这种,如果这种指标发生...
  • 现场大批量内存泄露问题追溯及根因分析 1. 问题背景 某现场集中在11日和15日的时候,陆续有4台机器出现异常,一台机器出现灭灯的情况,并且重启机器后可以恢复。但是进去查日志,发现并没有检测到物理硬件异常。一般...
  • 根因分析造成跨域的根本原因是,两个资源的协议、域名、子域名、端口不同,而且是只要有一个不同,这种情况下所进行的访问行动都是跨域的。而出于安全性的考虑,浏览器通常会限制跨域访问,不允许跨域请求资源,这是...
  • 什么是问题根因分析 根本原因分析(root cause analysis):通过调查和分析问题哪里出错、为什么出错,寻求防止差错事故再次发生的必要措施,从而提高服务安全和质量。 根因分析目标 问题(发生了什么) 原因(为...
  • 什么是问题根因分析 根本原因分析(root cause analysis):通过调查和分析问题哪里出错、为什么出错,寻求防止差错事故再次发生的必要措施,从而提高服务安全和质量。 根因分析目标 问题(发生了什么) 原因(为...
  • 根因分析造成跨域的根本原因是,两个资源的协议、域名、子域名、端口不同,而且是只要有一个不同,这种情况下所进行的访问行动都是跨域的。而出于安全性的考虑,浏览器通常会限制跨域访问,不允许跨域请求资源,这是...
  • 为何需要根因分析? 当某个宏观的监控指标发生异常时,如果能快速定位到具体是那个细粒度的指标发生了异常而导致的。具体来说,当某个流量发生了异常,具体如图中所示: 这个指标就对应是某个小时级别的流量情况,...
  • 上一篇较为详细地介绍了基于 Redis 的...本文将介绍一组 Redis 实际应用中遇到的异常场景,如 Redis 进程无法拉起、故障倒换失败、Slot 指派失败等,并针对这些异常场景给出根因分析和可供参考的解决方案。 1. red...
  • 智能运维 --- 质量保障 --- 根因分析 机器学习定位故障责任部门 --- 微软NetPoirot 特点 轻量级的持续监控:仅需收集TCP的数据,避免收集整个系统海量的日志(SNMP,网络拓扑,性能指标,程序日志等)。 ...
  • 数据库突发性能问题,有时可能通过重启应用、重新收集统计信息、重启数据库等方法得到临时...根因分析的另外一个重要性就是找到问题的责任方:运维、开发还是数据库产品自身原因(缺陷或是bug),有的问题是单方问...
  • A SURVEY ON THREATS, VULNERABILITIES AND SECURITYSOLUTIONS FOR CELLULAR NETWORK 文章里提到 4GSystem (LTE) SecurityModern LTE cellular networks provide advanced services for billions of users, which e...
  • 根因分析初探:一种报警聚类算法在业务系统的落地实施 2019独角兽企业重金招聘Python工程师标准
  • 根因分析建模 业界已经有好多在做根因分析的了,但是大都准确率不高,大部分还在 40% 到 70% 之间,从侧面说明根因分析确实是一个难啃的骨头。 根因分析看起来很庞大,很抽象,无从下手,从不同的角度(可能是表象...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 473
精华内容 189
关键字:

根因分析