Le 17 août, GitHub a subi une panne qui a duré 7 heures et 47 minutes. Cette panne a perturbé github.com, l’authentification, GitHub Actions, les API, les pull requests, les issues et Copilot, affectant des développeurs et des organisations du monde entier. Si vous avez essayé de publier des logiciels ce jour-là, nous vous avons laissés en plan.
Il s’agissait de notre deuxième incident majeur en août, après la panne d’Actions du 6 août. En mars et en avril, j’avais partagé les travaux que nous menions pour améliorer la fiabilité de GitHub. Nous avons progressé, mais ces incidents montrent clairement que nous devons accélérer ces travaux.
Que s’est-il passé
Notre enquête a révélé que la panne avait commencé lorsque le trafic a atteint un nouveau pic et qu’un composant critique de l’infrastructure de notre centre de données du centre des États-Unis n’a pas pu monter en charge pour y faire face. La pression sur la capacité qui en a résulté s’est propagée à nos systèmes, provoquant des erreurs d’authentification et perturbant plusieurs services de GitHub.
La récupération a nécessité plusieurs étapes coordonnées. Les équipes ont réacheminé le trafic, isolé l’infrastructure affectée et rétabli progressivement les services. La plupart des services de GitHub ont récupéré plus tôt dans la journée, mais certains services de Copilot ont pris plus de temps. Les erreurs affectant ces services ont déclenché une boucle de nouvelle tentative côté client, ce qui a accru le trafic pendant la récupération. Nous avons d’abord dû atténuer ce comportement avant de pouvoir rétablir le trafic en toute sécurité. L’analyse approfondie de la cause racine comprend une chronologie technique détaillée.
Aucune des deux interruptions n’a été provoquée par une modification du code ou de la configuration. Une capacité insuffisante était à l’origine des deux incidents. Nous n’avons pas pu faire évoluer les composants critiques avant que la demande ne dépasse la capacité. Depuis avril, le nombre mensuel de commits est passé de 1,4 milliard à 2,9 milliards. Cette croissance explique la pression exercée sur nos systèmes, mais elle n’excuse pas ces interruptions.
Ce que nous avons fait et ce qui nous attend
Dans le cadre des engagements de fiabilité que nous avons pris au début de cette année, nous nous sommes concentrés sur trois priorités : ajouter de la capacité, améliorer l’efficacité et éliminer les goulets d’étranglement de l’architecture. Depuis, nous avons ajouté plus de 3 millions de cœurs CPU, 120 pétaoctets de stockage haute vitesse et une capacité réseau considérablement accrue. Dans nos centres de données existants, nous avons installé autant de matériel que notre capacité électrique actuelle le permettait, tout en accélérant notre migration vers Azure.
Aujourd’hui, Azure prend en charge environ 58 % de la charge de la plateforme de GitHub et la moitié de l’ensemble des opérations Git ; cette proportion est en hausse par rapport aux 12 % de la charge de la plateforme en mai. Cette infrastructure en expansion a également permis de soutenir la croissance des exécutions de tâches GitHub Actions présentée ci-dessous.
L’infrastructure et la capacité d’Azure ont également accéléré nos efforts pour faire évoluer les plus grands monorepos. Notre prochain jalon consiste à mettre en place une architecture qui fait évoluer linéairement la capacité de lecture avec le nombre de lecteurs et permet des opérations de lecture illimitées.
Nous la déploierons progressivement, en commençant par les plus grands monorepos.
La mise à l’échelle n’est pas le seul défi auquel nous sommes confrontés. À mesure que la vitesse et la complexité du changement ont augmenté, nos pratiques opérationnelles existantes n’ont pas réussi à suivre. Nous avons orienté les équipes et les ressources vers la disponibilité, et investi dans des tests plus robustes, des processus de mise en production plus sûrs, une meilleure observabilité et des mécanismes d’alerte plus efficaces. Nous avons progressé, mais ce travail n’est pas encore terminé.
En outre, nous isolons les systèmes critiques les uns des autres et supprimons les dépendances communes entre eux. Ce travail vise à réduire la probabilité d’une interruption et à en limiter l’impact lorsqu’elle survient.
Nous tirons les enseignements de chaque interruption et ajoutons de nouveaux travaux à notre feuille de route consacrée à la disponibilité. Les incidents des 6 août et 17 août ont donné lieu à deux changements urgents.
Premièrement, nous mettons en place des limites de tentatives répétées cohérentes, des budgets de tentatives répétées et des délais d’expiration variables dans les interactions entre services afin d’éviter les tempêtes de tentatives répétées et la surcharge en cascade. Deuxièmement, nous réexaminons les alertes de faible priorité concernant le CPU et la mémoire afin d’identifier les composants susceptibles de tomber en panne lors de pics soudains de trafic.
Notre engagement en faveur d’une haute disponibilité n’est pas seulement une promesse technique.