La forma de un lanzamiento cuidadoso: chico, observable, reversible

Descripción

Las últimas cuatro lecciones construyeron piezas sueltas: el experimento solo probó una fracción de la base (L2), el lanzamiento es una decisión de riesgo con dos ejes (L3), el radio de impacto escala con el porcentaje expuesto (L4), y deploy y release son eventos separables (L5). Esta lección junta las cuatro piezas en un solo patrón: sin importar la herramienta específica —feature flag, canary, dashboard, kill switch— todo lanzamiento cuidadoso comparte tres propiedades: es chico (empieza con poca exposición), es observable (puedes ver qué está pasando mientras ocurre) y es reversible (puedes deshacerlo rápido si hace falta). Un plan que tiene las tres es cuidadoso, sin importar qué tan simple sea; un plan que le falta alguna, no lo es, sin importar cuántas otras cosas haga bien.

Conexión con el módulo. Esta es la lección de síntesis del módulo: no introduce ningún concepto nuevo, reorganiza los cuatro anteriores en un criterio de tres puntos que vas a poder aplicar a cualquier lanzamiento, incluidos los que veas fuera de esta guía. La lección 7 usa este mismo criterio, en la última lección de tema, para cerrar el argumento completo sobre el caso de recommendations; y los módulos 2 a 5 son, cada uno, la herramienta técnica concreta que le da cuerpo a una de las tres propiedades.

Una analogía: probar el agua antes de tirarte

Nadie serio se tira de cabeza a una alberca sin saber la profundidad. Antes de saltar, hay tres cosas que un nadador con sentido común hace, casi sin pensarlo: primero, mete un pie —una porción chica de su cuerpo, no el cuerpo entero— para sentir la temperatura y confirmar que hay agua de verdad ahí abajo. Segundo, mira: observa la superficie, busca el marcador de profundidad, nota si hay algo raro flotando. Tercero, se para en un punto donde, si algo se siente mal, puede simplemente sacar el pie y alejarse — no salta desde un trampolín de diez metros donde, una vez en el aire, ya no hay forma de cambiar de opinión.

Meter un pie es chico. Mirar la superficie es observable. Poder sacar el pie sin consecuencias es reversible. Ningún nadador cuidadoso hace solo una de las tres —mirar la superficie sin meter nunca un pie tampoco te dice la temperatura real, y meter el pie sin poder sacarlo (imagina que quedaras atado) no sirve de nada—. Las tres juntas son las que hacen que probar el agua sea, de hecho, seguro. Un lanzamiento de producto sigue exactamente el mismo patrón, con usuarios en vez de agua.

Ejemplo trabajado: safeLaunchScore() sobre dos planes para recommendations

Vamos a comparar, con un criterio explícito de tres puntos, dos planes distintos para lanzar recommendations con su guardrail de latencia roto:

// safeLaunchScore: verifica si un plan de lanzamiento cumple las tres
// propiedades que comparten los lanzamientos cuidadosos -- chico, observable,
// reversible. Las HERRAMIENTAS que logran cada propiedad (flags, dashboards,
// rollback) se enseñan en los modulos 2 a 5; aqui solo se nombra el criterio.
function safeLaunchScore({ name, small, observable, reversible }) {
  const pillars = [small, observable, reversible];
  const score = pillars.filter(Boolean).length;
  return { name, small, observable, reversible, score: score + '/3' };
}

const plans = [
  { name: 'Plan A: 100% de golpe, sin flag, sin dashboard de guardrails', small: false, observable: false, reversible: false },
  { name: 'Plan B: canary con flag + dashboard de guardrails + kill switch', small: true, observable: true, reversible: true },
];

console.log('=== safeLaunchScore sobre dos planes de lanzamiento de recommendations ===\n');
plans.forEach((p) => {
  const r = safeLaunchScore(p);
  console.log(r.name);
  console.log('  small=' + r.small + '  observable=' + r.observable + '  reversible=' + r.reversible + '  -> score=' + r.score + '\n');
});

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

=== safeLaunchScore sobre dos planes de lanzamiento de recommendations ===

Plan A: 100% de golpe, sin flag, sin dashboard de guardrails
  small=false  observable=false  reversible=false  -> score=0/3

Plan B: canary con flag + dashboard de guardrails + kill switch
  small=true  observable=true  reversible=true  -> score=3/3

Fíjate en que el Plan A falla las tres propiedades a la vez, no solo una: al lanzar al 100% de golpe sin flag ni dashboard, no hay forma de que sea chico (todos expuestos desde el minuto uno), no hay forma de observarlo en vivo antes de que sea demasiado tarde (sin dashboard, te enteras por las quejas), y no hay forma de revertirlo rápido (sin flag, hace falta un nuevo deploy). Las tres fallas están conectadas: la falta de una herramienta —el feature flag— es, en este caso concreto, la raíz de las tres. Eso es exactamente lo que vas a ver en el módulo 2: una sola pieza técnica (el flag) resuelve, de un solo golpe, la posibilidad de ser chico y de ser reversible.

