Résumé
- L’incident a commencé le 24 juillet à 16 h 04 UTC; l’analyse détaillée a été ajoutée le 29 juillet à 02 h 36 min 25 s UTC.
- Dans l’une des trois zones physiques, une cage a perdu ses liaisons entre commutateurs spine et couche d’agrégation.
- Les chemins encore actifs ont saturé après la perte de 25 % de la capacité d’interconnexion disponible.
- GitHub chiffre 10 % d’échecs Actions, 5 % de démarrages retardés mais réussis, 27 % d’interactions Issues lentes ou expirées, ainsi que 4 % d’erreurs Copilot et 4 % de poussées Git touchées.
- Le fournisseur a utilisé des fibres réservées à une extension future, retrouvé assez de capacité à 17 h 07, restauré tous les chemins à 17 h 36 et accélère le passage de 100 à 400 Gbit/s.
La panne est apparue sous plusieurs noms de produits, mais le nouveau document les ramène à une contrainte physique commune. Cette précision change la lecture opérationnelle. Les équipes n’ont pas seulement à constater que GitHub est revenu au vert; elles doivent déterminer quelles actions ont échoué, lesquelles ont attendu et lesquelles ont pu réussir malgré un délai côté client.
La date de l’explication ne doit pas déplacer la panne
Les services ont été perturbés le 24 juillet. Le 29 juillet, GitHub a enrichi l’entrée déjà résolue avec la topologie, les pourcentages d’impact, la voie de secours et la mesure corrective. L’événement journalistique de cette fenêtre est donc la publication de preuves nouvelles, pas une récidive.
Cette séparation évite deux erreurs. La première serait de dater l’arrêt au 29 juillet. La seconde serait de confondre cet incident avec d’autres alertes GitHub des jours suivants. L’identifiant yjysg0xrl67m conserve sa propre chronologie et ses propres composants.
L’analyse explique ce qui s’est passé après la perte des liaisons: la capacité restante a été saturée et les paquets ont été perdus. Elle ne nomme pas l’équipement, l’opération de maintenance ou l’événement qui a provoqué la perte initiale. La cause déclenchante reste donc inconnue.
Une même congestion, des effets incompatibles entre eux
GitHub décrit une architecture leaf-spine par cage, reliée à une couche d’agrégation dans chaque zone. La rupture s’est produite entre la cage et cette agrégation dans une zone sur trois. Les charges dépendantes des ressources de calcul de cette cage ont alors rencontré des pertes intermittentes.
Les chiffres ne partagent pas le même dénominateur. Dix pour cent des tâches Actions ont échoué; 5 % ont réussi mais commencé en retard. Vingt-sept pour cent des interactions avec Issues ont été lentes ou ont expiré. Quatre pour cent des requêtes Copilot ont renvoyé une erreur, avec reprise automatique pour la plupart. Quatre pour cent des poussées Git ont été touchées. L’authentification a ralenti, tout en gardant un taux d’erreur inférieur à 1 %.
Il serait faux d’additionner ces taux pour fabriquer un pourcentage mondial. Leur intérêt est ailleurs: une même perte de paquets devient échec, attente, expiration ou nouvelle tentative selon l’état et la politique de chaque produit.
La reprise a emprunté de la capacité au futur
Pour contourner la panne, GitHub a rerouté les connexions vers des fibres prévues pour de futures augmentations de capacité. À 17 h 07, le réseau disposait de nouveau d’assez de marge pour éliminer la perte de paquets. La majorité des services semblait rétablie à 17 h 16; tous les chemins et services étaient sains à 17 h 36.
Ces trois horaires montrent que « réseau suffisant », « applications majoritairement rétablies » et « topologie complète » ne sont pas le même seuil. Ils devraient être conservés séparément dans un compte rendu client.
La fibre de réserve a fourni une mitigation utile. GitHub ne dit toutefois pas quelle marge restait pendant cette configuration temporaire ni si cette voie est déjà redevenue disponible pour une autre urgence.
Les demandes à rejouer ne sont pas toutes sans danger
La documentation GitHub permet de relancer un workflow, ses tâches en échec ou une tâche précise. La relance utilise les droits de l’acteur initial, le même commit et la même référence Git. Cette continuité aide au diagnostic, mais ne garantit pas l’idempotence d’un déploiement, d’une publication ou d’une migration de données.
Une tâche simplement retardée a pu finir après le lancement d’une exécution plus récente. Une poussée signalée en erreur peut avoir modifié la référence distante avant la rupture de réponse. Une modification d’Issue qui expire côté client peut néanmoins avoir été enregistrée. La bonne reprise commence donc par une lecture de l’état effectif.
Les nouvelles tentatives automatiques de Copilot réduisent les erreurs visibles, mais peuvent masquer une dégradation du premier essai. De même, moins de 1 % d’erreurs d’authentification n’efface pas la hausse de latence. Chaque file exige son propre contrôle.
Le passage à 400 Gbit/s doit être mesuré sous défaillance
GitHub indique que les anciennes cages emploient des interfaces de 100 Gbit/s et accélère leur remplacement par des interfaces de 400 Gbit/s. Cette réponse vise directement la saturation: davantage de bande passante à chaque niveau doit fournir plus de marge lorsqu’un chemin ou un équipement disparaît.
Mais quadrupler un débit nominal ne prouve pas à lui seul une résilience quadruplée. Le calendrier, le nombre de cages restantes, le seuil de réserve et les scénarios de perte acceptés ne sont pas publiés. La détection, l’isolation et l’accès aux outils de crise comptent aussi.
Le bon indicateur sera la capacité restante pendant une panne définie. GitHub pourra montrer qu’une perte cage-agrégation ne sature plus les chemins survivants et que l’équipe détecte l’écart avant les utilisateurs.
Fermer la boucle physique et applicative
Les clients devraient conserver les identifiants de tâches échouées ou retardées, vérifier les références Git distantes, rechercher les mutations Issues potentiellement dupliquées et mesurer les latences d’authentification. Une reprise sûre réconcilie les effets avant de répéter les écritures.
Un prochain rapport utile préciserait le déclencheur de la perte de connectivité, la marge obtenue après reroutage, le calendrier du programme 400 Gbit/s et les contrôles qui empêchent une cage de saturer le reste. Il devrait aussi indiquer si les fibres d’extension sont de nouveau disponibles comme réserve.
Le document du 29 juillet donne enfin une forme physique à une dépendance souvent présentée comme abstraite. Un quart de capacité a disparu; les chemins survivants se sont remplis; chaque produit a créé sa propre file de reprise.
