Módulo 12Trimestre 4 · Operaciones en producción11 puntos del póster

Observabilidad y SRE

Inicia sesión para guardar tu progreso en todos tus dispositivos. Mientras tanto, se guarda en este navegador.

Por qué importa

Si los clientes te dicen que algo está roto antes que tus alertas, no tienes monitorización, tienes clientes haciendo QA. La observabilidad es además lo que permite depurar el código escrito por IA: cuando no escribiste tú el código, necesitas que el sistema te diga qué está haciendo.

Resultados de aprendizaje

  1. Emitir logs estructurados, métricas y trazas con OpenTelemetry.
  2. Definir SLIs y SLOs que reflejen la satisfacción del usuario y usar presupuestos de error.
  3. Escribir alertas accionables que no generen fatiga.
  4. Construir dashboards para las cuatro señales doradas.
  5. Observar el comportamiento, el coste y la calidad de los LLM y los agentes.

Lecciones

12.1 Las tres señales (58 a 61, 66)

  • Logs (59): JSON estructurado, un evento por línea, con request_id, user_id/tenant_id (no datos personales), level, event y duración. Nunca registres secretos, tokens, contraseñas, números de tarjeta completos ni datos personales en bruto. Define la retención.
  • Métricas (61): series temporales numéricas y baratas. RED para servicios (Rate, Errors, Duration); USE para recursos (Utilisation, Saturation, Errors).
  • Trazas (60): una petición seguida a través de servicios, colas y llamadas a LLM, con spans y tiempos. Propaga el contexto de traza a través de colas y webhooks.
  • La monitorización (58) vigila los modos de fallo conocidos. La observabilidad (66) te permite hacer preguntas nuevas al sistema en ejecución sin desplegar código nuevo. Necesitas ambas.
  • Usa OpenTelemetry para no quedarte atado a un proveedor.

12.2 Las cuatro señales doradas

Latencia, tráfico, errores, saturación (de la práctica SRE de Google). Un dashboard por servicio, en la parte superior de la página.

12.3 SLIs, SLOs y presupuestos de error (63, 64, 65)

  • SLI (64): una proporción medida de eventos buenos: "peticiones servidas con éxito en menos de 500 ms / total de peticiones".
  • SLO (63): un objetivo para el SLI en una ventana de tiempo: "99.9% en 28 días".
  • Presupuesto de error (65): el fallo permitido: el 0.1% de 28 días son unos 40 minutos. Si queda presupuesto, despliega con libertad. Si se ha consumido, frena y arregla la fiabilidad.
  • Elige SLOs por recorrido de usuario (login, checkout, respuesta de la IA), no por servidor. El 100% es el objetivo equivocado: es inasumible y frena todo cambio.

12.4 Alertas (62)

  • Despierta a una persona solo cuando los usuarios están sufriendo ahora o lo harán pronto (basado en síntomas), no ante cada pico de CPU.
  • Prefiere las alertas de burn rate sobre los SLOs (el consumo rápido avisa a guardia, el lento abre un ticket).
  • Cada alerta enlaza a un runbook: qué significa, cómo comprobarlo y cómo mitigarlo.
  • También alertas de negocio: cero registros en una hora, caída de la tasa de éxito de pagos, pico de gasto en LLM, DLQ creciendo, heartbeat de cron perdido.
  • Revisa el ruido de las alertas cada mes; borra las alertas sobre las que nadie actúa.

12.5 Health checks y probes (56, 57)

Consulta 07 · Patrones de resiliencia. Añade monitorización sintética externa del recorrido real desde varias regiones.

12.6 Observabilidad de LLM y agentes

Traza cada llamada al modelo: modelo, versión, versión del prompt, tokens de entrada y salida, coste, latencia (tiempo hasta el primer token y total), llamadas a herramientas, fuentes recuperadas, feedback del usuario y puntuaciones de evals. Herramientas: Langfuse, Helicone, Braintrust, o las convenciones GenAI de OpenTelemetry hacia tu backend actual. Vigila la deriva de calidad tras cambios de modelo o de prompt.

12.7 Seguimiento de errores y RUM

Seguimiento de excepciones con source maps y etiquetas de release (Sentry o equivalente). Monitorización de usuarios reales (RUM) de los Core Web Vitals.

Lab 12: Entérate antes que ellos

  1. Instrumenta la app con OpenTelemetry (logs, métricas, trazas) de extremo a extremo, incluido un salto por cola y una llamada al LLM.
  2. Define 3 SLOs para los recorridos críticos; construye el dashboard y las alertas de burn rate.
  3. Escribe un runbook para cada alerta.
  4. Rompe algo en staging; mide el tiempo desde la rotura hasta la alerta.
  5. Construye un panel de coste y calidad del LLM.

Definition of Done

Paquete de prompts de IA

  • "Añade instrumentación de OpenTelemetry a este servicio. Propaga el contexto a través de la cola. Añade un span alrededor de cada llamada al LLM y a herramientas, con atributos de tokens y coste."
  • "Audita nuestras llamadas de logging y marca cualquiera que pueda registrar secretos, tokens o datos personales."