Machine-Learning on Adur

Patrones de diseño para pipelines MLOps

Wed, 22 Mar 2023 10:00:00 +0100

Qué es MLOps y por qué importa

MLOps trata de desplegar y mantener modelos en producción de forma fiable y eficiente. Conecta la experimentación en ciencia de datos con la ingeniería de producción. Sin MLOps, chocas con los mismos problemas: modelos que funcionan en notebooks pero fallan en producción, sin reproducibilidad, traspasos dolorosos entre equipos, cero visibilidad una vez desplegados.

La idea: trata sistemas de ML con el mismo rigor que software. Control de versiones, pruebas automatizadas, entrega continua, monitorización. Solo reconoce que datos y modelos introducen desafíos únicos.

El ciclo de vida de ML

Antes de entrar en los patrones, conviene entender las etapas por las que pasa todo sistema de ML:

Ingesta y validación de datos — Recopilar, limpiar y validar los datos de entrada.
Ingeniería de features — Transformar los datos en bruto en features que el modelo pueda consumir.
Entrenamiento del modelo — Ejecutar experimentos, ajustar hiperparámetros, seleccionar algoritmos.
Evaluación del modelo — Validar la calidad del modelo con datos de prueba y métricas de negocio.
Despliegue del modelo — Servir predicciones en producción (batch o tiempo real).
Monitorización y retroalimentación — Seguimiento del rendimiento, detección de drift, activación de reentrenamiento.

Cada etapa tiene sus propios modos de fallo, y los patrones que se presentan a continuación los abordan de forma sistemática.

Patrones de diseño clave

Feature store

Un feature store es un repositorio centralizado para almacenar, compartir y servir features de ML. En lugar de que cada equipo recalcule features desde cero, un feature store proporciona:

Consistencia entre entrenamiento y serving (evitando el training-serving skew).
Reutilización entre equipos y modelos.
Corrección temporal para valores históricos de features.

Herramientas como Feast, Tecton y Hopsworks implementan este patrón. Si varios equipos están duplicando pipelines de features, un feature store probablemente merezca la inversión.

Model registry

Un model registry actúa como catálogo versionado de modelos entrenados. Almacena artefactos del modelo, metadatos (hiperparámetros, métricas, versión de los datos de entrenamiento) y etapa del ciclo de vida (staging, producción, archivado).

MLflow Model Registry es una de las soluciones más adoptadas. Permite promover modelos a través de etapas con flujos de aprobación y rastrear la trazabilidad desde el experimento hasta producción.

CT/CI/CD para ML

Los pipelines tradicionales de CI/CD construyen y despliegan código. Los pipelines de ML necesitan tres bucles:

Continuous Training (CT) — Reentrenar modelos automáticamente cuando cambian los datos o el rendimiento se degrada.
Continuous Integration (CI) — Validar no solo el código sino también esquemas de datos, expectativas de features y umbrales de calidad del modelo.
Continuous Delivery (CD) — Desplegar modelos validados a la infraestructura de serving de forma automática.

Un flujo típico podría ser: llegan datos nuevos al data lake, CT lanza el reentrenamiento, CI ejecuta las pruebas de validación y CD publica el modelo en producción si todas las verificaciones pasan.

A/B Testing

El A/B testing para modelos consiste en dirigir un porcentaje del tráfico a un modelo nuevo mientras el resto sigue llegando al modelo actual en producción. Se miden métricas de negocio (tasa de conversión, clicks, ingresos) en lugar de solo métricas de ML (accuracy, F1). Este patrón es esencial porque un modelo que puntúa bien en offline puede funcionar mal en producción debido a bucles de retroalimentación, latencia o diferencias en la distribución.

Shadow Deployment

En el modo shadow, el modelo nuevo recibe tráfico de producción y genera predicciones, pero esas predicciones no se sirven a los usuarios. En su lugar, se registran junto a las predicciones del modelo actual para una comparación offline. Es una forma de bajo riesgo de validar un modelo con tráfico real antes de exponerlo a los usuarios.

