Estrategia de Rollback

El Problema

Cuando un despliegue rompe produccion, el panico se apodera del equipo. Todos intentan recordar como revertir, debaten si avanzar o retroceder, y frecuentemente empeoran las cosas en el caos. Sin una estrategia de rollback planificada previamente, cada despliegue fallido se convierte en una respuesta de crisis improvisada con resultados impredecibles y tiempo de inactividad prolongado.

El Prompt

Eres un ingeniero de confiabilidad de despliegue. Crea una estrategia integral de rollback para mi aplicacion.

DETALLES DE LA APLICACION:
- Stack: [ej., Next.js en Vercel, Django en AWS ECS, Rails en Heroku]
- Base de datos: [ej., PostgreSQL con migraciones, MongoDB, ninguna]
- Metodo de despliegue: [ej., basado en contenedores, serverless, SSH tradicional]
- Gestion de estado: [ej., sesiones en Redis, JWT stateless, sticky sessions]
- Dependencias externas: [ej., Stripe API, SendGrid, S3]

Diseña una estrategia de rollback que cubra:
1. **Marco de decision**: Cuando hacer rollback vs. roll forward — arbol de decision con criterios especificos (tiempo transcurrido, severidad, radio de impacto).
2. **Procedimientos de rollback**: Paso a paso para cada tipo — reversion de codigo, rollback de BD, rollback de configuracion.
3. **Seguridad de rollback de BD**: Como manejar migraciones destructivas (eliminacion de columnas, transformaciones de datos) — recuperacion point-in-time vs. migraciones inversas.
4. **Plantilla de comunicacion**: A quien notificar, que decir, cuando escalar.
5. **Lista de validacion**: Como confirmar que el rollback fue exitoso y el servicio esta restaurado.
6. **Objetivos de tiempo**: Tiempo maximo aceptable para cada escenario de rollback.

Ejemplo de Salida

Marco de decision:
- < 5 min desde el despliegue + causa clara → Revertir inmediatamente
- < 30 min + causa no clara → Revertir, investigar despues
- > 30 min + impacto parcial → Hot-fix roll forward si el fix toma < 15 min
- Corrupcion de datos detectada → DETENER todo el trafico, activar comandante de incidentes

Procedimiento de rollback (Contenedor):
1. kubectl rollout undo deployment/app --to-revision=<anterior>
2. Verificar pods saludables: kubectl get pods -w
3. Ejecutar smoke tests contra endpoint de produccion
4. Confirmar que metricas vuelven a la linea base (ventana de 5 minutos)
Objetivo: < 3 minutos desde la decision hasta servicio restaurado

Cuando Usarlo

Usa este skill antes de tu primer despliegue a produccion para tener un plan listo. Revisalo cuando cambies la infraestructura de despliegue, agregues migraciones de base de datos, o despues de un rollback que salio mal. Tener un runbook preparado reduce el tiempo de rollback de mas de 30 minutos a menos de 5.

Consejos Pro

• Nunca planifiques un rollback durante un incidente — escribe la estrategia cuando todo esta tranquilo. Durante un incidente, ejecutas el plan, no creas uno nuevo.
• Prueba rollbacks en staging mensualmente — despliega, luego revierte intencionalmente. Cronometralo. Si toma mas de 5 minutos, simplifica tu proceso.
• Separa los rollbacks revertibles de los no revertibles — el codigo es facil de revertir, pero las migraciones destructivas de BD no lo son. Diseña migraciones retrocompatibles por al menos un ciclo de release.
• Automatiza la decision — configura triggers automaticos de rollback basados en picos de tasa de error, para que no necesites un humano decidiendo a las 3 AM.