Por qué las tres propiedades, y no dos

Podrías preguntarte si de verdad hacen falta las tres, o si con dos alcanza. La respuesta es no, y vale la pena verlo con un ejemplo de cada combinación incompleta:

• Chico, observable, pero no reversible: lanzas al 1%, tienes un dashboard perfecto que te avisa en tiempo real que el guardrail se rompió — y no tienes forma de apagarlo sin un nuevo deploy de 40 minutos. Ves el problema con toda claridad, y no puedes hacer nada rápido al respecto. La observabilidad sin reversa es, en la práctica, solo ansiedad con gráficas.
• Chico, reversible, pero no observable: lanzas al 1% con un kill switch listo, pero sin ningún dashboard que vigile el guardrail. Tienes la capacidad de apagar el problema — y ninguna forma de saber que existe hasta que alguien se queja. La reversa sin observabilidad es un botón de emergencia que nadie sabe cuándo presionar.
• Observable, reversible, pero no chico: tienes el dashboard y el kill switch listos, pero lanzas al 100% de una vez "porque de todos modos podemos revertir si algo sale mal". El problema: revertir después de que 12,500 personas ya sufrieron la regresión (el número exacto de la lección 4) no deshace el daño ya ocurrido, solo detiene que siga creciendo.

Cada combinación de dos, sin la tercera, deja un hueco real. Las tres juntas —chico primero, observado mientras ocurre, reversible si hace falta— son las que convierten "vamos a lanzar con cuidado" de una frase bien intencionada a un plan verificable con un criterio de tres casillas.

Errores comunes

Confiar en "vamos a estar atentos" como sustituto de un plan chico y reversible. Qué pasa: el equipo decide lanzar al 100% pero promete "monitorear de cerca" durante las primeras horas, tratando esa vigilancia informal como si compensara la falta de exposición gradual. Por qué pasa: "estar atentos" se siente como una precaución real, y es más rápido de decir que de implementar un canary de verdad. Cómo detectarlo: la pregunta "¿qué porcentaje de usuarios ve la feature en la primera hora?" tiene como respuesta "100%, pero la estamos vigilando" — que es exactamente el patrón "observable, reversible, pero no chico" de la sección anterior, con todo el daño ya ocurrido antes de que la vigilancia sirva de algo. Cómo corregirlo: la observación atenta reduce el tiempo hasta detectar un problema, no el número de personas ya expuestas cuando lo detectas — para eso hace falta, específicamente, empezar chico.

Construir el dashboard de monitoreo, pero solo mirarlo si alguien se acuerda. Qué pasa: existe un dashboard perfectamente configurado con los guardrails de la guía de métricas, pero nadie tiene la responsabilidad explícita de revisarlo durante el lanzamiento, así que la regresión se detecta, en la práctica, por las quejas de soporte y no por el dashboard. Por qué pasa: construir la herramienta se siente como "ya está resuelto", y es fácil olvidar que la observabilidad requiere que alguien, de hecho, observe. Cómo detectarlo: existe el dashboard, pero nadie puede decir quién lo está mirando en tiempo real durante las primeras horas del rollout. Cómo corregirlo: un plan de lanzamiento cuidadoso asigna, explícitamente, a alguien la responsabilidad de vigilar cada etapa — esto se retoma con más detalle en el módulo 4.

Asumir que "reversible" y "ya lo revertimos alguna vez" son lo mismo. Qué pasa: el equipo asegura que el plan es reversible porque, en teoría, existe un kill switch — pero nunca lo probaron de verdad, y cuando hace falta usarlo en medio de un incidente real, descubren que tiene un bug o que nadie recuerda cómo activarlo. Por qué pasa: construir el mecanismo de reversa se siente como el trabajo terminado, sin considerar que un mecanismo sin probar es, en la práctica, una promesa sin verificar. Cómo detectarlo: nadie en el equipo puede decir la última vez que se probó el kill switch, ni cuánto tiempo tomó activarlo. Cómo corregirlo: un plan reversible de verdad incluye haber probado la reversa —no solo haberla construido— antes de necesitarla en un incidente real; el módulo 5 desarrolla esto con el concepto de runbook.

Ejercicios

Ejercicio 1 — Puntúa un plan nuevo. El equipo de Mercado propone lanzar recommendations con feature flag (puede apagarse al instante) y arrancando al 5% de la base, pero sin ningún dashboard específico de guardrails —solo el monitoreo general de infraestructura que ya existe—. Usa safeLaunchScore() mentalmente: ¿qué puntaje le darías, y qué le falta?

