English

Un rollback sin probar no es un rollback

Tu plan de rollback nunca fue probado. Eso no es un plan: es una esperanza con un runbook al lado. La noche en que el lanzamiento se tuerce es el peor momento para descubrir que el interruptor de apagado no estaba conectado a nada.

Por qué fallan los rollbacks sin probar

La falla no es el bug que enviaste. La falla es que la recuperación tardó 40 minutos en lugar de 40 segundos porque nadie había accionado el interruptor bajo carga. Los rollbacks se pudren en silencio: el flag se renombra, la ruta de configuración cambia, una dependencia ahora lee la función al arrancar y apagarla no hace nada hasta un reinicio. Nada de eso aparece hasta que lo necesitas, y para entonces estás depurando tu salida de emergencia frente a usuarios enojados.

La práctica de SRE de Google es contundente: la capacidad de volver a un estado conocido y bueno (known good state) es fundamental, y cada cambio automático se vigila para poder "revertirlo rápidamente" en cuanto se comporta mal. La ruta de reversión no es algo secundario: se diseña y se ejercita primero.

Comprueba el kill switch antes del lanzamiento

Un kill switch es un feature flag cuyo único trabajo es hacer que el nuevo camino de código deje de ejecutarse: sin deploy, sin recompilar, sin esperar el CI. El objetivo de desacoplarlo del deploy es la velocidad: accionas el flag y la función desaparece en segundos.

Pruébalo tal como lo vas a usar:

1. Enciende la función en un entorno de staging o canary con tráfico real.
2. Apaga el flag y confirma que el camino viejo, conocido y bueno, vuelve a responder — medido, no supuesto.
3. Cronométralo. El estándar son segundos. Si requiere un redeploy o un reinicio, todavía no es un kill switch.
4. Escribe el disparador. Decide el umbral de rollback por adelantado — p. ej. "tasa de error sube 0.5% vs. control → apagar" — para que la decisión sea aritmética a las 2 a.m., no un juicio.

Reglas prácticas

Apagar el flag le gana al hotfix heroico

Cuando algo se rompe, el movimiento tranquilo es aburrido: apaga el flag, restaura el estado conocido y bueno, y recién entonces diagnostica — sin presión, porque los usuarios ya están atendidos. El movimiento heroico — parchear hacia adelante a toda velocidad mientras todo arde — es como los equipos convierten un incidente en dos. Primero la recuperación, después la causa raíz.

Nivel avanzado: haz que el interruptor sea confiable

• Corta la ruta de lectura, no solo la de escritura. Si algún consumidor cachea el flag o lo lee una vez al arrancar, "off" es mentira hasta el reinicio. Lee el flag en el momento de evaluación.
• Los flags nuevos por defecto en off. Un flag que falla abierto anula el propósito; si el servicio de flags no está disponible, la respuesta segura es el comportamiento viejo.
• Ensaya el rollback como un game day. Dispáralo a propósito en una ventana de bajo riesgo. Un kill switch que ya accionaste una vez a propósito es uno en el que confías cuando importa.
• Limpia después. Un flag permanente es deuda técnica permanente y un nuevo modo de falla. Elimínalo cuando la función sea confiable.

Recursos

• Canarying Releases — Google SRE Workbook — volver a un estado conocido y bueno cuando el canary se comporta mal.
• Reliable Product Launches — Google SRE Book — planifica el interruptor de apagado como parte del lanzamiento.
• Feature Flags 101 — LaunchDarkly — el patrón de kill switch explicado.
• Feature flags as part of your rollback plan — Harness — los flags como ruta de reversión rápida.
• What is a feature flag — Honeycomb — buenas prácticas y ciclo de vida.