"Si sale mal, lo deshacemos"
Es la frase que tranquiliza antes de un cambio importante, y la que menos se cumple. Deshacer un cambio de código de aplicación suele ser fácil. Deshacer un cambio de infraestructura no siempre lo es: una base de datos migrada, una red reconfigurada o un certificado sustituido no vuelven atrás con un clic.
Por eso, en infraestructura, la vuelta atrás se diseña antes del cambio, no se improvisa después.
Mantener lo anterior vivo
La técnica más segura es no modificar lo que funciona, sino levantar al lado la versión nueva:
- La versión actual sigue dando servicio.
- Se crea la versión nueva, completa, en paralelo.
- Se prueba sin tráfico real o con una pequeña parte.
- Se cambia el tráfico a la nueva.
- Si algo falla, el tráfico vuelve a la anterior en segundos, porque sigue ahí.
- Solo cuando la nueva está confirmada, se retira la anterior.
Cuesta más durante unas horas (hay dos versiones a la vez) y ahorra muchísimo cuando algo sale mal.
Cuando no se puede tener dos versiones
Hay cambios que no admiten paralelo, sobre todo en datos. Para ellos:
- Copia verificada justo antes, restaurable y probada (no una suposición).
- Cambios en dos tiempos: primero se añade lo nuevo sin quitar lo viejo (una columna, un campo) y solo después, cuando todo usa lo nuevo, se retira lo antiguo.
- Ventana y plan escritos: qué se hace, cuánto tarda, en qué punto ya no hay vuelta atrás y quién decide seguir.
La regla
Ningún cambio importante se aprueba sin una respuesta escrita a "¿cómo volvemos atrás, y cuánto tarda?". Si la respuesta es "no se puede", el cambio necesita otra forma.
Volver atrás protege de los errores que ya ocurrieron. Mejor todavía es impedir que ciertos errores lleguen a aplicarse.
Cómo lo aplicamos: Automatización e IaC.