Resumen Ejecutivo
El 10 de junio de 2026, a las 09:15 UTC, el deploy de la versión 3.8.1 de la plataforma CULTIVA IA provocó la caída completa del módulo de ejecución de skills durante 2 horas y 18 minutos. Todos los clientes con acceso al panel recibían errores 503 al intentar lanzar cualquier skill.
La causa raíz fue la ausencia de la variable de entorno
El incidente se resolvió deployando el hotfix v3.8.2 con un valor por defecto para la variable. Tres clientes enterprise sufrieron automatizaciones paralizadas y ~240 skills quedaron sin procesar. No hubo pérdida de datos.
La causa raíz fue la ausencia de la variable de entorno
REDIS_QUEUE_PREFIX en el secrets manager de producción, introducida en v3.8.1 pero únicamente configurada en staging mediante un valor hardcodeado en .env. Sin ese valor, los workers crasheaban silenciosamente al no poder conectar a la cola de tareas correcta.El incidente se resolvió deployando el hotfix v3.8.2 con un valor por defecto para la variable. Tres clientes enterprise sufrieron automatizaciones paralizadas y ~240 skills quedaron sin procesar. No hubo pérdida de datos.
Impacto
3
Clientes enterprise afectados
240
Skills en cola sin procesar
14
Tickets de soporte abiertos
2h18
Duración total del incidente
0
Pérdida de datos
Alto
Riesgo renovación ImmoByte (julio)
Cronología (UTC)
09:15
Deploy v3.8.1 completado en producción deploy
Sistema de cola de tareas actualizado con soporte multi-tenant. Workers reiniciados.
09:27
Primera alerta Datadog: skill_worker_error_rate > 10% alerta
Tasa de error sube rápidamente al 100%. Cola de skills bloqueada.
09:31
@tomas-devops reconoce alerta, inicia investigación
Revisión de logs: workers crasheando con error de conexión Redis. Sin stack trace claro.
09:38
Clientes enterprise reportan automatizaciones detenidas
Nutribox, ImmoByte y GreenSaaS abren tickets de soporte. Carla (CS) informa al equipo.
09:45
Incidente escalado SEV2 escalado
@laura-cto y @alex-backend se suman. War room en Slack #inc-2026-06-10.
10:10
Causa raíz identificada diagnóstico
REDIS_QUEUE_PREFIX no existe en secrets manager de producción. Variable nueva en v3.8.1 no documentada en checklist de deploy.
10:22
Hotfix v3.8.2 preparado y revisado por @alex-backend
Añade fallback: REDIS_QUEUE_PREFIX=cultiva-default si variable ausente. Startup check con mensaje de error claro.
10:35
Deploy v3.8.2 completado fix
Workers arrancan correctamente. Cola comienza a procesar las 240 skills pendientes.
11:05
Cola de skills completamente procesada
Los 240 jobs atrasados ejecutados. Error rate = 0%. Clientes notificados por Carla.
11:33
Incidente cerrado — monitoring estable 28 min
Análisis de Causa Raíz — 5 Whys
1
¿Por qué el módulo de skills dejó de funcionar?
Los workers no podían conectar a la cola Redis correcta y crasheaban en silencio.
Evidencia: Logs de worker:
RedisConnectionError: key 'null:jobs' not found. Error rate 100% desde 09:27.2
¿Por qué los workers no podían conectar a la cola correcta?
La variable REDIS_QUEUE_PREFIX era undefined en producción, generando una clave Redis inválida.
Evidencia: AWS Secrets Manager no tenía la clave. En staging existía en .env como valor hardcodeado.
3
¿Por qué no se añadió REDIS_QUEUE_PREFIX al secrets manager de producción?
No existe en el checklist de deploy ningún paso que verifique que todas las nuevas variables de entorno estén configuradas en producción.
Evidencia: Checklist actual (v1.2) no incluye validación de variables de entorno nuevas en el paso pre-deploy.
4
¿Por qué no se detectó en staging?
Staging usaba un .env con la variable hardcodeada. No existe parity check entre variables de staging y producción.
Evidencia: Staging .env contiene REDIS_QUEUE_PREFIX=cultiva-staging. Producción nunca fue actualizada.
5
¿Por qué el fallo no generó alerta inmediata y fue silencioso durante 12 minutos?
El worker capturaba la excepción de conexión Redis y reintentaba silenciosamente sin loguear a nivel ERROR ni emitir métrica de startup failure.
Evidencia: Código pre-hotfix: try/catch genérico en RedisWorker.initialize() sin emit de métricas de health check.
Plan de Acción
| Acción | Tipo | Prio | Responsable | Fecha límite |
|---|---|---|---|---|
| Añadir step "validar env vars nuevas" al checklist de deploy pre-producción | Prevención | Alta | @tomas-devops | 20 jun 2026 |
| Crear script CI que compare variables entre staging y producción en cada PR | Prevención | Alta | @alex-backend | 27 jun 2026 |
| Añadir startup health check al worker con alerta inmediata si Redis inaccesible | Detección | Alta | @alex-backend | 24 jun 2026 |
| Reducir umbral de alerta skill_worker_error_rate de 10% a 2% | Detección | Media | @tomas-devops | 20 jun 2026 |
| Documentar naming convention de variables de entorno en wiki interno | Prevención | Media | @laura-cto | 30 jun 2026 |
| Call de disculpa + demo recuperación con ImmoByte (riesgo renovación) | Mitigación | Alta | @carla-cs + @laura-cto | 18 jun 2026 |
| Activar canary deploy (10% tráfico) antes de rollout total en producción | Mitigación | Baja | @tomas-devops | 15 jul 2026 |
Cultura Blameless — Revisión de Anti-Patrones
✓ Evitado — Blame game
No se buscó "quién hizo el deploy". El análisis se centró en qué condiciones del sistema permitieron que esto ocurriera.
✓ Evitado — Análisis superficial
Se aplicaron los 5 Whys completos, llegando a la causa sistémica (ausencia de parity check y health check).
✓ Evitado — Sin action items
Todos los items tienen responsable, fecha límite y están trackeados en Linear (#INC-047).
⚠ Riesgo — Follow-up olvidado
Revisar estado de action items el 27 jun en retro quincenal. Asignar recordatorio en calendario del equipo.