Canary releases para modelos

Similar a los canary deployments en software, se despliega un nuevo modelo a una pequeña fracción del tráfico (por ejemplo, el 5%), se monitorizan las métricas clave y se aumenta gradualmente el tráfico si todo se mantiene saludable. Si las métricas se degradan, se realiza un rollback automático. Este patrón se combina bien con A/B testing pero se centra más en la mitigación de riesgos que en la experimentación.

Panorama de herramientas

Herramienta	Uso principal	Punto fuerte
MLflow	Tracking de experimentos, model registry	Flexible, independiente del proveedor
Kubeflow	Pipelines de ML de extremo a extremo en Kubernetes	Escalable, cloud-native
DVC	Versionado de datos y modelos	Flujo de trabajo similar a Git para datos
Weights & Biases	Tracking de experimentos, visualización	Excelente interfaz y colaboración
Feast	Feature store	Open-source, listo para producción
Seldon Core	Model serving en Kubernetes	Estrategias de despliegue avanzadas

No existe una herramienta que cubra todo. La mayoría de las configuraciones en producción combinan varias, eligiendo según la experiencia del equipo y las restricciones de infraestructura.

Ejemplo: tracking de experimentos con MLflow

Este es un ejemplo mínimo de cómo registrar un experimento con MLflow:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


import mlflow
import mlflow.sklearn
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import accuracy_score, f1_score
from sklearn.model_selection import train_test_split

# Start an MLflow run
with mlflow.start_run(run_name="rf-baseline"):
 # Log parameters
 n_estimators = 100
 max_depth = 10
 mlflow.log_param("n_estimators", n_estimators)
 mlflow.log_param("max_depth", max_depth)

 # Train model
 model = RandomForestClassifier(
 n_estimators=n_estimators,
 max_depth=max_depth,
 random_state=42
 )
 X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2)
 model.fit(X_train, y_train)

 # Log metrics
 predictions = model.predict(X_test)
 mlflow.log_metric("accuracy", accuracy_score(y_test, predictions))
 mlflow.log_metric("f1_score", f1_score(y_test, predictions, average="weighted"))

 # Log model artifact
 mlflow.sklearn.log_model(model, "random-forest-model")

Cada ejecución queda registrada con sus parámetros, métricas y artefactos, lo que facilita comparar experimentos y reproducir resultados.

Anti-patrones a evitar

No versionar datos ni modelos. Si no puedes reproducir un entrenamiento de hace seis meses, tienes un problema. Versiona todo: código, datos, configuración y artefactos del modelo.

Training-serving skew. Cuando la lógica de cálculo de features difiere entre entrenamiento y serving, las predicciones se degradan de forma silenciosa. Un feature store o una librería compartida de cálculo de features ayuda a eliminar esto.

Despliegue manual. Copiar archivos del modelo a un servidor es una receta para incidentes. Automatiza el despliegue mediante pipelines con puertas de validación adecuadas.

Ignorar la monitorización del modelo. Los modelos se degradan con el tiempo a medida que cambian las distribuciones de entrada. Sin monitorización, solo te enteras cuando un usuario se queja o una métrica de negocio cae. Configura alertas para cambios en la distribución de predicciones, latencia y calidad de datos.

Pipelines monolíticos. Un pipeline único que hace todo desde la ingesta de datos hasta el serving del modelo es frágil y difícil de depurar. Divide los pipelines en etapas modulares e independientemente testeables.

Sobreingeniería prematura. No todos los proyectos de ML necesitan Kubeflow y un feature store desde el día uno. Empieza simple, identifica cuellos de botella y adopta patrones a medida que la complejidad del sistema crece.

Niveles de madurez MLOps

Las organizaciones suelen progresar a través de varios niveles de madurez:

Nivel 0: Manual

Modelos entrenados en notebooks.
Despliegue manual (copia de archivos, reinicio manual de la API).
Sin tracking de experimentos.
Sin monitorización.

