Planteamiento y contexto
Un equipo de búsqueda ha completado un nuevo algoritmo de ranking, pero el método de lanzamiento aún no está decidido. Ingeniería quiere un feature flag, crecimiento (growth) quiere una prueba A/B y operaciones está preocupada por los incidentes. Explica cómo eliges el mecanismo, defines el éxito, controlas la exposición y reviertes un mal resultado. Asume que el algoritmo ya está desplegado; la pregunta es sobre quién lo ve, cómo compararlo y cuándo expandirlo.
Qué está evaluando el entrevistador
- Si separas los objetivos: un flag controla la exposición, un progressive rollout controla el riesgo y una prueba A/B responde a una comparación causal.
- Si defines salvaguardas (guardrails) de usuario, negocio y sistema antes de discutir porcentajes de tráfico.
- Si explicas la segmentación estable (stable bucketing), la contaminación, la autoridad para hacer rollback y los valores predeterminados seguros (safe defaults).
- Si incluyes la propiedad del flag, el ciclo de vida y la limpieza en lugar de tratar el lanzamiento como un simple clic de botón.
Preguntas de clarificación antes de responder
- ¿Estamos aprendiendo sobre el valor o solo lanzando de forma segura? Un valor desconocido requiere un experimento; un valor conocido con alto riesgo requiere un progressive rollout.
- ¿Cuál es la unidad de experimentación? El ranking de búsqueda normalmente necesita una segmentación estable por usuario o cuenta; la aleatoriedad a nivel de solicitud (request) hace que un mismo usuario alterne entre experiencias.
- ¿Cuál es la métrica principal y qué salvaguardas no son negociables? Más clics no pueden justificar una peor latencia, quejas, conversión o errores.
- ¿Existen restricciones entre dispositivos, regionales o de dependencias? La exposición inconsistente contamina las conclusiones; acota el alcance o corrige la asignación primero.
Estructura de respuesta en 30 segundos
“Primero aclaro si el objetivo es el aprendizaje, el control de riesgos o ambos. Para comparar el valor del ranking, utilizo una división A/B estable a nivel de usuario; cuando el valor es conocido pero el riesgo de falla es alto, comienzo con un progressive rollout pequeño detrás de un kill switch. Antes del lanzamiento, defino una métrica north-star y salvaguardas como latencia y errores, y registro el ID de variante, la exposición y el resultado. Solo expando después de que se cumplan los umbrales preestablecidos, pauso y revierto ante fallas, y elimino la rama de experimentación y el flag después de la decisión.”
Respuesta detallada paso a paso
1. Mapear cada mecanismo a la pregunta
Un feature flag es un plano de control en tiempo de ejecución: el código se puede desplegar sin exponerlo a todos. Un progressive rollout es una política de exposición: pasar de cuentas internas a una pequeña cohorte de clientes y luego a un tráfico más amplio. Una prueba A/B es un diseño de medición: comparar variantes en grupos comparables. Se pueden superponer por capas, pero uno no reemplaza a los otros.
2. Elegir la unidad y la segmentación estable
El ejemplo de Google Cloud utiliza userID para una segmentación persistente (sticky bucketing) e identificadores descriptivos de variantes para el análisis. Para el ranking, aplica un hash al usuario o cuenta para asignarlo a la línea base (baseline) o al grupo experimental, de modo que la misma persona no cambie durante la prueba. La aleatorización a nivel de solicitud contamina el almacenamiento en caché, el comportamiento de aprendizaje y la experiencia del usuario que regresa.
3. Definir métricas y reglas de parada
La métrica north-star debe representar la tarea del usuario, como un clic satisfecho tras una búsqueda útil o la finalización de una tarea. Las salvaguardas cubren la latencia P95, la tasa de resultados cero, la tasa de errores, las quejas y el perjuicio comercial. Escribe los umbrales de expansión, pausa y reversión antes de ver los resultados para que un aumento de clics a corto plazo no oculte daños a largo plazo o en el sistema.
4. Utilizar progressive rollout para riesgos irreversibles
Microsoft describe la separación entre despliegue y exposición, pasando de cuentas del equipo a clientes seleccionados y luego a usuarios más amplios. Los usuarios internos validan la corrección primero; luego sigue la expansión por región o cohorte. Revisa métricas y registros en cada etapa. La ruta de desactivación (kill path) debe ser independiente del nuevo algoritmo para que el control de reversión no dependa de la ruta de código con fallas.
5. Prevenir la contaminación y auditar variantes
Registra el usuario, la variante, la marca de tiempo, la versión, el evento de exposición y el evento de resultado. Google Cloud recomienda nombres descriptivos de variantes en lugar de un simple booleano. Si un usuario se divide de manera diferente entre dispositivos o los grupos interfieren, marca la contaminación y deja de interpretar los resultados. El análisis debe rastrear cada resultado hasta las reglas de flags activas en ese momento.
6. Finalizar el experimento y gobernar el flag
Optimizely separa los experimentos de la entrega dirigida (targeted delivery): los experimentos responden qué opción es mejor, luego la opción ganadora se despliega con un flag. Tanto Atlassian como Microsoft enfatizan la eliminación de flags tras un despliegue completo para evitar deudas técnicas de ramas, coordinación y mantenimiento. Registra un responsable, fecha de caducidad, comportamiento por defecto y una tarea de eliminación cuando se cree el flag.
Ejemplo de respuesta de alta calidad
Primero preguntaría si el equipo necesita aprendizaje o control de riesgos. El valor del ranking es desconocido, por lo que comenzaría con un experimento A/B estable a nivel de usuario, envuelto en una compuerta de exposición progresiva pequeña que se pueda apagar si se vulnera una salvaguarda. La métrica principal serían los clics satisfechos después de una búsqueda útil; las salvaguardas incluirían la latencia P95, la tasa de resultados cero, los errores y las quejas.
Registraría el ID de la variante, la exposición y el resultado, nunca aleatorizaría por solicitud y evitaría mirar los clics de forma aislada. Comenzaría con cuentas internas y una pequeña cohorte de clientes, verificaría el registro de logs, el comportamiento de la caché y la asignación entre dispositivos, para luego expandir según umbrales explícitos. Una vez tomada la decisión, convertiría al ganador en el valor predeterminado y eliminaría la rama de experimentación, el registro de propiedad y el flag. Si las salvaguardas empeoran, pausaría, restauraría la línea base e investigaría. Esto cubre el aprendizaje, la seguridad y la propiedad del ciclo de vida.
Errores comunes
- Error → Llamar prueba A/B a un feature flag. Por qué falla: un flag controla la exposición, pero no crea automáticamente una medición comparable. Solución: especifica grupos, métricas, registro de exposición y análisis.
- Error → Aleatorizar cada solicitud. Por qué falla: un mismo usuario parpadea entre experiencias y contamina la caché y el comportamiento. Solución: elige una unidad estable y utiliza sticky bucketing.
- Error → Definir únicamente una métrica de crecimiento. Por qué falla: los clics pueden aumentar mientras que la latencia, los errores o las quejas empeoran. Solución: acompaña la métrica north-star con salvaguardas del sistema y de la experiencia.
- Error → Mantener el flag después del despliegue completo. Por qué falla: las ramas y las reglas se acumulan, dificultando razonar sobre el comportamiento futuro. Solución: crea un responsable, una fecha de caducidad y una tarea de eliminación junto con el flag.
Preguntas de seguimiento y respuestas
El experimento aumenta los clics pero también la latencia. ¿Qué resultado gana?
Verifica primero el umbral de salvaguarda preestablecido. Si se ha sobrepasado, pausa la expansión y restaura la línea base; luego segmenta el valor del usuario para decidir si optimizar el algoritmo o mantener la prueba solo para contextos tolerantes a la latencia. Un aumento de clics no invalida la degradación del sistema.
El mismo usuario recibe variantes diferentes en web y móvil. ¿Qué haces?
Define la unidad del experimento. Si la consistencia entre dispositivos importa, utiliza una clave a nivel de cuenta y un único servicio de asignación. Si no se puede unificar, limita la conclusión a una sola plataforma en lugar de tratar la interacción entre dispositivos como un efecto del experimento.
¿Cuándo no vale la pena realizar una prueba A/B?
Omítela cuando la corrección o el cumplimiento normativo dominen, el tamaño de la muestra no pueda detectar la diferencia objetivo o una restricción externa ya determine el lanzamiento. Un pequeño progressive rollout con salvaguardas es más económico cuando la incertidumbre en la decisión es baja.
¿Qué debería suceder si el servicio de flags no está disponible?
Define un valor predeterminado seguro para cada variante, normalmente la línea base verificada, y mantén localmente la última configuración utilizable cuando sea apropiado. Registra las fallas de evaluación para que una caída del servicio de flags no se convierta en una caída del negocio principal.