La télémétrie : voir, analyser et anticiper les problèmes

Une vérité crue gouverne l'exploitation : les choses tournent mal. Dans un système complexe, un petit changement peut provoquer une cascade d'effets inattendus — pannes, défaillances globales qui touchent tous les clients — et nul ne tient dans sa tête la totalité du système ni la manière dont les pièces s'emboîtent. Cette partie du livre, consacrée à la seconde voie (the Second Way), traite du retour rapide et continu de l'exploitation (Operations) vers le développement (Development). Tout commence par la télémétrie : sans elle, lors d'une panne, on ne sait même pas dire si le défaut vient de l'application (un bug dans le code), de l'environnement (un problème réseau, une mauvaise configuration serveur) ou d'une cause externe (une attaque par déni de service massive). Ce chapitre montre comment instrumenter tous les niveaux, centraliser les signaux, les rendre accessibles à tous, puis les analyser statistiquement pour détecter les anomalies avant qu'elles ne deviennent des catastrophes.

De la « culture du redémarrage » à la « culture de la causalité »

Face à un incident, le réflexe le plus répandu en exploitation ressemble à une plaisanterie un peu amère : on redémarre le serveur ; si ça ne marche pas, on redémarre celui d'à côté ; si ça ne marche toujours pas, on redémarre tous les serveurs ; et si rien n'y fait, on accuse les développeurs — ce sont toujours eux qui cassent tout. À l'opposé, une étude du Microsoft Operations Framework (MOF) menée en 2001 a établi que les organisations aux meilleurs niveaux de service redémarraient leurs serveurs vingt fois moins souvent que la moyenne et subissaient cinq fois moins d'écrans bleus de la mort. Ce que Kevin Behr, Gene Kim et George Spafford ont nommé, dans The Visible Ops Handbook, une culture de la causalité (culture of causality) : une démarche disciplinée de résolution de problèmes, appuyée sur la télémétrie de production pour identifier les facteurs contributifs, plutôt que des redémarrages aveugles.

La télémétrie se définit largement comme « un processus de communication automatisé par lequel des mesures et d'autres données sont collectées à des points distants, puis transmises vers un équipe de réception à des fins de surveillance ». L'objectif est d'en produire partout : dans nos applications et dans nos environnements, en production comme en pré-production, et jusque dans le pipeline de déploiement (deployment pipeline).

Le rapport State of DevOps de 2015 a confirmé l'enjeu : les organisations très performantes (high performers) résolvaient les incidents de production 168 fois plus vite que leurs pairs, avec un MTTR médian compté en minutes contre des jours pour les moins performantes. Les deux pratiques techniques qui rendaient ce MTTR rapide possible étaient l'usage de la gestion de version par l'exploitation et le fait de disposer d'une télémétrie et d'une surveillance proactive en production.

L'étude de cas Etsy : « si ça bouge, mesure-le »

L'exemple fondateur est celui d'Etsy. Michael Rembetsy et Patrick McDonnell ont raconté comment la surveillance de production fut une pièce maîtresse de la transformation DevOps amorcée en 2009, au moment où l'entreprise standardisait toute sa pile technologique vers le LAMP (Linux, Apache, MySQL, PHP), abandonnant une myriade de technologies devenues ingérables. À la conférence Velocity de 2012, McDonnell a décrit le risque : changer des infrastructures critiques sans que les clients le remarquent supposait « plus de métriques pour nous donner la confiance que nous ne cassions rien pendant ces grands chantiers ».

L'équipe a collecté toutes les informations serveur dans Ganglia, les a affichées dans Graphite — un outil open source dans lequel elle a massivement investi — puis a agrégé toutes les métriques, des indicateurs métier aux déploiements. Elle a même doté Graphite d'une « technologie de ligne verticale sans pareille » : un trait vertical superposé à chaque graphe au moment d'un déploiement, pour repérer immédiatement tout effet de bord. Des écrans de télévision dans les bureaux montraient à tous l'état des services.