Nivel 1: automatización del pipeline de ML

Pipelines de entrenamiento automatizados.
Tracking de experimentos con herramientas como MLflow.
Validación básica del modelo antes del despliegue.
Algo de monitorización de las predicciones del modelo.

Nivel 2: CI/CD para ML

Testing automatizado de datos, features y calidad del modelo.
Continuous training activado por cambios en los datos o por programación.
Despliegue automatizado con canary o shadow releases.
Monitorización completa con alertas y rollback automático.

Nivel 3: MLOps completo

Feature store para la gestión consistente de features.
Model registry con gobernanza y flujos de aprobación.
A/B testing integrado en el proceso de despliegue.
Trazabilidad de datos y modelos de extremo a extremo.
Pipelines auto-reparables que detectan y responden al drift automáticamente.

La mayoría de los equipos se encuentran entre el Nivel 0 y el Nivel 1. El objetivo no es saltar al Nivel 3 de inmediato, sino progresar de forma incremental, abordando primero los cuellos de botella más dolorosos.

Conclusión

MLOps consiste en aplicar patrones de ingeniería a los desafíos únicos de ML. Empieza con tracking de experimentos y automatización básica, luego añade feature stores, registries y estrategias avanzadas conforme crezcas. La clave: trata modelos como artefactos de producción. Versiona, prueba, monitoriza, mejora.

Introducción a AIOps: operaciones de TI inteligentes

Mon, 05 Dec 2022 00:00:00 +0000

¿Qué es AIOps?

AIOps (Artificial Intelligence for IT Operations) aplica machine learning y analítica de datos a los datos operativos (logs, métricas, eventos, trazas) para automatizar y mejorar flujos de trabajo. Gartner acuñó el término en 2017, pero la idea es simple: usar algoritmos para gestionar el volumen y la complejidad que los humanos no pueden manejar manualmente.

En términos prácticos, las plataformas AIOps ingieren datos de herramientas de monitorización, sistemas APM, agregadores de logs y fuentes de eventos. Aplican modelos de ML para detectar anomalías, correlacionar eventos, identificar causas raíz y, en algunos casos, desencadenar remediación automatizada. El objetivo es reducir el tiempo medio de detección (MTTD) y el tiempo medio de resolución (MTTR) mientras se libera a los equipos de operaciones de la fatiga por alertas.

Por qué la monitorización tradicional se queda corta

La monitorización funcionaba bien cuando los sistemas eran simples. Tenías pocos servidores, unas pocas apps y un número limitado de métricas. Un umbral estático de CPU o un regex en logs era suficiente.

La infraestructura moderna rompió ese modelo:

Escala: Un clúster de Kubernetes genera millones de métricas y logs por minuto. No puedes vigilar dashboards a esa escala.
Complejidad: Los microservicios crean dependencias enredadas. Una petición puede atravesar docenas de servicios. Encontrar qué causó una latencia significa correlacionar datos entre todos.
Entornos dinámicos: Auto-scaling, contenedores efímeros, serverless. Las baselines cambian constantemente y los umbrales estáticos explotan con falsos positivos.
Fatiga por alertas: Los equipos se hunden en alertas. Cuando el 90% es ruido, ese crítico 10% desaparece. Los ingenieros empiezan a ignorar todo.

AIOps no reemplaza la monitorización. Se sitúa encima de lo que ya tienes y lo hace más inteligente.

Capacidades clave

1. Detección de anomalías

En lugar de umbrales estáticos, AIOps usa modelos de ML (frecuentemente análisis de series temporales, clustering o autoencoders) para aprender qué aspecto tiene lo “normal” para cada métrica y servicio. Cuando el comportamiento se desvía significativamente de la línea base aprendida, se marca una anomalía.

Esto maneja el problema de la línea base dinámica. Si tu aplicación normalmente ve un pico de tráfico cada lunes a las 9 de la mañana, el modelo aprende ese patrón y no alerta por ello. Pero un pico inesperado a las 3 de la madrugada de un miércoles sí se marca.

