如何提高架构的稳定性、可扩展性和易用性等能力?点击看大咖分享 了解详情
写点什么

智能运维系列(十二)| 智能运维的四大挑战和应对之道

  • 2020 年 9 月 09 日
  • 本文字数:2549 字

    阅读完需:约 8 分钟

智能运维系列(十二)| 智能运维的四大挑战和应对之道

智能运维系列专题已经进入尾声,已经发表的文章从管理和技术上全面解释了微众是如何建设智能根因分析系统的。这篇文章主要阐述作者团队的一些思考。

前文回顾

专题 | 智能时代下的运维


微众银行的 RCA 项目组成立了一年多,一直围绕着异常识别及根因定位开展工作,并以异常识别准确率和根因定位准确率作为最重要的衡量指标。经过这一年多的努力,异常识别准确率从最初每个月的 30%左右到后来基本稳定在 95%以上,根因定位准确率从 50%左右到维持在 85%左右,目前两大指标仍在持续优化中,具体情况如下图:



图 1 异常识别准确率和根因定位准确率月度趋势


作为经历了整个 RCA 项目从 0 进化到当前状态的一份子,在本文中我主要为大家介绍我们所面临过或正在面临着的四大挑战,同时也会分享一些我们的解决办法及经验,希望对大家有帮助。


挑战 1. 及时性和准确率,如何平衡?


金融行业对应用系统运行的稳定性要求很高,关键交易要做到无损服务,那么如何及时的识别问题并通知责任方就非常重要。但如果异常识别算法过于敏感,将会产生很多误告从而对运维同学造成骚扰,“宽松了容易漏告,严格了又会造成骚扰”。经过对一段时间的实际案例的分析判断,我们使用了“算法+经验/规则”结合的方式来维持误告与漏告的平衡。另外,判断误告漏告的标准要尽量做统一、清晰,这样算法在演进的过程中才能不断进步,防止前后矛盾。


当算法识别到一个指标异常时,系统会及时通知业务运维的同学,随着时间的推移,有可能发现更多指标曲线出现异常,不同的异常指标的曲线反应了不同的影响范围。一个检测周期内(一般是 1 分钟)如果识别到了异常,我们先发出异常预警,同时轮询根因定位结果,当异常指标发生变化后,再次启动新的根因分析,如此往复,一旦根因有结果了取最新的结果推送根因,为运维人员提供定位方向。从而在及时性和准确性之间找到一个平衡,具体流程见图 2。由于目前整个根因分析过程在 2 分钟之内完成,结果也相对稳定,故我们目前只在图 2 中的 1、3 进行推送,避免短时间内多次推送消息造成骚扰。



图 2 异常推送策略


挑战 2. 算法和经验/规则,哪个更有效?


RCA 是一个 AI 算法工程化的项目,开始时我们更倾向于使用算法来实现所需功能,但算法的调参过程周期比较长,对于一些根据专家经验较明显的特征,通过加一些规则能更快的达到预期效果。经过我们的实践,无论是在异常识别方面还是根因定位方面,“算法+经验/规则”都是更加快速有效的解决方案。


在异常识别方面,通过算法已经可以覆盖大部分异常场景的识别,这可以达到 RCA 的早期目标。随着 RCA 项目的持续推进,标准和要求越来越高。有一段时期,运维人员常常反馈我们识别的异常是误告,我们通过分析这段时间的异常事件,发现大多运维人员认为是误告的事件都是时延指标突增。有些时延指标波动的确较大,常常出现毛刺(见图 3),对比历史来说,这些毛刺都是小概率事件,算法判断为异常,但对于运维人员来说,把毛刺当做异常显得过于敏感,如果每个毛刺都投入人力分析也不现实。


为了快速调整这种因为算法太敏感导致的误告,我们想到传统异常识别中常用的思路——设置阈值,相当于人工观察几分钟,如果只是毛刺就暂且忽略不当做异常,如果持续时间超过阈值才当做异常。如果仅通过调整算法来解决这个问题可能需要更多的时间去调参以适配所有指标曲线。当然,这种做法也有弊端,例如对专家经验的依赖大,当指标曲线的行为发生变化时很难及时发现从而及时调整参数,所以后续我们也会将“观察分钟数”参数由人工定义优化为算法自动学习自动调整。



图 3 时延指标毛刺


在根因定位方面,我们依然选择使用“算法+经验/规则”的方式,包括将专家经验进行总结,沉淀到算法中。


挑战 3. 实时数据和历史数据,哪个更可信?


在异常识别中,常规做法就是使用历史曲线的趋势来预测实时曲线的趋势。而在根因定位中,我们最初只重点关注了实时数据,忽略了历史数据。那么历史数据在根因定位中是否也同样具有参照意义呢?经过实践证明,在根因定位中历史数据也和实时数据一样重要。