Les chiffres disent la trajectoire : en 2011, Etsy suivait plus de 200 000 métriques de production à chaque couche de la pile, les trente plus importantes étant affichées en évidence sur un « tableau de bord de déploiement » ; en 2014, le compteur dépassait 800 000 métriques. Comme l'a résumé Ian Malpass, ingénieur chez Etsy : « Si l'ingénierie d'Etsy a une religion, c'est l'Église des graphes. Si ça bouge, on le mesure. Parfois on dessine même le graphe d'une chose qui ne bouge pas encore, au cas où elle déciderait de se faire la malle… Tout mesurer est la clé pour aller vite, mais la seule façon d'y parvenir est de rendre la mesure facile. »

Bâtir une infrastructure de télémétrie centralisée

La surveillance et la journalisation ne datent évidemment pas d'hier : des générations d'ingénieurs ont utilisé des cadres comme HP OpenView, IBM Tivoli ou BMC Patrol. Le problème historique tient aux silos : le développement ne journalise que ce qui intéresse les développeurs, l'exploitation ne surveille que l'état « en marche / arrêté » des environnements. Résultat, quand survient un événement fâcheux, personne ne peut dire pourquoi le système entier dévie ni quel composant précis défaille.

Dans The Art of Monitoring, James Turnbull décrit une architecture de surveillance moderne, telle qu'on la trouve chez Google, Amazon ou Facebook, souvent bâtie sur des outils open source (Nagios, Zenoss) déployés à une échelle inatteignable pour le logiciel commercial sous licence de l'époque. Elle repose sur deux composants.

Composant	Rôle	Exemples concrets
Collecte aux trois couches (métier, application, environnement)	Produire la télémétrie sous forme d'événements, de journaux (logs) et de métriques	Logs centralisés via syslog (Linux) ou l'Event Log (Windows) ; métriques système (CPU, mémoire, disque, réseau) via collectd, Ganglia ; APM via AppDynamics, New Relic, Pingdom
Routeur d'événements (event router)	Stocker événements et métriques pour permettre visualisation, tendances, alertes et détection d'anomalies	Stockage et agrégation, alerting par seuil, contrôles de santé — Sensu, Nagios, Splunk, Datadog, Riemann

Une fois les journaux centralisés, on peut les transformer en métriques en les comptant dans le routeur d'événements : un message tel que child pid 14024 exit signal Segmentation fault peut être agrégé en une unique métrique « segfault » à l'échelle de toute l'infrastructure. Devenu métrique, le signal se prête alors aux opérations statistiques — on peut, par exemple, alerter si l'on passe de « dix segfaults la semaine dernière » à « des milliers dans la dernière heure ».

Il faut aussi collecter la télémétrie du pipeline de déploiement : succès ou échec des tests automatisés, déploiements vers chaque environnement, durée des builds et des tests. Si un test de performance ou un build prend soudain deux fois plus de temps que d'habitude, c'est un signe avant-coureur qu'on peut traiter avant la mise en production.

Instrumenter l'application : les niveaux de log appropriés

Une fois l'infrastructure en place, encore faut-il que les applications produisent suffisamment de télémétrie. Scott Prugh, architecte en chef et vice-président du développement chez CSG, en fait l'un des meilleurs retours sur investissement : « Chaque fois que la NASA lance une fusée, des millions de capteurs automatisés rapportent l'état de chaque composant de ce précieux actif. Et pourtant, nous prenons rarement le même soin avec le logiciel. En 2014, nous avons généré plus d'un milliard d'événements de télémétrie par jour, avec plus de cent mille emplacements de code instrumentés. » Le principe : toute fonctionnalité doit être instrumentée — si elle valait la peine d'être implémentée, elle vaut celle d'être mesurée.

Chaque membre de la chaîne de valeur exploite la télémétrie autrement : un développeur en crée temporairement davantage pour diagnostiquer un souci sur son poste, un ingénieur d'exploitation s'en sert pour un problème de production, l'équipe sécurité (Infosec) et les auditeurs vérifient l'efficacité d'un contrôle, un chef de produit suit les résultats métier. Pour servir ces usages, on dispose de niveaux de journalisation distincts.

