Guía de simulacro de rollback: restaurar una versión dañada en 5 minutos

Por qué los rollbacks dan miedo (y por qué practicar ayuda)

Una release puede verse bien en pruebas y luego romperse en los primeros cinco minutos de tráfico real. La parte aterradora casi nunca es el bug. Es la incertidumbre: qué cambió, qué puedes deshacer con seguridad y si un rollback lo empeorará.

Justo después de una release, las fallas suelen ser simples y dolorosamente visibles. Un botón nuevo puede bloquear la página en móvil. Un cambio en el backend puede devolver una forma de datos equivocada y hacer que el checkout falle. Un pequeño ajuste de configuración puede romper el inicio de sesión, los correos o los pagos. Incluso cuando la solución es fácil, la presión sube porque los usuarios están mirando y cada minuto se siente caro.

El pánico empieza cuando la ruta de rollback no está clara. La gente hace las mismas preguntas al mismo tiempo: ¿tenemos snapshot? ¿Qué versión fue la última buena? Si revertimos la app, ¿y la base de datos? ¿Quién tiene acceso para hacerlo? Cuando esas respuestas no están ya escritas, el equipo pierde tiempo debatiendo en vez de restaurar el servicio.

Adivinar durante un incidente tiene un costo real. Pierdes tiempo, los usuarios pierden confianza y los cambios apresurados pueden causar una segunda caída además de la primera. Los ingenieros también son jalados en demasiadas direcciones a la vez: depurar, comunicar y tomar decisiones.

Un ensayo cambia el ánimo porque reemplaza la incertidumbre por memoria muscular. Un buen simulacro de rollback no es solo “¿podemos revertir el código?”. Es una rutina repetible: qué snapshotear, qué restaurar, qué verificar y quién tiene permiso para actuar. Tras unos cuantos ensayos, el rollback deja de sentirse como un fracaso y pasa a ser una herramienta de seguridad.

Si tu flujo de despliegue ya soporta snapshots y restauración (algunas plataformas, incluyendo Koder.ai, integran esto en el flujo de release), los simulacros son más fáciles porque “volver a una versión conocida” es una acción normal, no un procedimiento de emergencia personalizado. En cualquier caso, la meta es la misma: cuando llegue el momento, nadie debería estar improvisando.

Qué significa realmente “restaurar en 5 minutos”

“Restaurar en 5 minutos” no significa que todo vuelva a ser perfecto. Significa que puedes devolver a los usuarios a una versión funcional rápidamente, incluso si la nueva release sigue rota.

Servicio primero, arreglos después. Si puedes restaurar el servicio rápido, ganas tiempo tranquilo para encontrar el bug real.

Los 5 minutos son para actuar, no para debatir

El reloj empieza cuando acuerdas: “Estamos haciendo rollback”. No incluye una larga discusión sobre si las cosas podrían recuperarse solas.

Decide tu disparador de rollback con antelación. Por ejemplo: “Si los errores de checkout permanecen por encima de X% durante 3 minutos tras el deploy, hacemos rollback.” Cuando el disparador se cumple, sigues el guion.

Qué cuenta como “restaurado”

“Restaurado” debería ser un conjunto pequeño de señales que te digan que los usuarios están a salvo y el sistema estable. Manténlo estrecho y fácil de comprobar:

• La acción clave del usuario vuelve a funcionar (login, checkout, búsqueda, o lo que tu app debe hacer)
• La tasa de errores vuelve cerca de lo normal
• La latencia vuelve a un rango aceptable
• No hay ciclos de crash ni tormentas de reinicio

Cuando esas señales se ven bien, para el temporizador de 5 minutos. Todo lo demás puede esperar.

Para mantener el simulacro honesto, marca explícitamente lo que no vas a hacer durante la ruta de 5 minutos: depuración profunda, cambios de código o hotfixes y cualquier cosa que se convierta en trabajo de ingeniería.

Elige un enfoque de rollback que tu equipo pueda repetir

Un rollback solo se siente rápido cuando la decisión está mayormente predefinida. Escoge un enfoque que funcione para la mayoría de incidentes y prácticalo hasta que sea aburrido.

