veilletech.frCe qui se passe
Le 17 août, GitHub a connu une panne de 7 heures et 47 minutes. Elle a touché github.com, l'authentification, GitHub Actions, les API, les pull requests, les issues et Copilot, partout dans le monde.
C'était le deuxième incident majeur du mois, après une défaillance d'Actions le 6 août. Le billet est signé du directeur technique, Vladimir Fedorov, et fait suite à deux publications de mars et avril sur la fiabilité de la plateforme.
La cause
L'enquête pointe un composant d'infrastructure critique du centre de données Central US qui n'a pas réussi à monter en charge quand le trafic a atteint un nouveau pic. La pression de capacité s'est propagée aux systèmes interconnectés, provoquant des échecs d'authentification en cascade.
Le point à retenir est explicite dans le billet : aucun des deux incidents n'est dû à un changement de code ou de configuration. Les deux sont des défaillances de capacité. Des composants critiques n'ont pas été redimensionnés avant que la demande ne dépasse ce qu'ils pouvaient encaisser.
Le chiffre qui éclaire la pression : depuis avril, les commits mensuels sont passés de 1,4 à 2,9 milliards. La plateforme a doublé de charge en quatre mois. GitHub précise que cette croissance explique la tension, sans excuser les pannes.
Le détail qui vous concerne
La reprise a demandé plusieurs actions coordonnées — réacheminement du trafic, isolation de l'infrastructure touchée, restauration par étapes. La plupart des services sont revenus dans la journée. Certains services Copilot ont mis plus longtemps, et la raison mérite d'être lue attentivement.
Les erreurs de ces services ont déclenché une boucle de réessai côté client, qui a augmenté le trafic pendant la reprise. Les équipes ont dû neutraliser ce comportement avant de pouvoir rétablir le trafic en sécurité.
C'est la tempête de réessais, le mode de défaillance le plus banal des architectures distribuées : le client qui retente en boucle empêche le système de se relever, et transforme une panne courte en panne longue.
Ce qui est fait
Sur le volet capacité, GitHub annonce plus de 3 millions de cœurs processeur ajoutés, 120 pétaoctets de stockage rapide, et une accélération de la migration vers Azure — qui sert aujourd'hui environ 58 % de la charge de la plateforme et la moitié des opérations Git, contre 12 % en mai.
Le prochain jalon annoncé est une architecture dont la capacité de lecture évolue linéairement avec le nombre de lecteurs, déployée d'abord sur les plus gros monorepos.
Deux changements immédiats découlent des incidents des 6 et 17 août. D'abord, l'application de limites de réessai, de budgets de réessai et de délais variables de façon cohérente entre services, pour prévenir les tempêtes de réessais et les surcharges en cascade. Ensuite, la revue des alertes processeur et mémoire de faible priorité, pour repérer les composants susceptibles de céder lors d'un pic soudain.
Ce que ça change pour vous
Votre échelle n'est pas celle de GitHub, et la moitié de ces mesures ne vous concerne pas. Une, si.
Allez relire vos politiques de réessai — dans vos clients HTTP, vos workers, vos appels entre services. Sans plafond, sans budget et sans recul exponentiel avec gigue, votre code aggrave la panne qu'il subit. C'est vrai à trois serveurs comme à trois millions de cœurs.
Fedorov conclut sans détour : la communauté ne peut travailler que si elle peut compter sur GitHub, « et le 17 août, vous ne le pouviez pas ».