Consigna y contexto
Un equipo quiere exponer una nueva versión a una pequeña porción de solicitudes reales antes de incrementar el tráfico gradualmente. El servicio debe configurar ponderaciones (weights), comparar la versión canary con la estable y detener o revertir (rollback) automáticamente cuando las señales se degraden. Diseña el plano de control y el de datos, incluyendo SLOs, ventanas de métricas, estado duradero, permisos, idempotencia y el comportamiento cuando el controlador se desconecta.
Esto encaja en roles de diseño de sistemas, ingeniería de plataformas y SRE. La habilidad central es transformar un "despliegue seguro" en una máquina de estados recuperable, no limitarse a enumerar Kubernetes, una malla de servicios (service mesh) y un producto de monitoreo. La respuesta debe cubrir enrutamiento, tareas de análisis, umbrales de decisión, intervención humana y compatibilidad hacia atrás con la versión anterior.
Qué evalúa el entrevistador
Una respuesta sólida define la exposición, la duración y el objetivo del rollback antes de separar el controlador de despliegue, el enrutador, las consultas de métricas y la lógica de decisión. Distingue entre éxito, falla y evidencia insuficiente para que la falta de métricas no se convierta accidentalmente en una aprobación. Utiliza estado duradero y acciones idempotentes para sobrevivir a reinicios del controlador, empareja las ventanas de análisis con los pasos del despliegue y aborda el ruido de muestras pequeñas, las métricas retrasadas y las tormentas de rollbacks.
Preguntas para clarificar primero
- ¿El objetivo es un solo servicio, una orquestación de múltiples servicios o únicamente cargas de trabajo de Kubernetes?
- ¿El tráfico se divide por solicitud aleatoria, hash estable de usuario, región o tenant, y los usuarios deben mantener afinidad (stickiness)?
- ¿Qué SLOs importan: tasa de errores, latencia, conversión de negocio o costo, y cómo se elige la línea base estable?
- ¿Cuánto tiempo puede ejecutarse cada paso, cuántas fallas disparan un rollback y un análisis incierto debe pausar para revisión humana?
- ¿Los esquemas de bases de datos, formatos de mensajes y APIs externas son compatibles hacia atrás, y es seguro revertir a la versión anterior?
Estructura para una respuesta de 30 segundos
"Dividiría el servicio en un controlador de despliegue, un adaptador de enrutamiento de tráfico, un analizador de métricas y un almacén de estado duradero. Cada despliegue tiene versiones estable y candidata, ponderaciones por etapas, una ventana de análisis y condiciones explícitas de éxito, falla e inconcluso. El controlador solo expande tras el éxito, regresa el tráfico a estable ante fallas y pausa con una alerta cuando la evidencia es inconclusa. Los comandos llevan una versión y una clave de idempotencia, y el estado se persiste antes del siguiente paso. Durante una interrupción breve del enrutador o de las métricas, se mantiene el último peso seguro y se reanuda desde el estado duradero tras la recuperación."
Solución paso a paso
Paso 1: definir objetivos y escala
Asume que una región maneja 200 despliegues por día, cada uno con una duración máxima de 40 minutos, mientras que el controlador procesa decenas de eventos de estado y métricas por segundo; las solicitudes de negocio permanecen en el gateway y los servicios existentes. Esta estimación de orden de magnitud respalda un controlador y una cola de alta disponibilidad en lugar de una instancia de flujo de trabajo por solicitud.
El objetivo de seguridad es limitar el radio de impacto (blast radius). Una secuencia configurable como 1% → 5% → 25% → 50% → 100% es ilustrativa, no un umbral universal. Cada paso necesita un tiempo mínimo de observación y una espera máxima para que una señal faltante no ocupe un espacio de despliegue indefinidamente.
Paso 2: separar los planos de control y de datos
El plano de control almacena la especificación del despliegue, los resúmenes (digests) de versión, el paso actual, el peso objetivo, los resultados de análisis y el actor. El plano de datos utiliza un gateway o service mesh para enrutar solicitudes al ReplicaSet estable o canary. La arquitectura de Argo Rollouts separa el Rollout, dos ReplicaSets versionados, Services/Ingress y AnalysisTemplate/AnalysisRun, demostrando límites que pueden evolucionar independientemente.
El adaptador de métricas solo ejecuta consultas contra proveedores como Prometheus y devuelve observaciones con su ventana de tiempo. El motor de decisiones aplica políticas y no edita rutas directamente, por lo que reemplazar un backend de métricas no modifica la máquina de estados del despliegue.
Paso 3: construir una máquina de estados recuperable
Utiliza estados como Draft → Running → Paused → Promoting → Succeeded, con Running o Paused capaces de ingresar a Aborting → RolledBack. Cada transición lleva un rollout_id, versión deseada, número de paso y clave de idempotencia. Una restricción única o compare-and-set evita que dos controladores avancen el mismo despliegue.
Running + analysis=success -> Promoting(next_weight)
Running + analysis=failure -> Aborting(weight=0)
Running + analysis=inconclusive -> Paused(reason=insufficient_signal)
Paused + operator=resume -> Running
Aborting + route=stable -> RolledBackTras un reinicio, el controlador reproduce las acciones no finalizadas a partir del último estado confirmado. Las actualizaciones de rutas y las escrituras de estado no pueden formar una única transacción atómica entre sistemas, por lo que las acciones deben ser repetibles: establecer el mismo peso dos veces no tiene efecto adicional, y el controlador lee la ruta real antes de elegir el siguiente paso.
Paso 4: elegir métricas y ventanas
Cada paso debe tener al menos una señal de confiabilidad y una señal de negocio, tales como el delta de tasa de errores entre canary y estable, el delta de latencia P95 y la tasa de éxito de solicitudes clave. Fija la ventana de consulta, el denominador y los filtros para que los reintentos de canary no se comparen con las solicitudes originales de la versión estable.
La ventana debe cubrir el retraso de recolección y mantenerse dentro del tiempo de espera (timeout) del paso. La guía de canary de Google SRE compara el canary con un control y advierte que un período de métricas más largo que una etapa corta de canary produce una señal confusa. Marca las muestras pequeñas como inconclusas; pausar es más seguro que expandir basándose en evidencia débil.
Paso 5: manejar divisiones de tráfico y afinidad (stickiness)
La división aleatoria de solicitudes se adapta a APIs sin estado. Para una experiencia consistente, utiliza un hash estable de usuario o tenant y registra la versión enrutada. El enrutamiento porcentual debe manejar un candidato no saludable, un peso no aplicado, divergencia regional y colisiones de claves de caché.
El adaptador de enrutamiento devuelve el peso efectivo y el digest de la versión. Si los valores deseados y reales difieren, el controlador se pausa y alerta; una respuesta exitosa de la API de enrutamiento no es prueba de que el tráfico haya cambiado.
Paso 6: diseñar rollback, pausa e intervención humana
Ante una falla, detén el incremento del tráfico canary y redúcelo a cero o a un peso seguro. Mantén la versión antigua ejecutable y utiliza un esquema de orden expand/contract para las migraciones de bases de datos, de modo que el rollback aún pueda leer el esquema. El rollback en sí necesita un timeout y un límite de reintentos para evitar un bucle infinito cuando el enrutador no esté disponible.
Cuando el análisis sea Inconclusive, pausa junto con la evidencia: la consulta, el conteo de muestras, la versión, la ventana y el umbral deben ser auditables. Argo Rollouts documenta Inconclusive como un resultado en pausa para el juicio humano, lo cual es más seguro que tratar los datos faltantes como un éxito.
Paso 7: confiabilidad, permisos y auditoría
Utiliza elección de líder o un lease para el controlador. La entrega de la cola puede ser al menos una vez (at-least-once), por lo que los consumidores deduplican mediante clave de idempotencia. Escribe las especificaciones de lanzamiento, los cambios de políticas y las aprobaciones en un registro de auditoría inmutable. Solo los propietarios del lanzamiento modifican los pesos; las credenciales de métricas provienen de un secret manager; el permiso de rollback es independiente de la promoción ordinaria.
Monitorea los SLOs del plano de control: latencia de transición, despliegues atascados, duración del rollback, peso real frente al deseado y fallas en consultas de métricas. Cuando falle el plano de control, mantén la última ruta segura y envía una alerta (page) a un operador en lugar de enviar automáticamente el canary al 100%.
Paso 8: verificar y realizar pruebas de carga
Inyecta fallas para tasas de error crecientes, ausencia de datos, datos demorados, timeouts del enrutador, reinicios del controlador, mensajes duplicados y un esquema de base de datos incompatible. Verifica el estado final y la alerta para cada falla, no solo la ruta feliz (happy path).
Reproduce lanzamientos históricos para medir el costo de consultas de análisis y la acumulación de la cola, y ejecuta pruebas de falla del controlador N+1. Utiliza cien despliegues simultáneos como un límite de carga de ejemplo, observa la contención de bloqueos en el almacén de estado, las QPS del proveedor de métricas y la tasa de actualización de rutas, y luego establece un límite de concurrencia.
Compensaciones y límites
La automatización elimina la demora humana, pero un umbral incorrecto puede transformar el ruido en un rollback o una regresión real en una aprobación. Un umbral de tasa de error absoluto es fácil de explicar y se adapta a servicios de bajo tráfico; una comparación con la versión estable o una línea base estratificada maneja mejor las variaciones diarias de tráfico, pero requiere estadísticas más cuidadosas y alineación de muestras. Los servicios de alto riesgo pueden requerir aprobación humana después del análisis automatizado.
Blue-green ofrece un cambio rápido y un rollback simple, pero generalmente requiere el doble de capacidad. Canary reduce la exposición, pero requiere división de tráfico y ventanas de análisis. Un feature flag puede separar el lanzamiento de una funcionalidad de un despliegue de binarios, aunque no puede reemplazar las comprobaciones de compatibilidad para binarios, dependencias o esquemas. Elige según el costo de rollback, la forma del tráfico y el riesgo de SLO.
Plan de implementación y evidencia
Comienza con análisis de solo lectura y pausa manual para un servicio sin estado. Verifica las etiquetas de stable/canary, la agrupación de métricas y los campos de auditoría; luego habilita el rollback automático; finalmente agrega señales multirregión, métricas de negocio y un límite de concurrencia. Mantén un interruptor de emergencia (kill switch) humano y un propietario explícito en cada etapa.
Google SRE define la estrategia canary como un despliegue parcial y por tiempo limitado más una evaluación, y exige que dicha evaluación alimente el proceso de lanzamiento. Argo Rollouts proporciona AnalysisTemplate/AnalysisRun, umbrales de métricas y resultados de éxito, falla e inconcluso. El material público de entrevistas de diseño de sistemas también trata la división de tráfico, la evaluación de salvaguardas (guardrails) y el rollback automático como puntos de diseño de canary. Por lo tanto, este artículo de Offer.cc se centra en una máquina de estados del plano de control recuperable en lugar de un glosario de estrategias de despliegue.
Errores comunes y preguntas de seguimiento
Solo decir "observar el 10% del tráfico"
Sin la población, duración, denominador y acción ante fallas, la seguridad no está demostrada. Agrega una línea base estable, ventana, umbral, pausa y ruta de rollback.
Tratar las métricas faltantes como una aprobación
Una caída del recolector puede fabricar una señal aparentemente saludable. Marca la ausencia de datos, NaN, demoras y muestras insuficientes como inconclusos; pausa y alerta.
Hacer rollback de un Deployment pero no de la ruta
Tener pods antiguos saludables no demuestra que las solicitudes hayan salido del canary. Verifica el peso efectivo, los selectores de servicio y la persistencia de sesiones o caché.
Hacer que la migración de base de datos sea irreversible
Es posible que la versión anterior no pueda leer el nuevo esquema, por lo que revertir la ruta no restaurará la seguridad. Utiliza cambios expand/contract compatibles hacia atrás y haz que el estado de la migración sea una compuerta (gate) del despliegue.
¿Qué pasa si el proveedor de métricas está caído?
Mantén el último peso seguro, detén la expansión automática, registra el análisis incompleto y notifica al propietario. Tras la recuperación, reanuda desde el estado duradero; nunca llenes el vacío con una "aprobación" por defecto.