Cuando la Red de Seguridad se Incendia: Solucionando Problemas de Feature Flags a Gran Escala

Hola, soy Ryan Feigenbaum. Soy un Senior Developer Advocate en GrowthBook, una plataforma de código abierto para feature flagging y experimentación. Hoy, voy a hablarles sobre cuando los feature flags se incendian, resolviendo problemas de feature flags a escala. Y comencemos con la primera diapositiva aquí. Lo siento, encontrando mi cursor.

El if statement de $460 millones. Así que esta es una historia interesante de 2012 del Knight Capital Group, que reutilizó un antiguo feature flag sin saberlo. Y en el transcurso de 45 minutos, perdieron $460 millones, que era más dinero del que tenían. Y en poco tiempo, luego se quedaron sin negocio y fueron adquiridos. Y todo esto sucedió debido a una mala gestión de feature flags.

Y por interesante que sea esa historia, no es la historia que voy a contar aquí. De hecho, más bien quiero hablar sobre cómo no ser como Knight Capital Group y qué puedes hacer para evitar tal catástrofe. Y algunos de los hechos sobre la gestión de feature flags y por qué es difícil. Así que una gran cifra que muestran las investigaciones es que el 73% de los feature flags nunca se eliminan. Y así se acumulan en la base de código como deuda técnica, no es algo bueno.

Se estima que esto cuesta a un equipo de 10 desarrolladores alrededor de $125,000 por año. Así que son costos reales tangibles. Y esto proviene simplemente de tener que navegar por esta antigua base de código, averiguar qué están haciendo las cosas. Es simplemente una gran pérdida de tiempo. Y los informes muestran que alrededor del 95, 90% de los equipos de desarrollo luchan con la deuda de flags. Así que puede parecer simple, ¿verdad?, un flag que está encendido o apagado. Son solo algunos toggles. ¿Qué tan difícil puede ser? En realidad, es bastante difícil. Y déjame mostrarte un poco por qué se vuelve tan difícil. Así que tenemos aquí cuatro formas en las que la complejidad de tu sistema de feature flags crecerá. Y la más simple de entender y pensar es solo la lógica del flag. Así que tenemos un flag Booleano que es verdadero o falso. Pero con el tiempo, por supuesto, ese simple verdadero o falso se convertirá en una lógica multivariante donde tal vez tengas un tipo diferente de experimentos ejecutándose en él. Despliegues progresivos, todo tipo de lógica de segmentación sofisticada.

Y esta complejidad se extiende a la infraestructura donde podrías comenzar con solo una simple aplicación Web. Pero luego se convierte en una aplicación móvil. Y luego se convierte tal vez en que estás ejecutando en la parte trasera de una pantalla en un avión o algo así. Así que tu infraestructura se vuelve muy complicada. Y eso luego se extiende, nuevamente, a tus usuarios que podrían comenzar todos de la misma manera. Pero luego tienen dispositivos muy diferentes y diferentes condiciones de red, diferentes agrupaciones. Se vuelve mucho más complejo.

Y luego, por último, tu equipo. Así que podría comenzar con solo un equipo de desarrollo. Pero luego tal vez hay dos equipos de desarrollo y la infraestructura está involucrada y los productos están involucrados y el marketing está involucrado. Y todos quieren saber qué está pasando con los feature flags. Y así esa simple complejidad luego florece exponencialmente y se vuelve mucho más difícil de manejar.

Y lo que hemos encontrado es que esta complejidad, esta dificultad se puede categorizar en tres muros diferentes. Y estos son tres muros. Cada equipo se enfrenta a su plataforma de feature flagging. Y de eso quiero hablar hoy. El primero es la visibilidad. El segundo es el ciclo de vida. Y el tercero es la arquitectura. Así que vamos a sumergirnos directamente en el problema, el muro de la visibilidad. La visibilidad, bastante simple de pensar. Es solo el hecho de que no puedes ver lo que está haciendo tu flag.