2. Correlación de eventos

Un único problema de infraestructura puede generar cientos o miles de alertas relacionadas en diferentes herramientas de monitorización. AIOps correlaciona estos eventos — agrupándolos por tiempo, topología y relaciones causales — para presentar un único incidente en lugar de un muro de alertas.

Por ejemplo, un fallo en un switch de red podría disparar alertas en: el propio switch, todos los servidores conectados (conectividad perdida), todas las aplicaciones en esos servidores (fallos en health checks), y servicios downstream (errores de timeout). Una plataforma AIOps correlaciona todos estos en un incidente: “Switch de red X ha fallado.”

3. Análisis de causa raíz

Más allá de la correlación, AIOps intenta identificar la causa raíz de un incidente. Al comprender la topología de tu infraestructura y la cadena causal de eventos, puede sugerir que el fallo del switch de red es la causa raíz, en lugar de presentar el timeout de la aplicación como un problema independiente.

Aquí es donde el valor se vuelve tangible. En lugar de que un ingeniero de guardia pase 30 minutos rastreando a través de dashboards y logs, la plataforma muestra la causa raíz probable inmediatamente.

4. Auto-remediación

Las implementaciones más maduras de AIOps cierran el ciclo disparando acciones de remediación automatizadas. Si se detecta un patrón conocido (disco llenándose, un pod en CrashLoopBackOff, un proceso descontrolado consumiendo memoria), la plataforma puede ejecutar runbooks predefinidos automáticamente.

Ejemplos:

Reiniciar un pod o servicio caído.
Escalar un deployment cuando se detecta carga anómala.
Limpiar un directorio de logs cuando el uso de disco supera un umbral dinámico.
Disparar un failover cuando una base de datos primaria deja de responder.

La auto-remediación requiere un diseño cuidadoso. Empieza con acciones de bajo riesgo y amplía conforme crece la confianza.

Plataformas y herramientas comunes

El panorama de AIOps incluye tanto plataformas comerciales como bloques de construcción open-source:

Plataformas comerciales

Plataforma	Fortalezas
Dynatrace	Auto-descubrimiento robusto, motor de IA (Davis), observabilidad full-stack
Datadog	Monitorización unificada + alertas con ML, detección de anomalías Watchdog
Splunk ITSI	Analítica de logs potente + toolkit de ML, bueno para correlación de eventos
Moogsoft	Pionero en el espacio AIOps, fuerte correlación de eventos y reducción de ruido
BigPanda	Enfocado en correlación de eventos y automatización, se integra con herramientas existentes
PagerDuty	Gestión de incidentes con reducción de ruido por ML y agrupación inteligente

Bloques de construcción open-source

Puedes ensamblar un stack similar a AIOps con componentes open-source:

Recolección de datos: Prometheus, Grafana Agent, OpenTelemetry Collector, Fluentd/Fluent Bit.
Almacenamiento de datos: Prometheus (métricas), Elasticsearch/OpenSearch (logs), Jaeger/Tempo (trazas).
Detección de anomalías: Facebook Prophet, Isolation Forest (scikit-learn), luminol, Grafana ML.
Correlación de eventos: Lógica personalizada sobre streams de eventos, o StackStorm para automatización dirigida por eventos.
Alertas y automatización: Alertmanager, Grafana OnCall, StackStorm, Rundeck.

Construir un stack AIOps personalizado es significativamente más trabajo que usar una plataforma comercial, pero te da control total y evita el vendor lock-in. Un punto medio razonable es usar una plataforma comercial para las capacidades core de AIOps mientras mantienes tu pipeline de datos en open-source.

Casos de uso prácticos

Reducción de ruido en gestión de alertas

Un equipo que recibe más de 500 alertas al día implementa correlación de eventos AIOps. Las alertas relacionadas se agrupan en incidentes, los duplicados se suprimen y las alertas fluctuantes se silencian. El volumen de alertas baja un 80%, y el ingeniero de guardia puede enfocarse en incidentes reales.

