Video Summary and Transcription
Los feature flags se pueden utilizar para mitigar el riesgo en el desarrollo de software mediante la alteración de la visibilidad de las características para los usuarios finales. Mediante el uso de flags, puedes protegerte contra puntos únicos de fallo y cambiar a un servicio de respaldo en los peores escenarios. La monitorización y gestión de la complejidad es crucial, y el uso de feature flags permite cambios dinámicos y ajustar valores basados en la corrección comprobada. Operar en lo desconocido es inevitable en el desarrollo de software, por lo que es importante gestionar la complejidad y abrazar el aprendizaje. La colaboración es clave para hacer que las fallas en las características sean menos dolorosas.
1. Introducción a las banderas y mitigación de riesgos
Hola a todos en React Advanced. Soy Jessica y voy a hablarles sobre cómo pueden usar las banderas para mitigar el riesgo en su desarrollo de software. Las banderas de características se utilizan típicamente para alterar la visibilidad de una característica para los usuarios finales. Se pueden utilizar para pruebas, implementar características para un subconjunto de usuarios y más. En LaunchDarkly, podemos utilizar banderas basadas en diferentes tipos de datos, lo que le permite mitigar el riesgo en escenarios complejos.
Hola a todos en React Advanced. Espero que estén pasando un buen rato. Soy Jessica y voy a hablarles sobre cómo pueden usar las banderas para mitigar el riesgo en su desarrollo de software. Así que, empecemos.
Probablemente ya hayan escuchado hablar de las banderas de características que resuelven problemas relacionados con el lanzamiento, ¿verdad? Y a menudo se utilizan en estos escenarios de derechos, cambiando lo que está disponible para ciertos usuarios. Y típicamente se utiliza en ese tipo de estado booleano. Tomamos una característica, la envolvemos en una bandera y eso se convierte en nuestro punto de control dentro de nuestro código, lo que nos permite alterar su visibilidad para nuestros usuarios finales. La característica está visible o no lo está. Está activada o desactivada. Y una vez que hemos validado los cambios en producción y estamos seguros de que nuestra característica puede estar activada para el 100% de nuestra audiencia, eliminamos la bandera. Ese es el ciclo de vida típico que vemos con las banderas.
Como saben, esto es súper útil cuando se trata de, por ejemplo, previsualizar características para testing y producción sin llegar a nuestros usuarios finales o para implementar características dirigidas a solo un subconjunto de nuestra base de usuarios. Pero ¿qué pasa si el problema que estamos tratando de resolver requiere más que un simple cambio de estado binario o una prueba A-B? En LaunchDarkly, cuando hablamos de banderas, no nos referimos simplemente a dos estados. En realidad, podemos manejar todo un espectro de etapas en su proceso de lanzamiento. Podemos utilizar banderas basadas en un número, una cadena. Incluso tenemos banderas JSON. Y eso le permite mitigar el riesgo en estos escenarios más complejos. Una válvula de seguridad es una bandera a largo plazo que se puede utilizar para degradar la funcionalidad no crítica de sus aplicaciones y servicios.
2. Banderas para la mitigación de riesgos
Es importante protegerse de los puntos de falla únicos y mitigar el riesgo mediante el uso de banderas. Al señalar los posibles puntos de falla, se puede crear un sistema que le permita cambiar a un servicio de respaldo en los peores escenarios. Esto le ayuda a retroceder de manera elegante y mantener la disponibilidad, incluso en presencia de actores malintencionados. Cambiar las banderas puede mantener la estabilidad en línea y proporcionar agilidad para resolver problemas. La implementación en etapas y el uso de banderas garantizan una solución que se puede aplicar a toda su base de usuarios. Las banderas le brindan certeza y la capacidad de operar desde una única versión de la verdad. Es crucial tener cuidado al implementar en entornos complejos.
En última instancia, esto le ayuda a mantener la disponibilidad de todas sus aplicaciones. Y es muy común, como todos sabemos, depender de servicios y proveedores externos. Pero las cosas comienzan a ponerse preocupantes cuando hay un único punto de falla en su entrega. Bueno, ¿por qué no protegerse? Reduzca el riesgo de ese elemento. Al señalar ese punto, podría crear efectivamente un sistema que le permita cambiar a un servicio de respaldo, en caso de que ocurra el peor escenario, que sabemos que a menudo ocurre, desafortunadamente. Lo siento.
Esto le brinda la capacidad de retroceder de manera elegante, sin tener que desconectarse por completo, todo en aproximadamente 200 milisegundos. Está protegiendo su tiempo de actividad, apoyando los objetivos de nivel de servicio de su equipo y todos están mucho más felices. Esto también se puede hacer en caso de actores malintencionados. Digamos que alguien está utilizando su servicio para algo que realmente no debería. Puede aislar ese punto final. Puede devolver un código 404 para ese dispositivo que está actuando mal y todos los demás recibirán códigos 200. En esencia, puede definir cómo degrada. Puede acotar su radio de acción y tomar una decisión sobre cómo retroceder. Por lo tanto, esto es perfecto para escenarios como la reducción de carga o el control manual de ciertos problemas. Este proceso se trata de devolverle el control de una situación que probablemente no anticipó ni solicitó.
Y, por supuesto, cuando hablamos de la resolución de este tipo de escenarios, tomemos la situación en la que una válvula de seguridad puede mantener el tiempo de actividad al retroceder a un estado anterior donde hay un cambio que rompe la compatibilidad. Cambiar una bandera no solo puede ayudarlo a mantenerse en línea, sino que también le brinda la agilidad necesaria para solucionar el problema en cuestión. Utilizando el registro de auditoría y su plataforma de observabilidad, puede identificar el problema, ver cuándo y dónde ocurrió. ¿Cuál fue el cambio que contribuyó a la interrupción? Y cuando su solución esté lista para implementarse, por supuesto, debe estar seguro de que realmente puede llegar a todos sus usuarios. Que es una solución que se puede aplicar a toda su base de usuarios, y no causará más problemas cuando se implemente, porque puede implementar su solución en etapas. Puede implementar su solución en un subconjunto de usuarios al principio y luego implementarla gradualmente en más personas a medida que su confianza aumenta. Las banderas le brindan el regalo de la certeza aquí. Le brinda la capacidad a todos de operar desde una única versión de la verdad. Y ahora que está en línea nuevamente, sus soluciones están disponibles para toda su base de usuarios.
Por supuesto, queremos mantenernos en línea, ¿verdad? A veces es difícil saber si su configuración está realmente lista para funcionar. Puede hacer algunas suposiciones basadas en su plataforma y cómo se comporta en ciertos escenarios. Pero lo cierto es que las suposiciones pueden demostrarse fácilmente incorrectas y las preconcepciones pueden resultar equivocadas. Ya sabe, cuando tiene una miríada de microservicios o se ocupa de procesos que requieren numerosas llamadas de red, a menudo se requiere una sintonización compleja. La mayoría de las veces, debe tener mucho cuidado al implementar.
3. Monitoreo y Gestión de la Complejidad
El monitoreo es crucial para comprender el impacto de la CPU y el rendimiento. Aceptar conjeturas como parte de su flujo de trabajo puede ser beneficioso. Almacenar configuraciones en banderas de características permite cambios dinámicos. Comenzar con suposiciones y ajustar valores basados en la corrección comprobada. Se pueden enviar diferentes configuraciones según las direcciones IP, conjuntos de nodos o métodos. Operar en lo desconocido es inevitable en el desarrollo de software. Debemos gestionar la complejidad y abrazar el aprendizaje. Explorar nuevas posibilidades con protección y confianza adicionales. Colaborar para que las fallas de las características sean menos dolorosas.
El monitoreo puede convertirse rápidamente en tu mejor amigo y te permite tener una idea real del impacto de tu CPU general y el rendimiento que estás incurriendo aquí.
¿Qué tal si aceptamos las conjeturas como parte de nuestro flujo de trabajo? Almacena tu configuración en una bandera de características, y este enfoque te permite cambiar dinámicamente el valor que estás utilizando. Comienzas con tus suposiciones y te diriges hacia un valor más adecuado a medida que tus suposiciones, con suerte, se demuestran correctas o incorrectas a medida que avanzas. Incluso puedes enviar diferentes configuraciones según diferentes direcciones IP, conjuntos de nodos o métodos para llegar a donde quieres llegar.
Y cuando se trata de software, a veces simplemente no se puede evitar operar en lo desconocido. Debemos gestionar la complejidad y siempre estar aprendiendo. Tendremos que aventurarnos en territorio desconocido para descubrir mejores formas de hacer las cosas. Así es como funciona esto. Pero asegurémonos de explorar estas nuevas posibilidades con un sentido de protección y confianza adicionales. Entonces, aunque las características inevitablemente fallarán a veces y las cosas saldrán mal, trabajemos juntos para que sean menos dolorosas. ¿De acuerdo? ¡Gracias por ver!
Comments