Y esto se presenta de tres formas. Entonces, primero, este es un escenario bastante común. Podrías encontrar un flag como este en producción. Así que tenemos un flag NCDFF123 temp. Y entonces podrías estar pensando, ¿qué hace esto? ¿Por qué es FF123? ¿Es un marcador de posición? ¿Es ese el nombre real? ¿Qué es esto? ¿Qué significa temp? ¿Es realmente temporal? El git blame dice 2019. Eso fue hace varios años. ¿Puedo quitar esto? ¿Puedo no quitar esto? Y este es el problema de la visibilidad. Afortunadamente, este problema no es demasiado difícil de resolver. Así que la gran solución aquí es simplemente pensar en nombrar tu feature flag de la misma manera que piensas en nombrar tus variables. Así que debería ser lo más autodescriptivo posible. Así que en lugar de ese flag muy oblicuo NCD123 temp V2 del que hablamos, o que acabas de mostrar en la diapositiva anterior, es mucho mejor tener algo como flag mobile. Así que tienes el equipo combinado flujo de pago. Sabes cuál es la característica que está apuntando, y luego una fecha. Así que queda muy claro lo que ese flag está haciendo. Es aún mejor si tu plataforma puede imponer nombres únicos para los flags. Hemos visto con demasiada frecuencia donde un equipo tendrá, ya sabes, nuevo flujo de pago, pero luego otro equipo también tiene un flag llamado nuevo flujo de pago, y están activando y desactivando inadvertidamente los flags de los demás. Sucede. Y así, un buen enfoque aquí, también, como dije, es usar este patrón de equipo característica fecha. Permite que todos se alineen en nombrar los flags de la misma manera. Y aún mejor, si tu plataforma puede introducir algo como una aplicación de regex que verifique para asegurarse de que todos están nombrando las cosas de la misma manera, mantiene a todos en la misma página, y hace que sea mucho más fácil cuando vuelves a un flag en la base de código muchos años después, si todavía está allí. Esperemos que no, pero al menos sabes lo que está haciendo. Así que ese es un problema de visibilidad. Aquí hay otro problema de visibilidad. Entonces, lo que sucedió antes fue cuando estabas en la base de código y estabas mirando el flag y no sabías lo que hace, aquí hay otra forma en la que la visibilidad es difícil. Cuando miras el feature flag en tu plataforma, así que en la UI, pero no sabes dónde está en el código. Así que Launch Darkly desarrolló este paquete llamado find code references. Es un paquete de código abierto y utiliza GitHub actions para escanear tu base de código y mostrar todos los lugares donde existe ese feature flag. Así que esta es una gran herramienta para comenzar a usar. Tenemos un fork de este growth book que no necesita ni siquiera GitHub actions para funcionar. Es un contenedor Dockerizado y puedes ejecutarlo localmente también, o conectarlo a una plataforma diferente.

Y te mostraré cómo se ve esto aquí. Esta es una captura de pantalla de, de nuestra plataforma donde tenemos esta característica de code reps. Y así, este es un feature flag show reviews, no es un gran nombre, pero te da exactamente dónde en la base de código, aparece este feature flag. Así que hay dos lugares. Y lo que es realmente agradable es que te da el enlace al repositorio de GitHub. Así que puedes ir y ver este código, ya sabes, en persona y ver qué está pasando allí. Así que los gráficos de código son una excelente manera de abordar este problema de visibilidad desde el otro lado.

Y luego un último problema de visibilidad. Así que digamos que puedes ver el código donde puedes ver el feature flag en tu base de código. Puedes ver el feature flag en tu plataforma. Todo eso es genial, pero luego esta es la lógica de ello. Así que tienes un interruptor de apagado. Tienes todas estas diferentes condiciones. Se vuelve muy difícil de resolver. Bueno, si tengo este usuario en particular, ¿cómo se va a renderizar el feature flag para ellos? Empiezas a sentirte como Charlie Day y no está exactamente claro realmente qué está pasando, qué está pasando allí. La forma que hemos encontrado que puede ser realmente útil para los desarrolladores, para las personas de producto para, para entender esto mejor es una característica que llamamos simulación, que puedes buscar en tu plataforma o construir algo como esto.

