Cómo redujimos los errores en GOV.UK

Este artículo fue escrito por Chris Ashton y [Tim Motz](https://technology.blog.gov.uk / autor / tim-motz-product-manager-gds /). Este artículo se publicó por primera vez en el Blog de Tecnología en el Gobierno GOV.UK. Puede leer el artículo original aquí .

Como todos los sitios web, GOV.UK a veces experimenta dificultades técnicas. Estos pueden ser causados por errores en el código, entradas inesperadas, carga pesada del sistema o cualquier combinación de los anteriores. Problemas como estos son inevitables. Lo que podemos controlar es cómo los detectamos y resolvemos rápidamente.

__ • ¿Quiere escribirnos? Eche un vistazo a la [guía para colaboradores] de Apolitical (https://apolitical.co/opinion-writing-becoming-an-apolitical-contributor/) __

En los últimos meses, hemos reducido nuestro recuento de errores en más del 90%. Esto ya nos ha permitido descubrir nuevos problemas que antes se perdían en el ruido. También hemos mejorado la experiencia del desarrollador mediante la integración de informes de errores con Slack y mejorando nuestra documentación. Nos hemos comprometido con otros equipos para fomentar un enfoque dirigido a las alertas de Slack, a fin de mantener bajo nuestro recuento general de errores.

Cómo rastreamos los errores

En GOV.UK, hacemos un seguimiento de los errores mediante un servicio externo llamado Sentry. Esta es una plataforma de monitoreo que registra cosas inesperadas que ocurren en GOV.UK. Nos brinda información detallada para cada evento, y esto permite a los desarrolladores de GOV.UK determinar cuál es el problema y cómo resolverlo. Hay otras herramientas de monitoreo disponibles; para obtener una explicación de por qué elegimos Sentry, consulte esta [discusión sobre GitHub](https://github.com/alphagov/govuk-rfcs/blob/main/rfc-070-path-towards-continuous-deployment-cd.md # cambiar-nuestro-marco-de-notificación-de-errores).

Descubrimos que recibíamos una cantidad extremadamente alta de errores cada semana, lo que dificultaba la navegación en Sentry. La gran cantidad de errores también significó que Sentry no estaba almacenando todos los errores que estábamos enviando, ya que hay un límite en la cantidad de eventos que Sentry permitirá por hora. Los eventos que superan el umbral se descartan ("tasa limitada"), lo que no proporciona a los desarrolladores información para continuar y, en el peor de los casos, no hay indicios de que haya un problema en absoluto.

Necesitábamos reducir nuestro recuento de errores en Sentry para llevarnos por debajo del límite de velocidad y asegurarnos de que pudiéramos detectar y resolver nuevos problemas lo más rápido posible. Esta publicación de blog explica los 3 pasos que tomamos para hacer esto y cómo redujimos nuestro recuento de errores en más del 90%.

Qué queríamos mejorar

Si bien GOV.UK parece un único sitio web, en realidad está formado por más de 50 aplicaciones frontend y backend que se alojan y mantienen de forma independiente. Durante gran parte de 2020, registramos regularmente entre 100.000 y 200.000 errores semanales en estas aplicaciones. Esto suena extremadamente alto, pero muchos de ellos podrían atribuirse a un puñado de "problemas" distintos. Sentry agrupa los eventos en problemas, lo que facilita la cuantificación de la frecuencia con la que ocurre el problema. También es posible escribir comentarios sobre problemas y asignar problemas a los desarrolladores.

La gran cantidad de problemas hizo que Sentry fuera ruidoso. Esto no fue ayudado por el hecho de que muchos de los problemas parecían estar duplicados, y los problemas con el mismo título aparecían varias veces en la lista. Queríamos investigar cómo Sentry agrupa sus problemas para ver si podíamos configurarlo para hacer un mejor trabajo.

La gran cantidad de problemas se vio agravada por tener una cuenta GOV.UK Sentry compartida para todos nuestros entornos. Un problema en un entorno de prueba podría hacernos superar el límite de velocidad y, por lo tanto, dificultar el registro en la producción. Es fundamental que reduzcamos la cantidad de eventos que enviamos para que permanezcan por debajo del umbral, de modo que los problemas no se pierdan en el sistema.

Finalmente, necesitábamos una estrategia preventiva para evitar que el número de eventos volviera a aumentar.

Investigando agrupación centinela

De forma predeterminada, Sentry agrupa los problemas por seguimiento de pila, y si no hay seguimiento de pila disponible, también mire el tipo / mensaje de excepción. Sin embargo, Sentry también le permite personalizar la forma en que agrupa los problemas al especificar su propio algoritmo de huellas digitales, o cambiar la configuración en la interfaz de usuario.

Investigamos si la agrupación personalizada sería beneficiosa, auditando todos los problemas no resueltos y considerando cuáles deberían agruparse. Nuestra auditoría mostró que muchos de los problemas que parecían duplicados en realidad se referían a diferentes controladores y plantillas, por lo que de hecho eran problemas separados, incluso si parecían similares.

La auditoría destacó un problema: algunos problemas duplicados resultaron de [actualizaciones de dependencia] inofensivas (https://www.gapintelligence.com/blog/application-dependencies-when-and-why-to-upgrade-them/), porque el La estructura de archivos de la dependencia cambiaría ligeramente, cambiando el seguimiento de la pila (que Sentry usa para agrupar problemas). Realmente, estos "rastros de marco" no son muy útiles para la agrupación de problemas; lo que nos importa es el "seguimiento de la aplicación".

Es posible "limpiar" el seguimiento de la pila antes de enviarlo a Sentry, pero hacerlo haría que el seguimiento de la pila original nunca se registre, perdiendo información de diagnóstico valiosa. Hemos planteado una solicitud de función con Sentry para usar solo el seguimiento de la aplicación para la agrupación de problemas, sin dejar de registrar el seguimiento de la pila completa.

Llegamos a la conclusión de que, a fin de cuentas, el algoritmo de agrupación predeterminado de Sentry funciona bastante bien para nosotros.

Reducir los eventos enviados a Sentry

En resumen, estábamos registrando demasiados errores, lo que significaba que no teníamos visibilidad de los errores que ocurrieron por encima del límite de velocidad.

Creamos un panel de Grafana para monitorear nuestros errores en Sentry a lo largo del tiempo, de modo que pudiéramos medir qué tan bien estábamos abordando el problema. También creamos un panel separado para los errores en la que era nuestra aplicación que más errores producía.

Esta aplicación registraba constantemente casi 15.000 errores en Sentry todos los días. Aunque el volumen es alto, la mayoría de los errores se atribuyeron a un solo problema, que solo parecía ocurrir durante la [sincronización de datos] nocturna (https://docs.publishing.service.gov.uk/manual/govuk-env- sync.html).

Todas las noches, todo el contenido de GOV.UK se copia en nuestros entornos de preparación e integración. Esto se logra eliminando y volviendo a crear bases de datos, lo que significa que algunos servicios en estos entornos pueden no estar disponibles temporalmente y cualquier intento de realizar una llamada a ellos da como resultado un error. Estos errores particulares son inofensivos, esperados e inaccesibles, por lo que queríamos evitar que se registraran en Sentry.

Decidimos implementar una nueva opción de configuración: una lista de tipos de excepción que deberían ignorarse si ocurrieron durante la sincronización de datos. Esto se agregó a nuestro módulo GovukError, que nuestras aplicaciones utilizan para interactuar con Sentry. El efecto fue inmediato: los errores en la aplicación que más errores producían se redujeron en un 98%.

Una aplicación registró consistentemente casi 15,000 errores por día hasta que aplicamos una solución que casi los eliminó de la noche a la mañana (Gráfico: Gobierno del Reino Unido)

Continuamos auditando Sentry, escribiendo los problemas más prolíficos para los desarrolladores en el [equipo de salud de la plataforma](https://insidegovuk.blog.gov.uk/2019/03/27/why-we-created-a-platform- health-team-on-gov-uk /) para trabajar y luego 'ignorar' el problema en la interfaz de usuario de Sentry. Esto significaba que los errores aún se estaban registrando, pero ya no eran tan visibles, lo que ayudó a reducir el ruido y nos permitió detectar nuevos problemas a medida que surgían. "Resolveremos" el problema una vez que solucionemos el problema: este es un mecanismo útil ya que Sentry envía un correo electrónico al solucionador del problema si el problema vuelve.

Con el tiempo, resolvimos los problemas de mayor volumen e hicimos otras mejoras en nuestra configuración predeterminada, como solo permitir errores de entornos particulares. También nos volvimos más particulares sobre lo que debería registrarse en Sentry, solo permitiendo errores del sistema procesables, y no, por ejemplo, los errores causados por el usuario.

Logramos llevar nuestro recuento general de errores muy por debajo del umbral límite de velocidad. Nuestra mejor semana fue en marzo de 2021, donde registramos solo 5.500 errores; una reducción significativa de los más de 100.000 errores que veíamos de antemano con regularidad.

Ahora teníamos que empezar a pensar en una estrategia preventiva para evitar que los recuentos de errores volvieran a aumentar.

Estrategia preventiva

Si bien todos nuestros desarrolladores tienen acceso a Sentry, normalmente solo inician sesión en Sentry durante un [incidente](https://insidegovuk.blog.gov.uk/2015/11/18/what-happens-when-things-go-wrong -on-gov-uk /) o para vigilar el estado de una aplicación durante la implementación. Esto hace que sea fácil que los nuevos problemas aparezcan sin ser detectados.

Sentry tiene una integración de Slack que envía notificaciones cuando ocurren eventos, de acuerdo con las [reglas de alerta] configuradas (https://docs.sentry.io/product/integrations/ slack / # alert-rules). Creamos una alerta para notificarnos cuando ocurre un problema más de 100 veces en el espacio de 60 minutos. Descubrimos que esto logra el equilibrio adecuado, ya que prioriza nuestros peores errores y evita el envío de spam al canal. Esperamos reducir gradualmente este umbral para poder resolver la "cola larga" de los problemas.

Un problema con estas notificaciones es que no están dirigidas: dependen de que alguien supervise el canal y se haga cargo del problema. Muchos problemas surgen como resultado de cambios de código realizados fuera de nuestro equipo, y sería mucho más eficiente notificar directamente al equipo o al desarrollador responsable del cambio. Por lo tanto, estamos alentando a otros equipos en GOV.UK a configurar sus propias alertas de Slack para las aplicaciones en las que trabajan regularmente, lo que esperamos evitará la introducción de la mayoría de los errores nuevos.

Próximos pasos

A corto plazo, esperamos mejorar las alertas de producción que avisan a nuestra segunda línea y a los desarrolladores de guardia cuando algo en GOV.UK necesita una respuesta urgente. Más allá de esto, estamos pensando en cómo podríamos introducir más observabilidad en GOV.UK: [recientemente presentamos Real User Monitoring](https://insidegovuk.blog.gov.uk/2021/06/16/how- real-user-monitoring-will-better-gov-uk-for-Everyone /), y están considerando opciones como Application Performance Management. Nuestro proyecto de remodelación en curso presenta una gran oportunidad para diseñar estos procesos desde cero. — Chris Ashton y Tim Motz

__Queremos escuchar lo que piensa sobre este artículo. Envíenos un artículo o envíenos sus comentarios a [discusion@apolitical.co](mailto: discusion@apolitical.co) __

(Crédito de la imagen: Unsplash)