¿Qué criterios usas para decidir entre un rollback y un hotfix?

Question

Accepted Answer

Por defecto, **rollback** — es la forma más rápida y fiable de restaurar un estado conocido-bueno. Recurre a un **hotfix** solo cuando el rollback sea imposible o más peligroso que arreglar hacia adelante. En un incidente activo, la prioridad es **detener la hemorragia primero**, diagnosticar después.

## Los criterios de decisión

- **¿Es el rollback seguro y posible?** Si la versión anterior es conocida-buena y no ha pasado nada irreversible, haz rollback. Esta es la respuesta habitual.
- **¿La mala release creó estado irreversible?** Una **migración de base de datos** o una corrupción de datos puede hacer que el rollback sea peor que el bug. Si no puedes volver atrás con seguridad, debes arreglar hacia adelante.
- **¿Entendemos el arreglo?** El rollback no necesita diagnóstico — ese es su poder. Un hotfix que no entiendes del todo puede agravar el incidente; nunca lleves a prod una conjetura bajo presión.
- **Tiempo hasta un estado seguro.** Elige el camino que alcance la estabilidad más rápido con menos riesgo. Un hotfix de una línea, bien entendido, puede ganar a un rollback complejo; un arreglo-hacia-adelante arriesgado nunca gana a una reversión limpia.
- **Radio de impacto y severidad.** Una caída total exige la restauración más rápida posible (normalmente rollback); una degradación menor puede permitir un hotfix cuidadoso.

## Una tabla de decisión rápida

| Situación | Elegir |
| --- | --- |
| Versión anterior conocida-buena, sin migración | Rollback |
| Migración de DB irreversible desplegada | Hotfix / fix-forward |
| Causa desconocida, impacto severo | Rollback (ganar tiempo) |
| Cambio trivial, de una línea bien entendido | Hotfix |
| El propio rollback es arriesgado/no probado | Hotfix |

## Trade-offs y errores a evitar

- El **rollback** es seguro pero solo trata el síntoma — sigues debiendo un arreglo real y un postmortem.
- El **hotfix** ataca la causa raíz pero se salta la red de seguridad normal; los bugs en los hotfixes son comunes precisamente porque son apresurados.
- Un **camino de rollback no probado** es una trampa — si nunca lo has ensayado, puede fallar cuando más lo necesitas. Practica los rollbacks antes de necesitarlos.
- Cuidado con **depurar en producción** bajo presión; si estás a más de unos minutos de un arreglo seguro, haz rollback e investiga con calma.

## Por qué es importante

Esta decisión ocurre en el peor momento posible — sistema caído, reloj corriendo, todos mirando. Un Tech Lead con una regla clara y ensayada para ello reduce el MTTR drásticamente y evita el clásico error de querer ser ingenioso a mitad de incidente cuando la aburrida reversión estaba justo ahí. Restaura primero, sé listo después.

Situación	Elegir
Versión anterior conocida-buena, sin migración	Rollback
Migración de DB irreversible desplegada	Hotfix / fix-forward
Causa desconocida, impacto severo	Rollback (ganar tiempo)
Cambio trivial, de una línea bien entendido	Hotfix
El propio rollback es arriesgado/no probado	Hotfix