Y lo que te permite hacer es tomar tu feature flag, pero luego ver inmediatamente cómo se va a evaluar para diferentes grupos de usuarios o para cualquier tipo de propiedades arbitrarias. Así que digamos que estás lanzando una nueva característica. Tienes estas reglas muy complejas y quieres ver cómo esa característica se va a evaluar. Tal vez para usuarios beta en móviles en los EE. UU. podrías mirar la página de simulación y ver exactamente cómo se va a evaluar. Esto se vuelve súper útil también, cuando tienes un montón de pruebas AB para que puedas saber en qué grupo estarían esos usuarios. También es bueno. Puedes verificar. Bien. Se supone que debe estar activado para usuarios beta, pero no para, para usuarios complejos todavía. Así que puedes hacer todo tipo de simulaciones y averiguar cómo se va a evaluar ese flag. Así que ese es este problema de visibilidad, saber qué hace un flag, saber qué hace desde la perspectiva de la base de código, pero luego también desde la plataforma y luego también entender esa lógica compleja. Pasemos ahora a la segunda pared.

Idealmente, así es como va. Entonces, el feature flag se crea para algún propósito y quieres controlar una característica particular, activarla o desactivarla. Luego se introduce en la base de código y está activo. Y luego, en algún momento, ese feature flag se completa. Así que la característica se lanza al cien por ciento, por ejemplo, y ya no necesitas ese feature flag. Y luego se elimina de la base de código. Y esa es la muerte. Así que la, la situación ideal es que cada feature flag tenga un certificado de nacimiento y un certificado de defunción, pero esto es muy a menudo, no es realmente lo que sucede.

Esto es más parecido a lo que usualmente ves. Así que en, en tu base de código, tendrás tu flag use new DB connection, temp P2, pero tendrás estos comentarios que se acumulan, como eliminar esto después del lanzamiento, pero luego otro comentario, bueno, espera, todavía se necesita. Algo pasó con ese lanzamiento. Y luego, Oh, no elimines esto. Y luego preguntas sobre qué hace. Necesito ayuda. ¿Verdad? Esto es muy común. Tan común. De hecho, los estudios muestran que el 87% de los esfuerzos de limpieza de flags fallan. Así que este es un problema real con el ciclo de vida de los flags que ya no son necesarios, se acumulan en la base de código y causan muchos problemas.

Este problema se volvió tan grande que Uber escribió un artículo académico al respecto. Y de una manera muy ingenieril propuso o desarrolló una utilidad de código abierto para combatirlo. Así que este artículo es realmente interesante. Recomiendo encarecidamente revisarlo. Y lo que encontraron fue básicamente que en algunas de sus bases de código, había 8,000 feature flags, muchos de los cuales estaban obsoletos, pero era difícil, por supuesto, a esa escala, 8,000 flags para revisarlos todos y realmente averiguarlo.

Así que desarrollaron una utilidad llamada Piranha. Y lo que hace Piranha es que le das el nombre del feature flag, le das el propietario del feature flag y luego lo que se supone que debe hacer el feature flag. Y escanea automáticamente el AST de la base de código y encuentra esos flags obsoletos junto con todo el código muerto asociado con ellos. Una vez que ha hecho eso, abre un PR en el repositorio que tiene todo ese código muerto en el código y los feature flags que ya no son necesarios eliminados. Y luego establece al propietario original del feature flag como revisor. Así que es un sistema bastante genial. Y lo que encontraron en el uso inicial de esto es que pudieron eliminar 1,381 flags, que eran alrededor de 70,000 líneas de código, lo cual es bastante genial con la salvedad aquí de que 20,000 líneas eran, así que esos eran PRs LGTM. Pudieron ser fusionados inmediatamente, pero otras 50,000 líneas requirieron alguna entrada adicional del propietario del flag. Pero esta es una herramienta muy genial que puedes poner en tu pipeline CICD, y es, nuevamente, de código abierto y disponible para usar.

