C

Skill Entry

Canary rollouts

Despliega una nueva versión a un pequeño porcentaje de tráfico de producción primero, monitorea error budgets y latencia contra línea base y automáticamente amplía o hace rollback basado en criterios pre-definidos. Esto mantiene el blast radius de un mal deployment pequeño: particularmente importante cuando agentes de IA están modificando pipelines de deployment donde un solo mal comando podría afectar a muchos usuarios.

Categoría Operaciones
Plataforma Codex / Claude Code
Fecha de publicación 2026-04-13
deploymentsriskreliability

Casos de uso

  • Rolling out una actualización de dependencia riesgosa donde quieres señales tempranas antes de comprometerte con el deployment completo
  • Desplegando una nueva versión de modelo de IA o cambio de prompt que podría afectar la calidad de respuesta de maneras sutiles
  • Deployments de viernes donde quieres limitar exposición sobre el fin de semana cuando menos ingenieros están disponibles
  • Un feature flag toggle para una funcionalidad de alto tráfico donde quieres validar rendimiento antes de la audiencia completa
  • Desplegando cambios de infraestructura (nueva versión de base de datos, nueva capa de caching) donde las diferencias de comportamiento no son obvias en staging

Funciones principales

  • Antes de cambiar cualquier tráfico, define métricas de éxito: tasa de error, latencia p99 y cualquier métrica de calidad de modelo apropiada para el cambio
  • Fija el slice inicial de canary a un subconjunto pequeño y representativo de tráfico: típicamente 1-5% de requests y enrútalo a la nueva versión
  • Monitorea las métricas de éxito continuamente por los primeros 30-60 minutos y compara contra la línea base de la versión estable anterior
  • Si las métricas se mantienen dentro de límites aceptables, amplía automáticamente a 25%, luego 50%, luego 100% en un schedule pre-definido; si las métricas degradan, haz rollback automático a la versión anterior
  • Después del rollout completo, confirma que las métricas permanecen estables por al menos un día laboral completo antes de considerar el deployment completo

Relacionados

Relacionados

3 Entradas indexadas