基于“拥有相似特征的异常事件极大可能是同一根因导致的”,我们对所有的异常事件进行了特征提取及根因分类,形成了历史事件库,使用神经网络算法训练模型,当出现新的异常事件时,我们提取新事件的特征,通过根据历史事件库训练出的模型,得出新异常事件最可能属于哪些根因类别,每个根因类别会计算出一个相似度(异常属于这个根因类别的可能性),再与异常发生时挖掘到的实时数据做匹配,那么匹配值最高的就最可能是这个事件的根因,这个过程见图 4。


例如根据模型计算出新事件的根因类别可能是数据库异常,而实时数据中存在数据库变更、数据库主机告警等信息,那么匹配值会非常高,从而推断出这个事件极有可能是数据库变更或数据库主机异常导致。而当新事件从未出现过,提取的特征不能很好的推断出这个事件属于什么根因类别,即根据历史事件库训练出的模型新异常事件属于各根因类别的可能性都较低时,我们选择相信实时数据的分析结果,不和历史数据做匹配,这样也对这部分事件的根因定位进行了覆盖。



图 4 结合历史数据和实时数据进行根因定位


挑战 4. 当掌握全面的信息时,如何聚焦到有用的信息上?


根因定位掌握的数据源越多越好,挖掘到的数据越全面越好,但我们需要用有效的方式去评估各类数据源以及各类数据的置信度。


对于信息使用者来说,并不需要看到底层的所有数据,他们更希望直接看到对他们最有用的数据,甚至只想看到最终的结论——我该做些什么来处理这个异常?而做到这一点实现数据可视化就很重要,我们需要从繁杂的数据中找到信息使用者最想要了解和最需要关注的数据,形成主要的推导链,让信息使用者聚焦到这些有用的数据上,在能快速了解推导过程的同时建立起对推导方式的认同和信赖,从而快速采取对应的措施来解决异常。


所以无论是实现方还是信息使用者,都希望可以一眼看到最有用的信息。面对这个诉求,我们通过图形化的推到展示推到过程。



图 5 根因定位推到可视化


以上就是在我们在智能根因分析过程中的面临四个挑战以及我们的一些思考,欢迎面临同样挑战或有好的解决方案的朋友和我们交流。如果希望了解我们在智能运维中使用的机器学习算法以及支持根因分析的具体方法,请参阅该系列其他文章。


作者简介


微众银行智能运维系统高级产品经理 孙芮


2020 年 9 月 09 日 14:061964
用户头像
陈思 InfoQ编辑

发布了 576 篇内容, 共 228.4 次阅读, 收获喜欢 1254 次。

关注

评论

发布
暂无评论
发现更多内容

【架构实战营】模块2作业

dragonboa

微信朋友圈高性能复杂度分析设计

小荷才露尖尖角

#架构实战营

朋友圈高性能复杂度

Simon

架构实战营

架构0期作业2

sjj

Ansible 安装

耳东@Erdong

ansible 4月日更

微信朋友圈 高性能分析

return

架构实战营模块 2 作业

梦寻解语花

架构实战营

架构实战营模块2作业

林子钧

作业 架构实战营 模块二

SQL 子查询怎么优化?写的很深的这种!

xcbeyond

sql SQL优化 4月日更

架构实战营 模块二

Keyto

模块二-微信朋友圈的高性能复杂度

华仔架构训练营

架构训练营模块2作业

唐江

架构实战营模块 2 作业

Lukefang

架构训练营-模块二作业

Neil43

架构训练营

Golang interface and error handle

escray

学习 极客时间 Go 语言 4月日更

架构实战营-M02H

赤色闪电

微信朋友圈高性能复杂度分析

thewangzl

作业 - 分析一下微信朋友圈的高性能复杂度

a1vin-tian

架构实战营

架构实战营模块 2 学习总结

林子钧

总结 架构实战营 模块二

架构师实战营 模块二作业 微信朋友圈高性能架构分析

小遵

架构学习模块二作业

架构实战营

「架构实战营」第二次作业

高亮

架构实战营

架构实战营 模块二作业

Dylan

架构实战营

架构实战营模块二作业

hunk

架构实战营

微信朋友圈架构设计

Vincent

#架构实战营

Java-技术专题-CountDownLatch的介绍和使用

浩宇天尚

Java AQS CountDownLatch JUC

产品经理训练营Week14学习心得

Mai

华仔架构-模块

大师兄

架构实战营-作业2

大肚皮狒狒

作业

算法训练营 - 学习笔记 - 第三周

心在飞

模块二作业-架构训练营

架构训练营

“芯”有灵“蜥” 走进 Intel MeetUp

“芯”有灵“蜥” 走进 Intel MeetUp

智能运维系列(十二)| 智能运维的四大挑战和应对之道_AI_孙芮_InfoQ精选文章