机器学习有可能彻底革新根本原因分析,但它必须克服数据、计算和可解释性方面的挑战。
译自 Machine Learning for Automated Root Cause Analysis: Promise and Pain,作者 Yuval Lev 是零检测生智能先驱 Senser 的 CTO 和联合创始人,他曾在云原生网络解决方案领导者 DriveNets 锻炼了自己的技术领导力技能。Senser 最近被评为 Intellyx 2023 年数字创新者.. 继续阅读 Yuval Lev 的内容
让我们设想一个世界,在任何系统性能下降的那一刻,就能立即确定根本原因:
Maria,一位电子商务网站的可靠性工程师,收到一条警报,由于高于正常水平的失败率,该网站的结账成功率在过去 30 分钟内下降了 15%。使用传统的监控工具,要花费数小时进行人工分析和故障排查。
相反,几秒钟内,Maria 的 AIOps 平台就会发送一条通知,显示根本原因: 支付微服务所依赖的组件性能下降,导致交易处理时间延长。最新版本的支付服务无法处理之前版本的规模。
AIOps 平台还会详细列出此事件涉及的所有受影响组件和 API。有了这些洞见,Maria 立即知道了问题的影响范围和范围。她只需通过回滚对支付服务的最后一次更新,就可以快速解决问题,结账成功率得以恢复,没有进一步影响客户。从收到警报到解决问题不到 5 分钟。
这种自动化的根本原因分析能带来巨大的好处:
这一承诺似乎太美好了。事实上,生产级机器学习流水线用于根本原因分析的道路上确实存在许多障碍。
要理解原因,可以将生产环境想象成一辆汽车。你在高速公路上行驶时,发动机开始发出噪音、抖动,最终熄火。如果你试图用机器学习算法来取代机修工识别根本原因,你可能会遇到哪些挑战?
让我们进一步探讨阻碍自动化根本原因分析的这些缺陷:
ML 模型只能在可访问的数据中发现模式。如果没有现有的拓扑结构来映射成千上万个相互依赖的服务、容器、API 和基础设施元素,模型就没有途径来遍历跨域的故障。
手动创建这种拓扑结构是非常复杂的,有时甚至是不可能的,因为生产环境会动态地跨混合云基础设施进行扩展。
即使有了拓扑结构,在事故期间进行搜索也会带来可扩展性问题。现有的机器学习库无法处理生产因果分析。
要诊断结账失败,我们应该评估支付 API 还是数据库集群?直觉上,工程师会优先考虑与收入交付相关的服务。但通用的机器学习技术缺乏这种推理能力,迫使跨所有拓扑层次进行指数级搜索 —— 就像在汽车发动机的每一寸地方都放一个麦克风一样。
需要先进的算法在事故期间遍历拓扑图,根据业务关键性来权衡和过滤选项。无论是简单还是错综复杂的故障链,都必须解开 - 在收入和信任消失之前。
最后,ML 故障排查带来了一个新的挑战: 如何使推理对人类可解释。在指标数据中识别模式会揭示事件之间的统计相关性,但不会显示因果优先链:
但是这种诊断并没有回答以下能为工程师提供可操作洞见的问题:
解决这个最后一英里问题需要捕获和可视化根本原因概率、业务影响顺序、风险级别和缓解建议的模型。
虽然核心机器学习技术显示出前景,但需要专门构建的解决方案来解决生产规模的因果分析的复杂性。结合专门的拓扑推理、启发式图搜索算法和可解释的数据科学,就可以释放自动化根本原因分析的力量。但这需要在数据收集、服务映射、ML 和技术洞见传达方面取得进展 - 目标是修复。
要了解更多关于 Kubernetes 和云原生生态系统的信息,请于 3 月 19 日至 22 日与我们一起参加在巴黎举行的 KubeCon + CloudNativeCon Europe 活动。