¿Qué es el despliegue canary? Guía práctica para SRE

¿Qué es el despliegue canary? Es una técnica de release en la que una nueva versión llega primero a una pequeña porción del tráfico de producción, se compara con la versión que ya está en ejecución y solo se amplía si los números aguantan. Dicho de otra forma: es un deploy con un punto de decisión integrado. El cambio llega al 1 o al 5 por ciento de los usuarios, y una comprobación de métricas decide si continúa o si se revierte.

El resto de esta guía explica cómo funciona, dónde falla y qué conviene automatizar.

La página de las 3 de la mañana que un canary habría convertido en un mensaje de Slack

Un despliegue sale un jueves a las 16:40. La tasa de errores del servicio de checkout sube del 0.2 al 4 por ciento. Nadie lo nota hasta que, dos horas después, llega un ticket de soporte, y para entonces todos los usuarios ya están ejecutando la nueva build. Revertir tarda 25 minutos porque la migración de base de datos está aplicada a medias.

Lanza el mismo cambio como canary sobre el 5 por ciento del tráfico y el daño queda acotado. Aproximadamente uno de cada veinte usuarios ve el error, la comparación contra el control falla en cuestión de minutos y el pipeline se detiene. El postmortem hablaría de lo que el canary detectó, no de lo que se le escapó.

El nombre viene de las minas de carbón, donde el canario dejaba de cantar antes de que el aire se volviera letal. Tu cohorte pequeña cumple el mismo papel. No evita la mala release. Limita quién la respira.

Qué hace un despliegue canary, paso a paso

La Google SRE Workbook define el canarying como un despliegue parcial y limitado en el tiempo de un cambio, más una evaluación que decide si el rollout continúa. El subconjunto que ejecuta el cambio es el canary. El resto de la flota es el control. Este encuadre importa porque convierte el canary en una prueba A/B sobre tu propia fiabilidad, y no en un despliegue lento.

Una secuencia típica se ve así:

• Desplegar la versión nueva junto a la estable, sin tráfico todavía.

• Enviar un porcentaje pequeño hacia ella (el ejemplo del Workbook usa el 5 por ciento).

• Mantener una ventana fija (el mismo ejemplo usa 30 minutos) mientras se comparan canary y control.

• Avanzar al siguiente paso, por ejemplo 25, 50 y 100 por ciento, o abortar y devolver el tráfico a la versión estable.

El bucle es simple. La parte difícil es el paso de comparación, que la mayoría de equipos implementa como "alguien mira un dashboard".

Canary, blue-green y rolling: cuál encaja con tu modo de fallo

Estas tres estrategias se confunden constantemente, así que aquí va la distinción que importa al elegir.

• Rolling update: reemplaza instancias poco a poco. Es barato y viene integrado en cualquier orquestador, pero no hay comparación contra un control ni un reparto de tráfico limpio. Las versiones vieja y nueva comparten carga hasta el final.

• Blue-green: dos entornos completos, y se cambia todo el tráfico de golpe. La reversión es instantánea, pero el radio de impacto en el momento del cambio es el 100 por ciento de los usuarios, y pagas capacidad doble.

• Canary: una fracción controlada del tráfico real sobre la versión nueva, juzgada contra la antigua. Es el radio de impacto más pequeño y también la complejidad operativa más alta.

Elige blue-green cuando el riesgo es un despliegue roto que puedes detectar con un smoke test y revertir en segundos. Elige canary cuando el riesgo es una regresión sutil que solo el tráfico real revela: un aumento del p99 de latencia, una fuga lenta de memoria o un plan de consulta que se derrumba con las formas de datos de producción.

Descarta canary si tu servicio tiene muy poco tráfico. Con unos cientos de peticiones por hora, un corte del 5 por ciento te da un puñado de muestras y ninguna señal. El Workbook lo dice sin rodeos: muy pocas consultas no ofrecen una señal útil para cargas de trabajo diversas.

Por qué tu canary del 1 por ciento probablemente te miente

