Si nous devons en croire les histoires que nous entendons, les équipes de logiciels de l’industrie ont des pratiques modernes de surveillance et d’observabilité. Les équipes sont alertées des problèmes potentiels avant qu’ils ne touchent les clients et peuvent afficher des tableaux de bord dignes d’une émission de crime pour trouver et résoudre leurs problèmes.
D’après tout ce que j’ai vu ces dernières années, peu d’organisations de logiciels ont atteint ce niveau de surveillance. La plupart des équipes que j’ai rencontrées m’ont dit qu’elles n’avaient pas la couverture de surveillance qu’elles souhaiteraient sur la surface de leur application. J’ai vu de nombreuses startups aller étonnamment loin sans presque aucune surveillance. À ceux qui ont encore du mal avec les bases de la surveillance : vous êtes en bonne compagnie.
Aujourd’hui, il est plus facile que jamais pour une équipe de surveiller les logiciels en production. Il existe plus d’outils de surveillance et d’observabilité disponibles que jamais auparavant. Nous constatons également une meilleure compréhension collective des meilleures pratiques de surveillance et d’observabilité dans l’ensemble de l’industrie. Alors pourquoi y a-t-il un tel écart entre les idéaux du monitoring et la réalité du monitoring ?
Ce qui se passe, c’est que les équipes s’endettent plus rapidement qu’elles ne sont capables de la rembourser. Dans cet article, je vais parler de ce qu’est la surveillance de la dette, pourquoi il est plus facile que jamais pour les équipes de se préparer à la surveillance de la faillite et ce qu’il y a à faire à ce sujet.
Qu’est-ce que le suivi de la dette ?
La plupart des ingénieurs logiciels connaissent le concept de dette technique, une métaphore pour comprendre comment les compromis techniques ont des conséquences à long terme. Les gens parlent généralement de la dette technologique en termes de la façon dont le coût de la refactorisation, de la refonte ou de la réécriture de demain permet à une équipe d’expédier plus rapidement aujourd’hui. La dette technologique, comme la dette financière, peut être prise judicieusement et remboursée de manière responsable.
À certains égards, la surveillance de la dette est analogue à la dette technologique : les équipes peuvent choisir de sous-investir dans la surveillance au moment de l’expédition du code au prix de devoir revenir en arrière et investir dans la surveillance plus tard. D’un point de vue technique, la surveillance de la dette se comporte de la même manière que la dette technologique. Cela coûte plus cher à nettoyer plus tard et nécessite une connaissance intime d’un système dont un développeur peut avoir changé de contexte. Et c’est en supposant que même développeur est là pour rembourser la dette !
Les coûts de surveillance de la dette sont encore plus insidieux. Lorsqu’une équipe choisit d’expédier du code sans surveillance approfondie, voici les coûts immédiats :
- L’équipe doit accepter une capacité limitée à détecter les problèmes avant les clients, ce qui signifie que le client est le plan de surveillance. Cela peut fonctionner pour certains outils, mais peut épuiser la patience des clients payants.
- L’équipe a choisi de renoncer au moins partiellement à la capacité de localiser rapidement les problèmes lorsqu’ils surviennent, ce qui signifie qu’elle est moins susceptible de pouvoir résoudre les problèmes rapidement. Cela signifie que les clients peuvent attendre jusqu’à des heures ou des jours pour que leurs problèmes soient résolus.
Pire encore, le remboursement de la dette de surveillance est souvent plus difficile que le remboursement de la dette technique, car cela nécessite à la fois une connaissance approfondie du code (quel type de comportement est normal ; quels sont les événements les plus prioritaires à surveiller), ainsi qu’une facilité avec les outils de suivi (comment trouver et résoudre les problèmes d’intérêts compte tenu de ce que les outils supportent ?).
Souvent, les raisons pour lesquelles les équipes décident d’assumer le suivi de la dette—pas assez d’expertise ; pas assez de temps – les faire s’endetter de plus en plus.
Pourquoi il est plus facile que jamais d’évoluer vers la surveillance des faillites
Aujourd’hui, il y a plusieurs raisons pour lesquelles il est plus facile que jamais pour les équipes d’évoluer rapidement vers la surveillance des faillites.
La surveillance est une activité hautement qualifiée
La surveillance d’un système nécessite une quantité non négligeable de connaissances à la fois sur le système sous surveillance et sur la manière dont ce système doit être surveillé à l’aide des outils.
- La mise en place de la surveillance et de l’observabilité nécessite une connaissance du système sous-jacent. Si vous utilisez quelque chose comme Datadog APM, il peut sembler que tout ce que vous avez à faire est d’inclure une bibliothèque, MAIS cela peut souvent impliquer la mise à jour d’autres dépendances. Même dans notre base de code d’environ 1 an avec trois microservices, il a fallu une semaine à un ingénieur extrêmement expérimenté pour traquer les dépendances dans plusieurs langues. Et même après l’avoir configuré, mes développeurs n’ont pas la bande passante nécessaire pour configurer tous les tableaux de bord dont nous avons besoin pour utiliser correctement ces données. Nous sommes perpétuellement en retard !
- Les outils eux-mêmes ont une courbe d’apprentissage. De nombreux outils nécessitent une certaine compréhension de la façon d’utiliser les outils : comment instrumenter ; comment personnaliser les graphiques. L’utilisation d’OpenTelemetry en dehors d’un cadre qui fournit un support d’instrumentation automatique a une courbe d’apprentissage assez élevée car vous devez apprendre à implémenter des étendues. D’autres outils d’observabilité préconisent d’écrire du code pour anticiper que vous consommerez les logs ou les traces, ce qui demande de la compréhension et de la discipline de la part du développeur. Les outils qui nécessitent des tableaux de bord personnalisés exigent souvent que les développeurs comprennent comment accéder aux données dont ils ont besoin et quels seuils signifient que quelque chose ne va pas. À l’instar des voitures à transmission manuelle, la plupart des outils de surveillance et d’observabilité troquent aujourd’hui la facilité d’utilisation contre le contrôle et la flexibilité ; ces outils nécessitent une certaine facilité et une compréhension de base des objectifs de surveillance clairs et des mécanismes de surveillance sous-jacents.
La surveillance est mieux faite fraîche
Plus un logiciel reste longtemps sans surveillance, plus il devient exponentiellement difficile à surveiller. Tout d’abord, la connexion à l’outil de surveillance est plus difficile pour un système qui n’est pas complètement à jour et paginé. Tout système de surveillance qui nécessite l’utilisation d’une bibliothèque signifie qu’il existe probablement des problèmes de compatibilité – à tout le moins, quelqu’un doit faire le tour de la mise à jour des bibliothèques. Des outils plus puissants qui nécessitent des modifications de code sont encore plus difficiles à utiliser. Il est déjà difficile de revenir à l’ancien code pour faire des mises à jour. Le remettre en contexte pour le traçage est tout aussi délicat !
Deuxièmement, la consommation des « anciennes » données de surveillance est délicate. Même si vous pouvez vous fier à votre infrastructure pour générer automatiquement des journaux ou ajouter de l’instrumentation, ce qui est considéré comme un “comportement normal” pour un système peut avoir été supprimé ou avoir quitté l’entreprise avec d’anciens membres de l’équipe.
Enfin, les équipes logicielles étant plus juniors que jamais et connaissant plus de désabonnement que dans l’histoire récente, les chances augmentent qu’un développeur différent, plus junior, soit chargé de nettoyer la dette. Ces développeurs vont prendre plus de temps juste pour comprendre la base de code et ses besoins. S’attendre à ce qu’ils acquièrent simultanément des compétences en matière de surveillance et d’observabilité, tout en modernisant les instructions de journalisation et de traçage sur une base de code, est une grande demande.
De meilleurs outils ont facilité le suivi de la dette
Enfin, l’essor du SaaS et des API a rendu beaucoup plus difficile la surveillance des systèmes. La surveillance ne consiste plus à voir ce que fait votre propre système, mais comment votre système interagit avec une variété d’autres systèmes, des API de paiement tierces à l’infrastructure de données. Je dirais également qu’un sous-système hérité que personne dans l’équipe ne comprend complètement entre également dans cette catégorie. Bien que les pratiques traditionnelles de surveillance et d’observabilité aient un sens pour les monolithes et les services distribués entièrement sous le contrôle d’une seule organisation, il est difficile de savoir comment adapter ces pratiques lorsque votre système distribué comporte des composants qui ne sont pas sous le contrôle de votre équipe.
Ce dont les équipes ont besoin pour rembourser la dette de surveillance
Mon point de vue : obtenons de nouveaux outils. Mais en attendant, repensons aussi nos pratiques.
Les outils de surveillance d’aujourd’hui sont conçus pour un monde dans lequel les développeurs qui ont construit des systèmes bien confinés de taille gérable peuvent obtenir une journalisation haute fidélité dans l’ensemble. Nous vivons plutôt dans un monde où les services logiciels se déchaînent avec des comportements émergents et où le génie logiciel ressemble plus à l’archéologie ou à la biologie. Les outils de suivi doivent refléter ce changement.
Pour répondre au développement de logiciels là où il en est, les outils de surveillance ont besoin d’une remise de dette. Mes propositions d’améliorations :
- Faciliter la mise en place d’une boîte noire de suivi et d’observabilité. Je sais, je sais : la sagesse commune concernant la recherche et la résolution des problèmes est que vous voulez comprendre aussi bien que possible le fonctionnement interne du système sous-jacent. Mais que se passe-t-il s’il y a trop de code dans le système sous-jacent pour rendre cela possible ? Ou s’il y a des parties du système qui sont trop anciennes, ou trop précaires, pour plonger et ajouter de nouveaux journaux ? Permettons aux utilisateurs d’accéder plus facilement à un système et de pouvoir le surveiller, sans avoir à toucher au code ni même à mettre à jour les bibliothèques. Surtout pour rendre possible la mise en place d’une nouvelle surveillance sur l’ancien code, nous voulons des solutions d’accompagnement qui ne nécessitent aucun changement de code et aucun SDK. Et avec de plus en plus d’interactions système devenant visibles à travers les API réseau et d’autres interfaces bien définies, la surveillance de la boîte noire se rapproche de la réalité.
- Aidez les équipes à identifier plus facilement ce qui ne va pas sans avoir une connaissance complète de ce qui est juste. Les outils de surveillance d’aujourd’hui sont conçus pour les personnes qui savent ce qu’elles font pour faire exactement ce qu’elles doivent faire pour réparer ce qui ne va pas. Les équipes ne devraient pas avoir besoin de comprendre quels doivent être leurs seuils de latence ou quels doivent être les taux d’erreur pour commencer à comprendre comment leur système fonctionne ensemble. Les outils de surveillance et d’observabilité accessibles du futur devraient aider les équipes de logiciels à combler les lacunes en matière de connaissances.
En matière de surveillance et d’observabilité, nous disposons d’excellents outils puissants, mais que ne le faites pas avons-nous besoin d’une solution “pour les nuls” ? C’est quelque chose auquel nous devrons réfléchir collectivement dans l’ensemble de l’industrie, mais voici quelques idées de départ :
- Nous ne construisons pas pour des équipes qui optimisent les performances de pointe. Ils essaient de s’assurer que lorsque la charge est élevée, le système ne bascule pas. Répondre aux questions de base du type “quelque chose est-il une erreur ?” et “est-ce que quelque chose est trop lent?” ne nécessite souvent pas de machinerie précise.
- Être capable de tracer avec précision les demandes et les réponses à travers le système est formidable, mais ce n’est généralement pas nécessaire. Pour un point de référence : un ami m’a dit un jour que moins de cinq ingénieurs principaux de son entreprise de type FAANG utilisaient leurs outils de traçage.
- De quelles informations minimales avons-nous besoin pour le suivi ? Lorsque la racine cause des problèmes, suffit-il simplement d’obtenir un identifiant unique sur le processus d’où provient le problème ? J’aimerais voir plus de discussions sur les “informations minimales viables” lorsqu’il s’agit de trouver et de résoudre des problèmes.
Parler davantage des réponses à ces questions peut aider à établir des normes minimales, plutôt qu’idéales, pour le suivi à l’aide des outils existants.
Réduire la dette
Afin d’aider les équipes à rembourser la dette de surveillance, nous avons besoin d’un changement de mentalité dans les outils de développement. Nous avons besoin de plus d’outils utilisables face à la dette technologique, à la surveillance de la dette et à une très faible compréhension du système ou des outils sous-jacents.
Aujourd’hui, ce serait un exploit héroïque pour une nouvelle personne subalterne de rejoindre une équipe et de résoudre avec succès un incident. Mais nous en voyons déjà des récits dans les actualités – et la dynamique du lieu de travail technologique signifie que nous ne pouvons que nous attendre à ce que cela se produise davantage. Pourquoi pas faciliter la gestion d’un incident par un développeur junior ?
Tags : surveillance, observabilité, dette technologique