Contexte de la panne
Le 17 août, GitHub a connu une interruption de service de 7 heures 47 minutes. L’incident a touché l’accès au site github.com, l’authentification, GitHub Actions, les API, les pull‑requests, les issues et même Copilot. Cette indisponibilité a impacté des millions de développeurs et d’organisations à l’échelle mondiale, notamment ceux qui tentaient de livrer du code ce jour‑là.
Il s’agit du deuxième incident majeur du mois, le premier étant une défaillance des actions le 6 août. GitHub indique que les deux pannes sont liées à des défaillances de capacité plutôt qu’à des changements de code ou de configuration.
Analyse des causes techniques
Selon l’enquête interne, le pic de trafic a atteint un niveau jamais observé, dépassant la capacité d’un composant d’infrastructure critique du centre de données Central US. Ce composant, non spécifié mais probablement un répartiteur de charge ou un service de métadonnées, n’a pas pu s’ajuster automatiquement, créant une pression en chaîne qui a provoqué des échecs d’authentification et la perte de plusieurs services dépendants.
Le processus de récupération a été compliqué par un boucle de retry côté client. Les services affectés, notamment Copilot, ont renvoyé des erreurs qui ont incité les clients à réessayer de façon agressive, augmentant ainsi le trafic pendant la phase de remise en service. GitHub a dû limiter ces retries avant de pouvoir réacheminer le trafic en toute sécurité.
Le contexte de charge explique partiellement la panne : les commits mensuels sont passés de 1,4 milliard à 2,9 milliard entre mars et avril, doublant la pression sur les systèmes de stockage et de calcul.
Mesures correctives et plan d’évolution
GitHub a ajouté plus de 3 millions de cœurs CPU, 120 pétaoctets de stockage haute vitesse et a renforcé la capacité réseau. La migration vers Azure a été accélérée ; la plateforme Azure supporte désormais 58 % de la charge de GitHub, contre 12 % en mai, et gère la moitié des opérations Git.
Pour éviter de nouveaux « retry storms », l’entreprise standardise les limites de retry, les budgets de retry et les délais variables entre services. Elle révise également les alertes CPU/mémoire de faible priorité afin d’identifier les composants susceptibles d’échouer lors de pics soudains.
Un objectif clé est de déployer une architecture dont la capacité de lecture s’échelle linéairement avec le nombre de lecteurs, ce qui devrait permettre des lectures « illimitées » pour les plus grands monorepos. Cette évolution sera introduite progressivement, en commençant par les plus gros dépôts.
Enfin, GitHub isole les systèmes critiques et élimine les dépendances partagées afin de réduire la propagation d’une éventuelle panne. Ces actions s’inscrivent dans un plan plus large d’amélioration de l’observabilité, des tests de sécurité et des procédures de déploiement.
