智能平台或系统中的归因、根因分析案例集锦
留个坑位,记录看到的工业界比较好的,系统归因、根因分析的案例
文章目录
- 1 AIOps在小红书的探索与实践——故障定位与诊断
- 2 准确率89%,携程酒店大前端智能预警归因实践
- 2.1 Adtributor算法
- 2.2 Pearson相关系数(Pearson Correlation Coefficient)
- 2.3 滑动T检验(Moving T test , MTT):突变点检测
- 3 聚焦电商场景,详解抖音集团埋点及归因分析方案
1 AIOps在小红书的探索与实践——故障定位与诊断
https://mp.weixin.qq.com/s/5KOpCFJ0SuWQ-qe9_U4Qyg
小红书AIOps现状
关联团队建设
AIOps体系中的演进顺序如下:
学术界关于微服务根因定位的研究层出不穷:
在行业内,在根因分析领域主要有如表4.2的相关实践和分享,主流思路还是基于rpc或trace调用链路进行根因分析。
变点检测算法:
对于类QPS指标,通常具备趋势,直接使用孤立森林算法检测,在其上升期很难识别出异常下跌波动。如下图所示,我们使用MSRA提出的SR-CNN[20]方法,对原始时间序列做一个频域变换,获得Spectral Residual(SR,谱残差)序列,放大这种波动,然后再基于孤立森林识别出这种变点。
RCSF(异常频繁项集挖掘) - 根因分析
RCSF[14]从告警出发,认为通过挖掘调用链路图上异常最集中的的部分可以找到根因
通过RCSF的确可以很容易找到异常最集中的区域,因此我们基于上述生成的异常拓扑并结合RCSF的思路实现了一个异常拓扑排序方法,和RCSF有所不同的是,在生成调用路径序列时,我们使用的是风险/异常节点到任意其他风险/异常节点的路径
时间序列离群分析
该方法针对系统指标异常,有些情况下的单机异常并不会在Exception上反应出来,比如单机CPU跑满,但是不存在相关的Exception。使用DBSCAN聚类的方法对系统指标进行离群分析,提取出这种单机异常序列。
2 准确率89%,携程酒店大前端智能预警归因实践
准确率89%,携程酒店大前端智能预警归因实践
考虑到对异常数据进行本身根因的分析、与其相关的其他问题导致情况、趋势问题等各类问题归因,使用了以下三种算法模型:
- Adtributor算法
- Pearson相关系数
- 滑动T检验
2.1 Adtributor算法
文章没有看明白,需要自行探索了
归因系统需要对检测到的异常指标进行维度分析和根因定位,而Adtributor算法非常适用于这个场景。
首先对异常指标进行维度拆分,维度拆分意在从预警结果的诸多维度中,分析出哪几个维度对一条预警造成的影响最大。
使用Adtributor算法来实现维度拆分主要包括以下几个步骤:
- 1)数据收集:以pv、uv作为参考指标KPI,将预警结果和预警池作为数据源,按维度构造原始数据集。
- 2)异常检测:采用ARMA时间序列模型对KPI进行实时预测,将预测值F和真实值A对比,判断KPI是否发生异常。
- 3)维度分析:Adtributor对异常KPI的所有维度和元素计算EP值和S值,从而定位到影响程度最大的维度。
2.2 Pearson相关系数(Pearson Correlation Coefficient)
通过 Adtributor算法定位深度原因,没有充分利用uv、pv的趋势变化,而事实上趋势的变化是预警判断时的重要依据,因此这里补充使用了另外一种基于趋势的相似度计算方法来定位预警的深度原因
对预警明细表基于每个维度聚合,得到21天的pv、uv值作为特征表。然后对于每一条预警数据,以及待匹配的深度类型,都从特征表中获取相关特征,然后计算特征间的相似度。
2.3 滑动T检验(Moving T test , MTT):突变点检测
对于每条预警信息,首先获取当天分钟级别的pv、uv值,分别作为两组特征变量。对于每一组特征变量,使用滑动T检验(Moving T test , MTT)算法来定位发生突变的时刻。
滑动t检验是通过考察两组样本平均值的差异是否显著来检验突变。其基本思想是把序列中两段子序列均值有无显著差异看作来自两个总体均值有无显著差异的问题来检验。如果两段子序列的均值差异超过了一定的显著性水平,则可以认为有突变发生。
3 聚焦电商场景,详解抖音集团埋点及归因分析方案
详解抖音集团埋点及归因分析方案
构建归因平台的原因,这主要是为了解决以下两个问题:
- 产品的迭代影响归因逻辑,归因数据问题滞后:当前产品有许多策略,如调整用户路径结构、增加实验等,但这些实验往往无法及时同步到数据侧处理。
- 归因策略只能靠文档管理,口径不易理解,问题难排查:在归因的落地过程中,数据团队发现很多归因口径只能通过文档来管理。
归因平台主要通过3个核心要素来解决整体的归因问题。
- 标签化:对于新增的点位,需要确定它的性质。如果在业务层面上不涉及任何归因,那么它可能只是一个路过页。归因平台会提供丰富的标签,为这个点位打上合适的标识,比如入口页或末次归因等。
- 对应策略配置:根据不同的页面类型,需要决定如何处理。例如,当遇到一个入口页时,是将其截断,还是根据其类型定义相应的业务逻辑,这可能涉及到因子数的配置。
- 生成对应数据加工任务:最后,将入仓的硬编码转化为整个归因平台上的配置信息,然后通过 UDF 管控进行落实。