DataOps on Adur

LLMOps: integrando LLMs en flujos de trabajo DevOps

Sun, 15 Jun 2025 00:00:00 +0000

Los LLMs han ido más allá de chatbots. Ahora se integran en flujos de trabajo de ingeniería donde automatizan tareas tediosas, aceleran respuesta a incidentes y potencian productividad. Pero desplegar un LLM en un pipeline de DevOps en producción es fundamentalmente diferente a usar ChatGPT en un navegador.

Esta guía cubre qué significa LLMOps en la práctica, dónde encajan los LLMs en DevOps, patrones de arquitectura que funcionan y trampas que debes evitar.

Qué es LLMOps

LLMOps es el conjunto de prácticas, herramientas e infraestructura necesarios para operacionalizar LLMs. Extiende MLOps pero aborda desafíos únicos de los modelos de lenguaje:

Selección de modelo vs. entrenamiento de modelo: La mayoría de equipos consumen modelos pre-entrenados (mediante APIs o inferencia auto-alojada) en lugar de entrenar desde cero. El foco operacional se desplaza hacia prompt engineering, fine-tuning y generación aumentada por recuperación (RAG).
Gestión de costes: La inferencia con LLMs es cara. La tarificación por tokens significa que los costes escalan con el uso de formas más difíciles de predecir que el cómputo tradicional.
No determinismo: Los LLMs producen salidas variables para la misma entrada, lo que complica las pruebas, la validación y la reproducibilidad.
Latencia: Tiempos de respuesta de segundos (no milisegundos) requieren patrones arquitectónicos diferentes a los microservicios tradicionales.

LLMOps no es una disciplina separada. Es una extensión de tus prácticas existentes de DevOps y MLOps, adaptada a las características operacionales específicas de los modelos de lenguaje.

Casos de uso prácticos en DevOps

Aquí es donde los LLMs están aportando valor real en flujos de trabajo DevOps hoy en día:

Revisión automatizada de código

Los LLMs pueden proporcionar una primera pasada de revisión de pull requests, detectando problemas comunes como manejo de errores ausente, anti-patrones de seguridad, nomenclatura inconsistente o tests faltantes. No reemplazan a los revisores humanos, pero reducen la carga del feedback repetitivo.

Resumen de incidentes

Cuando un incidente salta a las 3 de la mañana, la persona de guardia necesita contexto rápido. Un LLM puede ingerir datos de alertas, logs de despliegues recientes, runbooks relacionados e informes de incidentes anteriores para producir un resumen conciso de lo que probablemente está fallando y qué se hizo la última vez.

Análisis de logs

Los LLMs son sorprendentemente efectivos en el reconocimiento de patrones en datos de logs no estructurados. Aliméntalos con un bloque de logs de error y pueden identificar la causa raíz más rápido que sesiones manuales de grep, especialmente para sistemas con los que no estás familiarizado.

Generación de documentación

Generar borradores de documentación a partir de código, esquemas de API o módulos de Terraform. El resultado necesita revisión humana, pero elimina el problema de la página en blanco y mantiene la documentación más cercana al estado actual.

Generación de Infrastructure as Code

Dada una descripción en lenguaje natural de la infraestructura deseada, los LLMs pueden generar manifiestos de Terraform, Ansible o Kubernetes como punto de partida. Útil para scaffolding, no para código listo para producción sin revisión.

Patrones de arquitectura para integración de LLMs

Patrón 1: API gateway a LLM externo

El enfoque más simple. Tu aplicación llama a una API de LLM externa (OpenAI, Anthropic, etc.) a través de un gateway centralizado que gestiona autenticación, rate limiting, logging y seguimiento de costes.

1
2
3
4
5


[Pipeline CI/CD] --> [API Gateway] --> [API LLM Externa]
 |
 [Logging y Métricas]
 |
 [Seguimiento de Costes]

Pros: Sin infraestructura que gestionar, acceso a los modelos más capaces, rápido de implementar. Contras: Los datos salen de tu red, dependencia del proveedor, latencia variable, costes continuos de API.

Patrón 2: Inferencia auto-alojada

Ejecutar modelos de pesos abiertos (Llama, Mistral, etc.) en tu propia infraestructura usando servidores de inferencia como vLLM u Ollama.

1
2
3


[Pipeline CI/CD] --> [Load Balancer] --> [Instancia(s) vLLM / Ollama]
 |
 [Pool de Nodos GPU]

