Résumé

  • GitHub indique que l’incident du 17 août a duré 7 h 47. Au plus fort de la panne, environ 20 % des requêtes web et API échouaient, contre près de 50 % pour le téléchargement d’archives et de contenus bruts.
  • Selon l’entreprise, un sidecar Istio a atteint sa limite de concurrence sans déclencher la bonne montée en charge. Quatre nœuds HAProxy ont ensuite épuisé leur capacité de flux, tandis que les relances ont fait passer le service de jetons Copilot de 7 000–9 000 à 70 000–100 000 requêtes par seconde.

Le transfert d’une partie du trafic vers la Virginie du Nord a servi des requêtes qui échouaient dans le centre des États-Unis. Il n’a pourtant pas suffi à clore l’incident.

Dans la mise à jour détaillée de l’incident zkxwbgr0cnmx, GitHub situe la dégradation entre 13 h 28 et 21 h 15 UTC le 17 août. Les Issues, pull requests, API, Actions et Copilot ont subi des erreurs ou de la latence. Le taux d’erreur a culminé autour de 20 % pour les usages web et API et de 50 % pour les archives et les fichiers bruts des dépôts.

La panne ne concernait pas uniquement les opérations de développement visibles. L’entreprise cite aussi l’authentification SAML et OIDC, SCIM et Team Sync. Des workflows Actions exécutés sur GitHub Enterprise Cloud avec résidence des données ont été touchés lorsqu’ils dépendaient d’étapes publiques hébergées sur GitHub.com. Cette précision ne prouve ni une perte de données ni une sortie de la région choisie: elle décrit une dépendance d’exécution à un autre domaine de service.

GitHub place l’origine immédiate dans les équilibreurs de charge de son centre Central US. Un pic inédit de trafic a rencontré un pod sidecar Istio arrivé à sa limite de concurrence. La règle d’autoscaling surveillait le service hôte, mais pas la limite du sidecar. Le composant contraint n’a donc pas ajouté de capacité au rythme de la demande.

L’échec s’est propagé. Quatre nœuds HAProxy ont fini par épuiser leurs limites de flux, ce qui a dégradé la passerelle d’authentification et élargi les erreurs. La mise en pause simultanée de HAProxy sur ces nœuds a produit, selon GitHub, une reprise générale immédiate. La plupart des services avaient retrouvé un fonctionnement normal vers 16 h 36 UTC, mais Actions est resté dégradé jusqu’à environ 18 h 03.

Le reliquat Copilot suivait une autre dynamique. Les réponses tardives d’un point d’accès interne ont révélé un bogue latent de relance dans VS Code. Une opération de jeton en échec pouvait engendrer plusieurs demandes supplémentaires puis entrer dans une boucle. Le trafic du Copilot Token Service, normalement compris entre 7 000 et 9 000 requêtes par seconde, a atteint 70 000 à 100 000 requêtes par seconde.

La solution a consisté à réduire la production de nouvelles demandes, et pas seulement à leur offrir une autre destination. GitHub a diminué temporairement les relances de la passerelle, renvoyé des réponses HTTP 403 à certaines demandes de jetons Copilot au niveau des équilibreurs, puis rouvert le trafic progressivement site par site. Le service de jetons a été pleinement rétabli vers 21 h 02, treize minutes avant la clôture du dossier.

Des attaques de scraping sur les points d’accès codeload ont compliqué l’intervention. GitHub ne chiffre cependant pas leur part dans la saturation. Les faits publiés attribuent la chaîne initiale à la limite du sidecar, à la règle de montée en charge incomplète, à l’épuisement des flux HAProxy et à l’amplification par les relances.

La documentation publique permet de comprendre les surfaces traversées. Les workflows réutilisables peuvent appeler des définitions conservées dans un dépôt public. Le guide des runners hébergés cite GitHub.com, l’API, les domaines Actions et codeload.github.com parmi les destinations nécessaires à l’exécution et au téléchargement des actions.

Pour l’identité, GitHub présente SAML SSO et SCIM comme des moyens centraux de contrôler l’accès et le cycle de vie des comptes. Sa documentation sur la résidence des données décrit des sous-domaines GHE.com dédiés et le choix entre plusieurs régions. L’incident rappelle qu’une localisation de stockage ne décrit pas à elle seule tous les chemins d’identité, d’automatisation ou de téléchargement nécessaires pour exploiter le service.

GitHub annonce maintenant une correction de l’autoscaling tenant compte de la capacité des sidecars, un audit des limites Istio, une révision des relances côté passerelle et côté client, un traitement du comportement de VS Code, ainsi qu’un meilleur suivi des équilibreurs et des bascules régionales. Ce sont des mesures annoncées. Le dossier public ne prouve pas encore leur déploiement ni leur efficacité.

Les clients peuvent déjà distinguer leurs propres chemins de reprise. Lire un dépôt, appeler l’API, s’authentifier par SSO, synchroniser une équipe, charger une définition de workflow, démarrer un runner et obtenir un jeton Copilot ne sont pas une seule opération. Une vérification séparée de ces fonctions vaut mieux qu’un seul voyant « opérationnel ».

Les bonnes pratiques de l’API REST recommandent par ailleurs de respecter Retry-After, l’heure de réinitialisation des limites et un délai exponentiel en cas d’échecs répétés. Ce guide concerne les intégrations clientes, pas la logique interne de la panne. Il illustre néanmoins la même contrainte: une relance non bornée transforme une attente en demande supplémentaire.

Source