Módulo 3: Gradual Rollout

Deployment rings: quién ve la feature primero

Siguiente →

Descripción

Hasta ahora, la rampa completa de este módulo se definió únicamente por porcentaje: 1%, 10%, 50%, 100% de una base tratada como un solo grupo homogéneo. Esta lección agrega una segunda dimensión que el porcentaje, por sí solo, no captura: quién, específicamente, está en ese porcentaje. Un 1% elegido al azar entre 250,000 compradores es una cosa. Un 1% compuesto, primero, por el propio equipo de Mercado, es otra completamente distinta — con más tolerancia al riesgo, más contexto técnico, y un canal directo para reportar problemas. Esta idea —organizar la exposición por población, no solo por cantidad— es lo que la industria llama deployment rings, o anillos de despliegue.

Conexión con el módulo. Esta lección no reemplaza la rampa por porcentaje de las lecciones 2 a 5 — la complementa. El porcentaje responde "¿cuánta gente?"; el ring responde "¿cuál gente, específicamente?". Mercado puede —y debería— usar ambos a la vez: el ring 0 (empleados internos) ve recommendations incluso antes de que exista un canary con usuarios reales, y los rings siguientes se alinean, aproximadamente, con las mismas etapas de porcentaje que ya conoces.

Una analogía: estrenar la obra con la familia, antes que con el público

Ninguna compañía de teatro estrena una obra nueva directamente frente al público que pagó su entrada. Primero hay un ensayo general, frente a nadie o casi nadie — solo el elenco y el director, revisando que las luces entren a tiempo y que nadie olvide una línea. Después, muchas compañías invitan a familiares y amigos a una función previa: gente que quiere que la obra salga bien, que va a dar retroalimentación honesta pero generosa, y que no va a escribir una reseña destructiva si algo sale mal. Recién después de esas dos rondas, la obra se abre al público pagante — que no tiene ningún incentivo para ser indulgente si algo falla.

Cada ronda de esta secuencia tiene una audiencia distinta, elegida a propósito por su tolerancia al riesgo y su capacidad de dar retroalimentación útil — no por cuántas personas caben en la sala. Eso es exactamente un deployment ring: no "cuánta gente", sino "cuál gente, en qué orden, y por qué esa gente primero".

Ejemplo trabajado: los rings de recommendations en Mercado

Definimos los cuatro rings del rollout de recommendations, y los alineamos con las etapas de porcentaje que ya conoces de las lecciones anteriores:

// deploymentRings: QUIEN ve la feature primero, en vez de CUANTOS (eso es
// rolloutPlan). Cada ring es una poblacion con mas tolerancia al riesgo -- y mas
// contexto para reportar problemas -- que la siguiente. Mercado combina los rings
// con el porcentaje de la rampa: ring 0 no depende del %, los siguientes rings
// se alinean con las etapas ya vistas en este modulo.
const rings = [
  { ring: 0, name: 'internal employees', size: 480, alignsWith: 'ninguna etapa (antes del canary)' },
  { ring: 1, name: 'opt-in beta buyers', size: 2500, alignsWith: 'canary 1%' },
  { ring: 2, name: 'broader rollout', size: 125000, alignsWith: 'rollout 50%' },
  { ring: 3, name: 'general availability', size: 250000, alignsWith: 'rollout 100%' },
];

console.log('=== deployment rings de recommendations en Mercado ===\n');
rings.forEach((r) => {
  console.log('ring ' + r.ring + ': ' + r.name.padEnd(22) + 'size=' + r.size.toLocaleString('en-US').padStart(7) +
    '  alinea con -> ' + r.alignsWith);
});

const employeesFirst = rings[0].size;
console.log('\nring 0 (' + employeesFirst + ' empleados) ve recommendations ANTES que el primer usuario real del canary --');
console.log('el guardrail de latencia ya deberia notarse ahi, con cero riesgo para un comprador real.');

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

=== deployment rings de recommendations en Mercado ===

ring 0: internal employees    size=    480  alinea con -> ninguna etapa (antes del canary)
ring 1: opt-in beta buyers    size=  2,500  alinea con -> canary 1%
ring 2: broader rollout       size=125,000  alinea con -> rollout 50%
ring 3: general availability  size=250,000  alinea con -> rollout 100%

ring 0 (480 empleados) ve recommendations ANTES que el primer usuario real del canary --
el guardrail de latencia ya deberia notarse ahi, con cero riesgo para un comprador real.

