1% canary

En el Radar compartido: Adopt (valoración de la edición aportada).

Cómo funciona

Se mantienen una versión estable y una candidata. Una regla de enrutamiento o un feature flag asigna una cohorte estable a la candidata. La observabilidad compara fallos, latencia y resultados del negocio entre ambas, segmentados por contexto.

Ejemplo: ampliar con evidencia

Etapa ilustrativa	Qué comprobar antes de continuar
1 %	Tráfico suficiente y ausencia de regresiones relevantes
5 % y 25 %	Estabilidad sostenida y cobertura de segmentos
100 %	Criterios acordados satisfechos durante la observación

Los porcentajes y ventanas deben adaptarse a la carga. Un servicio con pocas solicitudes puede necesitar más tiempo para producir evidencia útil.

Comparar contra una línea base, no contra el pasado

Compara la canary con instancias de la versión estable en el mismo momento y con el mismo tipo de tráfico, no con la semana anterior. Algunas plataformas despliegan además un baseline nuevo de la versión estable del mismo tamaño que la canary, para que diferencias por instancias recién arrancadas (cachés frías) no se atribuyan a la versión.

Señales a vigilar

Tipo	Ejemplos
Técnicas	Tasa de errores 5xx, latencia p95/p99, reinicios, memoria
Dependencias	Errores y latencia hacia base de datos y servicios externos
Negocio	Solicitudes completadas, pagos exitosos, tasa de aprobación
Cliente	Errores de JavaScript, caídas de la app móvil

Las métricas de negocio detectan errores funcionales que no producen excepciones (un cálculo de cuota incorrecto que el sistema procesa «con éxito»).

Análisis automático

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: tasa-errores
spec:
  metrics:
    - name: errores-5xx
      interval: 1m
      count: 10
      failureLimit: 2
      successCondition: result[0] < 0.01
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_server_requests_total{app="api-pagos",track="canary",status=~"5.."}[5m]))
            /
            sum(rate(http_server_requests_total{app="api-pagos",track="canary"}[5m]))

Herramientas similares: Flagger, Kayenta (análisis estadístico de canaries) o la división de tráfico de Cloud Run controlada desde el pipeline.

Poco tráfico, poca evidencia

Con un 1 % de un servicio que recibe 100 peticiones por minuto, la canary ve una petición por minuto: en 10 minutos no hay base estadística. Opciones:

• Ampliar la duración de la primera fase.
• Empezar con un porcentaje mayor (5–10 %) en servicios con poco tráfico.
• Dirigir primero tráfico interno o de empleados (dogfooding).
• Complementar con pruebas sintéticas sobre la canary.

Canary en aplicaciones móviles

No se puede revertir una app instalada. Las tiendas ofrecen lanzamientos graduales: Google Play permite elegir el porcentaje de usuarios, y App Store ofrece phased release durante siete días. Combínalo con feature toggles para desactivar funciones sin publicar otra versión y con monitorización de crashes por versión.

Antipatrones frecuentes

• Canary sin criterios de aborto definidos: alguien mira un panel y decide «parece bien».
• Cohortes que cambian en cada petición: un usuario ve alternativamente las dos versiones.
• Canary de código con migración de datos incompatible: el retroceso no deshace los datos.

Criterios de implementación

Elige cohortes representativas y conserva su asignación entre sesiones. Define umbrales de aborto antes de empezar. Asegura compatibilidad de datos y una estrategia de recuperación; una migración destructiva no se revierte simplemente desviando tráfico.