Despliegues progresivos: cómo volver atrás antes de que un fallo se extienda

Un despliegue seguro no es el que nunca falla, sino el que limita la exposición, detecta problemas y conserva una forma de recuperar el servicio. Las entregas progresivas permiten observar una versión en una parte controlada del tráfico antes de extenderla. Para que funcionen, necesitan algo más que un porcentaje pequeño: artefactos identificables, métricas relevantes y decisiones preparadas. El momento de acordar cuándo detenerse es antes de pulsar el botón, cuando todavía no existe presión por justificar el cambio.

Construye una versión que puedas identificar y repetir

Promueve el mismo artefacto validado entre entornos, manteniendo identificador de versión y referencias a configuración. Reconstruirlo de manera distinta en cada paso puede introducir variaciones que no se han probado. Conserva el artefacto anterior y comprueba que sigue disponible para recuperar. La trazabilidad debe permitir responder qué código, dependencias y configuración atendieron una petición. Esa información facilita comparar resultados y evita perder tiempo investigando sistemas que no ejecutan realmente la misma versión.

Elige un grupo inicial que aporte información

Una canaria recibe una parte limitada del trabajo mientras el resto permanece en la versión de control. El tamaño depende del tráfico y del riesgo. Si el grupo es demasiado pequeño o no ejecuta la función modificada, puede dar una falsa sensación de estabilidad. Considera diferencias entre clientes, regiones o tipos de operación. Los despliegues canarios descritos por Google SRE se apoyan precisamente en evaluar un cambio parcial y acotado antes de decidir si continúa.

Mantén la comparación en condiciones razonablemente equivalentes. Si la versión nueva recibe únicamente solicitudes fáciles, la latencia no será comparable. También hay fallos que solo aparecen tras cierto tiempo, como fugas de memoria o tareas programadas. Define una duración de observación que tenga sentido para el cambio y no solo para la velocidad deseada de la entrega. Una progresión automática sin datos suficientes puede extender un problema antes de detectarlo.

Define señales de parada antes de desplegar

Selecciona errores, latencia y una medida funcional que indique si la tarea principal se completa. Establece umbrales con contexto y una persona responsable de valorar desviaciones ambiguas. Un indicador técnico normal no garantiza que los usuarios obtengan el resultado correcto. Para cambios importantes, añade comprobaciones sintéticas o verificaciones de negocio que no generen efectos reales indebidos. Registra qué condición obliga a parar, cuál requiere observación adicional y quién puede aprobar el siguiente paso.

• Verifica artefacto anterior, configuración compatible y permisos de recuperación.
• Abre la versión nueva a un grupo limitado con actividad representativa.
• Compara señales técnicas y funcionales durante el periodo acordado.
• Detén la expansión y ejecuta la recuperación prevista si se cumple un criterio de parada.

Comprueba qué puede revertirse de verdad

Volver al código anterior no deshace una migración incompatible, un mensaje enviado o un trabajo que ya está en ejecución. Revisa efectos persistentes y dependencias antes de afirmar que existe rollback. Cuando hay cambios de datos, conserva compatibilidad temporal o prepara una corrección hacia delante. Si el despliegue modifica configuración compartida, incluye esa configuración en el plan. La recuperación debe describir el estado final esperado, no limitarse a mencionar un comando de versiones.

Ensaya el regreso en condiciones controladas

Practica la reversión con un cambio de bajo riesgo y mide cuánto tarda en recuperar el comportamiento esperado. Comprueba conexiones, cachés, tareas pendientes y balanceadores. Algunas peticiones pueden seguir ejecutándose en instancias antiguas durante un tiempo; decide cómo se drenan y qué pasa con las operaciones largas. Una recuperación probada revela permisos que faltan y automatismos que podrían volver a desplegar la versión problemática si no se desactivan de manera coordinada.

La comunicación también forma parte del proceso. Quien atiende soporte debe conocer el cambio y cómo reportar síntomas relacionados. Si se detiene la entrega, informa de alcance, estado y siguiente revisión sin atribuir una causa antes de comprobarla. Mantén una cronología con versión, momento de activación y decisiones. Esta información permitirá distinguir un fallo del cambio de una incidencia coincidente y facilita que otra persona continúe el trabajo si hace falta un relevo.

Aprende sin normalizar recuperaciones constantes

Una reversión bien ejecutada protege el servicio, pero repetirla en cada entrega señala problemas previos. Revisa pruebas, tamaño de cambios, calidad de observación y compatibilidad de datos. Corrige la causa antes de reintentar y actualiza los criterios si eran insuficientes. El objetivo de la entrega progresiva es obtener información con una exposición limitada y avanzar con confianza basada en evidencia. Un proceso claro permite desplegar con frecuencia sin convertir cada versión en una apuesta sobre la continuidad.