Pros: Los datos permanecen internos, costes predecibles a escala, sin dependencia de proveedor, control total sobre versiones del modelo. Contras: Requiere infraestructura GPU, sobrecarga operacional, modelos más pequeños pueden ser menos capaces.

Patrón 3: Pipeline mejorado con RAG

Combinar un LLM con un sistema de recuperación que proporciona contexto relevante de tu propia base de conocimiento (runbooks, documentación, incidentes pasados). Esto mejora drásticamente la calidad de las respuestas para tareas específicas del dominio.

1
2
3
4


[Consulta] --> [Modelo Embedding] --> [Búsqueda Vector DB] --> [Contexto + Consulta] --> [LLM] --> [Respuesta]
 |
 [Tu Base de Conocimiento]
 (runbooks, docs, etc.)

Este patrón es particularmente potente para respuesta a incidentes y tareas de documentación donde el LLM necesita el contexto específico de tu organización.

Consideraciones clave

Coste

Los costes de API de LLMs pueden sorprender. Un pipeline de revisión de código que procesa 50 PRs al día con diffs grandes puede fácilmente alcanzar cientos de dólares al mes. Estrategias para controlar costes:

Establecer límites de tokens por petición
Cachear consultas y respuestas comunes
Usar modelos más pequeños para tareas simples (triaje con un modelo pequeño, escalar a uno mayor)
Monitorizar el uso de tokens por pipeline y configurar alertas

Latencia

Las respuestas de LLMs tardan segundos, no milisegundos. Diseña tus integraciones como procesos asíncronos:

Publicar comentarios de revisión de código después del hecho, no bloquear la PR
Procesar datos de incidentes en segundo plano, enviar resultados a un canal de Slack
Usar streaming de respuestas donde sea posible para mejorar el rendimiento percibido

Alucinaciones

Los LLMs generarán con confianza información que suena plausible pero es incorrecta. Esta es una preocupación crítica para tareas de DevOps donde un mal consejo puede causar caídas.

Mitigaciones:

Siempre presentar la salida del LLM como sugerencias, nunca como acciones autoritativas
Requerir aprobación humana antes de aplicar cualquier cambio generado por LLM
Usar RAG para anclar las respuestas en documentación verificada
Implementar validación de salida (por ejemplo, lint del IaC generado antes de presentarlo)

Seguridad

Exposición de datos: Cualquier cosa que envíes a una API de LLM externa puede ser usada para entrenamiento o almacenada. Nunca envíes secretos, credenciales o datos sensibles de clientes.
Prompt injection: Contenido malicioso en código, logs o entrada de usuario puede manipular el comportamiento del LLM. Sanitiza las entradas y valida las salidas.
Cadena de suministro: El código generado por LLM puede introducir vulnerabilidades. Pasa todo el código generado por tu pipeline de escaneo de seguridad existente.

Herramientas y plataformas

LangChain

Un framework para construir aplicaciones potenciadas por LLMs. Útil para orquestar cadenas de múltiples pasos (por ejemplo, recuperar contexto, formatear prompt, llamar al LLM, parsear la salida). Soporta muchos proveedores de LLMs y tiene buen tooling para pipelines RAG.

1
2
3
4
5
6
7
8


from langchain.chat_models import ChatOpenAI
from langchain.prompts import ChatPromptTemplate

prompt = ChatPromptTemplate.from_template(
 "Review this code diff for security issues and suggest fixes:\n\n{diff}"
)
chain = prompt | ChatOpenAI(model="gpt-4o", temperature=0)
result = chain.invoke({"diff": code_diff})

vLLM

Un motor de inferencia de alto rendimiento para modelos auto-alojados. Soporta PagedAttention para gestión eficiente de memoria y continuous batching para alto throughput.

1
2
3
4


# Iniciar un servidor vLLM
python -m vllm.entrypoints.openai.api_server \
 --model mistralai/Mistral-7B-Instruct-v0.2 \
 --port 8000

Expone una API compatible con OpenAI, así que puedes cambiar entre APIs auto-alojadas y externas con cambios mínimos de código.

Ollama

La forma más fácil de ejecutar LLMs localmente para desarrollo y pruebas. Ideal para prototipar pipelines antes de comprometerte con infraestructura.

1
2
3
4
5
6
7