Tu simulacro debe responder cuatro preguntas:

• ¿Hacemos rollback o hotfix?
• ¿A qué versión volvemos?
• ¿Qué dispara el rollback?
• ¿Quién tiene autoridad para decir “hazlo”?

Rollback vs hotfix: elige el defecto

El rollback es mejor cuando la nueva release está dañando activamente a los usuarios o los datos, y ya tienes una versión conocida como buena a la que volver. Un hotfix es mejor cuando el impacto es pequeño, el cambio está aislado y tienes confianza en parchear con seguridad.

Un defecto simple funciona bien: si los usuarios no pueden completar la acción principal (checkout, login, signup) o la tasa de errores se dispara, haz rollback primero y arregla hacia adelante después. Reserva los hotfixes para problemas molestos pero no peligrosos.

Elige el objetivo del rollback

Tu “objetivo” debe ser algo que tu equipo pueda seleccionar rápido, sin debate. La mayoría de equipos usan tres objetivos comunes:

• La versión anterior (última release que pasó las comprobaciones)
• Un snapshot de despliegue que puedas restaurar
• Un rollback solo de configuración (feature flag o cambio de entorno)

Si tienes snapshots de despliegue confiables, hazlos el predeterminado porque son lo más repetible bajo presión. Mantén el rollback de configuración como una ruta separada para casos donde el código está bien pero una configuración está mal.

También define qué cuenta como “anterior buena”. Debe ser la release más reciente que completó las comprobaciones de monitoreo y no tenía un incidente activo, no “la que la gente recuerda”.

Define el disparador y la autoridad

No esperes a una reunión durante un incidente. Escribe los disparadores que inician un rollback y cúmplelos. Disparadores típicos incluyen un flujo principal roto por más de un par de minutos, tasa de errores o latencia que cruzan umbrales acordados, riesgo de datos (escrituras erróneas, cargos duplicados) y cualquier preocupación de seguridad o privacidad introducida por la release.

Luego decide quién puede aprobar el rollback. Elige un rol (líder de incidente o on-call), más un respaldo. Todos los demás pueden aconsejar, pero no pueden bloquear. Cuando el disparador se cumple y el aprobador dice “rollback”, el equipo ejecuta los mismos pasos cada vez.

Qué snapshotear antes de cada release

Un simulacro de rollback solo funciona si puedes volver rápidamente a un estado conocido. Los snapshots no son solo “agradables de tener”. Son los comprobantes que demuestran qué se estaba ejecutando, qué cambió y cómo volver.

Las cinco cosas que capturar

Antes de cada release, asegúrate de poder obtener estos elementos sin buscar en logs de chat:

• El build exacto que enviaste: hash del commit, número de versión y el artefacto del build (tag de contenedor, bundle o paquete).
• Estado de la base de datos y plan de migraciones: qué migraciones se aplicaron y si son reversibles. Para cambios riesgosos, toma un backup o snapshot que puedas restaurar rápido.
• Configuración en el momento del deploy: feature flags, variables de entorno, endpoints de terceros y qué cambió. Los secretos deben vivir en un sistema seguro, pero aún necesitas un registro versionado de cambios.
• Infraestructura y ajustes de enrutamiento: dominios, certificados, reglas del balanceador y cualquier switch de “a dónde va el tráfico”.
• Una nota corta de release: una frase sobre qué cambió y una frase sobre cómo verificar un rollback exitoso.

La seguridad de la base de datos es la trampa habitual. Un rollback rápido de la app no ayuda si la base de datos ahora espera el nuevo esquema. Para migraciones riesgosas, planifica un release en dos pasos (añadir campos primero, empezar a usarlos más tarde) para que el rollback siga siendo posible.

Nombra los snapshots para que los encuentres en segundos

Usa una regla de nombrado única en todas partes y hazla ordenable:

prod-2026-01-09-1420-v1.8.3-commitA1B2C3

Incluye entorno, timestamp, versión y commit. Si tus herramientas soportan snapshots en una UI, usa la misma regla de nombrado allí para que cualquiera pueda localizar el punto de restauración correcto durante un incidente.