Planificación proactiva de capacidad

Los modelos AIOps analizan tendencias históricas de uso de recursos y predicen cuándo se alcanzarán los límites de capacidad. En lugar de reaccionar a una alerta de disco lleno a las 2 de la madrugada, la plataforma predice el problema con dos semanas de antelación y crea un ticket para que el equipo lo aborde en horario laboral.

Respuesta a incidentes más rápida

Durante una caída de producción, la plataforma AIOps correlaciona alertas de todo el stack de monitorización, identifica la causa raíz (un despliegue reciente que introdujo una fuga de memoria) y muestra el commit del despliegue relevante. El MTTR baja de 45 minutos a 10 minutos.

Escalado automático

La plataforma detecta patrones de tráfico anómalos que se desvían de la línea base aprendida. En lugar de esperar a que la CPU alcance el 80% (el umbral estático), dispara una acción de scale-up basada en la tasa de cambio, asegurando que la capacidad está lista antes de que los usuarios experimenten degradación.

Cómo encaja AIOps en los flujos de trabajo DevOps

AIOps no es un reemplazo de las prácticas DevOps. Es una capa de mejora:

1
2
3
4
5


Código ──> CI/CD Pipeline ──> Deploy ──> Observar ──> Capa AIOps ──> Actuar
 │ │
 Monitoring Stack Modelos ML
 (métricas, logs, (detección de anomalías,
 trazas, eventos) correlación, RCA)

Los desarrolladores se benefician de una identificación más rápida de la causa raíz cuando su código causa problemas en producción.
Los equipos de operaciones se benefician de la reducción de ruido, remediación automatizada y alertas proactivas.
Los equipos SRE se benefician del seguimiento de SLOs basado en datos y el análisis de tasa de consumo del error budget.

AIOps funciona mejor cuando tu base de observabilidad es sólida. Si no estás recolectando buenos datos (logs estructurados, métricas significativas, trazas distribuidas), los modelos de ML no producirán insights significativos. Arregla primero tu observabilidad, luego añade AIOps encima.

Primeros pasos: Un camino pragmático

Si estás considerando AIOps, aquí tienes un enfoque práctico:

Audita tu stack de observabilidad actual. ¿Qué datos estás recolectando? ¿Los logs están estructurados? ¿Las métricas están etiquetadas de forma consistente? ¿Las trazas se propagan entre servicios? AIOps es tan bueno como los datos que ingiere.
Empieza con la reducción de ruido. Esta es la fruta que cuelga más baja. Implementa agrupación y deduplicación de alertas. Incluso una correlación básica basada en reglas (antes de cualquier ML) reducirá la fatiga por alertas significativamente.
Añade detección de anomalías a métricas clave. Elige 3-5 métricas críticas de negocio e infraestructura. Aplica un modelo de detección de anomalías de series temporales. Facebook Prophet o recording rules de Prometheus con ajustes estacionales son buenos puntos de partida.
Implementa remediación automatizada para problemas conocidos. Identifica los 5 incidentes recurrentes principales. Escribe runbooks para ellos. Automatiza los runbooks usando StackStorm, Rundeck o el motor de automatización de tu plataforma.
Evalúa una plataforma comercial cuando la complejidad lo requiera. Si tienes cientos de servicios, múltiples herramientas de monitorización y un equipo de operaciones creciente, la inversión en una plataforma AIOps comercial puede justificarse solo por la reducción en MTTR.
Mide el impacto. Sigue MTTD, MTTR, ratio alerta-a-incidente y tasa de falsos positivos. Sin métricas, no puedes probar que AIOps vale la pena.

AIOps no es magia. Es un conjunto de técnicas que, aplicadas a buenos datos operativos, pueden reducir la carga sobre los equipos y mejorar la fiabilidad. Empieza pequeño, mide todo, y escala lo que funcione.