# Descargar y ejecutar un modelo
ollama pull llama3
ollama run llama3 "Summarize this error log: [paste log]"

# Servir como API
ollama serve
# Luego llamar a http://localhost:11434/api/generate

Ejemplo: Pipeline de revisión automatizada de PRs

Aquí tienes un pipeline conceptual para revisión automatizada de PRs usando un LLM:

 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
31
32
33
34
35
36
37
38
39
40
41
42
43
44


# .github/workflows/llm-review.yml
name: LLM Code Review

on:
 pull_request:
 types: [opened, synchronize]

jobs:
 llm-review:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout
 uses: actions/checkout@v4
 with:
 fetch-depth: 0

 - name: Get diff
 id: diff
 run: |
 git diff origin/${{ github.base_ref }}...HEAD > diff.txt

 - name: Run LLM review
 env:
 LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
 run: |
 python scripts/llm_review.py \
 --diff diff.txt \
 --model gpt-4o \
 --max-tokens 2000 \
 --output review.json

 - name: Post review comments
 uses: actions/github-script@v7
 with:
 script: |
 const review = require('./review.json');
 await github.rest.pulls.createReview({
 owner: context.repo.owner,
 repo: context.repo.repo,
 pull_number: context.issue.number,
 body: review.summary,
 event: 'COMMENT',
 comments: review.line_comments
 });

El script de revisión:

Lee el diff
Divide diffs grandes en fragmentos que quepan en la ventana de contexto del modelo
Para cada fragmento, construye un prompt pidiendo problemas de seguridad, bugs y problemas de estilo
Agrega resultados y formatea como comentarios de revisión de GitHub
Incluye puntuaciones de confianza y siempre marca la salida como generada por IA

Guardrails y uso responsable

Etiqueta claramente toda la salida del LLM como generada por IA. Los ingenieros deben saber cuándo están leyendo salida de una máquina.
Nunca auto-mergees ni auto-apliques sugerencias del LLM. Mantén un humano en el bucle para todos los cambios.
Registra todos los prompts y respuestas para depuración y auditoría.
Establece límites de gasto y alertas sobre el uso de API de LLMs.
Revisa las plantillas de prompts regularmente para asegurarte de que no filtran información sensible.
Prueba sesgos y errores con muestras representativas antes de desplegar en flujos de trabajo de producción.

Recomendaciones para empezar

Elige un caso de uso - No intentes habilitar LLMs en todo. Empieza bajo riesgo: borradores, sugerencias de commits.
Empieza con API externa - No inviertas en GPU hasta validar el caso. Usa OpenAI o Anthropic para prototipar.
Mide todo - Registra coste por invocación, latencia, satisfacción, tasas de error desde el primer día.
Construye un framework - Crea un suite de tests con entradas y salidas conocidas. Ejecútalo contra cada cambio de prompt o modelo.
Planifica tu estrategia de datos - Decide qué datos enviarás a APIs externas. Documéntalo.
Itera en prompts - El prompt engineering es iterativo. Versiona prompts, trátalos como código.

Los LLMs son una herramienta potente para DevOps, pero son exactamente eso: una herramienta. Funcionan mejor cuando se integran de forma reflexiva en flujos existentes, con límites claros sobre qué pueden y no pueden hacer autonomamente.

DataOps: construyendo pipelines de datos confiables

Sun, 18 Feb 2024 00:00:00 +0000

¿Qué es DataOps?

DataOps aplica principios de DevOps (automatización, integración continua, monitorización, colaboración) a pipelines de datos y analítica. Mientras DevOps entrega software de forma fiable, DataOps entrega datos de forma fiable.

La diferencia: qué fluye por el pipeline. DevOps construye, testea, despliega código. DataOps construye, testea, despliega transformaciones de datos. El objetivo: asegurar que datos lleguen a dashboards, modelos de ML y sistemas downstream correctos, frescos, confiables.

Si alguna vez tuviste un dashboard roto el lunes porque un esquema cambio el fin de semana, sabes por qué DataOps importa.

Principios fundamentales

1. Automatización primero

Cada paso en tu pipeline de datos – extracción, transformación, carga, testing y despliegue – debe estar automatizado. Scripts SQL manuales ejecutados desde el portátil de alguien son un riesgo. Codifica todo, versiona en Git y deja que los orquestadores se encarguen de la ejecución.

2. Testing continuo

El testing de datos no es opcional. Debes validar los datos en cada etapa:

Tests de esquema: tipos de columna, restricciones de nulabilidad
Tests de volumen: conteos de filas dentro de rangos esperados
Tests de frescura: los datos llegaron según lo programado
Tests de reglas de negocio: los ingresos nunca son negativos, las fechas no están en el futuro

3. Monitorización y observabilidad

Necesitas saber cuándo algo se rompe antes que tus stakeholders. Instrumenta tus pipelines con métricas de latencia, conteo de filas, tasas de error y puntuaciones de calidad de datos. Configura alertas que se disparen cuando se detecten anomalías.

4. Colaboración y control de versiones

Los pipelines de datos son código. Trátalos como tal. Usa pull requests, code reviews y CI/CD para tu lógica de transformación. Cada cambio en un pipeline debe ser revisable, testeable y reversible.

Arquitectura de pipelines: ETL vs ELT

Los dos patrones dominantes para pipelines de datos son ETL y ELT. La elección depende de tu infraestructura y caso de uso.

ETL (Extract, Transform, Load)

Los datos se extraen de las fuentes, se transforman en un motor de procesamiento (Spark, scripts Python) y luego se cargan en el sistema destino. Este patrón tiene sentido cuando:

Necesitas reducir el volumen de datos antes de cargar (control de costes)
Las transformaciones requieren computacion pesada no adecuada para tu warehouse
Tienes requisitos estrictos de gobernanza que requieren transformacion antes del almacenamiento

ELT (Extract, Load, Transform)

Los datos se extraen y cargan en crudo en un data warehouse (BigQuery, Snowflake, Redshift), luego se transforman in situ usando SQL. Este es el enfoque moderno por defecto porque:

Los warehouses en la nube tienen capacidad de computo masiva
Las transformaciones basadas en SQL son más fáciles de revisar y testear
Los datos en crudo se preservan, permitiendo reprocesamiento cuando la logica cambia
Herramientas como dbt hacen de las transformaciones SQL ciudadanos de primera clase

Para la mayoría de equipos que empiezan hoy, ELT es el enfoque recomendado a menos que tengas una razón específica para transformar antes de cargar.

Herramientas clave

Apache Airflow – orquestación

Airflow es el orquestador open-source más ampliamente adoptado para pipelines de datos. Te permite definir flujos de trabajo como Directed Acyclic Graphs (DAGs) en Python, con planificación integrada, reintentos, gestión de dependencias y una interfaz web para monitorización.

Aquí tienes un ejemplo práctico de un DAG que orquesta un pipeline ELT:

 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
31
32
33
34
35
36
37
38
39
40


from airflow import DAG
from airflow.operators.python import PythonOperator
from airflow.providers.common.sql.operators.sql import SQLExecuteQueryOperator
from airflow.utils.dates import days_ago
from datetime import timedelta

default_args = {
 "owner": "data-team",
 "retries": 2,
 "retry_delay": timedelta(minutes=5),
 "email_on_failure": True,
 "email": ["data-alerts@company.com"],
}

with DAG(
 dag_id="elt_sales_pipeline",
 default_args=default_args,
 schedule_interval="@daily",
 start_date=days_ago(1),
 catchup=False,
 tags=["elt", "sales"],
) as dag:

 extract_load = PythonOperator(
 task_id="extract_and_load_raw",
 python_callable=extract_and_load_sales_data, # tu funcion de extraccion
 )

 transform = SQLExecuteQueryOperator(
 task_id="transform_sales",
 conn_id="warehouse_conn",
 sql="sql/transform_sales.sql",
 )

 run_quality_checks = PythonOperator(
 task_id="data_quality_checks",
 python_callable=run_great_expectations_suite,
 )

 extract_load >> transform >> run_quality_checks

Patrones clave a seguir en Airflow:

Tareas idempotentes: ejecutar la misma tarea dos veces debe producir el mismo resultado
Escrituras atomicas: usa tablas staging e intercambia al completarse
Fechas parametrizadas: usa variables template {{ ds }} para particionamiento por fecha
Tareas pequeñas: cada tarea debe hacer una sola cosa, facilitando el diagnóstico de fallos

dbt – transformacion

dbt (data build tool) es el estandar para gestionar transformaciones basadas en SQL en un pipeline ELT. Proporciona:

