GitHub a publié son compte rendu de la panne de près de huit heures de cette semaine, attribuant la douleur des développeurs à des équilibreurs de charge saturés, à une politique de mise à l’échelle automatique défectueuse et à un « bug latent de nouvelle tentative dans Visual Studio Code ».
Selon GitHub, les problèmes ont commencé à 13 h 28 UTC le 17 août et n’ont été entièrement résolus qu’à 21 h 15 UTC – un incident de 7 heures et 47 minutes qui a produit un nombre élevé d’erreurs dans les problèmes, les demandes d’extraction, les API, les actions et le copilote.
La cause immédiate était la saturation du réseau sur les équilibreurs de charge dans les installations de l’entreprise au centre des États-Unis, déclenchée lorsqu’un side-car Istio atteignait sa limite de concurrence.
AD ENREGISTREMENT
L’autoscaling ajouterait sûrement de la capacité une fois ces limites atteintes ? Hélas, non. Une politique mal configurée surveillait le service hôte mais pas la limite de concurrence du side-car, permettant ainsi le développement d’un échec en cascade. « Le problème », selon GitHub, « a été aggravé par une logique de nouvelle tentative optimiste qui surchargeait les équilibreurs de charge internes ».
AD ENREGISTREMENT
Les ingénieurs ont atténué le problème en réduisant temporairement les tentatives de passerelle grâce à un changement de code et en configurant les équilibreurs de charge pour rejeter les demandes entrantes du Copilot Token Service avec des réponses HTTP 403.
Ah oui, copilote. GitHub a expliqué : « Les réponses retardées à un seul point de terminaison interne ont déclenché un bug latent de nouvelle tentative dans VS Code qui a amplifié le trafic d’environ 10 fois et a retardé la récupération du service de jetons Copilot. »
La plupart des services ont été récupérés à 16h36 UTC et les actions à 1803 UTC, mais le service de jetons Copilot a duré jusqu’à 2102 UTC.
« Les facteurs qui ont compliqué la récupération comprenaient un certain nombre d’attaques de scraping sur les points de terminaison de chargement de code », a ajouté GitHub.
Le tentacule de Microsoft indique qu’il corrigera les politiques de mise à l’échelle automatique, examinera les limites de tentatives, auditera les paramètres de concurrence Istio et corrigera le comportement de VS Code « qui a amplifié le trafic des jetons Copilot ».
Ce dernier incident pourrait être le point de bascule qui pousse certains développeurs à se précipiter pour trouver une alternative. Moritz Plassnig, PDG de CloudBees, a noté dans un article sur LinkedIn que « Cursor, OpenAI et plusieurs petites startups créent déjà des solutions compétitives ».
« GitHub ne sera pas la solution par défaut à l’avenir et nous envisageons un écosystème beaucoup plus divisé (ce qui est bon et mauvais). »
Les résultats feront sourciller les ingénieurs. Une tempête de mauvaises configurations et de nouvelles tentatives a dégradé un élément essentiel de l’infrastructure dont dépendent de nombreuses organisations, laissant les développeurs incapables de travailler normalement pendant des heures.
AD ENREGISTREMENT
Les problèmes de fiabilité de GitHub remontent bien au-delà de cette semaine, comme le reconnaît l’entreprise elle-même. Les développeurs ont le choix, et l’équation douleur/gain ne semble pas trop favorable pour la cabane source. Comme l’a souligné Plassnig, des alternatives continuent de surgir – parfois au moment le plus délicat.
Alors que GitHub chancelait, Cursor, propriété de SpaceX, a annoncé une première version bêta d’Origin Code Hosting. ®