Roles: quién hace clic en qué (y quién solo observa)

Un simulacro de rollback es más rápido y calmado cuando todos conocen su carril. La meta no es “todos intervienen”. Es una persona tomando decisiones, una persona ejecutando la acción, una persona confirmando que funcionó y una persona manteniendo a los demás informados.

Para equipos pequeños y medianos, estos roles funcionan bien (una persona puede llevar dos sombreros si es necesario, pero evita combinar Desplegador y Verificador durante el simulacro):

• Líder de incidente (cronometrista y decisor): establece el objetivo de éxito y llama al rollback.
• Desplegador (manos en el teclado): ejecuta los pasos de rollback exactamente como están escritos y narra lo que hace.
• Verificador (prueba de que funciona): ejecuta las comprobaciones imprescindibles y vigila las señales clave.
• Comunicador (una voz hacia afuera): publica actualizaciones cortas y regulares a stakeholders y soporte.

Los permisos deciden si este plan es real o solo un buen documento. Antes del simulacro, acuerda quién puede revertir producción y cómo funcionan las emergencias.

Una configuración simple:

• Da al Desplegador derechos de rollback durante la rotación on-call o ventanas de simulacro programadas.
• Permite al Líder de incidente aprobar la acción (aunque no tenga el botón).
• Asegura que el Verificador tenga acceso de solo lectura a dashboards y logs.
• Configura una opción break-glass (acceso auditado y por tiempo limitado).
• Prueba los accesos durante la preparación del simulacro, no durante el temporizador de 5 minutos.

Si usas una plataforma que soporta snapshots y rollback (incluyendo Koder.ai), decide quién puede crear snapshots, quién puede restaurarlos y dónde se registra esa acción.

Paso a paso: el runbook del simulacro de rollback

Un simulacro de rollback funciona mejor cuando se siente como un simulacro de incendios: mismos pasos, mismas palabras, mismos lugares donde hacer clic. La meta no es la perfección. Es que cualquiera en turno pueda restaurar la última versión conocida como buena rápido, sin debatir opciones.

Antes de empezar

Elige un disparador claro y dilo en voz alta cuando comience el simulacro. Ejemplos: “Checkout devuelve 500 por más de 1 minuto” o “La tasa de errores es 5x la normal justo después del deploy.” Decirlo en voz alta evita que el equipo derive hacia la depuración.

Mantén una lista corta de preparación junto al runbook:

• Confirma que puedes ver señales de salud en vivo (uptime, tasa de errores, flujo clave de usuario)
• Confirma el identificador de la última versión buena (tag, build, nombre del snapshot)
• Confirma dónde se ejecutan los rollbacks (CI/CD, consola de hosting, UI de la plataforma)
• Confirma cómo pausar nuevos deploys
• Confirma quién registra timestamps

El runbook de 5 minutos

1. Inicia el temporizador. Una persona declara el disparador y la decisión: “Estamos haciendo rollback ahora.”

2. Congela cambios. Pausa nuevos deploys y detén ediciones no esenciales que puedan cambiar el sistema durante el rollback.

3. Toma un snapshot de última oportunidad (solo si es seguro y rápido). Esto protege por si necesitas recrear el estado roto después. Nómbralo claramente y sigue adelante.

4. Ejecuta la acción de rollback exactamente como está documentada. No improvises. Lee en voz alta los prompts de confirmación para que el registrador capture lo ocurrido.

5. Confirma que el rollback se completó en un lugar de confianza. Usa una pantalla y una señal cada vez (vista de historial de despliegues, etiqueta “versión actual” o un indicador de estado claro).

Justo después de la acción, captura lo que importa mientras está fresco:

• Hora de la decisión (disparador declarado)
• Hora de inicio del rollback (primer clic/comando)
• Hora de finalización del rollback (versión previa activa)
• Primera verificación verde (comprobación clave pasa)
• Sorpresas (permiso faltante, botón poco claro, paso lento)

Si el rollback toma más de 5 minutos, no lo justifiques. Encuentra el paso lento, arregla el runbook y repite el simulacro.

