L’observabilité au service du produit

Pourquoi on monitore

Vous vous rappelez la dernière fois qu’un utilisateur vous a remonté un problème avec une application. On ne s’en était pas rendu compte, et on a dû réagir sur le tard pour remettre d’équerre le système. Suite à ça, on s’est dit qu’on allait mettre en place du monitoring pour être au courant au plus tôt des problèmes éventuels.

La question à se poser c’est : qu’est-ce qu’on veut monitorer. Généralement ce sont les ops qui mettent en place l’observabilité. On se retrouve alors avec les éléments suivants :

• Un health check pour vérifier que le l’infra est bien up

• Des métriques sur l’utilisation des cpu et de la ram

• Le temps de réponse des API

• Un alerting lorsque les points du dessus sont en échec

Ainsi lorsqu’un service sera KO on est alerté directement et on peut réagir vite.

La limite avec ce monitoring c’est qu’il est très technique et ne permet pas de voir si le service métier est complètement rendu.

On peut alors rajouter le suivi des erreurs. Pour un système d’API les erreurs 400 et 500. On a alors une information un peu plus précise sur les services rendus.

On ajoute ensuite un APM, un outil qui permet de mesurer le temps qu’un traitement prend au sein de différentes couches applicatives. Il permet de détecter des problèmes au sein d’une de ces couches, mais aussi de connaître les traitements qui sont les plus utilisés, les plus gourmands, et de comparer leur fonctionnement dans le temps.

A la fin on se dit “c’est bon, je sais ce qui se passe”

Mais, qu’est-ce qu’on a vraiment gagné ?

(Ne pas)Anticiper

On a gagné en anticipation.

En effet, en mesurant dans le temps la qualité des services on peut observer des tendances et prévoir les moments où quelque chose va casser. En effet de bord on gagne un énorme avantage : la capacité à ne pas devoir over-designer.

Pour illustrer cela je peux donner un exemple sur un projet. On a développé un batch qui potentiellement allait prendre beaucoup de temps avec l’augmentation du nombre d’utilisateurs. Pour cela il y a eu plusieurs possibilités :

• Faire une hypothèse haute sur le nombre d’utilisateurs cible et faire en sorte que le code soit le plus performant possible, au détriment de sa lisibilité

• Faire une hypothèse basse, et faire un code plus simple au détriment de la performance

On a choisi la solution 2 tout en ajoutant une partie monitoring. Dès la mise en production on a créé un dashboard qui nous permettait d’analyser le temps du job par rapport au nombre d’utilisateurs. On a également mesuré l’impact du batch sur le reste du système pour s’assurer qu’il n’y avait pas d’effet de bord.

4 mois après on s’est rendu compte que la montée en charge tenait bien la route, et qu’il était inutile d’over-designer le batch.

Ce réflexe est possible sur un bon nombre de fonctionnalités : on se laisse la possibilité de faire au plus simple si on se donne les capacités de suivre précisément comment elles fonctionnent en production.