Niveau	Ce qu'il signale	Déclenche une alerte ?
DEBUG	Tout ce qui se passe dans le programme ; souvent désactivé en production, réactivé ponctuellement pour diagnostiquer	Non
INFO	Actions pilotées par l'utilisateur ou propres au système (ex. « début de transaction par carte »)	Non
WARN	Condition pouvant devenir une erreur (ex. un appel base de données plus long qu'un seuil)	Souvent
ERROR	Conditions d'erreur (échec d'appel d'API, erreur interne)	Oui
FATAL	Arrêt nécessaire (un démon réseau ne peut pas lier sa socket)	Oui

Choisir le bon niveau est crucial. Dan North, ancien consultant ThoughtWorks impliqué dans plusieurs projets fondateurs de la livraison continue, le formule par une image marquante : « Quand vous hésitez entre ERROR et WARN, imaginez qu'on vous réveille à 4 heures du matin. Un toner d'imprimante presque vide n'est pas une ERROR. » Pour la fiabilité et la sécurité, tout événement applicatif significatif devrait être journalisé — la liste d'Anton Chuvakin (Gartner) en recense les catégories : décisions d'authentification et d'autorisation, accès au système et aux données, changements applicatifs (surtout privilégiés), modifications de données, entrées invalides (possibles injections malveillantes), ressources (RAM, disque, CPU, bande passante), santé et disponibilité, démarrages et arrêts, fautes et erreurs, déclenchements de disjoncteurs (circuit breaker), délais, succès ou échec des sauvegardes.

La télémétrie en libre-service : radiateurs d'information

Créer la télémétrie ne suffit pas ; il faut la diffuser à toute l'organisation, de sorte que quiconque veut une information sur un service l'obtienne sans accès privilégié, sans compte de production, sans ouvrir un ticket et attendre des jours qu'on lui configure un graphe. En rendant la télémétrie rapide, facile d'accès et suffisamment centralisée, toute la chaîne de valeur partage une vision commune de la réalité.

C'est l'idée du radiateur d'information (information radiator), défini par l'Agile Alliance comme tout affichage placé dans un endroit très visible pour que l'équipe et les passants saisissent d'un coup d'œil l'information la plus récente — concept hérité du système de production Toyota. Le geste porte deux valeurs : l'équipe n'a rien à cacher à ses visiteurs, et rien à se cacher à elle-même — elle reconnaît et affronte ses problèmes. On peut même pousser la transparence jusqu'aux clients externes via des pages d'état de service publiques, ce qui bâtit la confiance.

À l'inverse, une culture du blâme autour des pannes produit l'exact contraire : les groupes évitent de documenter les changements et d'afficher la télémétrie de peur d'être accusés, ce qui mène à l'inverse de la culture de causalité — la métrique pernicieuse du mean time until declared innocent, à savoir « combien de temps me faut-il pour convaincre tout le monde que ce n'est pas moi qui ai causé la panne ». La télémétrie publique désamorce cette politique délétère : elle permet d'appliquer la méthode scientifique — quelles preuves avons-nous qu'un problème survient ? quels événements et changements ont pu y contribuer ? quelles hypothèses formuler pour relier cause et effet ? — et renforce une relation gagnant-gagnant entre développement et exploitation.

L'étude de cas LinkedIn : InGraphs

LinkedIn illustre le passage du libre-service. En 2010, malgré un volume colossal de télémétrie, les ingénieurs peinaient à y accéder. Comme le racontait Eric Wong, alors stagiaire : « Pour obtenir une chose aussi simple que l'usage CPU de tous les hôtes d'un service donné, il fallait ouvrir un ticket et quelqu'un passait trente minutes à monter un rapport. » Les données venaient de Zenoss, via une interface web lente ; Wong a écrit des scripts Python pour fluidifier le processus, puis a enrichi l'outil — calculs sur plusieurs jeux de données, comparaison hebdomadaire des tendances, tableaux de bord personnalisés. Son projet de stage est devenu InGraphs, l'un des éléments les plus visibles de l'exploitation de LinkedIn. Prachi Gupta, directrice de l'ingénierie, en rapporte une anecdote frappante : la surveillance d'InGraphs liée à un grand fournisseur de webmail s'est mise à décliner, et ce fournisseur n'a réalisé qu'il avait un problème dans son propre système… qu'après que LinkedIn l'a contacté.

Combler les trous de télémétrie

Avec l'infrastructure en place, on identifie les trous qui freinent la détection et la résolution des incidents. Il faut une couverture à tous les niveaux, pour tous les environnements et les pipelines qui les soutiennent.

Niveau métier        ── ventes, chiffre d'affaires, inscriptions,
                        taux d'attrition, résultats des tests A/B
Niveau application   ── temps de transaction, temps de réponse,
                        fautes applicatives
Niveau infrastructure── trafic serveur web, charge CPU, usage disque
  (base, OS, réseau,    (base de données, système, stockage, réseau)
   stockage)
Niveau client        ── erreurs et plantages JS dans le navigateur,
                        temps de transaction mesurés côté mobile
Niveau pipeline      ── état du build (rouge/vert), délais de
  de déploiement        déploiement, fréquence, promotions d'environnement

Surveiller les fautes applicatives et d'infrastructure (arrêts anormaux, exceptions, erreurs de stockage) sert aussi la sécurité : ces erreurs sont souvent l'indice qu'une vulnérabilité est activement exploitée. Après chaque incident, on identifie la télémétrie manquante qui aurait permis une détection plus rapide — mieux encore, on repère ces trous dès la revue par les pairs (peer review), durant le développement de la fonctionnalité.

Au niveau métier, l'objectif dépasse la santé applicative : il s'agit de mesurer dans quelle mesure on atteint les objectifs de l'organisation. Pour un site de commerce, on instrumente tout l'entonnoir d'acquisition (acquisition funnel) — temps total sur le site, clics sur les liens produits, ajouts au panier, commandes finalisées. Ed Blankenship (Microsoft Visual Studio Team Services) décrit ces stades par des « curieux », des « utilisateurs actifs », des « utilisateurs engagés » et des « utilisateurs profondément engagés », chacun appuyé par sa télémétrie. Chaque métrique métier doit être actionnable : si elle ne peut informer une décision produit ni nourrir une expérimentation A/B, c'est une métrique de vanité (vanity metric) qu'on stocke sans l'afficher ni alerter dessus.

Le couplage des métriques crée le contexte décisif. Si l'on voit les inscriptions chuter à 20 % de la norme quotidienne et, simultanément, toutes les requêtes base de données s'allonger d'un facteur cinq, on sait où concentrer l'investigation. Jody Mulkey, directeur technique de Ticketmaster/LiveNation, en tire une règle de management : « Plutôt que de mesurer l'exploitation à l'aune du temps d'indisponibilité, je trouve bien meilleur de mesurer le développement et l'exploitation à l'aune des vraies conséquences métier de l'indisponibilité : combien de revenu aurions-nous dû atteindre, mais que nous n'avons pas atteint. »

Analyser la télémétrie pour anticiper

Voir les problèmes quand ils surviennent ne suffit pas : on veut découvrir les variances et les signaux de défaillance de plus en plus faibles tapis dans la télémétrie, pour devancer les catastrophes. Netflix en offre l'illustration de référence. Roy Rapoport posait ainsi le défi : « Étant donné un troupeau de bétail censé être identique et se comporter pareil, lequel se distingue des autres ? Plus concrètement, sur un cluster de calcul de mille nœuds sans état, tous exécutant le même logiciel sous une charge similaire, comment trouver les nœuds qui ne ressemblent pas aux autres ? »

La technique employée en 2012, la détection de valeurs aberrantes (outlier detection), consiste à calculer la « normale du moment » pour la population de nœuds, puis à repérer ceux qui n'épousent pas ce motif et à les retirer de la production. « On peut signaler automatiquement les nœuds déviants sans avoir à définir ce qu'est le comportement "correct", explique Rapoport. Et comme nous sommes conçus pour fonctionner de manière résiliente dans le cloud, nous ne demandons rien à personne en exploitation : nous tuons simplement le nœud malade et nous le journalisons ou notifions les ingénieurs. » Le procédé Server Outlier Detection a, selon lui, « massivement réduit l'effort pour trouver les serveurs malades et, surtout, le temps pour les réparer », avec un bénéfice majeur sur la santé mentale des équipes, l'équilibre vie-travail et la qualité de service.

Moyennes, écarts-types et leurs limites

La technique statistique la plus simple consiste à calculer la moyenne (µ) et l'écart-type (σ) d'une métrique, puis à filtrer les valeurs s'écartant fortement de la norme. Pour une distribution gaussienne (la courbe en cloche), les premier, deuxième et troisième écarts-types contiennent respectivement 68 %, 95 % et 99,7 % des données. On peut donc alerter au-delà de trois écarts-types et n'attendre, en théorie, que 0,3 % de déclenchements. La grande vertu : personne n'a eu à fixer un seuil statique — chose impraticable quand on suit des centaines de milliers de métriques.

Mais beaucoup de jeux de données d'exploitation ne sont pas gaussiens. Le Dr Toufic Boubez prévient : « Non seulement on sera réveillé à 2 heures du matin, mais aussi à 2 h 37, 4 h 13, 5 h 17 — c'est ce qui arrive quand la donnée surveillée n'a pas de distribution gaussienne. » Le Dr Nicole Forsgren précise : « En exploitation, beaucoup de nos données suivent une distribution dite du khi-deux (chi squared). Utiliser les écarts-types y mène non seulement à sur- ou sous-alerter, mais aussi à des résultats absurdes : quand vous calculez le nombre de téléchargements simultanés situés à trois écarts-types sous la moyenne, vous obtenez un nombre négatif, ce qui n'a évidemment aucun sens. »

Les deux pathologies sont graves. La sur-alerte réveille inutilement les ingénieurs au milieu de la nuit — par exemple sur un nombre de téléchargements par minute dont l'histogramme est nettement asymétrique vers le bas. La sous-alerte est tout aussi dangereuse : si le nombre de transactions complétées chute de 50 % en plein jour à cause d'une panne logicielle mais reste à l'intérieur de trois écarts-types, aucune alerte ne se déclenche — et ce sont les clients qui découvriront le problème avant nous.

Instrumenter les alertes utiles

Tom Limoncelli, ancien Site Reliability Engineer chez Google, propose un exercice radical : « Dans un monde idéal, on supprimerait toutes les alertes existantes. Puis, après chaque panne visible par l'utilisateur, on se demanderait quels indicateurs l'auraient prédite, et on les ajouterait. Et on recommence. On n'a alors que des alertes qui préviennent les pannes, au lieu d'être bombardé d'alertes une fois la panne déjà survenue. » Concrètement, on analyse les incidents graves des trente derniers jours et l'on dresse la liste de la télémétrie qui aurait permis une détection plus précoce. Si un serveur web NGINX a cessé de répondre, les indicateurs précurseurs auraient été, au niveau applicatif, des temps de chargement croissants ; au niveau système, une mémoire ou un espace disque en baisse ; au niveau base de données, des transactions plus lentes ; au niveau réseau, une chute du nombre de serveurs actifs derrière le répartiteur de charge. En répétant l'exercice sur des signaux de défaillance de plus en plus faibles, on trouve les problèmes toujours plus tôt.

Détection d'anomalies pour données non gaussiennes

Quand la donnée n'est pas gaussienne, on recourt à la détection d'anomalies (anomaly detection), « la recherche d'éléments ou d'événements qui ne se conforment pas à un motif attendu ». Tarun Reddy, de Rally Software, encourage la collaboration entre exploitation et statistique : son équipe verse toutes les métriques de production dans Tableau, et une ingénieure d'exploitation formée aux statistiques écrit du code R, avec son propre backlog de demandes émanant des autres équipes voulant détecter la variance toujours plus tôt.

Une technique clé pour les séries temporelles est le lissage (smoothing) par moyenne mobile (moving average) : chaque point est moyenné avec les autres points de sa fenêtre glissante (sliding window), ce qui efface les fluctuations de court terme et révèle les tendances de fond. Des filtres plus exotiques existent : la transformée de Fourier rapide (FFT), et surtout le test de Kolmogorov-Smirnov (présent dans Graphite et Grafana), utilisé pour comparer deux distributions et déceler similarités ou différences dans des données périodiques ou saisonnières. Or une large part de la télémétrie utilisateur — trafic web, transactions de vente, visionnage de films — présente des motifs journaliers, hebdomadaires et annuels remarquablement prévisibles. On peut visualiser une bande d'anomalie ainsi :

valeur
  │            ┌─── borne haute (moyenne mobile + k·σ)
  │   .  .    /        .                  ●  ← ANOMALIE (hors bande)
  │  . . . . /  . . . .   . . . . . . . .
  │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  ← moyenne mobile (lissée)
  │  . . . . . . . . . .   . . . . . . . .
  │                    .
  │             └─── borne basse (moyenne mobile − k·σ)
  └──────────────────────────────────────────────► temps
   À l'intérieur de la bande : normal.  À l'extérieur : on alerte.

L'étude de cas Netflix : autoscaling prédictif avec Scryer

Netflix a poussé la logique jusqu'à la prédiction avec Scryer, conçu pour pallier les limites d'Amazon Auto Scaling (AAS). AAS souffrait de trois maux : les temps de démarrage des instances AWS (de dix à quarante-cinq minutes) rendaient la capacité additionnelle trop tardive face aux pics brusques ; après une panne, la chute rapide de la demande poussait AAS à retirer trop de capacité ; et AAS ne tenait pas compte des motifs de trafic connus. Netflix a exploité le fait que les habitudes de visionnage de ses abonnés, bien que non gaussiennes, étaient étonnamment régulières et prévisibles du lundi au vendredi. Scryer combine la détection d'aberrations pour écarter les points parasites, puis la FFT et la régression linéaire pour lisser la donnée tout en préservant les pics de trafic légitimes et récurrents. Quelques mois après sa mise en production, Scryer avait nettement amélioré l'expérience de visionnage et la disponibilité, tout en réduisant les coûts EC2.

À retenir

• La télémétrie fait passer l'exploitation d'une culture du redémarrage à une culture de la causalité : appuyés sur les faits, les meilleurs résolvent les incidents jusqu'à 168 fois plus vite — l'essentiel du MTTR consistant à découvrir ce qui a changé.
• Instrumenter doit devenir un réflexe du travail quotidien, à tous les niveaux (métier, application, infrastructure, client, pipeline de déploiement) ; la devise d'Etsy résume tout : « si ça bouge, mesure-le », et créer une métrique doit coûter une seule ligne de code (StatsD).
• L'infrastructure doit être centralisée (collecte aux trois couches, routeur d'événements) et accessible en libre-service via des API et des radiateurs d'information, sans tickets ni comptes privilégiés.
• Une télémétrie publique et partagée devient une source unique de vérité qui désamorce la culture du blâme et le « mean time until declared innocent », rétablissant une relation gagnant-gagnant entre développement et exploitation.
• Pour anticiper, on dépasse les seuils statiques : moyenne et écart-type suffisent pour les données gaussiennes, mais la plupart des données d'exploitation ne le sont pas — d'où la détection d'anomalies (moyenne mobile, bandes, test de Kolmogorov-Smirnov).
• Il faut lutter contre la fatigue d'alerte en n'instrumentant que des alertes actionnables — l'exercice de Limoncelli : partir de zéro alerte et n'ajouter, après chaque panne, que les indicateurs qui l'auraient prédite.
• Netflix illustre l'aboutissement : la détection de valeurs aberrantes retire automatiquement les nœuds malades, et Scryer prédit la demande pour dimensionner la capacité à l'avance — détecter, corriger et devancer avant que le client ne s'aperçoive de quoi que ce soit.