Este es el fallo que golpea a los equipos en los primeros tres meses. El canary recibe el 5 por ciento del tráfico y falla el 20 por ciento de sus peticiones. La tasa de errores de todo el servicio pasa del 0.2 a cerca del 1.2 por ciento. Tu umbral de alerta está en el 2 por ciento. No salta nada.

El monitoreo agregado oculta los fallos del canary. La misma aritmética aparece en el SRE Workbook: un canary que falla el 20 por ciento de las peticiones con el 5 por ciento del tráfico solo muestra un 1 por ciento de error global. Tienes que desglosar las métricas por población, canary frente a control, o la señal desaparece en el denominador.

Hay otras tres trampas que conviene conocer:

• Comparaciones antes y después. Comparar la ventana del canary con la hora anterior mezcla el cambio con el tiempo. El tráfico de un día laborable frente a un fin de semana puede tapar una regresión real. Compara contra un control concurrente.

• Dependencias compartidas. Si canary y control golpean la misma caché o la misma base de datos, un canary malo puede degradar a los dos y la comparación no muestra nada. Revisa tus dominios de fallo.

• Métricas ruidosas. El uso de CPU es un mal criterio de control. Los códigos de error y la latencia reflejan lo que siente el usuario. El Workbook recomienda ordenar las métricas candidatas según lo bien que reflejan problemas visibles para el usuario y quedarse solo con las mejores, quizá una docena como máximo.

Elige las métricas de control antes de desplegar, no durante el incidente

Empieza por tus SLI. Si ya tienes un SLI de disponibilidad y otro de latencia para el servicio, esos son tus dos primeros controles. Un conjunto inicial razonable para un servicio dirigido por peticiones:

• Tasa de errores 5xx del canary frente al control, durante la ventana de observación.

• Latencia p99 del canary frente al control.

• Una señal de saturación atribuible al cambio, como el crecimiento de memoria por pod.

• Una métrica cercana al negocio, por ejemplo la finalización de compras, si puedes aislarla por cohorte.

Los umbrales son donde los equipos pierden semanas. Si los fijas demasiado estrictos, cada canary se aborta por ruido y los ingenieros aprenden a saltarse el control. Si los fijas demasiado laxos, una build mala pasa sin problema. Revísalos con un calendario. Un control que no ha abortado nada en seis meses es perfecto o decorativo, y conviene averiguar cuál de las dos cosas es.

Mantén también el intervalo de agregación de las métricas no mayor que la ventana del canary. Un rollup de 10 minutos sobre un canary de 5 lo emborrona todo.

Un canary en configuración: así se ven los pasos en Argo Rollouts

En Kubernetes, la especificación de canary de Argo Rollouts expresa la secuencia como una lista de pasos. Esta es una versión condensada, en la forma que describe la documentación:

strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 30m }
      - analysis:
          templates:
            - templateName: error-rate-vs-baseline
      - setWeight: 25
      - pause: { duration: 30m }
      - setWeight: 50
      - pause: {}

Dos detalles de la documentación merecen atención. Sin un router de tráfico, el peso se aproxima por el número de pods, con base en el mejor esfuerzo: 10 réplicas al 10 por ciento significan un pod canary y nueve estables. Eso es aritmética de réplicas, no de peticiones. Y un pause: {} sin duración espera indefinidamente hasta que alguien ejecuta kubectl argo rollouts promote, una puerta humana que quizá quieras o quizá no.

Si el paso de análisis falla, el rollout se aborta. Ahí es donde conviene invertir.

Los feature flags son la otra mitad de un canary seguro

Los canaries de infraestructura reparten el tráfico por instancia o por pod. Los canaries basados en flags reparten por usuario, por cuenta o por cualquier atributo que puedas segmentar. Responden preguntas distintas. La primera pregunta si la build nueva está sana. La segunda pregunta si el comportamiento nuevo es aceptable, y permite apagarlo sin volver a desplegar.