Fíjate en el ring 0: 480 empleados de Mercado, y su columna alignsWith dice explícitamente "ninguna etapa" — porque el ring 0 no forma parte del porcentaje de la rampa en absoluto. Los empleados no son "el 0.2% de la base de usuarios" en ningún sentido de negocio; son una población aparte, elegida porque ya conocen el sistema, tienen un canal directo con el equipo de ingeniería, y —lo más importante— no son clientes reales. Si recommendations tiene un problema tan grave que rompe algo visible, es infinitamente mejor que lo descubra un empleado, dentro de la compañía, que el primer comprador del canary.

Por qué los rings no son solo "otro nombre para el porcentaje"

Es tentador leer la tabla de arriba y pensar que los rings son simplemente una forma más elegante de decir "1%, 10%, 50%, 100%" — pero hay una diferencia real que el ejemplo deja ver: el ring 1 (opt-in beta buyers, 2,500 personas) se alinea con el canary del 1% en tamaño, pero no necesariamente en composición. Un canary por porcentaje puro selecciona a cualquier 1% de la base, sin distinguir si son compradores frecuentes o esporádicos, atentos a cambios en la interfaz o completamente indiferentes. Un ring de opt-in beta buyers selecciona, a propósito, a gente que eligió estar ahí — típicamente más tolerante a fallas, más dispuesta a reportar problemas de forma detallada, y consciente de que está probando algo nuevo.

Esta distinción importa para la calidad de la señal que recibes en cada etapa. Un canary por porcentaje puro te da una muestra representativa del comportamiento real de la base — útil para medir el guardrail de latencia con precisión estadística. Un ring de opt-in te da retroalimentación cualitativa más rica —reportes detallados, capacidad de responder preguntas de seguimiento— pero con una muestra que puede comportarse distinto de la base general (gente más entusiasta con features nuevas, por ejemplo). Los equipos maduros usan las dos cosas: el porcentaje para la señal cuantitativa del guardrail (lo que este módulo viene ejecutando con rolloutPlan()), y los rings para la señal cualitativa temprana, especialmente en el ring 0.

Errores comunes

Saltarse el ring 0 (empleados internos) porque "el código ya pasó pruebas automatizadas en otro lado". Qué pasa: el equipo va directo del deploy a un canary con usuarios reales, sin que nadie dentro de la compañía haya usado recommendations en producción primero. Por qué pasa: las pruebas automatizadas y el entorno de staging se sienten como suficiente validación, y agregar un paso más —aunque sea con empleados, gratis en términos de riesgo real— parece burocracia innecesaria. Cómo detectarlo: si algo se rompe en el canary con usuarios reales, y nadie del equipo lo había visto funcionar en producción antes de ese momento, el ring 0 no se usó. Cómo corregirlo: como muestra el ejemplo de hoy, el ring 0 no cuesta nada en términos de radio de impacto sobre clientes reales — solo cuesta el tiempo de esperar a que los empleados lo prueben primero, y ese tiempo casi siempre vale la pena.

Tratar a los usuarios de un ring de "opt-in beta" como si fueran representativos de toda la base, para conclusiones cuantitativas. Qué pasa: alguien mide el guardrail de latencia solo dentro del ring de beta buyers, y usa ese resultado para decidir si recommendations está lista para el 100% de la base general. Por qué pasa: el ring de beta ya tiene datos reales, y parece redundante volver a medir lo mismo con un canary por porcentaje separado. Cómo detectarlo: el tamaño de la muestra reportada corresponde exactamente al ring de opt-in, y nadie puede decir qué fracción de la base general se parece a ese grupo. Cómo corregirlo: usa el ring de beta para señal cualitativa temprana y para validar que nada está catastróficamente roto — pero la decisión cuantitativa de avanzar por la rampa (lo que hace rolloutPlan()) necesita una muestra que sí represente a la base general, como el canary por porcentaje de las lecciones anteriores.

Confundir el orden de los rings con el orden de las etapas de porcentaje, y asumir que tienen que coincidir exactamente en tamaño. Qué pasa: alguien intenta forzar que cada ring tenga exactamente el mismo tamaño que su etapa de porcentaje "alineada", incluyendo el ring 0, que terminaría teniendo que ser artificialmente inflado o recortado para calzar con algún porcentaje de la base. Por qué pasa: ver las dos listas —rings y etapas— una al lado de la otra en una tabla sugiere que deberían corresponder número a número. Cómo detectarlo: el ring 0 (empleados) tiene un tamaño fijo, determinado por cuánta gente trabaja en la empresa — no por ningún porcentaje de la base de usuarios, que puede ser cien, mil o un millón de veces más grande. Cómo corregirlo: como en la tabla de este ejemplo, los rings y las etapas de porcentaje son dos ejes complementarios, no un mismo número expresado de dos formas — se combinan, no se fuerzan a coincidir exactamente.