Qué verificar después del rollback

Un rollback solo “funcionó” cuando los usuarios sienten que funcionó. No intentas probar que la versión antigua está desplegada; intentas probar que el servicio es utilizable otra vez y estable.

Mantén la verificación pequeña y repetible. Si la lista tiene más de cinco items, la gente la omitirá bajo estrés.

Las 3-5 comprobaciones imprescindibles

Usa comprobaciones que puedas correr rápido, con un claro pasa/falla:

• El usuario puede iniciar sesión (o registrarse) y llegar a la pantalla principal sin errores
• La transacción central funciona (checkout, reserva, envío de formulario)
• Un endpoint API clave devuelve 200 y la respuesta luce normal
• Admin/soporte puede realizar una acción crítica (reembolso, cancelar, actualizar estado)
• Un flujo frágil que suele romperse aún funciona (reset de contraseña, subida de archivos, búsqueda)

Tras las comprobaciones funcionales, echa un vistazo a la señal de salud más simple que confíes. Quieres ver la tasa de errores bajar y la latencia dejar de estar por las nubes en un par de minutos.

También confirma que las partes menos visibles vuelven a moverse. Los jobs en background deben procesarse y las colas drenarse, no crecer. Las comprobaciones de base de datos deben ser rápidas y aburridas: conexiones estables, sin bloqueos evidentes y la app puede escribir.

Finalmente, prueba el mundo exterior donde importa. Si puedes hacerlo con seguridad, corre una prueba de pago, confirma que la entrega de emails no rebota y asegúrate de que los webhooks sean aceptados (o al menos no fallen).

Decide la redacción de “todo claro”

Pre-escribe una frase para que nadie improvise:

“Rollback completo. Flujos centrales verificados (login + checkout). Tasa de errores y latencia de vuelta a lo normal. Monitoreo por 30 minutos. Próxima actualización a las 14:30.”

Ejemplo: una release rota y una restauración limpia en 5 minutos

Son las 10:02 de un martes. Sale una nueva release y en un minuto un grupo de usuarios no puede iniciar sesión. Algunos reciben “sesión inválida”, otros ven un spinner que nunca termina. Los registros aún funcionan, así que el problema pasa desapercibido al principio.

La primera señal no suele ser una caída dramática. Es un pico silencioso: tickets de soporte, una caída en logins exitosos y algunos mensajes enojados de usuarios reales. On-call ve una alerta: “tasa de éxito de login abajo 18% en 5 minutos” y soporte publica: “3 usuarios no pueden iniciar sesión tras la actualización.”

La restauración de 5 minutos (cómo puede verse)

Porque el equipo practicó el simulacro, no debaten mucho. Confirman, deciden y actúan.

• 10:03: On-call confirma que es real y asigna un líder de incidente.
• 10:04: Decisión de hacer rollback. Regla: si el login está roto y no hay un arreglo seguro en 2 minutos, hacemos rollback.
• 10:05: El Desplegador dispara el rollback a la snapshot previa conocida como buena.
• 10:06: El tráfico vuelve a la versión previa. El equipo vuelve a probar el login en web y móvil.
• 10:07: El líder de incidente publica “Login restaurado, monitoreando por 10 minutos” y pide a soporte que responda a los usuarios afectados.

Qué se revierte: código de aplicación y configuración para los servicios web y API. Qué queda igual: base de datos y datos de usuario.

Si la release incluyó una migración de base de datos, la regla del simulacro es simple: nunca revertir la base de datos en la ruta de 5 minutos. Mantén las migraciones compatibles hacia atrás, o pausa y consigue una segunda opinión antes de desplegar.

Qué se comunica (durante y después)

Durante el rollback, el líder de incidente publica actualizaciones cortas cada un par de minutos: qué ven los usuarios, qué acción se está ejecutando y cuándo será la próxima actualización. Ejemplo: “Estamos revirtiendo la última release para restaurar el login. Próxima actualización en 2 minutos.”

Después del rollback, cierran el ciclo: “El login volvió a la normalidad. Se está realizando un análisis de causa raíz. Compartiremos lo sucedido y qué cambiamos para evitar repeticiones.”

