Descubrir al desconocido no conocido

Meta cuenta con un ecosistema de productos que miles de millones de usuarios utilizan cada día, ya sea para establecer conexiones sociales o interactuar con empresas. Dichos usuarios también nos piden que ofrezcamos nuevas funcionalidades y mejoras de nuestros productos de forma continua y rápida. Debido a nuestra amplia base de usuarios, implementamos miles de cambios en los códigos todos los días para satisfacer sus expectativas.

Publicar de forma continua una cantidad tan elevada de mejoras en los productos facilita que se puedan producir regresiones en el estado de las aplicaciones que, a su vez, pueden provocar una degradación en la experiencia del usuario. En Meta contamos con una superposición sofisticada de herramientas de prevención para proteger contra la publicación de cambios defectuosos en los productos. Estas herramientas de prevención supervisan varias señales de los productos y detectan regresiones antes de que las aplicaciones se publiquen. Estas señales abarcan tres áreas: el rendimiento, la fiabilidad (funcional y sistémica) y la eficacia. En conjunto, estas áreas se conocen como las “PRE” de los productos. La prevención comienza con varias señales de análisis y observabilidad que se obtienen mientras los desarrolladores crean el código. Además, las herramientas de observabilidad y supervisión recogen datos del uso interno de los productos en los entornos de preproducción. Herramientas de control de calidad tanto manuales como automatizadas prueban los productos en dichos entornos de preproducción.

Y, aunque estos mecanismos existen para evaluar la calidad de los cambios en el código antes de la etapa de producción (y, por lo tanto, evitar el impacto en el usuario), puede ocurrir que cambios que afectan a los usuarios lleguen a la fase de producción y haga falta modificarlos y volver a enviarlos a dicha fase. A fin de reducir la posibilidad de que un problema afecte a una gran cantidad de usuarios, utilizamos varios mecanismos para lanzar los cambios al público de manera gradual.

Llamamos regresión a la desviación que se produce respecto a la funcionalidad que el usuario espera recibir. Usamos la palabra “señal” para indicar que los usuarios nos comunican que algo no cumple sus expectativas. Recogemos las señales de regresión tan pronto como nos es sistémicamente posible mediante insights de datos y código instrumentado, y luego trabajamos para reducir el impacto en el usuario implementando correcciones. En los casos en los que no recibimos una señal fuerte por parte de nuestras herramientas, dependemos de los informes de los usuarios como señal de que se ha producido una regresión. Estos informes provienen de varios mecanismos, por ejemplo cuando los usuarios sacuden el teléfono para informar de un problema en el contexto donde se encuentran en la aplicación cuando dicho problema ocurre.

A fin de garantizar que satisfacemos las necesidades de nuestros clientes lo más rápido posible (a veces, el mismo día), Meta ha realizado grandes inversiones en varios programas y sistemas relacionados con la fiabilidad para permitir una respuesta considerable a gran escala.

Las señales pueden provenir de nuestros usuarios públicos (individuos, empresas, grupos, etc.) o de usuarios internos. Revisamos cuidadosamente las señales de los usuarios internos para evitar que cambios no deseados lleguen a producción. Ten en cuenta que las señales son agregados; por ejemplo, hay señales que incluyen el número de errores por millón de usuarios. Las señales también pueden provenir de herramientas y escenarios de prueba automatizados, herramientas de desarrollo (advertimos a los desarrolladores sobre cambios que pueden causar problemas en los tiempos de ejecución), registros del sistema y muchos otros orígenes. También contamos con herramientas que aprovechan estas señales para identificar rápidamente las causas y las correcciones apropiadas.

Una vez que se detecta una regresión, procedemos a designar rápidamente a los ingenieros más adecuados para que apliquen las correcciones y las publiquen. En función de la complejidad de la regresión, empleamos una serie de métodos para identificar a los ingenieros apropiados, entre los que se incluye aprovechar los conocimientos de Meta en el aprendizaje automático. Debido al funcionamiento del aprendizaje automático, se trata de un proceso continuo a medida que lanzamos nuevas funciones y reentrenamos nuestros modelos para seguir el ritmo a los constantes cambios.

Y sí, existe un objetivo final: pasar de detectar regresiones a mitigarlas, prevenirlas y contenerlas de forma sostenible. En el proceso, maximizamos la respuesta, el retorno de la inversión y la eficacia.

