Qu'est-ce qu'un déploiement canary ? Guide pratique pour SRE

Qu'est-ce qu'un déploiement canary ? C'est une technique de mise en production qui consiste à envoyer une nouvelle version à une petite fraction du trafic réel, à la comparer à la version déjà en place, et à n'élargir le déploiement que si les chiffres tiennent. Concrètement, c'est un déploiement avec un point de décision intégré : la modification atteint d'abord 1 à 5 % des utilisateurs, et une vérification des métriques décide si elle continue ou si elle est annulée.

Le reste de ce guide explique comment ça fonctionne, où ça échoue et ce qu'il faut automatiser.

Le pager de 3 h du matin qu'un canary aurait transformé en message Slack

Un déploiement part à 16 h 40 un jeudi. Le taux d'erreur du service de commande passe de 0,2 % à 4 %. Personne ne le remarque avant un ticket du support, deux heures plus tard, quand tous les utilisateurs exécutent déjà la nouvelle version. Le retour arrière prend 25 minutes, parce que la migration de base de données est appliquée à moitié.

Refaites le même changement en canary sur 5 % du trafic, et les dégâts sont bornés. Environ un utilisateur sur vingt voit le bug, la comparaison avec le contrôle échoue en quelques minutes, et le pipeline s'arrête. Le post-mortem décrira ce que le canary a attrapé, et non ce qu'il a manqué.

Le nom vient des mines de charbon, où le canari cessait de chanter avant que l'air ne devienne mortel. Votre petite cohorte joue le même rôle. Elle n'empêche pas la mauvaise release. Elle limite le nombre de personnes qui la respirent.

Ce que fait un canary, et en quoi il diffère du blue-green et du rolling

Le Google SRE Workbook définit le canarying comme un déploiement partiel et limité dans le temps d'une modification, suivi d'une évaluation qui décide si le déploiement se poursuit. Le sous-ensemble qui exécute la modification est le canary. Le reste de la flotte est le contrôle. Ce cadrage compte : il fait du canary un test A/B sur votre propre fiabilité, et non simplement un déploiement lent.

Une séquence typique ressemble à ceci :

• Déployer la nouvelle version à côté de la version stable, sans trafic pour l'instant.

