Panne GitHub Actions : un plan de continuité CI/CD avec des runners autonomes

Pourquoi un plan de continuité CI/CD devient nécessaire

La CI/CD est souvent le chemin le plus court entre une correction validée et la production. Lorsqu’un fournisseur est indisponible, la difficulté n’est pas seulement technique : les équipes ne savent plus quelles releases peuvent avancer ni qui prend le risque de basculer.

Un plan de continuité CI/CD avec runners autonomes ne cherche pas à reproduire toute la plateforme. Il garantit une capacité dégradée, réservée aux livraisons urgentes, tout en conservant les contrôles qui protègent les clients.

Cette approche convient particulièrement aux PME SaaS qui dépendent d’un service de CI pour leurs runners hébergés, leurs artefacts ou leurs secrets. Elle est également utile en cas de dégradation réseau, de saturation de la file d’attente ou d’incident d’identité.

L’architecture minimale à préparer

Le socle repose sur trois briques indépendantes : une définition de pipeline portable, un petit parc de runners que vous administrez et un mécanisme d’autorisation de déploiement distinct. Chaque brique doit pouvoir être testée sans modifier la production.

Conservez les images de build dans un registre accessible depuis les runners de secours. Épinglez les versions d’outils, les images de base et les dépendances critiques. Sans cela, le runner fonctionne mais ne peut pas reconstruire un artefact identique.

Le runner de secours doit être isolé du parc courant : compte de service dédié, réseau limité et capacité dimensionnée pour les jobs d’urgence. Deux runners modestes dans des zones distinctes sont souvent plus utiles qu’un gros serveur non testé.

Définir les critères de bascule avant l’incident

La décision de basculer doit s’appuyer sur des signaux mesurables. Par exemple : un taux d’échec persistant pendant plus de quinze minutes, l’absence de communication confirmant l’état du fournisseur, ou un délai de file d’attente supérieur au RTO d’une release critique.

Écrivez une matrice simple : qui déclenche, quelles applications sont éligibles, quels environnements sont exclus et comment informer support, produit et clients. La continuité est un processus de décision, pas seulement un fichier YAML.

Mini-lab : valider votre bascule en 20 minutes

Faites ce test sur un dépôt non critique ou une branche dédiée. L’objectif est de vérifier l’enregistrement, l’exécution, la traçabilité et le nettoyage ; aucun déploiement en production ne doit être possible.

Installez le runner selon la documentation de votre forge, puis utilisez une étiquette dédiée. L’exemple ci-dessous illustre le principe sous Linux ; adaptez l’URL et le jeton à votre environnement sandbox.

sudo ./runner register --url https://forge.exemple.internal \
  --token "$RUNNER_TOKEN" --name continuity-sandbox \
  --labels continuity,linux --unattended
sudo ./runner run --once

Déclenchez ensuite un pipeline qui ne fait que construire une image de démonstration et publier un rapport. Attendez un journal identifiant le runner par son étiquette, le commit précis et le hash d’artefact.

make test
docker build -t registry.example.internal/demo/continuity:$GIT_SHA .
docker image inspect registry.example.internal/demo/continuity:$GIT_SHA

Le résultat attendu est un job vert, exécuté par le runner de continuité, sans accès à la production. Vérifiez le journal d’audit du fournisseur de forge et l’historique du registre.

Pour nettoyer, révoquez le jeton, désenregistrez le runner puis détruisez la VM éphémère. Vérifiez enfin qu’aucune variable sensible ne figure dans les logs ni dans l’image construite.

Gérer les secrets, les images et la communication

Les secrets sont le point de rupture le plus fréquent. Préparez des identités de secours avec le minimum de droits : lecture du registre, accès au projet concerné et déploiement uniquement vers l’environnement autorisé.

Évitez de copier des secrets de production dans des variables génériques. Préférez un gestionnaire de secrets accessible avec une identité éphémère, ou un coffre avec une politique réservée à la cellule de crise.

Conservez une liste courte d’images de build supportées et de leurs digest. Cette discipline réduit les écarts entre le pipeline nominal et le chemin de continuité.

Préparez aussi un message de situation. Il doit expliquer les services touchés, la politique de priorité et le prochain point d’information. Les équipes métier ont besoin de visibilité, pas d’une chronologie technique brute.

Checklist de votre plan de continuité CI/CD

Revenir au fonctionnement normal sans perdre la traçabilité

Le retour au fournisseur de CI ne doit pas être improvisé. Une fois l’incident résolu, gardez la cellule de continuité active jusqu’à ce que le pipeline habituel ait exécuté les mêmes contrôles sur un commit de vérification.

Commencez par arrêter les nouveaux déclenchements d’urgence. Laissez finir les jobs en cours, puis archivez leurs identifiants, les empreintes des artefacts et les approbations associées. Cette chronologie permet de répondre à une question simple : quel binaire a réellement été déployé en production ?

Comparez ensuite les artefacts. Si la release a été construite sur le chemin de secours, reconstruisez-la avec le pipeline habituel, en utilisant les mêmes versions d’images et de dépendances. Des empreintes différentes ne signalent pas toujours une erreur, mais elles doivent être expliquées avant de clôturer l’incident.

Révoquez les jetons temporaires et désactivez les accès exceptionnels. Conservez le runner si votre procédure prévoit une capacité chaude, mais videz ses espaces de travail et vérifiez les volumes, caches et journaux susceptibles de contenir des secrets.

Enfin, organisez un retour d’expérience court avec engineering, produit et support. Relevez le délai réel de détection, de décision, de premier build, de validation et de communication. Mettez à jour le RTO et la liste des dépendances à partir de faits observés.

Ajoutez une règle de clôture : aucune bascule n’est terminée tant qu’un responsable n’a pas confirmé le retour au fonctionnement normal. Cette validation évite que des jobs de secours restent actifs par oubli et qu’ils deviennent une voie de déploiement parallèle.

Conservez le compte rendu avec les changements réellement apportés. Lors du prochain incident, les équipes disposeront de décisions éprouvées, de commandes mises à jour et d’un périmètre de test déjà accepté.

Planifiez le prochain exercice immédiatement, avec un scénario différent. La répétition transforme une procédure d’exception en capacité opérationnelle, comprise par les nouveaux membres comme par les responsables de release.

Erreurs fréquentes et dépannage

FAQ

Passer d’un plan théorique à une continuité prouvée

La résilience CI/CD se construit avant l’incident : capacité limitée mais prête, secrets contrôlés, artefacts reproductibles et décisions explicites. Un exercice court révèle rapidement les dépendances que les documents ne montrent pas.