Cuando un ganador rompe un guardrail: el veredicto sobre `recommendations`

Descripción

Seis lecciones construyeron, pieza por pieza, el marco completo de este módulo: la brecha entre "ganó el experimento" y "listo para todos" (L2), el lanzamiento como decisión de riesgo (L3), el radio de impacto medido en número de personas (L4), la separación entre deploy y release que hace posible controlar ese radio (L5), y las tres propiedades que comparte cualquier lanzamiento cuidadoso (L6). Esta lección, la última de tema del módulo, junta las seis piezas en un solo veredicto sobre el caso que arrastra toda la guía: recommendations ganó, y rompe un guardrail. ¿Se lanza, o no?

Conexión con el módulo. No hay ningún concepto nuevo aquí — esta lección es, literalmente, aplicar el marco completo de las lecciones 2 a 6 a los datos reales que la guía de métricas dejó sobre la mesa. Es el ensayo del razonamiento que vas a repetir, con las herramientas técnicas completas, en el mini-proyecto de la lección 8, y el que vas a necesitar de nuevo, con mecánica distinta, cada vez que un ganador estadístico traiga consigo un problema conocido.

Una analogía: el veredicto del médico, con dos resultados en la mano

Un paciente llega con dos resultados de laboratorio en la mano: uno confirma que el tratamiento nuevo funcionó —el marcador que se quería mejorar, mejoró, de forma clara y medible—. El otro muestra un efecto secundario real, ya presente, no hipotético: la presión arterial subió más de lo esperado. Un médico que solo mira el primer resultado dice "sigamos con la dosis completa, funcionó". Un médico que entra en pánico por el segundo dice "suspendamos todo el tratamiento". Ninguno de los dos está pensando con el marco correcto. El médico que sí razona bien hace una tercera cosa: reconoce que el tratamiento funciona —eso ya no está en duda— y diseña un plan que sigue manteniendo el beneficio mientras contiene y vigila el efecto secundario: quizás una dosis más baja al principio, revisiones de presión más frecuentes, un plan claro de qué hacer si la presión sigue subiendo.

recommendations es exactamente ese paciente. El primer resultado (conversión +18.75%, p=0.0114) dice que funciona. El segundo (latencia p95 a 910ms, sobre el techo de 800) dice que hay un efecto secundario real, ya confirmado. El veredicto de esta lección no es "sí" ni "no" en blanco y negro — es el plan del médico que sabe leer los dos resultados a la vez.

Ejemplo trabajado: launchVerdict() sobre recommendations

Vamos a construir el modelo de decisión más simple posible, con tres preguntas booleanas que resumen todo lo que las lecciones anteriores construyeron: ¿el resultado primario es significativo? ¿hay un guardrail roto? y, si lo hay, ¿existe una forma de contener el daño mientras se decide qué hacer?

// launchVerdict: la decision de alto nivel (no la mecanica) frente a un ganador
// que rompe un guardrail. "containable" se refiere a si existe una forma de
// exponer solo a una fraccion primero -- el COMO (flags/rollout) es M2-M3.
function launchVerdict({ primarySignificant, guardrailBroken, containable }) {
  if (!primarySignificant) return 'no lanzar: el resultado primario ni siquiera es significativo';
  if (!guardrailBroken) return 'lanzar con rollout gradual estandar, sin cuidado extra';
  if (guardrailBroken && containable) return 'lanzar EMPEZANDO chico, vigilando el guardrail antes de escalar';
  return 'no lanzar todavia: guardrail roto y sin forma de contener el dano';
}

const mercadoCase = {
  primarySignificant: true, // checkoutConversion lift +18.75%, p=0.0114
  guardrailBroken: true, // p95Latency 910ms > techo 800ms
  containable: true, // existe la opcion de un rollout gradual (M2-M3 dan el como)
};

console.log('=== launchVerdict sobre recommendations en Mercado ===\n');
console.log('primarySignificant=' + mercadoCase.primarySignificant + '  guardrailBroken=' + mercadoCase.guardrailBroken + '  containable=' + mercadoCase.containable);
console.log('Veredicto: ' + launchVerdict(mercadoCase));

const noContainmentCase = { ...mercadoCase, containable: false };
console.log('\nSi Mercado NO tuviera forma de exponer solo a una fraccion primero:');
console.log('Veredicto: ' + launchVerdict(noContainmentCase));

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

=== launchVerdict sobre recommendations en Mercado ===

primarySignificant=true  guardrailBroken=true  containable=true
Veredicto: lanzar EMPEZANDO chico, vigilando el guardrail antes de escalar

Si Mercado NO tuviera forma de exponer solo a una fraccion primero:
Veredicto: no lanzar todavia: guardrail roto y sin forma de contener el dano

