Dans son rapport de disponibilité pour septembre 2026, GitHub a révélé deux incidents ayant affecté les performances de ses services, parallèlement aux progrès réalisés dans la redistribution de l’infrastructure et l’amélioration de la capacité des bases de données à supporter la charge. L’entreprise indique que les travaux correctifs ne sont pas encore terminés, malgré la mise en œuvre de changements visant à réduire les risques de panne en cas de forte charge ou de défaillance de l’un des composants partagés.
Au 7 octobre, 120 des 160 services de production étaient déployés dans la région Central US, tandis que 13 des 51 bases de données MySQL principales avaient été transférées. Azure traitait 65,4 % du trafic de lecture de l’application principale de GitHub, 48,3 % du trafic de lecture de Git et 80,2 % du trafic de traitement des flux. L’entreprise souligne que ces pourcentages concernent des charges différentes et ne doivent pas être additionnés.
Progrès dans le transfert de l’infrastructure, avec un retard sur le calendrier
GitHub a suspendu les déploiements et l’augmentation du trafic dans Central US le 11 septembre en raison d’un déséquilibre de capacité entre les zones de disponibilité. Les augmentations permanentes ont repris le 18 septembre après la mise à disposition d’une capacité temporaire, mais les travaux visant à assurer une capacité à long terme se poursuivent, avec pour objectif de rendre toute la capacité disponible d’ici la fin octobre. L’entreprise n’a pas atteint son objectif ambitieux de déployer tous les services de production dans cette région avant le 30 septembre.
Lors d’une opération planifiée de basculement d’une base de données, une procédure d’urgence automatisée a séparé les répliques de bases de données dans Central US, provoquant des perturbations pour les clients de la région. GitHub a désactivé cette procédure pendant les basculements planifiés, jusqu’à l’amélioration des mécanismes de récupération.
Réduction de la pression sur les bases de données et confinement des pannes
GitHub a déplacé 24 tables du système d’authentification principal hors de sa plus ancienne base de données partagée, supprimant ainsi environ un million de requêtes par seconde sur les répliques. Environ 980 millions d’enregistrements inutiles de l’historique des modifications ont également été supprimés du cluster prenant en charge Issues et Pull Requests, ce qui a libéré environ 1,8 téraoctet de stockage récupérable. Le nombre hebdomadaire de conflits entre transactions a diminué d’environ 77 % par rapport au pic de juin.
La moitié du trafic de Pull Requests inclus dans l’échantillon peut désormais continuer avec des fonctionnalités limitées lorsqu’une dépendance partagée tombe en panne. Le routage du trafic des bases de données peut également ajouter automatiquement de la capacité pendant les pics : l’un des groupes est passé de 14 à 19 répliques lors d’une hausse de l’activité des Pull Requests le 23 septembre. GitHub a ajouté un mécanisme de contrôle de charge permettant de refuser les requêtes les moins prioritaires avant que les services n’atteignent un niveau de saturation plus large.
Les deux incidents de septembre
Le 13 septembre, une opération de nettoyage des données en arrière-plan a entraîné une hausse de la charge sur une base de données partagée. Le mécanisme de protection surveillait le retard des répliques, mais pas la charge accumulée sur le serveur principal, qui a atteint la limite des connexions disponibles. L’absence d’un délai d’expiration court pour les requêtes a maintenu les gestionnaires de requêtes en attente, tandis qu’une boucle de nouvelle tentative continuait d’envoyer des opérations d’écriture ayant échoué. L’incident a duré 1 heure et 28 minutes et a pris fin après la réduction de la charge interne et l’arrêt de la tâche.
Le 28 septembre, une modification du service exécutant les revues de code Copilot a entraîné l’envoi à certains clients d’une version limitée des résultats de revue au lieu de la version complète contenant les commentaires. Les tâches semblaient donc terminées alors que les revues n’apparaissaient pas dans les pull requests. L’incident a duré 52 minutes et GitHub l’a résolu en annulant la modification, tout en demandant aux clients de relancer les revues concernées.
Qu’est-ce qui change concrètement ?
Les deux incidents montrent que les améliorations de capacité ne suffisent pas à elles seules : la fiabilité dépend également de la détection précoce des défaillances, de l’arrêt des nouvelles tentatives inutiles et de la garantie qu’une tâche ne soit pas déclarée réussie avant la remise effective de ses résultats. GitHub travaille à ajouter des contrôles pour le traitement en arrière-plan, à améliorer le comportement au démarrage des services et à renforcer la surveillance et la remise des résultats de Copilot code review.
GitHub a également enregistré une amélioration de l’infrastructure dédiée à GitHub Actions : le nombre d’opérations Redis mesurées a diminué d’environ 28 % et l’utilisation relative du processeur d’environ 30 %. Une couche de mise en cache séparée a réduit de 84 % la bande passante utilisée par Redis, de 66 % le temps de réponse moyen, de 96 % le temps de réponse médian de la requête d’inventaire principale et de 95 % le nombre de requêtes en attente. Les questions encore ouvertes concernent la capacité de l’entreprise à achever les travaux de capacité et à empêcher la répétition de pannes liées à des dépendances partagées dans les conditions réelles de production.