SRE 实践:服务可靠性案例课
白园
前百度资深运维专家,前快手资深 SRE 专家
1866 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已更新 24 讲/共 29 讲
SRE 实践:服务可靠性案例课
15
15
1.0x
00:00/00:00
登录|注册

20|AIOps 问题定位:如何在报警风暴中找到暴风眼?

你好,我是白园。
今天我跟你分享一下 AI 在故障定位领域解决了哪些问题。AI 与故障定位的方向基本分为三个方向:多维归因分析、因果推断、重复(相似)问题定位,我们一个个看。

多维归因定位

在一次故障中,我注意到网盘上传流量出现了阴跌。经过调查,我们发现是电信服务出现了问题。进一步分析后,我们确定故障发生在广东电信。后续我们发现这次事件凸显了一个问题:在众多指标中,如何快速准确地识别导致问题的主要因素是一个非常大的挑战。比如如何快速定位到是广东电信的问题,其中用到的方法就是多维定位。
面对流量下降的问题,关键在于识别导致下降的具体维度,并进一步深入分析。首要任务是确定波动发生在哪个维度。你可以看一下示意图,在机房和年龄这两个维度下,所有子维度都显示出波动;然而,当从运营商维度进行观察的时候,只有移动运营商的流量出现了异常,其他运营商的流量则保持正常。这里我们就可以判断是运营商的问题。
你可以看一下示意图,我们考虑上传量下降的情况。上传量同比下降了 20%,我们从机房、运营商、年龄三个维度进行横向分析。如果某个维度的子维度中仅有 1~2 个显示有问题,那么很可能是该维度导致了整体下降。
具体来看,机房维度可以细分为 A 机房和 B 机房。如果 A 机房和 B 机房的同比下降均为 20% 左右,这表明机房维度并非问题所在。同样,如果所有年龄段的上传量都呈现下降趋势,那么年龄维度也可以排除。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
  • 解释
  • 总结

1. AIOps在故障定位领域解决了多维归因分析、因果推断、重复问题定位等问题,通过多维归因定位可以快速准确地识别导致问题的主要因素,利用算法如Attributor、HotSpot和Divisia分解法进行多维数据分析和根因定位。 2. 多维归因定位方法包括总量贡献度分析、日常占比分析和差异性分析,通过分析不同维度和元素的“惊喜度”和“解释力”来量化和识别可能导致关键性能指标异常波动的因素。 3. 因果推断包含关联性的发现、干预验证和反事实推理,通过分析服务调用链的异常和故障,可以进行因果推断,确定是哪个服务导致了整个调用链出现问题的原因。 4. 通过算法和方法的应用,AIOps在故障定位领域能够帮助快速定位问题根源,提高故障排查效率和精度。 5. 通过多维归因分析和因果推断,可以有效解决报警风暴中的问题,帮助定位故障的暴风眼,提高故障排查的准确性和效率。 6. AIOps在故障定位领域的发展和应用,为提高系统稳定性和可靠性提供了重要的技术支持和解决方案。 7. 在处理重复类型故障时,相似度检查是定位问题的关键。这通常涉及到对故障特征的提取和比较,以便快速识别和解决类似问题。 8. DejaVu系统实现了面向重复类型故障的可操作故障定位,通过自动化、可执行且可解释的方式,对在线服务系统中的重复故障进行定位。 9. 多维归因分析适用于存在外部因素导致的原因,因果推断适用微服务多层链路调用的情况和定位,重复问题定位适用无直接调用的情况。这些方法可以显著提升故障诊断的速度和准确性,帮助我们从海量数据中迅速识别问题的根源。 10. 如果有一天业务的流量突然下降,定位思路和步骤包括提取关键特征、搜索类似故障、故障诊断和知识库更新,以最快的速度定位到原因。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《SRE 实践:服务可靠性案例课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(1)

  • 最新
  • 精选
  • 若水清菡
    如果有一天你发现业务的流量突然下降了,这个时候你的定位思路和步骤是什么?怎么做才能够以最快的速度定位到原因? 1.查看接入层的统计,对比其他业务流量变化趋势,如果发现只有这个业务流量明显下降了,可以确定是这个业务的问题,和接入层无关;用第三方拨测平台在全网对业务接口进行一下测试,排查一下网络运营商侧情况。 2.查看业务层的服务指标统计,对比现在和昨天同时间段的吞吐、响应时间等。排查是不是业务代码这边出的问题,同时回溯最近两天的服务代码、配置文件和基础组件的变更历史。 3.如果上面排查都没问题,和产品和运营同学确认业务是否有季节性周期属性,例如受学生寒暑假影响就会流量低;确认app是否进行过发版,排查app端的打点日志,排查是否因为app发的新版引起的故障。 4.所有的都做完了也没任何发现,翻看一下故障历史记录,可能能找到灵感。
    2024-08-28归属地:北京
收起评论
显示
设置
留言
1
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部