Résumé

  • GitHub a ouvert l’incident 20frdtvv3yg6 à 20:43:43Z le 22 juillet et l’a résolu à 22:09:26Z, soit 85 minutes et 43 secondes.
  • Environ 3 % des exécutions utilisant des runners hébergés par GitHub ont subi un délai de démarrage supérieur à cinq minutes.
  • Une petite partie pouvait échouer après un retard prolongé; GitHub a identifié la cause, appliqué une atténuation à 22:01:57Z et clos l’incident huit minutes plus tard.
  • Le dénominateur est celui des exécutions sur runners GitHub, non celui de tous les workflows Actions, runners auto-hébergés ou services GitHub.
  • GitHub promet une analyse de cause; le mécanisme de la panne et son risque de répétition ne doivent pas être inventés avant sa publication.

Une tâche d’intégration continue possède deux durées. La première commence à son entrée dans la file; la seconde lorsque la machine exécute réellement les commandes. Les équipes réduisent volontiers la seconde avec caches et tests parallèles, tout en supposant que la première est presque nulle.

L’incident GitHub a rendu cette attente visible. Trois pour cent représentent une minorité à l’échelle de la plateforme. Pour une livraison qui tombe dans ce sous-ensemble, ils représentent pourtant 100 % du chemin bloqué.

Acheter les machines revient aussi à acheter leur ordonnanceur

Les runners hébergés évitent de fournir, corriger et dimensionner des serveurs de compilation. Le client obtient un environnement prêt et une capacité élastique. En échange, l’admission des tâches, la capacité régionale, les images et l’ordonnancement deviennent des dépendances externes.

Une attente de file diffère d’un test lent. Le code du client n’a pas encore commencé; les journaux contiennent donc peu d’indices. Relancer peut sembler logique, mais plusieurs tentatives ajoutent de la demande au même bassin, consomment des minutes facturées ou déclenchent deux fois une étape de déploiement.

La formulation de GitHub impose une limite précise. Environ 3 % des exécutions sur runners hébergés ont dépassé cinq minutes avant démarrage. Seule une petite partie risquait ensuite d’échouer. Le fournisseur n’a pas attribué ce taux à tous les usages d’Actions ni aux runners auto-hébergés.

Quatre-vingt-cinq minutes traversent une fenêtre de changement

Le dossier débute à 20:43:43Z. L’atténuation apparaît à 22:01:57Z et la résolution à 22:09:26Z. L’incident complet dure 85 minutes et 43 secondes; environ huit minutes séparent l’atténuation de la fermeture.

Pour un contrôle de branche ordinaire, ce délai est une gêne. Pour une livraison planifiée, un renouvellement de certificat, une correction de sécurité ou un changement réseau, il peut consommer toute la fenêtre autorisée. La gravité dépend donc des tâches prises dans les 3 %, pas seulement du pourcentage mondial.

Des nouvelles tentatives limitées, des règles de concurrence, des délais explicites et une solution documentée pour les tâches critiques réduisent le risque. Un runner interne ou un second fournisseur ajoute une issue, mais réintroduit maintenance, identifiants, réseau et exposition de chaîne logicielle. La redondance a un coût réel.

La cause identifiée n’est pas encore publique

GitHub a indiqué avoir trouvé la cause avant d’appliquer l’atténuation et a promis une analyse. Le dossier public disponible ne décrit pas le mécanisme. L’attribuer à un manque de capacité, un déploiement, une région ou un défaut d’ordonnanceur serait spéculatif.

Cette inconnue limite la réaction rationnelle. Une défaillance isolée et corrigée peut ne pas justifier une architecture parallèle. Un défaut répétable de capacité ou de planification pourrait au contraire imposer un chemin de secours aux équipes ayant des objectifs de livraison stricts.

L’analyse utile devra préciser le déclencheur, la raison pour laquelle une fraction a franchi cinq minutes, le passage du retard à l’échec, l’effet exact de l’atténuation et les contrôles de non-récurrence.

La plupart des utilisateurs n’ont peut-être rien vu. C’est précisément le dénominateur borné qui rend l’incident instructif. Un runner géré transforme une machine en service; il ne retire pas la file d’exécution de la chaîne logicielle. Il confie sa responsabilité à GitHub.

Sources