Post Mortem · Épisode 06
#6 Monitor early — fix bugs early
Écouter cet épisode
Épisode 6 · Monitor early, fix bugs early
Spotify
Apple PodcastsSommaire
Interview avec Loïc Carbonne, VP engineering à Theodo.
#6 Monitor early — fix bugs early
Lead time reduction for bugfix @ Theodo
medium.com
Présentation de Theodo
Theodo est une société de service spécialisée dans le développement d’applications web. Nous développons des applications web pour différents types de clients, des startups aux grands groupes, en passant par les PME. Cela nous permet de travailler sur une typologie de projets assez variés. Depuis quelques années, de nouvelles entités se sont créées pour former le groupe Theodo, des entités spécialisées dans le mobile, dans la data, dans la finance, ou encore à l’étranger. Nous comptons aujourd’hui plus de 350 employés.
En tant que VP, j’accompagne nos ingénieurs sur différents projets afin de les aider à réussir à délivrer des applications de qualité et dans les délais.
Réduction du lead time de résolution des incidents
J’aimerais partager avec vous des apprentissages sur un sujet qui tourne autour de la résolution d’incident, plus précisément : la réduction du lead time de résolution des incidents. C’est-à-dire les bonnes pratiques et méthodes qui permettent de réduire la durée entre le moment où le bug apparaît, et le moment où le bug est corrigé.
Deux leviers pour réduire les bugs et leurs impacts
Pour réduire l’impact des bugs et incidents sur une plateforme, le premier levier auquel on pense généralement est la réduction de la fréquence du nombre d’incidents.
En effet, moins on a de bugs, moins ceux-ci vont impacter les utilisateurs. C’est assez important de travailler sur ce point. Cela se fait généralement en améliorant la qualité d’une application afin d’éviter que des bugs apparaissent. Ou en faisant des post mortem ou des QRQC (pour Quick-Response-Quality-Control), après chaque bug, pour identifier les causes profondes et prendre des actions pour que le problème ne revienne jamais.
Mais il existe un second levier qui permet de réduire l’impact des incidents, on peut également réduire leur durée et délai de correction. Moins longtemps le bug ou l’incident va être actif et moins les utilisateurs seront impactés. Souvent, essayer de réduire la durée de correction des incidents peut être plus impactant que d’essayer d’en réduire le nombre. Parfois, diviser le nombre de bugs sur une plateforme sera un véritable défi alors que diviser considérablement les temps de corrections peut se faire assez rapidement grâce à la mise en place de quelques actions.
Leçons tirées d’un projet
Je vais vous raconter un de mes précédents projets, dans lequel nous nous sommes fortement intéressés à ce sujet. Pour le contexte, j’étais tech lead sur une application web pour une grande banque française. Une application avec pas mal de legacy et assez complexe, on avait la main sur une vingtaine de micro services et on faisait appel à une vingtaine d’autres providers.
Je faisais partie de l’équipe chargée de la correction des bugs, et un sujet d’amélioration qui revenait était justement les durée de corrections des incidents.
On a commencé par monitorer les délais de résolutions, et on s’est fixé des objectifs qui varient en fonction de la criticité des bugs. Comme par exemple:
- 1H pour les bug les plus critiques
- 1J pour les bug urgents
- 1 semaine pour les bugs moins urgents.
La priorisation des bugs grâce à ce système est d’ailleurs très importante, il faut toujours traiter en premier les bugs ayant le plus d’impact.
Ensuite on a commencé à analyser en détail les résolutions de bug qui ne respectaient pas nos exigences. Voici le détails d’une résolution d’incident : un jour, un membre du support nous appelle pour nous indiquer qu’il ne reçoit plus ses notifications, ce qui est assez gênant pour un membre du support, car une partie de son job est d’accepter ou refuser des demandes reçues par notifications. Le ticket de bug est créé, et on prévoit une journée d’investigation dans le sprint suivant pour corriger le bug. On faisait du scrum et des sprints d’une semaine.
Le sprint se termine, on en démarre un nouveau au cours duquel l’investigation concernant le bug est réalisée, mais au terme de la journée d’investigation, le cause du bug n’est pas trouvée. Quand on essaye de générer une notification pour l’utilisateur en question, rien ne se passe, mais aucun log d’erreur n’apparaît. Ensuite, un ticket est créé pour continuer l’investigation, mais comme le sprint est figé, ce ticket est placé dans le sprint d’après et les développeurs passent à autre chose. La semaine d’après, on reprend l’investigation, grâce à l’ajout de log, on arrive à identifier la cause du bug puis on implémente un fix pour le corriger. La cause du bug était assez bête, il s’agissait d’un problème de majuscules. Pour enregistrer un utilisateur dans le service de notification, on allait chercher des informations sur un système tiers à partir de son email, mais comme cet utilisateur avait des majuscules dans son email, le service tiers ne trouvait pas l’utilisateur et cela faisait échouer l’enregistrement sur le service de notification.
Le délai de résolution de cet incident était donc de 1 semaine et demi, et on peut voir plusieurs problèmes.
Tout d’abord, la recherche de la cause du bug qui a duré plus d’un jour. Celle-ci a duré aussi longtemps car aucune erreur, ni aucun log ne remontait sur l’outil de monitoring utilisé. Et sans ces outils, trouver la cause d’un bug dans des milliers de lignes de code, sur des systèmes distribués, peut s’apparenter à rechercher une aiguille dans une botte de foin. C’est d’ailleurs en ajoutant des logs que l’on avait réussi à identifier la cause de l’erreur.
On a donc décidé de travailler sur l’amélioration du monitoring en priorité, car cela impactait aussi notre touch-time, le temps que l’on passe en tant que développeur à corriger des bugs.
On a réalisé un ensemble d’action pour améliorer le monitoring en nous inspirant des meilleures pratiques trouvées sur le web.
Techniquement, on a mis en place des middleware pour logguer tous les appels entrant de manière automatisée, on a mis en place des interceptors sur nos clients http pour logguer tous appels sortants. On a corrigé les mauvais patterns dans le code qui obfusquaient les erreurs. Et on a mis en place du distributed request tracing, c’est une technique qui permet de tracer une requête et son parcours au sein de différents services.
On a mesuré le touchtime, cad, le temps passé par les développeurs en moyenne pour corriger un bug, sur le mois qui a suivi, et seulement grâce à l’amélioration du monitoring, ce temps a été divisé par deux.
Mais nous ne nous sommes pas arrêtés là, si on reprend l’exemple de tout à l’heure, le plus gros gaspillage de temps était l’attente. On avait attendu trop longtemps avant de commencer à travailler effectivement sur le ticket, et n’ayant pas trouvé la cause du bug lors de la première investigation, on a de nouveau attendu le sprint d’après pour continuer à travailler sur ce bug.
On a cette fois-ci un problème de process, le scrum n’était pas le plus adapté à la résolution d’incident notamment à cause de ses sprints figés. On a donc décidé de sortir un développeur du sprint scrum, celui-ci pouvait se concentrer à 100% sur la résolution d’incident en mode kanban, il corrigeait les bugs un à un jusqu’à que ceux-ci soit résolu, et cela a mis fin aux bugs qui étaient reporté d’un sprint à l’autre.
Enfin, nous avons identifié un troisième axe d’amélioration. Toujours sur l’exemple précédent, nous nous sommes rendu compte après analyse que le bug était déjà présent depuis plusieurs mois, seulement pour une poignée d’utilisateurs. Mais le bug n’était jamais parvenu jusqu’à nous, car les utilisateurs ne l’avaient pas remonté. Ils n’avaient pas de notifications, mais probablement se disaient tout simplement qu’il n’avaient pas de notification.
Ce cas-là n’était pas un cas isolé, sur plusieurs résolutions, après avoir amélioré le monitoring, on a remarqué qu’on aurait pu détecter le bug plus tôt grâce aux exceptions et erreurs remontées dans le code. C’est donc ce que nous nous sommes mis à faire, on s’est mis à analyser les erreurs présentes dans notre monitoring, ce qui nous a permis de commencer à travailler sur la correction des bugs avant même que le support nous remonte ces bugs.
Suite à toutes ces actions, nous avons réussi à considérablement réduire le lead time de correction des incidents. Les durée de résolutions ont été divisées par 12 pour les bugs urgents, et divisée par 3 pour les bugs moins urgents.
Patterns identifiées pour réduire le lead time de résolution des bugs
Depuis cette période, je continue d’aider les ingénieurs sur nos différents projets afin d’améliorer leur leadtime de résolution de bug. Nous avons des typologies de projets très différentes, mais malgré cela nous avons détecté des patterns communs.
Un mauvais lead time de résolution peut être causé par un processus non adéquat. Comme on l’a vu précédemment, il faut éviter au maximum que les incidents se retrouvent en attente. Non seulement au niveau de l’équipe technique, quand les développeurs sont au courant de l’existence du bug, mais également avant, il faut également éviter que les demandes des utilisateurs restent en suspens et faire en sorte que celles-ci soient remontées rapidement aux équipes techniques.
Ensuite, le point sur lequel travailler pour réduire le lead-time est le monitoring. On va précisément travailler sur deux aspects du monitoring, l’alerting et l’aide au diagnostic.
L’alerting va nous permettre de remonter plus rapidement les bugs aux équipes techniques. Tandis que l’aide au diagnostic va nous permettre de débugger plus rapidement la cause de l’erreur.
Le monitoring va avoir un certain degré de maturité en fonction des projets.
Le premier niveau de maturité est le niveau zéro, c’est à dire qu’aucun outil de monitoring n’est installé. C’est en général le cas sur les projets en cours de développement, ou en production depuis peu. La mise en place d’un système de monitoring n’est pas priorisé, car si le projet n’est pas en production, on se dit qu’il n’y a rien à monitorer. Cependant, nous recommandons de mettre en place du monitoring le plus tôt possible, même si le projet n’est pas encore en production, car cela permettra de détecter et analyser des bugs sur les environnements de développement ou de préproduction.
Le deuxième niveau est lorsqu’ un outil de monitoring est installé mais que celui-ci est mal configuré, et que les erreurs qui sont remontées ne sont pas pertinentes.
Il faut en effet que les erreurs ne soient pas masquées et remontent bien dans le système. Pour cela on va chercher à automatiser la remontée des erreurs, et on va éliminer des mauvais patterns dans le code qui peuvent obfusquer des erreurs. Comme par exemple des blocs try/catch qui ne génèrent pas de log d’erreur, ou qui ne relèvent pas une exception. On peut imaginer mettre en place des règles de linter, d’analyse statique de code pour vérifier qu’on ajoute pas ces mauvais patterns dans le code
Quand on parle d’erreur pertinente, il faut que les erreurs remontent mais il ne faut pas que trop d’erreurs remontent. Sinon on risque d’être noyé sous les erreurs et de ne plus retrouver les erreurs qui concernent de vrais bugs. [Alarm Fatigue] Pour cela, il faut correctement utiliser les niveaux d’erreur (Fatal, error, warn). Ce qui nous permet par la suite de filtrer seulement sur les erreurs les plus critiques pour retrouver celles qui nous intéressent.
On arrive ensuite au troisième niveau, Après avoir rendu les erreurs pertinentes, on va rendre le contenu des erreurs pertinentes. Cela consiste à ajouter toutes les informations requises pour débugger dans nos erreurs. Ces informations sont précieuses pour identifier quelle est la portion de code faisant défaut, et pourquoi.
Voici quelques exemple d’informations qui doivent être remontées, la stack trace et le numéro de la ligne de code qui crash, le nom du fichier ou service causant l’erreur, l’url de la route HTTP appelée, les différents paramètres données, l’id de l’utilisateur, la date, ou encore le numéro de version de l’application.
Toutes ces informations très précieuses peuvent d’ailleurs être remontées dans le système de monitoring de manière automatisée.
Enfin, le quatrième et avant-dernier niveau est lorsque le système de monitoring est bien configuré, mais que personne n’est formé pour l’utiliser. Certaines plateformes de monitoring sont plus simples d’utilisation que d’autres. Ce qui signifie qu’une formation ou des explications peuvent être requises pour utiliser ces plateformes. Et si tous les membres de l’équipe participant à la gestion des incidents ne savent pas utiliser le monitoring, tous les efforts de configuration sont vains. A l’inverse, une bonne formation fait gagner un précieux temps, la formation peut même être faite aux équipes non techniques, comme le support, qui sera capable d’identifier directement les causes d’erreur afin de rediriger le bugs directement vers la bonne équipe.
Tous ces critères permettent de construire un bon monitoring. Nous les avons listé afin de construire un questionnaire pour auditer nos projets. On a construit un audit de monitoring qui permet d’évaluer le monitoring et trouver des actions afin de l’améliorer.
Et aujourd’hui, je dirais qu’on s’est bien amélioré, il y a deux semaines un de nos ingénieurs me racontait une résolution d’incident sur son projet : un jour vers 14h, le monitoring remonte une erreur, que les développeurs corrigent dans la foulée. Vers 17h, le bug correspondant est remonté aux développeurs, ce à quoi les développeurs ont pu répondre, le bug est déjà fixé, c’est en cours de déploiement. Ce qui est assez satisfaisant pour tout le monde.
Pour conclure, investissez dans le monitoring est la réduction du lead time des incidents, afin de ne plus laisser votre client et vos utilisateur découvrir les bugs avant vous.
Notes de l’épisode
Loïc Carbonne, VP Engineering @ Theodo, nous partage son expérience sur la réduction du lead time de résolution des incidents.
Au travers de leçons apprises lors du développement d’applications web, Loïc nous propose des outils et méthodes pour s’organiser afin:
1) d’identifier plus rapidement les bugs
2) et de réduire leur temps de résolution.
En résumé, des best practices sur l’alerting, le monitoring et la gestion de bugs dans un fonctionnement scrum.