文章探讨了如何将混沌工程应用于机器学习（ML）管道中的数据管道、特征存储和模型注册表，以提高其可靠性。文中详细介绍了针对每个组件的故障场景、混沌注入技术和推荐工具，强调了在ML系统中主动测试和构建弹性的重要性，并提供了实践步骤。
译自：A Guide To Stress-Testing Your ML Data Pipelines
作者：Tinega Onchari
这是两篇系列文章中的第二篇。另请阅读：
在本系列的第一部分中，我们论证了使用混沌工程来提高机器学习 (ML) 管道的可靠性。任何成功的 ML 运营的核心都是其基础设施——数据管道、模型注册表和特征存储。这些是导致混沌工程旨在暴露的那些类型的故障的最易受影响的组件。
一旦你了解了ML 管道中最常见的故障模式，下一个问题是：如何安全地模拟这些故障来测试系统的弹性？
答案在于将混沌工程原理应用于 ML 生命周期独有的组件：数据管道、模型注册表和特征存储。这些不是你典型应用程序的依赖项——它们与 AI 系统的逻辑紧密耦合。如果其中任何一个发生静默故障，你的模型可能会以传统监控无法捕获的方式退化。
让我们来看看如何将混沌注入每个组件以及为什么这很重要。
将混沌注入数据管道
数据管道是 ML 系统的生命线。它们将原始数据从源系统移动到特征工程和训练阶段。但管道通常是复杂的有向无环图 (DAG)，具有多个故障点：不稳定的 API、损坏的 cron 作业、缓慢的摄取或格式变化。
要模拟的故障场景：
- 数据延迟或乱序到达。
- 文件格式静默更改（例如从 CSV 到 JSON）。
- 缺失值意外增加。
- 整个列或表被删除。
混沌注入技术：
- 文件延迟模拟： 在暂存环境中临时保留每日摄取文件。在 Airflow/Kubeflow 中使用
sleep延迟来模拟 cron 作业延迟。 - 模式漂移： 注入一个数据集版本，其中包含重命名或缺失的列，以查看你的提取、转换、加载 (ETL) 脚本或特征存储的反应。
- API 错误模拟： 用随机返回 500、429 或格式错误数据的模拟器替换实时 API 调用。
- 引入部分数据： 使用 Chaos Mesh 终止多阶段 ETL 作业的中间部分，并测试下游逻辑是否检测到并报告不完整数据。
要使用的工具：
将混沌注入特征存储
特征存储充当训练和提供之间的桥梁。它们需要为训练和提供环境提供一致、新鲜且版本化的特征。但它们也容易出现过时、格式漂移和低可观测性。
要模拟的故障场景：
- 批处理作业失败，特征未更新。
- 实时流延迟数小时。
- 训练和推理之间的特征版本不匹配。
- 特征分布随时间变化（均值、标准差）。
混沌注入技术：
- 禁用特征更新作业（或使用 Chaos Mesh pod 终止来模拟它），并测量下游模型在使用过时特征时的行为。
- 通过注入超出范围的值（例如，归一化字段的非常大的数字）来提供损坏的特征，以测试模型的健壮性。
- 在训练与推理时引入不同的特征分布来模拟偏差（仅在提供时应用偏移或转换）。
- 通过删除常用特征并观察系统是默认使用另一个还是完全失败来测试回退逻辑。
要使用的工具：
- Feast，一个流行的开源特征存储，结合 Chaos Mesh 来终止在线存储更新进程。
- 自定义脚本来用损坏的文件替换
.parquet或.csv文件。 - Great Expectations 来验证特征的一致性。
将混沌注入模型注册表
像 MLflow、SageMaker Model Registry 或自定义工件存储这样的模型注册表是跟踪、版本化和部署模型的中心。损坏的注册表或不匹配的元数据可能导致提供错误的模型、丢失可追溯性或错误的滚回。
要模拟的故障场景：
- 旧模型版本被意外重新部署。
- 新模型在没有关联元数据（输入模式）的情况下注册。
- 模型签名已更改，但推理代码未更改。
- 在部署时无法访问注册表。
混沌注入技术：
- 覆盖版本标签以指向错误的工件，并测试下游使用者是否进行兼容性检查。
- 删除或混乱元数据（预期的特征列表、模型类型），并验证你的 CI/CD 管道是否在提供之前验证模型。
- 使用网络故障或防火墙规则阻止访问注册表，以模拟部署期间的停机。
- 故意在暂存环境中部署损坏的模型，并测量警报、滚回和提供行为。
要使用的工具：
- MLflow API 和命令行界面 (CLI) 来模拟不良注册。
- Chaos Mesh（网络混沌）来阻止注册表访问。
- Seldon Core 或自定义 CI/CD 逻辑来测试部署护栏。
用于将混沌注入 ML 管道的工具
将混沌注入 ML 管道不仅仅是随机翻转开关。它是关于战略性地模拟现实世界的故障模式，以测试系统在压力下的行为。要做好这一点，你需要合适的工具。
ML 中的混沌测试需要将基础设施级别的故障注入工具与 ML 特定的数据和模型验证框架相结合。目标是在整个生命周期中——从原始数据摄取到实时推理——模拟故障，同时不损害生产系统。
以下是一些帮助你设计和执行为 AI 系统量身定制的混沌实验的最有效工具：
最适合： 将基础设施级别的故障注入基于 Kubernetes 的 ML 平台（Kubeflow、MLflow、Airflow on K8s）
Chaos Mesh 是一个 Kubernetes 原生混沌工程框架，它使你能够直接在 ML 基础设施中模拟各种类型的故障——例如 pod 故障、网络延迟、磁盘损坏甚至时间偏差。
最适合： 在不同环境和服务（包括非 Kubernetes 系统）之间创建混沌工作流。
LitmusChaos 是另一个 Cloud Native Computing Foundation (CNCF) 项目，对复杂的多步骤混沌场景有强大的支持。虽然 Chaos Mesh 在针对 K8s 故障方面表现出色，但 LitmusChaos 更适合编排完整的混沌工作流。它在多云或混合 MLOps 堆栈中特别有用。
最适合： 验证数据完整性、期望并检测细微的数据质量回归。
Great Expectations 是一个数据验证框架，但在 ML 的混沌工程中，它起着至关重要的作用：检测看不见的数据故障。它确保你的输入数据符合预期的模式和模式定义，即使在引入上游故障之后也是如此。
最适合： 健壮的模型提供、金丝雀部署、版本化和推理故障转移。
Seldon Core 是一个 Kubernetes 原生的模型提供框架，提供 A/B 测试、流量拆分、滚回机制以及实时模型行为的详细指标。对于混沌实验，它支持大规模的模型版本切换、推理故障注入和监控。
最适合： 模型实验跟踪、版本化和注册表管理。
MLflow 不是一个混沌工程工具，但它在管理和审计混沌实验方面发挥着关键作用，特别是在模型版本化和评估方面。你可以使用它来跟踪跨实验的性能下降，识别回归并强制执行部署规则。
奖励：自定义 Python 和 Bash 脚本
最适合： 在 ETL 和训练管道中进行轻量级、有针对性的混沌实验。
有时，简单的工具就能奏效。对于将混沌注入数据转换脚本、基于 Notebook 的训练作业或 CI/CD 工作流，使用 Python 或 Bash 进行脚本编写可以让你完全控制。这些在 Airflow DAG 或 Kubeflow Pipelines 中特别有用，你希望在任务中间测试故障。
破而后立，精益求精
在 DevOps 中，我们早已认识到系统不是凭空变得有弹性的；它们之所以有弹性，是因为我们在最糟糕的条件下对其进行测试。混沌工程教会我们模拟网络中断、随机终止服务和压力测试环境，不是为了造成破坏，而是为了揭示那些最终会让我们崩溃的看不见的裂缝。
是时候将同样的理念带入 ML 系统了。
ML 管道有所不同。它们在出现问题时不会抛出异常。它们会退化——悄无声息、危险且通常不被检测到。特征交付的轻微延迟、错误标记的训练批次或输入分布的未被注意到的变化，可能在不触发监控或发出警报的情况下，就损坏你的模型行为数天或数周。
真正的危险不是停机时间；而是自信地犯错。
这就是为什么 AI 系统需要的不仅仅是高可用性。它们需要：
- 可观测性： 不仅监控日志和延迟，还要监控数据质量、特征漂移和预测分布。
- 容错性： 优雅退化、安全回退并在出现问题时触发智能警报的能力。
- 混沌就绪性： 在故障条件下经过故意测试的系统，这样当故障发生时（而且它一定会发生），你就已经知道什么会坏掉以及如何恢复。
混沌工程是大多数 MLOps 堆栈中缺失的反馈循环。
通过将受控的故障注入数据摄取、特征处理、训练、提供和反馈循环，你就可以从被动的救火转向主动的弹性构建。你不再只是希望你的管道正常工作，而是开始了解它是如何失败的——以及它是如何恢复的。
你接下来可以做什么
以下是如何立即开始为你的 ML 系统进行混沌工程：
- 选择一个管道组件——特征摄取、训练或提供——并注入一个简单的故障（例如延迟、模式不匹配或缺失列）。
- 衡量影响： 跟踪模型准确性、延迟、警报和业务 KPI。
- 记录你的发现： 什么坏了？什么没坏？什么需要更健壮？
- 与你的团队分享： 将其作为基础，开始将混沌测试集成到 CI/CD 管道中。
- 迭代： 将你的混沌测试扩展到新组件。自动化。安排。监控。