• Router un pourcentage réduit du trafic vers elle (l'exemple du Workbook utilise 5 %).

• Maintenir une fenêtre fixe (le même exemple utilise 30 minutes) pendant que vous comparez le canary et le contrôle.

• Passer à l'étape suivante, par exemple 25 %, 50 % puis 100 %, ou abandonner et renvoyer le trafic vers la version stable.

La boucle est simple. La partie difficile est l'étape de comparaison, que la plupart des équipes implémentent par « quelqu'un regarde un tableau de bord ».

Ces trois stratégies sont sans cesse confondues, donc voici la distinction qui compte au moment de choisir.

• Rolling update : remplace les instances progressivement. Peu coûteux, intégré à tous les orchestrateurs, mais sans comparaison avec un contrôle ni répartition de trafic nette. Anciennes et nouvelles versions partagent la charge jusqu'à la fin.

• Blue-green : deux environnements complets, avec bascule de tout le trafic d'un coup. Le retour arrière est immédiat, mais au moment de la bascule, le rayon d'impact porte sur 100 % des utilisateurs, et vous payez une capacité double.

• Canary : une fraction contrôlée du trafic réel sur la nouvelle version, jugée par rapport à l'ancienne. C'est le plus petit rayon d'impact, et la complexité opérationnelle la plus élevée.

Choisissez blue-green quand le risque est un déploiement cassé que vous détectez avec un test de fumée et que vous annulez en quelques secondes. Choisissez le canary quand le risque est une régression subtile que seul le trafic réel révèle : une dérive de la latence p99, une fuite mémoire lente, un plan de requête qui s'effondre sur des formes de données de production.

Renoncez au canary si votre service reçoit très peu de trafic. Avec quelques centaines de requêtes par heure, une tranche de 5 % ne vous donne qu'une poignée d'échantillons et aucun signal. Le Workbook le dit directement : très peu de requêtes ne fournissent pas de signal utile pour des charges de travail variées.

Pourquoi votre canary à 1 % vous ment probablement

Voici la panne qui frappe les équipes dans les trois premiers mois. Le canary prend 5 % du trafic et échoue sur 20 % de ses requêtes. Le taux d'erreur de l'ensemble du service passe de 0,2 % à environ 1,2 %. Votre seuil d'alerte est fixé à 2 %. Rien ne se déclenche.

La supervision agrégée masque les échecs du canary. Le même calcul apparaît dans le Workbook : un canary qui échoue sur 20 % de ses requêtes, pour 5 % du trafic, n'affiche qu'un taux d'erreur global de 1 %. Il faut découper les métriques par population, canary contre contrôle, sinon le signal se dilue dans le dénominateur.

Trois autres pièges méritent attention :

• Les comparaisons avant et après. Comparer la fenêtre du canary à l'heure précédente confond la modification avec le temps. Le trafic de semaine opposé à celui du week-end peut suffire à masquer une vraie régression. Comparez plutôt à un contrôle simultané.

• Les dépendances partagées. Si le canary et le contrôle sollicitent le même cache ou la même base, un mauvais canary peut dégrader les deux, et la comparaison ne montre rien. Vérifiez vos domaines de panne.

• Les métriques bruitées. L'utilisation du CPU est une mauvaise gate. Les codes d'erreur et la latence reflètent ce que ressentent les utilisateurs. Le Workbook conseille de classer les métriques candidates selon leur reflet des problèmes visibles par l'utilisateur, et d'en garder seulement les meilleures, une douzaine au plus.

Choisir les métriques de gate avant de shipper, pas pendant l'incident

Partez de vos SLI. Si vous disposez déjà d'un SLI de disponibilité et d'un SLI de latence pour le service, ce sont vos deux premières gates. Un ensemble de départ raisonnable pour un service piloté par les requêtes :

• Le taux d'erreur (5xx) du canary contre celui du contrôle, sur la fenêtre d'observation.

• La latence p99 du canary contre celle du contrôle.

• Un signal de saturation attribuable à la modification, comme la croissance de la mémoire par pod.

• Une métrique proche du métier, par exemple la finalisation des commandes, si vous pouvez l'isoler par cohorte.

Les seuils sont l'endroit où les équipes perdent des semaines. Trop stricts, chaque canary s'arrête sur du bruit, et les ingénieurs apprennent à contourner la gate. Trop lâches, un mauvais build passe. Relisez-les selon un calendrier. Une gate qui n'a rien arrêté depuis six mois est soit parfaite, soit décorative, et il faut savoir laquelle.

Gardez aussi l'intervalle d'agrégation des métriques inférieur ou égal à la durée de la fenêtre du canary. Un rollup de 10 minutes sur un canary de 5 minutes brouille tout.

Un canary en configuration : à quoi ressemblent les étapes dans Argo Rollouts

Sur Kubernetes, la spécification canary d'Argo Rollouts exprime la séquence sous forme de liste d'étapes. Voici une version condensée, dans la forme décrite par la documentation :

strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 30m }
      - analysis:
          templates:
            - templateName: error-rate-vs-baseline
      - setWeight: 25
      - pause: { duration: 30m }
      - setWeight: 50
      - pause: {}

Deux détails de la documentation méritent attention. Sans routeur de trafic, le poids est approximé par le nombre de pods, au mieux : 10 réplicas à 10 % donnent un pod canary et neuf pods stables. C'est du calcul sur les réplicas, pas sur les requêtes. Ensuite, un pause: {} sans durée attend indéfiniment que quelqu'un lance kubectl argo rollouts promote. C'est une validation humaine, que vous voulez peut-être ou non.

Si l'étape d'analyse échoue, le déploiement est abandonné. C'est dans cette partie qu'il faut investir.

Feature flags et sources de comparaison : les deux moitiés d'un canary sûr

Les canaries d'infrastructure répartissent le trafic par instance ou par pod. Les canaries à base de flags le répartissent par utilisateur, par compte ou selon tout attribut ciblable. Les deux répondent à des questions différentes. La première demande si le nouveau build est sain. La seconde demande si le nouveau comportement est acceptable, et elle permet de le désactiver sans redéploiement.

