一、背景介绍1.1程序员的烦恼作为开发运维等IT从业者，我有过类似的经历：睡觉时被电话吵醒，正在开机玩的时候值班，玩的时候有故障通知我处理。作为一名程序员，我们时刻想着利用信息技术为他人解决问题，提高效率，节约成本。随着微服务架构的快速发展，带来了一系列复杂的调用环节和海量数据。对我们来说，故障排除是一个很大的挑战。查找故障原因犹如大海捞针，费时费力。1.2现状分析vivo建立了完整的端到端监控体系，涵盖基础监控、通用监控、调用链、日志监控、拨测监控等，这些系统每天都会产生海量的数据。如何利用好这些数据，挖掘数据背后的潜在价值，让数据更好地为人们服务，成为监控系统探索的方向。目前业内很多厂商都在探索AIOps。业界有一些优秀的根因分析算法和论文，也有厂商分享了他们在故障定位实践中的解决方案。vivo有比较完善的监测数据，行业也有比较完善的分析算法和解决方案。将两者结合，即可运行故障定位平台，从而解决困扰互联网领域的定位问题。接下来我们看一下实现的效果。2.实施效果目前主要关注平均延迟指标的问题。切入场景包括主动查询和调用链告警两种。2.1主动查询场景当用户反映某个应用运行缓慢或超时时，我们的第一反应可能是查看对应服务的响应时间，定位问题原因。通常，这两个步骤是分开进行的，需要一系列的监控工具，费时费力。如果使用故障定位平台，只需要从vivo的paas平台进入故障定位首页，找到故障服务和故障时间，剩下的交给系统。2.2告警场景当收到平均响应时间问题的调用链告警时，只需查看告警内容下方的链接即可查看原因，故障定位平台可以帮助我们快速定位到可能的原因。下图为调用链告警示例：图1调用链告警调用链是vivo服务级别监控的重要手段，上图中红框内的原因链接是vivo提供的根因定位能力故障定位平台。2.3分析效果通过以上两种方式进入故障定位平台后，首先看到的是故障现场。下图显示了服务A的平均响应时间突然增加。图2故障现场上图红框区域，服务A从10:00左右开始增加，平均每分钟延迟从78ms增加，到10:03突然增加到90ms左右，直接点击图2中蓝色的【根本原因分析】按钮，可以分析出下图中的结果：图3根本原因分析结果从点击按钮到定位原因，系统是如何做到的？下面我们来看一下系统的分析过程。3.分析流程图4分析流程红色箭头部分组成递归调用图4为根因分析的主要流程，下面详细介绍：第一步：前端传递异常服务名称和时间作为参数通过后端接口；第二步：后台执行分析函数，分析函数调用检测算法，检测算法分析后，返回一组下游数据给分析函数（包括下游服务和组件，波动方差和pointType）；第三步：解析函数根据pointType进行不同的逻辑处理。如果pointType=END_POINT，分析结束。如果pointType=RPC_POINT，则将下游服务作为入参，继续解析函数，形成递归。RPC_POINT包括组件：HTTP、DUBBO、TARSEND_POINT包括组件：MYSQL、REDIS、ES、MONGODB、MQ最终分析结果显示服务异常的主要环节和原因，如下图所示：图5链接和原因在在整个分析过程中，分析函数负责调用检测算法，并根据返回结果决定是否继续下钻分析。核心逻辑在检测算法中实现。接下来，让我们看看检测算法是如何工作的。4检测算法4.1算法逻辑检测算法的总体逻辑是：首先对异常业务进行分析，标记开始时间、波动开始时间、波动结束时间。然后根据开始时间~波动结束时间，通过组件和服务名称对异常服务进行下钻，将得到的下游服务时间线分为正常区域（开始时间~波动开始时间）和异常区域（波动开始时间~波动结束时间），最后计算出每个下游服务的波动方差。大致流程如下图所示：图6检测算法图中异常服务A调用下游两个服务B和C，先标记服务A的开始时间、波动开始时间、波动结束时间，然后划分下游服务按时间线分为正常区和异常区两个。标准是开始时间到波动开始时间属于正常区域，波动开始时间到波动结束时间属于异常区域。那么波动率方差与异常原因之间的关系是什么？实际上，波动方差代表了当前服务波动的一个量化值。有了这个量化值，我们利用K-Means聚类算法对波动方差值进行分类，将波动大的归为一组，波动小的归为一类。如下图所示：图7K-Means聚类最后，我们通过聚类簇的波动方差过滤掉波动较小的簇，找出最有可能导致服务异常的原因。以上是对算法原理的简单介绍，接下来我们更进一步，深入算法实现的细节。4.2算法实现(1)分割时间线：将异常时间线从中点一分为二，如下图所示：图8分割时间线(2)计算波动的标准差：使用二次指数平滑算法进行数据预测上半部分，然后根据观测值和预测值计算波动标准差，如下图：图9波动标准差的计算(3)异常波动范围的计算：时间线下半年大于3倍波动标准差为异常波动，下图中红线代表3倍波动标准差，所以异常波动就是红线上方的时间线，如图下图：图10异常波动幅度计算（4）时间点标记：红线与时间线相交的时间点sect第一次为波动开始时间，红线最后一次与时间线相交的时间点为波动结束时间，开始时间和波动结束时间关于波动开始时间对称，如图下图中：图11时间点标记（5）下钻服务：根据startFrom时间到波动结束时间，按组件和服务名称下钻到异常服务，得到下游服务时间线，如图下图：图12服务下钻(6)计算正常区域的平均值：下游服务的前半部分为正常区域，下游服务的后半部分为正常区域。半截为异常区域，先求正常区域的平均值，如下图：图13计算正常区域的平均值(7)计算异常区域的波动方差：计算波动方差根据异常区域的波动点与正常区域的平均值之间的波动和波动比例，如下图所示：图14异常区域波动方差的计算（8）时间线过滤：过滤掉时间线波动方向相反且波动比例小于总波动比例1/10的，排除正常时间线，如下图：15时间线过滤(9)对剩余的下钻时间线进行KMeans聚类，如图下图中：图16进行KMeans聚类五、小结1.一个小而美的rootcause定位算法，使用variancequantificationFluctuations，一个然后通过排除法过滤掉波动小的下游，留下可能的下游作为原因。该算法可以利用我们比较完整的链路数据，成本较低的实现；2、对于下游依赖场景的原因定位，准确率可达85%以上。但不包括因自身原因造成的故障（如GC、变更、机器问题等）；3、分析结果只能提供大概线索，最后一公里仍需人工干预；4.故障定位是AI领域的项目，开发方式与传统敏捷开发有一定区别：角色职责：领域专家（提问）→AI专家（算法预研）→算法专家（算法实现与优化）→应用专家（工程开发）操作步骤：研究论文和git（工业界、学术界、同行）→交流→实践→验证项目实施：把复杂的问题简单化，先做简单的部分；把一般问题专门化，找出具体案例，先解决具体问题。六、未来展望1、故障预测：目前主要关注服务出现异常后如何检测异常，定位根源。未来是否可以通过一些现象提前预知故障，将干预的时间点左移，防患于未然；2、数据质量治理：目前我们有监控数据，但是数据质量参差不齐，数据格式差异很大（比如日志数据和指标数据）。我们在做机器学习或者AIOps的时候，想要从中学习到一些有价值的规律，其实是相当困难的；3、经验知识：目前我们很多专家经验都在运维和开发同学的脑海里。如果这些经验是有知识的，那么对于机器学习或AIOps将非常重要。宝贵的资产；4、从统计算法到AI算法的演进：我们现在其实是用统计算法来进行故障定位，而不是AI。统计数据通常是对强关系的描述，而人工智能则偏向于较弱的关系。它可以基于统计算法，然后通过AI算法进行优化。