Así que parte de esa utilidad es la capacidad de identificar cuándo un flag está obsoleto. Y lo que quiero decir con flag obsoleto, es bastante intuitivo, pero solo una sensación de un flag que ya no necesita ser usado. Este es un poco de nuestro algoritmo que usamos internamente en nuestra aplicación para determinar la detección de flags obsoletos. Así que es algo que podrías usar tú mismo o buscar cómo tu plataforma lo hace. Tenemos esto como código abierto, puedes revisarlo. Pero la idea es que miramos flags que no han sido actualizados en dos semanas, aquellos que tienen reglas unilaterales. Esto es muy importante. Básicamente está enviando todo el tráfico al mismo lugar. No está marcado, nunca obsoleto, ¿verdad? A veces tendrás flags que no son intencionalmente de larga duración. Este no es uno de esos. No tiene revisiones de borrador y ninguna otra característica depende de él. No hay nada que esté anidado. Y mostramos esto con este pequeño icono de reloj en la interfaz de usuario para indicar que este es un flag que necesitas revisar. Y luego, por supuesto, otra forma de saber sobre flags obsoletos es si tienes análisis de uso de feature flag que te dicen, bueno, este flag no ha sido evaluado en un mes, entonces eso es algo que también es un buen indicador de que ese es un flag que está obsoleto y realmente debería ser eliminado.

Bien, así que ese fue el ciclo de vida. La gran conclusión allí, por supuesto, nuevamente, es esta gestión de flags obsoletos, probablemente la parte más difícil sobre los feature flags a escala, para ser honesto. Ahora hablemos sobre la tercera pared, que es la arquitectura. Y la arquitectura va a tener dos partes. La primera será pruebas, y luego la segunda estará más enfocada en infraestructura. Así que las pruebas son realmente interesantes con los feature flags. Y por interesantes, quiero decir realmente difíciles. Y eso es debido a la explosión combinatoria. ¿Qué quiero decir con explosión combinatoria? Bueno, con cinco flags Booleanos, lo cual, correcto, eso es bastante simple. Cinco flags Booleanos encendidos o apagados, ya tienes 32 combinaciones. Si subes a 20 flags que son solo encendidos o apagados, eso es más de un millón de combinaciones. Y el problema es, también, si tienes un millón de combinaciones en tu base de código, ¿cómo vas a probar todas esas combinaciones? Incluso si esas tomaran solo un segundo por prueba, eso aún serían 12 días de pruebas continuas. Simplemente no es posible. Así que el gran problema es cómo lidiar con este hecho de que con más feature flags, especialmente feature flags que son más complejos, imagina si no fueran flags Booleanos, sino que tuvieran una lógica mucho más compleja asociada a ellos, ¿cómo vas a probarlo? Bueno, la verdad del asunto es que no puedes probar cada combinación. Simplemente no es físicamente posible. Así que las recomendaciones aquí son las siguientes. Así que la primera es probar rutas críticas. ¿Y qué significa eso? Básicamente, esas rutas que sabes son esenciales para el funcionamiento de tu aplicación, esas son las rutas que quieres probar primero. Esto tiene sentido, pero es solo algo a tener en cuenta. El otro lado de eso es también probar estados de producción. Así que piensa en esto con esos 20 flags, si hay una cierta configuración encendida y apagada de cada uno de esos flags que va a ser más prevalente en producción, esa es obviamente una configuración que quieres probar y asegurarte de que eso sea parte de, ya sabes, las pruebas en el futuro. Otra forma en que puedes abordar esto, que se está volviendo más y más común para cada proveedor de feature flags, es hacer algo que llamamos implementaciones seguras, y podría tener diferentes nombres, pero la idea aquí es que cada característica que lanzas con un feature flag que adjuntas básicamente una prueba EB a ella que te permite verificar algún tipo de tasa de fallos. Si esa tasa de fallos se activa, entonces la característica se revierte automáticamente. Por ejemplo, cómo funcionaría esto, digamos que estás probando una nueva característica de flujo de pago. Dirías que si la tasa de fallos del pago supera algún tipo de porcentaje, entonces revierte automáticamente esta característica. Esto te permite tener algo de tranquilidad cuando estás usando un feature flag con una nueva característica que obtienes este retroceso automático si las cosas van mal, y, por supuesto, a veces lo harán. Otra gran herramienta para buscar en tu plataforma de feature flags es algún tipo de herramienta que te permita mirar la aplicación real y simular diferentes estados de feature flags, estados de experimentos, y te mostraré un video de esto. Esto se vuelve realmente útil para mirar, bueno, si tengo este tipo de usuario o este tipo de atributo, ¿cómo va a funcionar realmente el flag en la aplicación? Si tienes una herramienta que te permite hacer esto fácilmente, te permite detectar muchos errores antes de la producción, o si tienes un error en producción, hace mucho más fácil depurar lo que está pasando. Y luego dos más fáciles, minimizar el anidamiento y las dependencias. Puedes entrar en una situación donde un flag va a depender del resultado de otro, y así deberías seguir simplemente buenos principios para el código donde estás modularizando cosas, tratando de minimizar ese anidamiento y dependencia tanto como sea posible.