Pour les déploiements pilotés par flags, l'outillage compte. LaunchDarkly offre les règles de ciblage et la piste d'audit les plus matures, et il domine largement en écosystème. Son tarif à l'échelle entreprise est la plainte habituelle des responsables plateforme.

Statsig associe l'expérimentation aux flags, ce qui convient aux équipes qui veulent un jugement fondé sur les métriques, sur la même plateforme. C'est moins adapté si vous n'avez besoin que d'un interrupteur d'arrêt.

Le compromis, en toute honnêteté : une plateforme de flags vous donne des déploiements en pourcentage, mais la plupart ne lisent pas vos SLO par eux-mêmes. Quelqu'un doit encore relier la métrique à la décision.

Pour la source de comparaison, il faut une télémétrie capable de découper par version. Quel que soit le moteur du déploiement, le verdict vient de votre télémétrie. Chaque métrique doit donc porter un label de version ou de cohorte, et votre backend doit pouvoir l'interroger par ce label sans un retard de 10 minutes.

Datadog fait bien ce travail avec des découpages par tags, et son suivi des déploiements corrèle les releases avec les pics d'erreurs. Le coût à forte cardinalité est le paramètre à modéliser avant de tout étiqueter.

Grafana avec Prometheus fonctionne si vous l'exploitez déjà et que vous étiquetez vos métriques par révision de rollout. Vous gardez le contrôle complet, et la maintenance vous revient.

Automatiser l'abort : d'où vient l'idée du pilot IA

L'analyse manuelle des canaries passe mal à l'échelle. À dix déploiements par jour, personne ne fixe un tableau de bord pendant 30 minutes à chaque fois, et la gate devient discrètement un « ça a l'air correct ». Le schéma qui tient est un juge automatisé : vous définissez le SLO, vous définissez la comparaison, et un contrôleur abandonne et revient en arrière quand le canary consomme son budget d'erreur plus vite que le contrôle.

C'est le problème visé par le AI Pilot d'upstreamapi : il lit le signal SLO pendant le déploiement et déclenche un retour automatique quand le taux d'erreur franchit le seuil que vous avez fixé. Il mesure le taux d'erreur et la latence par rapport à la cohorte stable, rien de plus. Si vous exploitez déjà des templates d'analyse Argo Rollouts avec une bonne requête Prometheus, vous disposez de l'essentiel de la même capacité, et il faut le dire à qui vous vend de la magie. Là où un pilot hébergé trouve sa place, c'est sur des stacks hétérogènes, où chaque équipe devrait sinon maintenir ses propres templates d'analyse.

Une erreur revient souvent : les équipes automatisent l'étape de promotion et n'automatisent jamais l'abandon. Un pipeline qui ne sait qu'avancer est un tapis roulant.

Mesurer pour savoir si votre processus canary fonctionne

Un programme canary a ses propres métriques. Suivez-les sur un trimestre :

• Taux d'abandon des canaries : part des canaries arrêtés par la gate. Zéro signifie que la gate est aveugle. Au-delà de 20 à 30 %, cela signale souvent des seuils instables ou des tests pré-merge insuffisants.

• Temps de détection sur canary : minutes entre la première mauvaise requête et l'abandon. C'est votre vrai MTTD pour les releases.

• Régressions échappées : incidents imputables à une release qui avait passé le canary. Chacun doit faire évoluer une gate.

• Temps moyen de retour arrière : de la décision d'abandon jusqu'à 100 % du trafic sur la version stable.

Ne lancez qu'un seul canary à la fois par service. Le Workbook le recommande fortement, et la raison est pratique : deux changements qui se chevauchent rendent l'attribution impossible, et vous ne saurez pas lequel vous a fait mal.

Pour démarrer cette semaine : choisissez un service sans état, avec assez de trafic pour produire un signal en 15 minutes. Ajoutez un label de version à ses métriques d'erreur et de latence. Écrivez une seule requête de comparaison, canary contre contrôle. Lancez un canary à 5 % avec une promotion manuelle, et notez ce que vous auriez attrapé lors des trois derniers incidents.

Puis posez la question qui dérange : si le canary avait échoué à 2 h du matin, quelque chose l'aurait-il arrêté sans qu'un humain soit réveillé ?