En la siguiente sección, hablaremos con más detalle sobre cómo determinamos con certeza que se ha producido una regresión y cómo respondemos.

Transformar los desconocidos en conocidos y cuantificarlos

Cuando hablamos de un desconocido, nos referimos a un error que un usuario o sistema experimenta. Podemos enterarnos de un posible error a través de orígenes distintos.

• Pruebas sintéticas del correcto funcionamiento de nuestras aplicaciones y de productos específicos en dichas aplicaciones.
• Usuarios internos que realizan pruebas en busca de errores. Esto puede incluir a nuestros equipos de pruebas dedicados o a la amplia base de usuarios de Meta.
• Usuarios externos que experimentan un problema y usan el cuadro de diálogo de informe de errores de nuestras aplicaciones.

Estos errores son desconocidos hasta que se marcan como incidencias que los usuarios están experimentando. Cuando la cantidad de dichos informes de errores supera un umbral determinado, los consideramos un positivo verdadero, lo que representa un evento de regresión: un cambio en el código ha creado un nuevo error y debemos proceder a mitigarlo rápidamente. Existen dos tipos principales de informes:

• “Desconocidos conocidos”: cuando el código instrumentado detecta la regresión e informa al respecto; tenemos una serie de herramientas que ayudan a generar esta señal.
• “Desconocidos no conocidos”: cuando la regresión no se ha detectado de forma interna y dependemos de que el usuario nos informe al respecto.

Además, las regresiones pueden pertenecer a varias categorías; por ejemplo, si son errores en el código, si se parecen más a spam o si representan cualquier otra infracción de la política de contenido. Nosotros nos centramos en la primera categoría, ya que nuestro objetivo es resolver problemas en la experiencia del usuario relacionados con el código. ¿Cómo lo conseguimos si los usuarios informan de miles de errores?

Generar señales e insights

Para administrar los grandes volúmenes de informes, generamos señales específicas que marcan los problemas por nosotros. El primer tipo de señal es la que, a partir de unos umbrales correctamente definidos, nos informa de que ha ocurrido una incidencia o una regresión. Ten en cuenta que es posible que se hayan producido varios eventos en función del tipo de regresión. Por ejemplo, es posible que una regresión afecte a varios productos debido a un código base común. Buscamos tales coincidencias y las tratamos como una única incidencia para asignar los recursos de la forma más óptima posible. El gráfico que aparece a continuación es un ejemplo de cómo podemos visualizar las desviaciones de la línea de tendencia que indican una regresión.

Luego, recogemos señales adicionales, algunas de las cuales indican el tipo de regresión al que podemos enfrentarnos. Estas señales provienen de algoritmos de aprendizaje automático definidos para productos de Meta específicos y nos proporcionan insights sobre los síntomas asociados a la regresión. Los algoritmos analizan los informes de los usuarios para determinar la causa de la regresión y, por lo tanto, qué equipo de ingeniería puede gestionarla mejor mediante una corrección en el código u otra medida.

También se generan muchas otras señales en función de los datos de registro obtenidos. Estos registros de diagnóstico pueden ser del lado del cliente o del lado del servidor y se recogen (con el permiso de los usuarios) para ayudar a determinar la causa de la regresión. Las aplicaciones incorporan los procesos de consentimiento apropiados para poder determinar si se puede obtener este tipo de datos en función de los permisos concedidos por el usuario. También tenemos en cuenta la antigüedad de los datos con el fin de cumplir con las normativas aplicables.

La combinación de las distintas señales nos permite identificar la regresión y asignarla al equipo de producto adecuado para mitigar el problema rápidamente y restaurar la experiencia de usuario esperada.

Los insights también se derivan de las observaciones en conjunto. Revisamos los datos para encontrar causas comunes y determinar si se debe realizar algún cambio para prevenir que las regresiones se repitan. Hacerlo es un aspecto clave para tener un enfoque sólido a la hora de abordar los problemas relacionados con la experiencia de usuario, ya que nos ayuda a minimizar la ocurrencia de regresiones con el tiempo.