Para los despliegues con flags, la herramienta importa. LaunchDarkly tiene las reglas de segmentación y el registro de auditoría más maduros, y gana en amplitud de ecosistema. Su precio a escala empresarial es la queja habitual entre los responsables de plataforma.

Statsig integra experimentación con flags, lo que encaja con los equipos que quieren juzgar por métricas en la misma plataforma. Encaja menos si solo necesitas un interruptor de emergencia.

El compromiso, dicho sin rodeos: una plataforma de flags te da despliegues por porcentaje, pero la mayoría no lee tus SLO por sí sola. Alguien sigue teniendo que conectar la métrica con la decisión.

Necesitas una fuente de comparación que pueda separar por versión

Sea lo que sea lo que dirija el rollout, el veredicto sale de tu telemetría. Eso significa que cada métrica necesita una etiqueta de versión o de cohorte, y que tu backend tiene que consultarla por esa etiqueta sin un retraso de 10 minutos.

Datadog lo hace bien con desgloses basados en tags, y su seguimiento de despliegues correlaciona las releases con los picos de error. El coste con alta cardinalidad es lo que conviene modelar antes de etiquetar todo.

Grafana con Prometheus funciona si ya lo ejecutas y etiquetas las métricas por revisión del rollout. Tienes control total, y el mantenimiento es tuyo.

Automatizar el aborto: de dónde viene la idea del piloto con IA

El análisis manual de canaries escala mal. A diez despliegues al día, nadie se queda 30 minutos mirando un dashboard cada vez, así que el control se convierte, sin hacer ruido, en un "parece bien". El patrón que aguanta es un juez automatizado: defines el SLO, defines la comparación y dejas que un controlador aborte y revierta cuando el canary consume el presupuesto de error más rápido que el control.

Ese es el problema al que apunta AI Pilot de upstreamapi: lee la señal del SLO durante el rollout y dispara un auto-rollback cuando la tasa de errores cruza el umbral que tú fijas. Mide la tasa de errores y la latencia frente a la cohorte estable, nada más místico. Si ya ejecutas plantillas de análisis de Argo Rollouts con una buena consulta a Prometheus, tienes buena parte de la misma capacidad, y conviene decirlo a quien te venda magia. Donde un piloto alojado se gana su sitio es en stacks heterogéneos, donde cada equipo tendría que mantener sus propias plantillas de análisis.

Un patrón de fallo frecuente: los equipos automatizan el paso de promoción y nunca automatizan el aborto. Un pipeline que solo sabe avanzar es una cinta transportadora.

Qué medir para saber si tu proceso de canary funciona

Un programa de canaries tiene sus propias métricas. Sigue estas durante un trimestre:

• Tasa de aborto de canaries: proporción de canaries detenidos por el control. Cero significa que el control está ciego. Por encima del 20 o 30 por ciento suele indicar umbrales inestables o pruebas previas al merge insuficientes.

• Tiempo de detección en el canary: minutos desde la primera petición mala hasta el aborto. Es tu MTTD real para las releases.

• Regresiones que se escaparon: incidentes atribuidos a una release que pasó el canary. Cada una debería cambiar un control.

• Tiempo medio de reversión: desde la decisión de abortar hasta que el 100 por ciento del tráfico está en la versión estable.

Ejecuta solo un canary a la vez por servicio. El Workbook lo recomienda con firmeza, y la razón es práctica: dos cambios superpuestos hacen imposible la atribución, y no sabrás cuál te perjudicó.

Por dónde empezar esta semana

Elige un servicio sin estado con tráfico suficiente para producir una señal en 15 minutos. Añade una etiqueta de versión a sus métricas de error y latencia. Escribe una única consulta de comparación, canary frente a control. Lanza un canary del 5 por ciento con promoción manual y anota qué habrías detectado en los últimos tres incidentes.

Luego hazte la pregunta incómoda: si el canary hubiera fallado a las 02:00, ¿algo lo habría detenido sin que una persona estuviera despierta?