Chez iad, l’observabilité est le ciment des bonnes relations entre Devs et Ops

Convaincre les développeurs

Il y avait tout de même un enjeu de taille à relever. Pendant la migration vers le cloud d’AWS, les Ops ont mis en place Datadog, ses agents et effectuer les configurations nécessaires.

« Nous nous sommes dit : “si nous voulons pratiquer l’observabilité, il va falloir le faire en coopération avec les développeurs” », indique Armand Saghri.

Pour déployer les fonctionnalités APM, il fallait instrumenter le code, configurer correctement les logs au format JSON et y inclure du contexte. « Tout ce que les développeurs loggent nous sert à mettre en place des métriques que l’état de santé des applications et des features ».

Si cela ressemble à une formalité technique supplémentaire, c’était loin d’être le cas. Elle impliquait une conduite du changement dans les habitudes de travail et donc de convaincre du bien-fondé de l’opération. Armand Saghri s’est dit que le meilleur moyen pour ce faire était d’apporter une preuve par l’exemple.

« Nous avions un projet à mener en parallèle », déclare le responsable. « Nous l’avons fait dans une stack “full serverless” avec un développeur habitué de Datadog en respectant tous les éléments d’observabilité que nous avions dans notre cahier des charges ».

Ce travail a été présenté aux développeurs, en sus des métriques affichées dans les tableaux de bord de Datadog.

« Nous avons montré comment obtenir une visibilité des performances à chaque étape du code, comment suivre précisément les requêtes envoyées à la base de données, et les performances associées », raconte-t-il. « Nous avons configuré les messages d’erreur pour qu’ils soient directement envoyés vers le canal de discussion de la squad de développeurs concernés et vers le Pagerduty des Ops ».

Une présentation qui a fait mouche. Les développeurs n’avaient pas l’habitude d’aborder les déploiements sous cet angle et d’aller si loin dans l’observabilité. « Eux s’assuraient avant tout que leur code passe les tests QA. Nous avons essayé d’aller plus loin en évaluant les performances, en identifiant ce qui peut être optimisé. iad est en pleine croissance, beaucoup de features sont lancées. Si nous ne nous sommes pas vigilant sur ces points, notre dette technique va s’alourdir ».

Les développeurs ont mis la main à la patte pour la mise en place des tableaux de bord et ont fait « beaucoup d’efforts » sur l’implémentation des logs. « “Logger” proprement est sans doute le plus gros enjeu pour les développeurs. Cela demande de réfléchir à des métriques spécifiques aux métiers et trouver comment les exposer à travers les logs et les événements ».

Ce « chantier » a eu l’effet escompté : rapprocher les développeurs des opérateurs. « Aujourd’hui, cela influe beaucoup sur les nouvelles features : il y a toujours un Ops et un Dev qui travaillent ensemble sur les sujets liés à l’observabilité, aux performances », assure Armand Saghri. « Du fait de cette démarche, lorsqu’une fonctionnalité est déployée, elle rencontre beaucoup moins de problèmes ».

Cela implique également de penser à la supervision dès la conception du code. « Je dis régulièrement que l’observabilité, c’est l’affaire de tous : que ce soient les développeurs, les ops ou les responsables produit. Cela porte grandement ses fruits », estime le responsable Cloud & Operations.

Une culture que les responsables souhaitent continuer à diffuser dans les équipes. 

Des routines pour rapprocher les développeurs et les Ops

Les Ops, de leur côté, ont mis en place les moyens pour faire la « chasse » aux faux positifs et obtenir les bonnes alertes. « Là aussi, cela fonctionne bien : dès qu’il y a un problème, nous sommes alertés. Nous utilisons également la fonction “error tracking” de Datadog qui remonte des informations sur les erreurs inédites ».

Les développeurs se sont presque « pris au jeu ». « Dès qu’une erreur est liée à leur périmètre, ça les pique un peu et ils se penchent rapidement sur le problème. C’est très plaisant de voir cela ».

Selon Armand Saghri, l’observabilité n’est atteignable que si les relations entre les développeurs et les opérateurs sont bonnes. « Sinon, ça ne fonctionne pas », lance-t-il.

Il n’y a pas de recette miracle. « Ce n’est pas évident, ce sont des populations qui n’ont pas forcément l’habitude de travailler ensemble ».

 En revanche, quelques pratiques peuvent aider à améliorer la qualité du code. « Nous, nous avons une routine. Nous organisons des points à plusieurs stades : principalement au lancement du développement et au moment de préparer le déploiement », explique Armand Saghri. « Si les critères d’observabilité ne sont pas là, nous pouvons refuser la sortie d’un projet. Ces rituels sont portés par les responsables produit ».

Une routine imposée par le directeur technique.

Ainsi, le gros de l’infrastructure cloud d’iad est supervisé à l’aide de Datadog. Au début du mois de janvier, 50 agents Datadog servaient à collecter les données des hôtes EC2. Le groupe oscille entre 120 et 300 conteneurs ECS (principalement PHP), ainsi que 700 fonctions lambda (principalement en Node.js) tous environnements confondus. L’APM permet de surveiller le comportement du CRM utilisé par les 18 000 conseillers.

Le tout représente un volume d’environ 100 millions de logs par semaine. 

Datadog sert aussi aux métiers

Outre la bonne santé de l’infrastructure et des applications métiers, Datadog est par exemple utilisé pour s’assurer de la bonne gestion des mandats immobiliers.

Ce document est nécessaire pour qu’un agent puisse vendre un bien au nom d’un propriétaire. Il existe différents mandats, par exemple suivant si le vendeur passe par une ou plusieurs agences. Il existe aussi des mandats de recherche : là, un acheteur réclame à un agent de trouver un bien répondant à ses critères.

« Dans Datadog, nous avons des tableaux de bord avec les mandats signés par conseiller, les types de mandats – exclusifs, simples, etc. —, les mandats expirés, annulés ou encore les demandes d’avenants », relate Armand Saghri. « Nous avons des alertes concernant le volume de mandats obtenus par jour. Si le volume est bas, cela peut être le signe d’un problème logiciel chez nous ou nos partenaires ».

FinOps : gérer les dépenses du cloud et… de l’observabilité

Un usage aussi important de la plateforme d’observabilité demande une certaine prudence économique.

« D’abord, nous gérons le FinOps de la facture de Datadog », indique le responsable. « Nous avons mis des alertes pour identifier les taux anormaux d’ingestion de logs. Sur les sessions de RUM, il faut également surveiller la volumétrie tout comme les logs en provenance de nos centaines de conteneurs ».

Sachant que les équipes d’iad gèrent une trentaine de comptes AWS séparés tous liés à Datadog, cela réclame une certaine « hygiène FinOps ».

Armand Saghri n’utilise pas le module dédié au FinOps de la plateforme. « J’ai déjà mes outils », note-t-il. En revanche, Datadog est utilisé pour le bon dimensionnement de l’infrastructure cloud. « Nous faisons cohabiter deux systèmes : un legacy et un nouveau. Nous en déshabillons un pour rhabiller l’autre ».

Datadog permet d’identifier les conteneurs inutilisés. Par exemple, un service d’une quinzaine de conteneurs Docker a été migré vers AWS, mais une fois en production, la plateforme d’observabilité a permis de se rendre compte qu’il n’était pas utilisé depuis environ un an et demi. Elle est également utilisée pour alerter les équipes quand des environnements de développement et de tests sont encore en fonctionnement alors qu’ils devraient être éteints.

À l’avenir, les équipes d’iad espèrent renforcer la gestion des vulnérabilités et leur remédiation à travers Datadog.

Article modifié.