GitHub rapporte 7 h 47 de perturbations le 17 août, avec des rétablissements différents selon les services. Son analyse relie une limite de concurrence du sidecar, la saturation des répartiteurs et une boucle de nouvelles tentatives côté client.
Le goulot était hors du conteneur surveillé
Le rapport d’incident officiel identifie un sidecar Istio atteignant ses limites de concurrence alors que la règle de dimensionnement surveillait le service principal. Quatre nœuds HAProxy ont ensuite épuisé leurs limites de flux, affectant le chemin d’authentification partagé.
Le même rapport situe le trafic habituel de jetons Copilot à 7-9 milliers de requêtes par seconde, contre 70-100 milliers pendant l’incident. Il attribue cette amplification à un défaut latent de nouvelles tentatives dans VS Code. Ce sont les chiffres opérationnels de GitHub, pas des mesures PeopleAreGeek.
L’explication du directeur technique du 20 août décrit une pression de capacité, sans changement de code ou de configuration déclencheur. Une configuration inchangée peut devenir insuffisante quand la demande augmente.
Pourquoi ajouter de la capacité ne suffit pas toujours
Prenons un service fictif recevant 1 000 opérations originales par seconde. Si chacune produit une tentative initiale et neuf reprises pendant un échec persistant, le destinataire reçoit jusqu’à 10 000 tentatives pour ces opérations. Il n’a pas dix fois plus d’utilisateurs ; il doit traiter dix fois plus de travail tenté.
Ce calcul suppose que les dix tentatives ont lieu et ne décrit pas l’algorithme exact de GitHub. Il montre pourquoi compter les opérations originales et compter les tentatives répond à deux questions. Un délai étale les reprises dans le temps ; un budget de reprises limite le travail supplémentaire admis. Aucun des deux ne doit être confondu avec une répétition illimitée jusqu’au succès.
Surveiller la dépendance qui transporte les requêtes
Une revue de service mesh peut relever séparément la demande et la capacité de l’application, du sidecar et de la passerelle. Incluez concurrence, files d’attente et erreurs lorsque le composant les expose. Un CPU applicatif peu chargé n’exclut pas une limite de connexions ou de concurrence du proxy.
Simulez ensuite une panne bornée de dépendance dans un environnement de test. Observez si les reprises consomment la marge nécessaire à la récupération et si l’appelant finit par arrêter. Utilisez des opérations de test adaptées : répéter une écriture peut avoir d’autres conséquences que répéter une lecture.
La durée ne décrit pas une coupure uniforme
Le rapport couvre 13 h 28-21 h 15 UTC. La plupart des services ont récupéré plus tôt ; Actions et Copilot ont nécessité du travail supplémentaire. Cette durée délimite l’incident, sans signifier que chaque requête échouait pendant tout l’intervalle.
GitHub cite la correction du dimensionnement, la revue des reprises et la surveillance de capacité parmi ses actions. Ces engagements décrivent une amélioration à mener ; ils ne garantissent pas l’impossibilité de toute panne similaire.
Revue du 8 septembre : faits et évolutions vérifiés, explications et médias repris.