SQL modular: divide transformaciones complejas en modelos referenciables
Testing integrado: tests de esquema, tests personalizados y chequeos de frescura
Documentacion: documentacion auto-generada a partir de las descripciones de tus modelos
Linaje: DAG visual mostrando como los modelos dependen unos de otros

Una estructura tipica de proyecto dbt:

1
2
3
4
5
6
7
8


models/
 staging/
 stg_sales.sql -- limpiar datos en crudo
 stg_customers.sql
 marts/
 fct_daily_revenue.sql -- agregaciones a nivel de negocio
 dim_customers.sql
 schema.yml -- tests y documentacion

Great Expectations – calidad de datos

Great Expectations es un framework Python para definir, ejecutar y documentar chequeos de calidad de datos. Va mas alla de simples aserciones generando documentacion de datos legible por humanos.

Aqui tienes un ejemplo de configuración de expectations para una tabla de ventas:

 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
31


import great_expectations as gx

context = gx.get_context()

# Conectar a tu fuente de datos
datasource = context.sources.add_or_update_pandas("sales_source")
data_asset = datasource.add_csv_asset("daily_sales", filepath_or_buffer="data/daily_sales.csv")

batch_request = data_asset.build_batch_request()

# Crear una suite de expectations
suite = context.add_or_update_expectation_suite("sales_quality_suite")

validator = context.get_validator(
 batch_request=batch_request,
 expectation_suite_name="sales_quality_suite",
)

# Definir expectations
validator.expect_column_to_exist("order_id")
validator.expect_column_values_to_be_unique("order_id")
validator.expect_column_values_to_not_be_null("customer_id")
validator.expect_column_values_to_be_between("amount", min_value=0, max_value=100000)
validator.expect_column_values_to_be_in_set("status", ["pending", "completed", "refunded"])

# Ejecutar validacion
results = validator.validate()
validator.save_expectation_suite(discard_failed_expectations=False)

if not results.success:
 raise Exception(f"Data quality checks failed: {results.statistics}")

Integra esto en tu DAG de Airflow para que las puertas de calidad se ejecuten despues de cada paso de transformacion. Si los chequeos fallan, el pipeline se detiene y las alertas se disparan.

Monitorizacion y observabilidad

Un pipeline de datos en producción necesita observabilidad en varias dimensiones:

Dimension	Que Rastrear	Herramientas
Salud del pipeline	Tasas de exito/fallo de tareas, tendencias de duracion	Metricas de Airflow, Prometheus
Frescura de datos	Tiempo desde la ultima carga exitosa	dbt source freshness, chequeos personalizados
Volumen de datos	Conteo de filas por tabla por ejecucion	Great Expectations, SQL personalizado
Calidad de datos	Tasas de tests aprobados/fallidos, puntuaciones de anomalias	Great Expectations, Monte Carlo
Coste	Uso de computo del warehouse, crecimiento del almacenamiento	Dashboards del proveedor cloud

Configura alertas para:

Cualquier fallo de tarea del pipeline
Frescura de datos excediendo umbrales de SLA
Desviaciones de conteo de filas mas alla de 2 desviaciones estandar de la media movil
Fallos en tests de calidad de datos

Envia metricas de Airflow a Prometheus y construye dashboards de Grafana que den a tu equipo una vista unificada de la salud del pipeline.

Buenas prácticas

Trata los pipelines como código: todo el SQL, definiciones de DAGs y configuración viven en Git
Usa entornos: dev, staging, producción – igual que el código de aplicacion
Implementa CI/CD: ejecuta tests de dbt y linting en cada pull request
Disena para el fallo: cada tarea debe ser reintentable e idempotente
Documenta contratos de datos: define y publica esquemas acordados entre equipos upstream y downstream
Empieza con testing: anade chequeos de calidad de datos antes de anadir nuevas funcionalidades
Alerta sobre SLAs, no solo fallos: un pipeline que tiene exito pero tarda 3x mas de lo habitual sigue siendo un problema
Mantener los datos en crudo inmutables: nunca modifiques datos fuente; transforma en tablas separadas

DataOps no es una herramienta. Es un conjunto de prácticas que hacen tu infraestructura fiable, testeable, mantenible. Empieza con orquestación y testing, luego añade monitorización y chequeos conforme madures.

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.

Recursos de formación en MLOps y rutas de aprendizaje

Mon, 15 Feb 2021 13:00:14 +0100

MLOps con GitHub

Vídeo de flujo de trabajo MLOps con Github Actions - O’Really