Aujourd'hui, retour sur la panne majeure qui a paralysé GitHub le 17 août dernier pendant près de huit heures. Un incident critique qui remet en question la gestion de la charge et la résilience des plateformes stratégiques. Et sur la base du retex de GitHub, je vous explique tout ça en trois points.

La croissance explosive des usages peut terrasser n'importe quel système

Premier enseignement majeur pour les directions informatiques, la croissance explosive des usages peut terrasser n'importe quel système, aussi robuste soit-il.

Le 17 août, GitHub a subi une interruption de près de huit heures touchant l'authentification, les intégrations, les API et Copilot. La cause n'est ni un bug de code ni une erreur de configuration. C'est un pur problème de capacité face à une explosion du trafic.

En quatre mois, le volume mensuel de commits sur la plateforme a quasiment doublé, passant de 1,4 à 2,9 milliards. Lorsque la charge a atteint un sommet, les composants du centre de données principal n'ont pas réussi à monter en charge.

Mais le vrai piège est venu des clients Copilot : en échouant à se connecter, ils ont déclenché des boucles de réessais massives. Ce phénomène a asphyxié le réseau et bloqué le rétablissement du service.

GitHub a dû injecter en urgence plus de trois millions de cœurs de processeurs

Second enseignement, l'accélération forcée vers le cloud pour absorber la surcharge.

Face à ce pic de charge, l'infrastructure sur site a rapidement trouvé ses limites physiques. GitHub a dû injecter en urgence plus de trois millions de cœurs de processeurs et 120 pétaoctets de stockage.

Mais le véritable salut est passé par l'infrastructure cloud d'Azure. La plateforme y a transféré 58 % de sa charge globale et la moitié de ses opérations Git, contre seulement 12 % quelques mois plus tôt.

Cette migration massive permet d'envisager une nouvelle architecture capable de faire évoluer la capacité de lecture de manière linéaire avec le nombre d'utilisateurs.

GitHub revoit en profondeur son architecture

Enfin, troisième enseignement, la refonte drastique des pratiques opérationnelles.

L'échelle ne sert à rien si un composant secondaire peut effondrer toute la pile technologique.

GitHub revoit donc en profondeur son architecture pour supprimer les dépendances partagées et isoler ses systèmes critiques. Concrètement, cela implique la mise en place de plafonds de réessais, de budgets de requêtes et de délais d'expiration variables pour éviter les réactions en chaîne.

Pour les CTO, la leçon est claire : la résilience exige une isolation stricte et une discipline de reprise sans concession.

Le ZD Tech est sur toutes les plateformes de podcast ! Abonnez-vous !

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.