Ejercicios

Ejercicio 1 — Diseña el ring 0 de un caso distinto. El equipo de logística de Mercado (del ejercicio 2 del proyecto del módulo 1) quiere lanzar su nuevo algoritmo de tiempos de entrega estimados con el mismo enfoque de rings. Mercado tiene 620 empleados en total, mucho más que los 480 de esta lección. ¿Debería el ring 0 de logística incluir a los 620 empleados completos, o a un subconjunto? Justifica tu respuesta.

Ver solución

Debería ser un subconjunto, no los 620 completos. El valor del ring 0 no viene de cuánta gente hay, sino de que esa gente pueda usar realmente la feature y dar retroalimentación relevante — para un cambio en tiempos de entrega estimados, eso significa empleados que hacen compras reales en la plataforma (no, por ejemplo, alguien de un equipo de finanzas que nunca compra nada). Un ring 0 más chico pero compuesto por gente que de verdad va a interactuar con el cambio da mejor señal que uno grande pero irrelevante para la feature específica — el mismo principio que llevó a elegir 480 (no los 620 totales) para recommendations en este ejemplo.

Ejercicio 2 — Explica la diferencia entre las dos fuentes de señal. En 2-3 frases, explica por qué el ring 1 (opt-in beta buyers, 2,500 personas) y el canary 1% (también 2,500 personas, de la lección 2) pueden tener el mismo tamaño exacto y aun así dar tipos de información distintos.

Ver solución

El tamaño idéntico (2,500) solo garantiza que la cantidad de señal cuantitativa —eventos de guardrail esperados, como viste en la lección 3— sea comparable entre los dos grupos. Lo que no garantiza es que la composición sea la misma: el ring de opt-in beta selecciona activamente a gente dispuesta a probar cosas nuevas y reportar problemas con detalle, mientras que un canary por porcentaje puro selecciona una muestra aleatoria de toda la base, sin ese sesgo hacia el entusiasmo o la tolerancia al riesgo. El primero da mejor retroalimentación cualitativa temprana; el segundo da una medición más representativa del comportamiento real de la base completa.

Ejercicio 3 — Combina rings y porcentaje en una propuesta. Escribe, en 3-4 frases, una propuesta de rollout para una nueva feature de Mercado (inventa el nombre y el contexto) que use tanto rings como porcentaje — nombrando explícitamente qué población entra en cada ring y con qué etapa de porcentaje se alinea.

Ver solución

No hay una única respuesta correcta — se evalúa que la propuesta combine ambos ejes con una razón explícita—. Un ejemplo posible: "Para smartSearch (autocompletado de búsqueda con IA), el ring 0 son los 45 empleados del equipo de producto que usan la búsqueda todos los días — antes de cualquier usuario real. El ring 1 es un grupo de 3,000 vendedores que ya optaron por probar features nuevas (alineado con un canary de 1.2% sobre la base de vendedores), donde medimos la tasa de búsquedas sin resultados. El ring 2 es el 25% general de compradores activos, y el ring 3 es el 100%, alineado con la etapa final de la rampa." Fíjate en que cada ring tiene una razón de ser distinta a "es más gente que el anterior": empleados por contexto técnico, opt-in por retroalimentación detallada, y las etapas generales por representatividad estadística.

Resumen y siguiente paso

En esta lección agregaste una dimensión que la rampa por porcentaje, sola, no cubre: los deployment rings — quién ve la feature primero, no solo cuántos. Viste que Mercado combina un ring 0 de 480 empleados (sin costo en radio de impacto sobre clientes reales) con rings que se alinean, en tamaño, con las etapas de porcentaje que ya conoces — y por qué la composición de cada ring importa tanto como su tamaño para el tipo de señal que da.

Antes de avanzar deberías poder: explicar la diferencia entre "cuántos" (porcentaje) y "quién" (ring); y diseñar un ring 0 razonable para una feature dada.

La lección 7 cierra el marco de la rampa con la última pieza que falta: el tiempo. Aunque una etapa tenga el tamaño correcto (lección 3), el criterio correcto (lección 4), y la población correcta (esta lección), ¿cuánto hay que esperar antes de que sus datos sean confiables?

Recursos

← AnteriorEl radio de impacto crece con cada etapaSiguiente →Dwell time: cuánto esperar antes de confiar en una etapa