Résumé

  • GitHub a enrichi l’incident qcvjkzcs7j74 le 11 août; la dégradation d’Actions elle-même s’est déroulée du 6 août à 15 h 05 UTC au 7 août à 00 h 14 UTC.
  • Au pic, 71 % des exécutions ont subi un échec d’infrastructure et 75 % du solde ont attendu plus de cinq minutes, selon GitHub.
  • Le remplacement de pods pendant un déploiement courant a mis au jour une faiblesse de capacité et de concurrence, puis saturé les services restants.
  • L’ajout de capacité et la limitation des webhooks ont amorcé le rétablissement, avant qu’un bogue d’attribution ne fasse réessayer des tâches déjà invalides aux runners.
  • Certains runners Actions Runner Controller ont dû être récupérés manuellement et certains événements push ou pull request ne pouvaient pas être rejoués automatiquement.
  • Les protections promises sur les déploiements, les files et la reprise automatique constituent encore un programme de contrôle, pas une efficacité démontrée.

La marge de déploiement était aussi une capacité de production

Le service interne concerné transforme les événements en tâches Actions. Lorsque le déploiement a remplacé des pods, la capacité restante n’a pas absorbé la charge. La saturation a provoqué des crashs et propagé l’impact à plusieurs clusters et services en aval.

Une réserve dimensionnée uniquement pour le trafic normal ne protège donc pas nécessairement un changement roulant. La bonne mesure est la capacité qui reste disponible pendant le remplacement, avec la file déjà accumulée.

Les deux taux ne partagent pas le même dénominateur

Les 71 % correspondent aux workflows frappés par des échecs d’infrastructure. Les 75 % portent sur les exécutions restantes, soit le groupe qui n’appartient pas aux 71 %. Les additionner ou présenter les 29 % restants comme des succès serait erroné.

Cette ventilation permet toutefois de distinguer une panne franche d’un retard supérieur à cinq minutes. Pour une chaîne de livraison, le second cas peut manquer une fenêtre sans produire le même signal d’erreur.

Une file vidée n’est pas encore une file cohérente

GitHub a augmenté la capacité, réduit temporairement l’entrée des travaux déclenchés par webhook et accéléré le traitement de l’arriéré. Puis un défaut latent a attribué aux runners des tâches qui n’étaient plus valides. Ils les redemandaient au lieu de prendre le travail légitime.

La correction a donc dû porter sur la sémantique de la tâche, pas seulement sur le débit. Il fallait empêcher la boucle d’acquisition invalide avant que les files puissent réellement se résorber.

La reprise du fournisseur n’a pas rejoué chaque intention

Une mesure prise pendant l’incident a laissé certains runners ARC hors ligne jusqu’à une intervention manuelle. En parallèle, des événements push et pull request n’ont pas été traités et ne pouvaient pas être rejoués automatiquement.

Le client devait alors vérifier ce qui manquait, relancer un workflow ou recréer l’événement déclencheur. L’état « opérationnel » du fournisseur ne répond pas à cette question dépôt par dépôt.

Le 11 août est une date de transparence

La disponibilité dégradée s’est terminée le 7 août. L’explication détaillée a été ajoutée le 11 août. Cette seconde date mesure l’avancement du dossier public, non la durée du service perturbé.

Conserver les deux horloges évite de transformer un post-mortem tardif en nouvel incident et permet d’évaluer séparément le rétablissement technique et le délai d’explication.

Les remèdes annoncés doivent encore être observés

GitHub promet de renforcer les garde-fous de capacité et de déploiement, la surveillance des signes précurseurs, la robustesse des files, l’attribution aux runners et la reprise automatique. La liste correspond bien à la chaîne causale publiée.

Elle ne dit pas quelles protections sont déjà livrées, quels seuils seront imposés ni comment leur efficacité sera mesurée. Une prochaine version de Runner ou d’ARC devra rendre la récupération automatique vérifiable.

Le registre du client clôt la dernière étape

Une organisation peut comparer ses événements attendus, les identifiants de workflow, les états terminaux et les artefacts réellement produits. Ce registre détecte un déclencheur perdu même lorsque la page d’état est verte.

Il empêche aussi de rejouer aveuglément une opération qui aurait tout de même abouti. La continuité dépend alors de deux preuves: le rétablissement de GitHub et la réconciliation locale des travaux.

Sources