Ver solución

small: true (arranca al 5%, no al 100%), reversible: true (el flag permite apagarlo al instante), observable: false (el monitoreo general de infraestructura no necesariamente vigila los guardrails específicos de producto —latencia del checkout, no solo salud general del servidor—). Puntaje: 2/3. Le falta la propiedad de observabilidad específica: sin un dashboard que vigile el guardrail concreto que ya sabemos que está roto, el equipo podría estar en el 5% de exposición durante horas sin darse cuenta de que el problema sigue ahí, incluso teniendo la reversa lista.

Ejercicio 2 — Explica el vínculo entre las lecciones. En dos o tres frases, explica cómo la lección 4 (radio de impacto) y la lección 5 (deploy vs. release) se conectan, cada una, con una de las tres propiedades de esta lección.

Ver solución

La lección 4 (radio de impacto) es, directamente, la propiedad de ser chico: blastRadius() es literalmente el modelo que mide qué tan chica es la exposición según el porcentaje de rollout. La lección 5 (deploy vs. release) es la condición previa que hace posible tanto ser chico como ser reversible: sin la separación entre código-en-producción y código-visible-a-usuarios, no existiría ningún mecanismo para exponer solo a una fracción (chico) ni para apagar la exposición sin un nuevo deploy (reversible). La propiedad de ser observable es la única de las tres que todavía no tuvo su propia lección de fondo en este módulo — y es, precisamente, el tema completo del módulo 4 de esta guía.

Ejercicio 3 — Encuentra el plan con trampa. Un compañero de equipo propone: "Lancemos al 100% pero con el flag apagado, y lo prendemos manualmente para cada usuario que nos escriba pidiéndolo." ¿Este plan es chico? ¿Es reversible? ¿Qué le falta para ser un lanzamiento cuidadoso completo, según el criterio de esta lección?

Ver solución

Es chico, en el sentido correcto: aunque el código está deployado al 100% de la infraestructura, la exposición real —cuántos usuarios efectivamente ven la feature— empieza en cero y crece solo con cada activación manual, así que el radio de impacto real se mantiene controlado desde el principio. También es reversible por el mismo mecanismo: el flag permite apagar la feature para cualquier usuario específico sin un nuevo deploy. Lo que le falta es observabilidad de guardrails: activar usuarios uno por uno a mano no incluye, por sí solo, ningún mecanismo que vigile si el guardrail de latencia se rompe para los usuarios ya activados — el equipo podría estar acumulando activaciones manuales durante días sin darse cuenta de que cada una está empeorando el problema. El plan no es malo en su forma (de hecho, activar usuario por usuario es una versión extrema y válida de "empezar chico"), pero necesita, igual que cualquier otro, la pieza de monitoreo del módulo 4 para completar las tres propiedades.

Resumen y siguiente paso

En esta lección sintetizaste las cuatro lecciones anteriores en un solo criterio de tres propiedades: un lanzamiento cuidadoso es chico (poca exposición al inicio), observable (se puede ver qué pasa mientras ocurre) y reversible (se puede deshacer rápido). Con safeLaunchScore() comparaste dos planes extremos para recommendations —uno que falla las tres propiedades a la vez, y otro que las cumple todas— y viste, con tres ejemplos de combinaciones incompletas, por qué ninguna de las tres sustituye a las otras dos.

Antes de avanzar deberías poder: nombrar las tres propiedades de memoria y explicar cada una con tus propias palabras; evaluar un plan de lanzamiento nuevo contra las tres, identificando explícitamente cuál falta si el plan no es completo; y explicar por qué una combinación de solo dos de las tres deja un hueco real, no solo teórico.

La lección 7, la última de tema del módulo, cierra el círculo aplicando este criterio completo —junto con todo lo que construiste en las lecciones 2 a 6— al caso concreto que arrastra toda esta guía: recommendations, el ganador estadísticamente significativo que rompe el guardrail de latencia. Vas a ver, con una decisión ejecutada en Node, cómo se junta todo el marco mental de este módulo en un solo veredicto — antes de que el módulo 2 te dé la primera herramienta técnica para ejecutarlo.

Recursos

• Cindy Sridharan, "Testing in Production: the hard parts" — copyconstruct.medium.com/testing-in-production-the-hard-parts-3f06cefaf592. Un desarrollo extenso de por qué minimizar el radio de impacto —con despliegues por etapas, aislamiento y observabilidad— es central para probar cambios de forma segura en producción real. En inglés.
• LaunchDarkly, "What Is Progressive Delivery All About?" — launchdarkly.com/blog/what-is-progressive-delivery-all-about. Una introducción práctica de la industria a la idea de liberar cambios gradualmente a subconjuntos de usuarios de forma controlada, el nombre general de la práctica que las tres propiedades de esta lección describen. En inglés.