Nuestras aplicaciones para móviles no solo incluyen rutas de navegación para que los usuarios informen de un problema, sino que también ofrecen la posibilidad de indicar un problema sacudiendo el dispositivo. De esta forma, se puede obtener telemetría contextual. Dicha telemetría se complementa con señales de Black Box procedentes de la aplicación. Black Box es como un registrador de vuelo que captura automáticamente determinados registros (según los permisos concedidos por los usuarios) sobre lo que hacía la aplicación cuando se informó del error para que podamos diagnosticar mejor el problema.

Toda esta telemetría se integra en un conjunto de vistas cronológicas para ayudar a los equipos de ingeniería a determinar la causa del problema. Debido a la rápida cadencia de lanzamiento de nuestras aplicaciones, así como a los cambios en los componentes de aplicaciones del lado del servidor, identificar el problema sería difícil sin esta función. Con el tiempo, disponer de dicha telemetría nos ayuda a detectar patrones en las regresiones que nos ayudan a evitarlas en el futuro.

Reducir la superficie de regresión de los productos

Al haber mejorado nuestra capacidad para generar señales más precisas, podemos atacar una superficie de regresión mayor, incluidas partes de la misma que no se habían detectado anteriormente. Una superficie representa una oferta específica de un producto, como la sección de noticias o los Reels. Esto supone un reto porque los productos no solo tienen multitud de funciones diferenciadas, sino que también se añaden nuevas funciones a menudo. Por tanto, además de ser grande, la superficie de regresión crece con el tiempo. Y por este motivo, nuestras estrategias defensivas y ofensivas deben adaptarse continuamente.

Para poder reducir la superficie de regresión, deben cumplirse una serie de condiciones:

1. Debemos contar con una cobertura precisa y una clasificación apropiada de las superficies de los productos existentes.
2. Debemos reducir la superficie de regresión de los productos existentes (es decir, prevención).
3. Debemos ampliar el alcance de nuestros algoritmos a las nuevas superficies de productos.

Si no se cumplen estas condiciones, corremos el riesgo de tener un sistema sobrecargado que no se pueda administrar debido a su tamaño, complejidad e imprecisión. Nuestros esfuerzos se centran en mantener ese equilibrio y, al mismo tiempo, realizar nuestras operaciones cotidianas de forma eficiente.

Ir más allá de los errores

A medida que seguimos reduciendo la superficie de regresión (sin bajar nunca la guardia), reforzamos nuestra atención en otras áreas importantes: la prevención y la usabilidad.

La prevención se centra en lo siguiente:

1. ¿Cómo aprendemos de regresiones anteriores?
2. ¿Qué defensas implementamos para que dichas regresiones no vuelvan a producirse?
3. ¿Cómo nos aseguramos de que la superficie de regresión siga reduciéndose con el tiempo?

Como hemos mencionado anteriormente, agregamos datos de regresiones anteriores para aprender de ellos. Este aprendizaje se puede traducir en lo siguiente:

1. Colocar marcadores en el código para que nos alerten en el futuro durante la fase de preproducción y así poder evitar que un cambio no deseado llegue a producción.
2. Aumentar la cobertura de las pruebas en varios niveles para detectar tales regresiones.
3. Cambiar el propio producto para hacer frente a estos problemas.

La prevención nos ayuda a adelantar cada vez más las regresiones en el ciclo de desarrollo y, por lo tanto, a seguir reduciendo costes. Esto se consigue al obtener señales suficientemente detalladas en una fase más temprana del proceso de desarrollo, empezando por la creación del código y los ciclos de lanzamiento previos a la producción. Así, no solo se mejora la experiencia de usuario, sino que también se reducen los costes de desarrollo y nos permite destinar recursos al desarrollo de nuevos productos.

Mejorar nuestra habilidad para hacer frente a las regresiones de forma más eficiente nos permite centrarnos más en problemas de confusión del usuario o usabilidad. Se trata de cuestiones importantes, ya que se centran en mejorar los productos en lugar de corregirlos. Con el tiempo, la proporción de problemas de usabilidad debería aumentar con respecto a las regresiones y el número total de problemas de usabilidad y regresiones debería disminuir.

A fin de cuentas, el resultado es una experiencia de usuario que mejora continuamente tanto en funcionalidad como en facilidad de uso.

Este artículo se ha escrito en colaboración con Bijan Marjan, responsable técnico de programas en Meta.