Errores comunes en simulacros de rollback (y soluciones simples)

Un simulacro de rollback debería sentirse aburrido. Si se siente estresante, el simulacro probablemente esté exponiendo brechas reales: accesos, snapshots faltantes o pasos que solo existen en la cabeza de alguien.

Errores que hacen perder minutos

• Practicas con acceso asumido, no con permisos reales. La gente descubre a mitad de incidente que no puede desplegar, cambiar config o acceder a dashboards. Solución: corre el simulacro con las mismas cuentas y roles que usarías en el incidente.

• Los snapshots existen, pero están incompletos o son difíciles de encontrar. Los equipos snapshotean la app pero olvidan cambios de entorno, feature flags o enrutamiento. O el nombre del snapshot no tiene sentido. Solución: haz la creación de snapshot un paso del release con una regla de nombrado y verifica durante los simulacros que el snapshot es visible y restaurable rápidamente.

• Las migraciones de base de datos hacen inseguro el rollback. Un cambio de esquema no compatible convierte un rollback rápido en un problema de datos. Solución: prefiere migraciones aditivas. Si un cambio rompen es inevitable, planifica un arreglo hacia adelante y etiqueta la release claramente: “rollback permitido: sí/no”.

• Declaras éxito antes de comprobar qué sienten los usuarios. La app aparece desplegada, pero el login sigue roto o los jobs están atascados. Solución: mantén la verificación corta pero real y limite tiempo.

• El simulacro es demasiado complejo para repetir. Demasiadas herramientas, demasiadas comprobaciones, demasiadas voces. Solución: reduce el simulacro a una página y un dueño. Si no puede hacerse desde un runbook único y un canal de comunicación único, no pasará bajo presión.

Un buen simulacro de rollback es un hábito, no una actuación heroica. Si no puedes terminar con calma, elimina pasos hasta que puedas y luego añade solo lo que realmente reduzca el riesgo.

Lista rápida y siguientes pasos

Un simulacro de rollback funciona mejor cuando todos siguen la misma lista de verificación de una página. Tenla fijada donde tu equipo realmente la vea.

Una versión compacta que puedes ejecutar en menos de 10 minutos (incluyendo preparación y verificación):

• Antes del release: confirma el punto de rollback (snapshot/versión), registra el comportamiento “bueno” esperado, asigna roles (desplegador, verificador, comunicaciones).
• Disparador: declara “rollback iniciando”, inicia el temporizador, congela nuevos deploys.
• Acción de rollback: restaura la última release conocida como buena, captura qué se hizo clic y en qué orden.
• Verificar: ejecuta 2-3 comprobaciones críticas (login, flujo principal, una integración o check de API), confirma que la tasa de errores baja.
• Cerrar: declara “servicio estable”, escribe tres notas (qué funcionó, qué te retrasó, qué cambiar), descongela los deploys.

Realiza simulacros con la frecuencia suficiente para que los pasos se sientan normales. Mensualmente es un buen valor por defecto. Si tu producto cambia diariamente, hazlos cada dos semanas, pero mantén la verificación centrada en la ruta principal de usuario.

Después de cada simulacro, actualiza el runbook el mismo día mientras la experiencia está fresca. Guárdalo con las notas de release y añade una línea fechada “última prueba” para que nadie confíe en un procedimiento obsoleto.

Mide solo lo que te ayuda a mejorar:

• Tiempo a rollback (de decisión a restaurado)
• Tiempo a verificación (restaurado a estable)
• Claridad de roles (dónde la gente dudó o duplicó trabajo)
• Información faltante (credenciales, permisos, ubicación del snapshot)

Si tu equipo construye sobre Koder.ai, trata los snapshots y el rollback como parte del hábito: nombra snapshots consistentemente, ensaya restauraciones en la misma interfaz que usarás on-call e incluye comprobaciones rápidas de dominio personalizado e integraciones clave en los pasos del verificador. Mencionarlo en el runbook mantiene el simulacro alineado con cómo realmente haces deploy.