Simplemente, por supuesto, va a facilitar las pruebas. Y luego, nuevamente, solo para realmente enfatizar este punto, que eliminar flags obsoletos es la mayor prioridad. Así que déjame mostrarte, sin embargo. Este es un ejemplo aquí de esas dev tools de las que estaba hablando. Así que esta es una app que tenemos, una app de café, y te permite probar estas dos variaciones de un experimento justo en la página aquí, y es realmente agradable ver eso en acción. Lo reproduciré una vez más solo para que puedas ver de nuevo. Así que es una extensión de Chrome aquí arriba que abres. Muestra los experimentos que están activos en la página, y luego te permite alternar entre las variaciones. Así que puedes imaginar si tienes diferentes feature flags, puedes mirar directamente en tu app cómo están funcionando. Así que esta es una manera realmente agradable de hacer eso.

Bien, así que cambiemos ahora a la arquitectura. Y creo que esto es realmente importante para las personas que están construyendo apps del lado del cliente, así que específicamente tus frameworks de JavaScript que son cualquier tipo de renderizado del cliente. Este es un gran problema con el que se encuentran los equipos. Así que esta es la evaluación tradicional de flags del lado del cliente. Así que imagina que estás ejecutando una prueba A-B con un feature flag, y así ese estado por defecto se va a servir primero al usuario, y luego, basado en cualquier atributo que esté en esa prueba A-B, entonces renderizará esa variación. Así que va a haber un parpadeo de contenido. Estoy seguro de que todos lo han visto, donde el estado base se renderiza a la variación, y eso es realmente una mala UX para el usuario porque va a tener algún tipo de salto en la página, y hay diferentes maneras de mitigar eso, pero aún así no va a ser ideal. Y el otro mal resultado allí es que vas a tener una caída en el seguimiento de eventos, que es solo parte de una app del lado del cliente. Déjame mostrarte un ejemplo de esto de nuestro propio sitio web. Así que esta es una prueba A-B que estamos ejecutando.

