GitHub a révélé que la panne qui a touché sa plateforme le 17 août et a duré 7 heures et 47 minutes résultait de l’incapacité d’un composant d’infrastructure critique à évoluer lorsque le trafic a atteint un niveau record dans son centre de données de la région centrale des États-Unis. La pression sur la capacité qui en a résulté a propagé les problèmes à plusieurs systèmes. Le service github.com, l’authentification, GitHub Actions, les API, les pull requests et les issues ont été affectés, ainsi que Copilot, tandis que les répercussions de la panne se sont étendues aux développeurs et aux entreprises du monde entier.
L’incident constitue le deuxième événement majeur auquel GitHub a été confronté en août, après une défaillance ayant touché Actions le 6 août. L’entreprise a expliqué que l’enquête n’avait établi aucun lien entre ces deux incidents et une modification du code ou de la configuration ; leur cause fondamentale était plutôt une capacité insuffisante, car des composants essentiels n’avaient pas été étendus avant que la demande ne dépasse leurs capacités. Selon GitHub, le nombre mensuel de commits est passé de 1,4 milliard en avril à 2,9 milliards depuis lors, mais l’entreprise a reconnu que la croissance de l’utilisation ne la dispense pas de sa responsabilité d’empêcher les pannes.
Comment les services ont-ils récupéré ?
Le rétablissement a nécessité de rediriger le trafic, d’isoler l’infrastructure touchée et de réactiver les services par étapes. La plupart des services GitHub ont repris leur fonctionnement le jour même, mais certains services Copilot ont pris plus de temps. Les erreurs de ces services ont provoqué une boucle de nouvelles tentatives côté client, ce qui a accru le trafic pendant le rétablissement. Les équipes ont donc dû limiter ce comportement avant de rediriger le trafic en toute sécurité.
GitHub indique que le rapport complet d’analyse des causes profondes comprend une chronologie technique détaillée, tandis que l’entreprise poursuit la mise en œuvre des engagements annoncés précédemment pour améliorer la disponibilité et la fiabilité.
Qu’est-ce qui change concrètement ?
Le plan de GitHub met l’accent sur l’augmentation de la capacité, l’amélioration de l’efficacité et la suppression des goulets d’étranglement architecturaux. L’entreprise a annoncé avoir ajouté plus de 3 millions de cœurs CPU et 120 pétaoctets de stockage haute vitesse, ainsi que des capacités réseau supplémentaires. Elle a également installé autant de matériel que possible dans les limites de l’alimentation disponible dans ses centres de données actuels, tout en accélérant sa transition vers Azure.
Azure prend actuellement en charge environ 58 % de la charge de la plateforme GitHub et la moitié des opérations Git, contre 12 % de la charge de la plateforme en mai. Cette expansion a également contribué à soutenir la croissance des exécutions de tâches GitHub Actions. L’entreprise travaille sur une nouvelle architecture permettant d’augmenter linéairement la capacité de lecture des dépôts volumineux avec le nombre de lecteurs, ce qui permettrait théoriquement un nombre illimité d’opérations de lecture. Son déploiement commencera progressivement dans les plus grands monorepos.
Réduire l’étendue des pannes et prévenir les tempêtes
GitHub ne considère pas l’extension de capacité comme suffisante à elle seule ; l’entreprise a affecté des équipes et des ressources supplémentaires à la disponibilité et investi dans des tests plus robustes, des déploiements plus sûrs, une meilleure surveillance et des alertes plus efficaces. Elle isole également les systèmes critiques et supprime les dépendances partagées entre eux afin de réduire la probabilité d’une panne et d’en limiter l’impact si elle survient.
À la suite des incidents des 6 et 17 août, l’entreprise appliquera des limites et des budgets unifiés pour les nouvelles tentatives, ainsi que des délais d’expiration variables dans les communications entre services, afin d’empêcher les tempêtes de nouvelles tentatives et les charges en cascade. Elle réexamine également les alertes de faible priorité concernant le CPU et la mémoire afin de détecter les composants susceptibles de tomber en panne lors de hausses soudaines du trafic. Ces mesures revêtent une importance directe pour les développeurs et les entreprises qui dépendent de GitHub pour créer, livrer et exploiter leurs logiciels, car le rétablissement de la plateforme ne consiste pas seulement à restaurer le service, mais aussi à empêcher la répétition de la panne et à en limiter l’étendue lorsqu’elle se produit.