Chaque jour ouvrable, les ingénieurs de Facebook mettent en production des milliers de diffs (c’est-à-dire une modification composée d’un ou plusieurs fichiers). Cette vitesse de code nous permet d’expédier rapidement de nouvelles fonctionnalités, de fournir des corrections de bogues et des optimisations, et de mener des expériences. Cependant, un inconvénient naturel de la rapidité d’exécution dans n’importe quel secteur est le risque de provoquer par inadvertance des régressions de performance, de fiabilité ou de correction fonctionnelle.
Pour nous permettre d’adapter notre infrastructure de développement à ce volume – tout en atténuant et en minimisant les régressions – nous construisons des outils et des mécanismes pour aider les ingénieurs à comprendre si une différence a introduit (ou va introduire) une régression. Nous considérons les réactions que nous recevons de ces outils comme des signaux. Les signaux peuvent être générés par des tests automatisés, des cadres d’analyse statique, des journaux de performances, des crash dumps, des rapports de bogues, des alarmes de suivi de production et des dizaines d’autres sources. Ces signaux peuvent faire surface à n’importe quel stade du cycle de vie du développement. Une diff donnée peut générer des centaines de signaux – y compris des erreurs, des succès et des avertissements – qui peuvent aider un ingénieur à évaluer si cette diff est prête à être introduite dans une branche stable et à commencer à se frayer un chemin vers la production. Une fois qu’une diff a atterri, les signaux sont généralement transmis aux ingénieurs via notre système de gestion des tâches. Un ingénieur peut facilement avoir des centaines de tâches en attente.
Avec autant de signaux générés, les ingénieurs peuvent rapidement se sentir dépassés par le nombre de tâches qu’ils doivent accomplir. Un signal très important peut être négligé parce qu’il a été noyé par des signaux bruyants et de moindre priorité, ce qui rend plus difficile pour les ingénieurs d’évaluer rapidement ou facilement la priorité relative de chaque signal. Ils pouvaient passer des heures à déboguer un problème qui s’avérait être du bruit, ou ne pas disposer des informations nécessaires pour les aider à le diagnostiquer et à le résoudre.
Au fil du temps, à mesure que nous avons construit de nouveaux outils et systèmes de surveillance, le volume du signal a augmenté jusqu’à devenir une distraction persistante. Finalement, nous avons réalisé que nous avions besoin d’un moyen plus efficace pour aider les ingénieurs à voir facilement sur quoi travailler en premier, et à passer moins de temps à déboguer et à réparer les problèmes.