Fíjate en las dos salidas del mismo caso, con un solo campo distinto (containable). Con containable: true —porque existe, en principio, la posibilidad de un rollout gradual—, el veredicto es lanzar, con cuidado. Con containable: false —imagina un mundo donde Mercado no tuviera ninguna infraestructura para exponer a una fracción, ni feature flags, ni nada— el veredicto cambia por completo a "no lanzar todavía", a pesar de que el resultado primario sigue siendo exactamente igual de significativo. Esa comparación es el argumento completo de este módulo, condensado en dos líneas de salida: la decisión de lanzar no depende solo de si el experimento ganó — depende, igual de fuerte, de si tienes la capacidad de contener lo que ya sabes que está roto.

Por qué esto no es, todavía, un plan de lanzamiento completo

Vale la pena ser honesto sobre lo que launchVerdict() no hace. No decide en qué porcentaje exacto empezar (¿1%? ¿5%?) — eso es el módulo 3. No decide qué guardrail específico vigilar en cada etapa, ni con qué frecuencia — eso es el módulo 4. No decide qué hacer si, ya en producción, el guardrail empeora en vez de mejorar — eso es el módulo 5. Lo que launchVerdict() sí hace, y es exactamente el trabajo de este módulo 1, es contestar la pregunta de más alto nivel: ¿el camino de "lanzar con cuidado" existe siquiera, dado lo que sabemos? Para recommendations, la respuesta es sí — y esa respuesta es la que autoriza a que los módulos 2 a 5 empiecen a construir el cómo.

Esta es la frontera exacta entre este módulo y el resto de la guía: el módulo 1 contesta si vale la pena intentar un lanzamiento cuidadoso; los módulos 2 a 5 son, cada uno, una pieza distinta del cómo ejecutarlo.

Errores comunes

Simplificar el caso a "ganó, así que se lanza" o "rompió un guardrail, así que no se lanza". Qué pasa: en una conversación apurada, alguien colapsa las tres variables de launchVerdict() en una sola —"¿ganó o no ganó?"— y toma la decisión con esa única pregunta. Por qué pasa: manejar tres variables a la vez exige más esfuerzo mental que manejar una sola, y bajo presión de tiempo es tentador simplificar. Cómo detectarlo: la decisión se anuncia sin mencionar, ni una vez, la palabra "guardrail" o "contención". Cómo corregirlo: usa siempre las tres preguntas explícitas de launchVerdict(), en ese orden — significancia, guardrail, contención — antes de anunciar cualquier decisión de lanzamiento.

Tratar containable como una propiedad fija del problema, en vez de una capacidad del equipo. Qué pasa: alguien asume que si un guardrail está roto, automáticamente "no hay forma de contenerlo", sin considerar si el equipo tiene —o puede construir rápido— la infraestructura de exposición gradual. Por qué pasa: el problema técnico (la latencia) se siente fijo e inevitable, y es fácil olvidar que la capacidad de contenerlo depende de herramientas que el equipo controla, no del bug en sí. Cómo detectarlo: la conversación sobre "¿es containable?" nunca menciona si existen feature flags, ni si hay forma de medir el guardrail en tiempo real. Cómo corregirlo: recuerda que containable en este modelo es una pregunta sobre capacidad organizacional (¿tenemos las herramientas de los módulos 2 a 4?), no sobre la gravedad del bug — dos preguntas completamente distintas.

Confundir "empezar chico" con "posponer el lanzamiento indefinidamente". Qué pasa: el equipo acepta el veredicto de "lanzar empezando chico, vigilando el guardrail", pero en la práctica nunca fija una fecha ni un plan concreto, y el 1% inicial se queda ahí durante meses sin que nadie decida avanzar. Por qué pasa: "empezar chico" se siente como una forma segura de posponer una decisión más grande indefinidamente, sin la incomodidad de decir "no vamos a lanzar" en voz alta. Cómo detectarlo: pasan semanas desde que se decidió "lanzar con cuidado" y el porcentaje de exposición sigue siendo el mismo del primer día, sin ningún criterio explícito de cuándo subir. Cómo corregirlo: "empezar chico" es el primer paso de un plan con etapas definidas —no un estado permanente—; el módulo 3 de esta guía enseña exactamente cómo diseñar esas etapas con criterios claros de avance.

Ejercicios

Ejercicio 1 — Aplica el modelo a un caso distinto. El equipo de vendedores de Mercado corre un experimento de sellerDashboard que gana con significancia estadística clara, sin romper ningún guardrail conocido. Usa launchVerdict() mentalmente: ¿qué valores le asignarías a las tres variables, y qué veredicto obtienes?

Ver solución

primarySignificant: true, guardrailBroken: false, containable no llega a evaluarse porque la función retorna en el segundo if. El veredicto: 'lanzar con rollout gradual estandar, sin cuidado extra'. Este es el caso más simple de los cuatro que puede producir el modelo — sin un guardrail roto, no hace falta el nivel de cautela adicional que sí necesita recommendations, aunque un rollout gradual estándar (el módulo 3, sin el cuidado extra de vigilancia intensiva del módulo 4) sigue siendo una buena práctica por defecto.