Y déjame hacer una pausa aquí. Así que esta es nuestra página de inicio, y puedes ver que tenemos esta gran imagen aquí de la app, una captura de pantalla de ella. Y lo que estamos probando, tenemos una prueba A-B en ejecución, donde si reducimos el tamaño de esto, y déjame mostrarte en realidad solo lo que será esto, y en su lugar mostrar algo de esta prueba social, entonces eso aumentará las conversiones. Pero estos son los valores predeterminados, y esta es la variación. Y lo que verás aquí cuando reproduzca el video es que salta. Así que esto probablemente no sea muy notable para un usuario, pero hace que toda la página se desplace hacia arriba. Tiene algo de ese jank que odiamos. Y así hay una mejor manera de abordar este problema. Y esto es algo que espero que se vuelva más y más común con los feature flags en el futuro. La mayoría de las plataformas ya ofrecen algo en esta línea, y eso es la evaluación de flags en el Edge en el renderizado. Y esto es realmente genial. Así que lo que sucede es que en lugar de que el renderizado ocurra en el navegador del cliente, ocurre en el Edge. Y lo que eso significa es que obtienes dos grandes beneficios aquí, es que no obtienes ese parpadeo porque la página completamente renderizada, la página hidratada, se envía directamente al usuario, por lo que nunca ven ese estado de control. Así que no hay jank, la experiencia es mucho mejor. Y el otro gran beneficio es que tu seguimiento de eventos es mucho más seguro porque está ocurriendo desde el Edge en lugar de desde la máquina del cliente, desde el navegador del cliente. Así que obtienes un montón de beneficios. Y cuando hicimos nuestras pruebas, comparando esa configuración solo de navegador con el renderizado en el Edge, la diferencia en el tiempo desde el renderizado inicial hasta la variante fue simplemente, como, increíblemente acelerada en el Edge. Así que puedes ver los números aquí, 530 milisegundos de renderizado inicial, tiempo a variante 390 milisegundos, obtienes ese terrible parpadeo de contenido, mientras que con el Edge, obtienes 150 milisegundos, 150 milisegundos, sin parpadeo. Es simplemente el camino a seguir para echar un vistazo.

Bien, así que esa es la arquitectura, la tercera pared que encontrarás. Y lo que realmente quiero que te lleves de esto es que el mejor momento para comenzar a pensar en la gestión de tus feature flags y lo que vas a hacer es ahora, por supuesto. Si ya te lo estás preguntando, probablemente sea el momento. Y lo que hemos encontrado es que los equipos que abordan esta deuda de flags temprano son cinco veces más exitosos que los equipos que esperan. Simplemente tiene sentido que si te adelantas, va a ser genial. Así que aquí está lo que puedes hacer en las próximas semanas para comenzar a pensar en esto seriamente. En tu primera semana, encuentra tus flags e identifica aquellos que están desactualizados o en caminos críticos. Este es ese problema de visibilidad del que hablé. Si puedes comenzar a echar un vistazo a los flags, averiguando cuáles son importantes y necesitan ser revisados, ese es un gran primer paso. Y la próxima semana, comienza a pensar en una convención de nomenclatura que puedas compartir con tu organización, junto con algunas de las mejores prácticas de las que hablé. Esa es una manera fantástica de dar mucha visibilidad a tus feature flags y ayudar a todos a saber qué está pasando con ellos.

Semana tres, comienza a configurar algunos de los sistemas de los que hablamos, como la detección de flags obsoletos, saber automáticamente cuándo un flag está obsoleto. Configura gráficos de código para saber dónde está tu código, dónde están viviendo tus flags en tu base de código. Y comienza a pensar en la evaluación en el edge, si eso es algo que deseas hacer para las apps de tus clientes. Y finalmente, si te sientes realmente audaz, prueba esta limpieza automatizada para PRs, esa herramienta Piranha que Uber desarrolló. Así que realmente puedes reducir tus flags obsoletos. Y luego piensa en hacer revisiones mensuales de flags. Esto es algo que ha sido realmente útil.

Así que al igual que podrías tener una sesión donde miras tus vulnerabilidades de seguridad o tal vez miras las actualizaciones de diferentes paquetes que necesitas hacer, trata los feature flags de la misma manera, ten una revisión mensual donde digas, bueno, han pasado tres meses desde que este flag está en la base de código. La característica ha sido implementada. ¿Por qué sigue ahí? ¿Todavía lo necesitamos? Comenzar a hacer estas cosas tendrá un gran impacto en tu organización y te preparará mejor para escalar los feature flags.

Así que te dejo en esta encrucijada. Podrías estar en el camino A donde no sabes qué están haciendo tus flags, y eres como ese grupo de capital nocturno donde estás a cientos de millones de dólares de un desastre o estás a minutos de un desastre, o puedes estar en el camino bien gestionado y ser visible, gobernado y rápido. Muchas gracias. No dudes en ponerte en contacto si quieres hablar sobre feature flags o cualquier otra cosa en la vida. Soy Ryan en growthbook.io. Sí, que tengas un buen día.