Finalement on a gagné en anticipation par le fait de ne pas avoir besoin de trop anticiper. Cela rejoint le principe du YAGNI (You Aren't Gonna Need It). En étant sereins sur notre capacité à savoir ce qui se passe en production on peut aller au plus simple et garder le focus sur la valeur utilisateur qu’on va livrer.

Pour résumer : monitorer permet de repousser à plus tard des choix techniques qui nécessitent plus d’informations.

Il existe également d’autres techniques qui permettent de prendre les bonnes décisions au bon moment, vous pouvez consulter cet article.

Mesurer

Observer notre système nous permet de faire des choix pragmatiques et se concentrer sur le minimum pour apporter de la valeur aux utilisateurs. On peut alors diversifier ce que l’on mesure. Avec de simples logs bien formatés on est capable de remonter des mesures d’usage et des défauts liés au service métier.

Une pratique que nous avons mise en place sur un de nos projets est de faire ressortir les actions métiers dans les logs : on peut donc savoir dans quelle mesure notre système lui répond.

Pour illustrer cela par l’exemple : on a une API qui permet de créer des rendez-vous. En loguant les différentes étapes de cette action on devient capable de suivre à la fois la technique mais aussi le métier qui lui est lié.

En mesurant le nombre d’appels et le temps de réponse agrégé à des actions métier on a un double gain :

• Mesurer l’utilisation d’une fonctionnalité

• Détecter des problèmes d’ergonomie, de performance ou des bugs lors de l’utilisation de ces fonctionnalités

C’est à dire qu’en utilisant simplement un système de remontée de logs et en les mettant en forme dans des dashboards, on obtient rapidement beaucoup d’informations qui nous permettent à la fois de mesurer la santé de notre application et de notre produit. Dans l’exemple que j'évoque, nous avons utilisé la stack Elastic - Logstash - Kibana.

Pour avoir une idée de ce qu’il est possible de faire, ci-dessous un dashboard que nous avons mis en place sur un de nos projets. On y observe directement les services les plus utilisés et ceux qui sont en échec.

Ceci est complémentaire à d’autres outils spécifiques pour mesurer la manière dont un outil est utilisé, comme Matomo, et a l’avantage de répondre à la fois à des problématiques techniques et produit. Un gain à son utilisation est que l’on place un objectif commun aux développeurs et au produit. Ainsi on va tous dans le même sens.

Comment monitorer permet de réagir

Nous avons maintenant accès à des indicateurs qui nous donnent deux informations :

• Est-ce que mon système fonctionne ?

• Est-ce que mon service métier est rendu ?

En combinant les deux, on a alors gagné quelque chose qui a énormément de valeur : lorsque mon système tombe, je suis capable de connaître rapidement l’impact sur le métier. Pour remettre en état une application il ne suffit pas de la relancer ou de corriger un bug, il faut également communiquer avec les utilisatrices et utilisateurs et potentiellement rattraper l’état des données. Avoir de l’observabilité au niveau du produit rend possible de réagir extrêmement rapidement : plus on détecte le problème à la source, plus il devient simple à résoudre.

Cette capacité de réaction s’inscrit pleinement dans la culture du post-mortem popularisée par Google. On ne peut pas empêcher les erreurs d’arriver, par contre on peut apprendre d’elles, s’en prémunir et se donner la capacité d’en limiter les impacts. L’observabilité de l’infrastructure, de l’application et du produit en est une clé indispensable.

Afin de donner un exemple d’un problème où une équipe a pu rapidement réagir et prévenir le métier et les utilisateurs des impacts, vous pouvez allez jeter un œil à ce post-mortem.

Pour le résumer voici la chronologie des événements depuis la détection du problème jusqu’à la communication de ses impacts :

• 11h01 : détection d’un problème => des services ne répondent plus depuis 2 heures

  • Immédiatement nous avions dans des dashboards l’impact métier des services non rendus

• 11h05 : Découverte de la root cause du problème

• 11h08 : Redémarrage des services workers et rattrapage des services qui pouvaient l’être

• 11h27 : Livraison en production d’un correctif pour prévenir le problème

• 11h30 : Communication au métier des impacts sur les services qui n’ont pas été rendus

• Plus tard: mise en place d’alerting pour détecter ce type de problème au plus tôt

Le temps de réaction une fois que le problème a été détecté a été suffisamment rapide pour en limiter les impacts, et l’observabilité mise en place en a été l’acteur principal.

L’intégrer dès le début des projets

Jusque là on a vu que les outils d’observabilité sont mis en place au début des projets pour des besoins d’infrastructure, et qu’ils peuvent devenir un outil orienté produit. Lorsque l’on est conscients de ça, on peut l’utiliser comme un levier pour que toute l’équipe aille dans le même sens en se posant les bonnes questions :

• Quels sont les services métier indispensables à rendre ?

• Comment je m’assure qu’ils sont bien rendus ?

• Comment me rendre compte au plus tôt d’un défaut ?

Avec ces réflexes-là, l’équipe de développement sera porteuse du produit qu’elle code, et on tirera tout le monde dans la même direction : faire un produit qui amène de la valeur.

Pour aller plus loin, on peut se poser la question : comment je m’assure que ce que je livre a de la valeur ? Pour faire celà on fixe des objectifs (OKR) aux fonctionnalités que l’on veut livrer. Ensuite on voudra mesurer leur utilisation. Si dès le début on s’est mis en ordre de marche pour observer les fonctionnalités, alors cela devient plus simple et porté par l’ensemble de l’équipe : le métier, les ops et les développeurs.