Ejercicio 2 — El caso donde nada es containable todavía. Imagina que Mercado, hoy, apenas está empezando a construir su primera infraestructura de feature flags (el módulo 2 de esta guía) y todavía no tiene nada funcional. ¿Qué significa, en términos prácticos y no solo teóricos, que containable sea false en este momento? ¿Qué tendría que pasar para que se vuelva true?

Ver solución

En términos prácticos, containable: false significa que hoy, si Mercado quisiera lanzar recommendations a una fracción chica de usuarios, no tendría ningún mecanismo real para hacerlo sin un nuevo deploy completo por cada cambio de porcentaje — exactamente el problema que se discutió en la lección 3 (reversible, pero lentamente) y en la lección 5 (sin la separación deploy/release, no hay forma de exponer solo a una fracción). Para que containable se vuelva true, el equipo necesita construir —no solo desear— la infraestructura de feature flags del módulo 2: sin esa pieza técnica concreta, la palabra "contenible" es solo una intención, no una capacidad real. Esto conecta el veredicto de esta lección directamente con el trabajo técnico que arranca en el módulo 2.

Ejercicio 3 — Escribe el mensaje al equipo ejecutivo. Imagina que tienes que explicarle, en 3-4 frases, a alguien fuera del equipo técnico —que solo sabe que "el experimento de recomendaciones ganó"— por qué recommendations no se está lanzando al 100% esta misma semana, a pesar de la buena noticia del resultado. Usa el vocabulario de esta lección (significancia, guardrail, contención) traducido a un lenguaje que esa persona pueda seguir.

Ver solución

Un mensaje razonable: "Las recomendaciones funcionaron mejor de lo esperado —18.75% más de gente completó su compra, y estamos seguros de que no fue casualidad—. Pero, al mismo tiempo, descubrimos que el checkout se vuelve notablemente más lento para los usuarios que ven el carrusel, más de lo que consideramos aceptable. En vez de elegir entre 'lanzarlo a todos ya' o 'cancelarlo por completo', vamos a lanzarlo empezando con una fracción muy pequeña de usuarios, vigilando de cerca esa lentitud, y solo vamos a subir el porcentaje cuando confirmemos que la podemos mantener bajo control. Así capturamos la mejora real sin arriesgar la experiencia de compra de toda nuestra base de un solo golpe." Fíjate en que el mensaje nombra los dos resultados —el bueno y el problemático— con el mismo peso, y explica el plan intermedio sin necesitar que la otra persona conozca los términos técnicos de "canary" o "feature flag" todavía.

Resumen y siguiente paso

En esta lección, la última de tema del módulo, juntaste las cinco lecciones anteriores en un solo veredicto ejecutado: launchVerdict() confirma que recommendations —significativo, con un guardrail roto, pero con la posibilidad de contener el daño— debe lanzarse empezando chico y vigilando el guardrail, no lanzarse al 100% de golpe ni cancelarse por completo. Viste, con la comparación entre containable: true y containable: false, que esa capacidad de contención no es una propiedad del bug sino de las herramientas que el equipo tiene disponibles — y que sin ellas, incluso un resultado perfectamente significativo no autoriza un lanzamiento.

Antes de avanzar deberías poder: aplicar las tres preguntas de launchVerdict() a un caso nuevo, con tu propio criterio de qué cuenta como significativo, guardrail roto, y contenible; explicar por qué "empezar chico" es el primer paso de un plan, no un estado final; y comunicar el veredico completo a alguien sin vocabulario técnico, sin perder ninguna de las dos mitades del resultado.

Con esto cierras el marco mental completo del módulo. La lección 8, el mini-proyecto, te pone en el lugar exacto del equipo de Mercado: comparar, con el modelo blastRadius() de la lección 4, el radio de impacto real de "lanzar al 100% de golpe" contra "empezar con un canary del 1%", y decidir formalmente el enfoque de lanzamiento — el último paso antes de que el módulo 2 te dé la primera herramienta técnica, feature flags, para construirlo de verdad.

Recursos

• Google SRE Workbook, Capítulo 16, "Canarying Releases" — sre.google/workbook/canarying-releases. El capítulo que formaliza la práctica de lanzar primero a una porción chica y evaluar antes de continuar, exactamente el veredicto que launchVerdict() recomienda para recommendations. En inglés.
• Google SRE Book, Capítulo 3, "Embracing Risk" — sre.google/sre-book/embracing-risk. El capítulo sobre error budgets: cómo un equipo decide, con un número explícito, cuánto riesgo de "no confiabilidad" está dispuesto a tolerar antes de frenar — la base conceptual detrás de decidir qué cuenta como containable. En inglés.