机器学习自动根因分析：期许与悲伤

机器学习有可能彻底革新根本原因分析，但它必须克服数据、计算和可解释性方面的挑战。

译自 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 分钟。

这种自动化的根本原因分析能带来巨大的好处:

• 快速检测:对"影响范围"的分析 - 将警报指标与潜在的服务降级和中断联系起来 - 在几秒钟内完成。
• 减少警报疲劳:通过整合警报并形成生产问题的连贯画面，自动化根本原因分析可以集中于需要修复的核心问题。
• 精确定位:跨所有层次的确切根本原因都会得到指示，并附上其对网站可靠性和收入的概率影响。
• 更快恢复:通过从一开始就了解根本原因和影响范围，团队可以精确地缓解问题，而不是被动地扑救火灾。
• 主动预防:随着时间的推移，会出现显示系统性缺陷的模式，例如需要故障转移配置的 Redis 集群，团队可以进行针对性改进。
• 指数级投资回报:停机时间 x 平均恢复时间 (MTTR)减少 + 工程师时间节省 + 客户忠诚度提高 + 风险/责任减少。当采用云设计的机器学习自动化具有高级数据收集功能时，资本支出(CapEx)也会减少。

为什么机器学习故障排查很难

这一承诺似乎太美好了。事实上，生产级机器学习流水线用于根本原因分析的道路上确实存在许多障碍。

要理解原因，可以将生产环境想象成一辆汽车。你在高速公路上行驶时，发动机开始发出噪音、抖动，最终熄火。如果你试图用机器学习算法来取代机修工识别根本原因，你可能会遇到哪些挑战?

• 无线连接图: 每个传感器、执行器、泵的位置在里，它们如何组合在一起?汽车每个零件的制造商是谁，如果其中一个零件损坏，你在哪里可以采购新的零件?如果没映射所有依赖关系的多维拓扑结构，机器学习模型就没有任何上下文来遍历相互关联的故障。手动创建这种布线图在大规模况下是极其复杂的。而且，当你需要在生产事故中实时获得答案时，情况只会变得更加困难。
• 未考虑盲点: 汽车维修或翻新过多少次，它有哪些第三方零件?仅依赖用户提供的遥测数据往往会在所有生产层次上留下盲点，造成空白，使自动分类几乎不可能。需要另一种方式来收集完整的环境数据。
• 无法从过去的经验中推理: 如果你开同一辆车很长时间，你可能会凭直觉知道是发电机故障、悬挂系统松动还是飞轮损坏导致了你的问题。机器学习模型缺乏这种将可能的罪魁祸首与业务影响(如结账转化率下降)联系起来的能力，从而降低噪音。
• 诊断结果的传达: 一旦确定了导致故障的根本原因(如缸垫损坏)，机修工仍需向车主解释诊断结果和严重程度。对工程师和客户来说也是如此 - 普通的机器学习模型相关性无法帮助到这一步。

让我们进一步探讨阻碍自动化根本原因分析的这些缺陷:

1. 缺乏机器可读的系统拓扑结构

ML 模型只能在可访问的数据中发现模式。如果没有现有的拓扑结构来映射成千上万个相互依赖的服务、容器、API 和基础设施元素，模型就没有途径来遍历跨域的故障。

手动创建这种拓扑结构是非常复杂的，有时甚至是不可能的，因为生产环境会动态地跨混合云基础设施进行扩展。

1. 大规模根本原因推理

即使有了拓扑结构，在事故期间进行搜索也会带来可扩展性问题。现有的机器学习库无法处理生产因果分析。

要诊断结账失败，我们应该评估支付 API 还是数据库集群?直觉上，工程师会优先考虑与收入交付相关的服务。但通用的机器学习技术缺乏这种推理能力，迫使跨所有拓扑层次进行指数级搜索 —— 就像在汽车发动机的每一寸地方都放一个麦克风一样。

需要先进的算法在事故期间遍历拓扑图，根据业务关键性来权衡和过滤选项。无论是简单还是错综复杂的故障链，都必须解开 - 在收入和信任消失之前。

1. 人类可解释性

最后，ML 故障排查带来了一个新的挑战: 如何使推理对人类可解释。在指标数据中识别模式会揭示事件之间的统计相关性，但不会显示因果优先链:

• 事件 A(高内存使用)经常对应于事件 Z(结账错误)。
• 因此，有很高的概率事件 A 导致了事件 Z。

但是这种诊断并没有回答以下能为工程师提供可操作洞见的问题:

• 对收入和可靠性的影响范围是什么?
• 我们如何向决策者传达这一点?
• 我们应该优先解决事件 A 还是与之也有关联的事件 B?

解决这个最后一英里问题需要捕获和可视化根本原因概率、业务影响顺序、风险级别和缓解建议的模型。

展望未来

虽然核心机器学习技术显示出前景，但需要专门构建的解决方案来解决生产规模的因果分析的复杂性。结合专门的拓扑推理、启发式图搜索算法和可解释的数据科学，就可以释放自动化根本原因分析的力量。但这需要在数据收集、服务映射、ML 和技术洞见传达方面取得进展 - 目标是修复。

要了解更多关于 Kubernetes 和云原生生态系统的信息，请于 3 月 19 日至 22 日与我们一起参加在巴黎举行的 KubeCon + CloudNativeCon Europe 活动。