Comment nous avons réduit les erreurs sur GOV.UK

Cet article est écrit par Chris Ashton et [Tim Motz](https://technology.blog.gov.uk /auteur/tim-motz-product-manager-gds/). Cet article a été publié pour la première fois sur le Technology in Government GOV.UK Blog. Vous pouvez lire l'article original ici.

Comme tous les sites Web, GOV.UK rencontre parfois des difficultés techniques. Ceux-ci peuvent être causés par des bogues dans le code, des entrées inattendues, une charge système importante ou toute combinaison de ce qui précède. Des problèmes comme ceux-ci sont inévitables. Ce que nous pouvons contrôler, c'est comment nous les repérons et les résolvons rapidement.

• Tu veux écrire pour nous? Jetez un œil au [guide pour les contributeurs] d'Apolitique (https://aphysical.co/opinion-writing-becoming-an-aphysical-contributor/)

Ces derniers mois, nous avons réduit notre nombre d'erreurs de plus de 90 %. Cela nous a déjà permis de découvrir de nouveaux problèmes qui étaient auparavant perdus dans le bruit. Nous avons également amélioré l'expérience des développeurs en intégrant les rapports d'erreurs avec Slack et l'amélioration de notre documentation. Nous nous sommes engagés avec d'autres équipes pour encourager une approche ciblée des alertes Slack, afin de maintenir notre nombre global d'erreurs bas.

Comment nous suivons les erreurs

Chez GOV.UK, nous suivons les erreurs à l'aide d'un service externe appelé Sentry. Il s'agit d'une plate-forme de surveillance qui enregistre les événements inattendus se produisant sur GOV.UK. Il nous donne des informations détaillées pour chaque événement, ce qui permet aux développeurs de GOV.UK de déterminer quel est le problème et comment le résoudre. D'autres outils de suivi sont disponibles ; pour une explication des raisons pour lesquelles nous avons choisi Sentry, consultez cette [discussion sur GitHub](https://github.com/alphagov/govuk-rfcs/blob/main/rfc-070-path-towards-continuous-deployment-cd.md #change-our-error-notification-framework).

Nous avons constaté que nous recevions un nombre extrêmement élevé d'erreurs chaque semaine, ce qui rendait difficile la navigation dans Sentry. Le nombre élevé d'erreurs signifiait également que Sentry ne stockait pas toutes les erreurs que nous envoyions, car il y a un plafond sur le nombre d'événements que Sentry autorisera par heure. Les événements dépassant le seuil sont rejetés (« à débit limité »), ce qui ne donne aux développeurs aucune information sur laquelle continuer et, dans le pire des cas, aucune indication qu'il y a un problème.

Nous devions réduire notre nombre d'erreurs sur Sentry pour nous ramener sous la limite de débit et nous assurer que nous pouvions détecter et traiter les nouveaux problèmes le plus rapidement possible. Cet article de blog explique les 3 étapes que nous avons suivies pour ce faire et comment nous avons réduit notre nombre d'erreurs de plus de 90 %.

Ce que nous voulions améliorer

Bien que GOV.UK ressemble à un seul site Web, il est en fait composé de plus de 50 applications frontend et backend hébergées et gérées indépendamment. Pendant une grande partie de 2020, nous avons régulièrement enregistré 100 000 à 200 000 erreurs hebdomadaires dans ces applications. Cela semble extrêmement élevé, mais bon nombre d'entre eux pourraient être attribués à une poignée de « problèmes » distincts. Sentry regroupe les événements en problèmes, ce qui permet de quantifier facilement la fréquence à laquelle le problème se produit. Il est également possible d'écrire des commentaires sur les problèmes et d'attribuer des problèmes aux développeurs.

Le nombre élevé de problèmes rendait Sentry bruyant. Cela n'a pas aidé par le fait que beaucoup de problèmes semblaient être dupliqués, avec des problèmes avec le même titre apparaissant plusieurs fois dans la liste. Nous voulions étudier comment Sentry regroupe ses problèmes pour voir si nous pouvions le configurer pour faire un meilleur travail.

Le nombre élevé de problèmes a été exacerbé par le fait d'avoir un compte GOV.UK Sentry partagé pour tous nos environnements. Un problème sur un environnement de test pourrait nous faire dépasser la limite de débit et donc entraver la connexion à la production. Il était essentiel que nous réduisions le nombre d'événements que nous envoyions pour rester en dessous du seuil, afin que les problèmes ne se perdent pas dans le système.

Enfin, nous avions besoin d'une stratégie préventive pour empêcher le nombre d'événements de remonter.

Enquête sur le regroupement de sentinelles

Par défaut, Sentry regroupe les problèmes par trace de pile, et si aucune trace de pile n'est disponible, regardez également le type/message d'exception. Cependant, Sentry vous permet également de personnaliser la façon dont vous regroupez les problèmes, en spécifiant votre propre algorithme d'empreinte digitale, ou modifier le paramètre dans l'interface utilisateur.

Nous avons cherché à savoir si un regroupement personnalisé serait bénéfique, en auditant tous les problèmes non résolus et en examinant ceux qui devraient être regroupés. Notre audit a montré que bon nombre des problèmes qui ressemblaient à des doublons faisaient en réalité référence à différents contrôleurs et modèles, il s'agissait donc en fait de problèmes distincts, même s'ils se ressemblaient.

L'audit a mis en évidence un problème : certains problèmes en double résultaient de [mises à niveau de dépendance] inoffensives (https://www.gapintelligence.com/blog/application-dependencies-when-and-why-to-upgrade-them/), car le la structure du fichier de la dépendance changerait légèrement, modifiant la trace de la pile (que Sentry utilise pour regrouper les problèmes). Vraiment, ces « traces du cadre » ne sont pas très utiles pour le regroupement des problèmes ; ce qui nous intéresse, c'est la « trace de l'application ».

Il est possible de « nettoyer » la trace de la pile avant de l'envoyer à Sentry, mais cela empêcherait la trace de la pile d'origine de ne jamais être enregistrée, ce qui entraînerait la perte d'informations de diagnostic précieuses. Nous avons lancé une demande de fonctionnalité avec Sentry pour n'utiliser que la trace de l'application pour le regroupement des problèmes, tout en enregistrant la trace de la pile complète.

Nous avons conclu que, dans l'ensemble, l'algorithme de regroupement par défaut de Sentry fonctionne assez bien pour nous.

Réduction des événements envoyés à Sentry

Pour récapituler, nous enregistrions trop d'erreurs, ce qui signifiait que nous n'avions aucune visibilité sur les erreurs survenues au-delà de la limite de débit.

Nous avons créé un tableau de bord Grafana pour surveiller nos erreurs dans Sentry au fil du temps, afin de pouvoir mesurer dans quelle mesure nous réglions le problème. Nous avons également créé un tableau de bord séparé pour les erreurs dans ce qui était notre application la plus productrice d'erreurs.

Cette application enregistrait régulièrement près de 15 000 erreurs dans Sentry chaque jour. Bien que leur volume soit élevé, la plupart des erreurs ont été attribuées à un seul problème, qui ne semblait se produire que pendant la [synchronisation des données] nocturne (https://docs.publishing.service.gov.uk/manual/govuk-env- sync.html).

Chaque nuit, tout le contenu de GOV.UK est copié dans nos environnements de développement et d'intégration. Ceci est réalisé en supprimant et en recréant des bases de données, ce qui signifie que certains services sur ces environnements peuvent être temporairement indisponibles, et toute tentative d'appel à ces derniers entraîne une erreur. Ces erreurs particulières sont inoffensives, attendues et sans action, nous voulions donc les empêcher d'être enregistrées dans Sentry.

Nous avons décidé de implémenter une nouvelle option de configuration : une liste de types d'exceptions qui doivent être ignorés s'ils se produisent pendant la synchronisation des données. Cela a été ajouté dans notre module GovukError, que nos applications utilisent pour s'interfacer avec Sentry. L'effet a été immédiat : les erreurs dans l'application la plus génératrice d'erreurs ont diminué de 98 %.

Une application a constamment enregistré près de 15 000 erreurs par jour jusqu'à ce que nous appliquions un correctif qui les a presque éliminées du jour au lendemain (Graphique : Gov.UK)

Nous avons continué à auditer Sentry, en rédigeant les problèmes les plus prolifiques pour les développeurs de l'[équipe Platform Health](https://insidegovuk.blog.gov.uk/2019/03/27/why-we-created-a-platform- health-team-on-gov-uk/) sur lequel travailler, puis « ignorer » le problème dans l'interface utilisateur Sentry. Cela signifiait que les erreurs étaient toujours enregistrées mais n'étaient plus aussi visibles, ce qui a contribué à réduire le bruit et nous a permis de détecter les nouveaux problèmes au fur et à mesure qu'ils se présentaient. Nous « résoudrons » le problème une fois le problème résolu : il s'agit d'un mécanisme utile car Sentry envoie un e-mail au résolveur du problème si le problème revient.

Au fil du temps, nous avons résolu les problèmes de volume les plus élevés et apporté d'autres améliorations à notre configuration par défaut, telles que autoriser uniquement les erreurs provenant d'environnements particuliers. Nous sommes également devenus plus précis sur ce qui devrait être enregistré dans Sentry, autorisant uniquement les erreurs système exploitables, et non, par exemple, les erreurs causées par l'utilisateur.

Nous avons réussi à amener notre nombre d'erreurs global bien en dessous du seuil de limitation de débit. Notre meilleure semaine a été en mars 2021, où nous n'avons enregistré que 5 500 erreurs ; une réduction significative sur les plus de 100 000 erreurs que nous voyions régulièrement auparavant.

Nous devions maintenant commencer à réfléchir à une stratégie préventive, pour éviter que le nombre d'erreurs ne grimpe à nouveau.

Stratégie préventive

Bien que tous nos développeurs aient accès à Sentry, ils ne se connectent généralement à Sentry que lors d'un [incident](https://insidegovuk.blog.gov.uk/2015/11/18/what-happens-when-things-go-wrong -on-gov-uk/), ou pour garder un œil sur la santé d'une application lors du déploiement. Cela permet aux nouveaux problèmes de se glisser facilement inaperçus.

Sentry a une intégration Slack qui envoie des notifications lorsque des événements se produisent, selon les règles d'alerte configurées slack/#alert-rules). Nous avons créé une alerte pour nous avertir lorsqu'un problème se produit plus de 100 fois en l'espace de 60 minutes. Nous avons constaté que cela atteint le bon équilibre, car il donne la priorité à nos pires erreurs tout en évitant de spammer la chaîne. Nous espérons abaisser progressivement ce seuil afin de pouvoir travailler sur la « longue traîne » des problèmes.

L'un des problèmes avec ces notifications est qu'elles ne sont pas ciblées : elles dépendent de quelqu'un qui surveille la chaîne et s'approprie le problème. De nombreux problèmes surviennent à la suite de modifications de code effectuées en dehors de notre équipe, et il serait beaucoup plus efficace d'informer directement l'équipe ou le développeur responsable de la modification. Nous encourageons donc les autres équipes de GOV.UK à configurer leurs propres alertes Slack pour les applications sur lesquelles elles travaillent régulièrement, ce qui, nous l'espérons, empêchera l'introduction de la plupart des nouvelles erreurs.

Prochaines étapes

À court terme, nous espérons ensuite améliorer les alertes de production qui avertissent nos développeurs de deuxième ligne et d'astreinte lorsque quelque chose sur GOV.UK nécessite une réponse urgente. Au-delà de cela, nous réfléchissons à la manière dont nous pourrions introduire plus d'observabilité sur GOV.UK : [nous avons récemment introduit le Real User Monitoring](https://insidegovuk.blog.gov.uk/2021/06/16/how- real-user-monitoring-will-improve-gov-uk-for-everyone/), et envisagent des options telles que la gestion des performances des applications. Notre projet de replatforming en cours présente une opportunité passionnante de concevoir ces processus à partir de zéro. — Chris Ashton et Tim Motz

__Nous voulons savoir ce que vous pensez de cet article. Pitch an article à nous ou envoyez vos commentaires à discussion@aphysical.co __

(Crédit photo : Unsplash)