La v1.8 part en production « en canary » : 10 % des requêtes via un Ingress pondéré. L'équipe célèbre. Deux heures plus tard, le support signale des timeouts — mais seulement chez certains clients. Personne n'a configuré de tableau de bord comparant le p95 canary et la version stable. Le retour arrière manuel prend quarante minutes parce que personne ne sait quel poids avait été appliqué.
Une canary release n'est pas un pourcentage magique. C'est un contrat de mesure : une petite part du trafic réel, des métriques qui comparent, et un retour arrière automatisé ou scripté en moins de quelques minutes.
Phases : interne, canary, montée en charge
Un déploiement canary mature suit un chemin explicite :
- Dogfood : équipe interne ou header
X-Canary: 1pour les testeurs. - Canary : 1 à 5 % du trafic réel, métriques métier et techniques en parallèle.
- Montée : 25 → 50 → 100 % si les objectifs de niveau de service sont tenus.
- Abandon : poids à 0 % plus arrêt des instances canary.
Chaque phase a une durée minimale — par exemple trente minutes à 5 % avec trafic suffisant. Sinon la canary est statistiquement vide et ne valide rien.
Cinq pour cent du trafic un dimanche à 3 h du matin ne valide aucune régression visible en semaine.
Métriques et garde-fous
| Signal | Seuil exemple | Action |
|---|---|---|
| Taux d'erreur HTTP 5xx | > 2× la baseline | Rollback automatique |
| Latence p95 | + 30 % vs stable | Pause de la montée |
| Succès checkout | − 5 % vs stable | Abandon |
| Saturation CPU canary | Throttling | Investigation avant montée |
Prometheus et Alertmanager, ou outils Argo Rollouts / Flagger. Définissez avant le déploiement qui reçoit la pager et quels seuils déclenchent l'arrêt — pas après le premier ticket support.
Routage : mesh, Ingress, feature flags
Service mesh : granularité fine, chiffrement mutuel, observabilité — avec coût opérationnel plus élevé.
Ingress nginx ou Traefik pondéré : simple pour HTTP sans état, souvent suffisant pour une première canary.
Feature flags (LaunchDarkly, solutions open source) : canary logique sans split d'infrastructure — utile pour l'interface, moins pour un changement de protocole profond.
Commencez par une cohorte header ou cookie en environnement proche de la production, puis trafic aléatoire en pourcentage.
Pour les métriques qui alimentent les garde-fous, voir Prometheus : choisir des métriques utiles au diagnostic.
Compatibilité de version et données
La canary exige deux versions simultanées en production. Un changement d'API incompatible interdit la canary sans passerelle de version ou clients homogènes.
Migrations de base de données : schéma « expand only » pendant la canary ; contraction après stabilisation à 100 %. Sessions, clés de cache, sérialisation — vérifiez la compatibilité croisée entre versions.
Le sommet : fausse canary, vrai déploiement sans filet
Voici ce que le label « canary » masque quand les garde-fous manquent.
Garde-fous = métriques comparées + rollback testé + fenêtre de montée explicite — pas un curseur Ingress oublié dans un wiki.
Décider et avancer sans angle mort
Avant le prochain déploiement « à petite échelle », verrouillez le processus :
- Choisissez un signal de rollback principal (erreurs, latence p95 ou conversion checkout).
- Automatisez ou scriptez l'abandon : poids à zéro en moins de deux minutes, testé en staging.
- Vérifiez que les migrations de schéma restent compatibles ancienne et nouvelle version.
- Rédigez un runbook d'une page : commandes de poids, lien tableau de bord, seuils, décideur.
- Répétez en game day : simulez une dégradation canary et mesurez le temps de retour arrière.
- Comparez les offres mesh, Kubernetes managé et load balancer via l'annuaire si vous montez en charge.
Critère de maturité : abandon canary en staging en moins de deux minutes sans réunion — sinon vous n'êtes pas prêt pour la production.
Questions fréquentes
Canary ou blue-green ?
La canary progresse par fractions ; le blue-green bascule tout d'un coup. La canary limite le rayon d'impact ; le blue-green simplifie le rollback binaire complet.
Quelles métriques déclenchent un rollback automatique ?
Taux d'erreur, latence p95, conversion ou paiement — comparés à la baseline stable, avec seuils fixés avant le déploiement.
Comment router le trafic canary ?
Ingress pondéré, service mesh ou feature flags — toujours mesuré et reproductible, jamais « on a mis dix pour cent à la main ».
Faut-il canary sur la base de données ?
Le schéma doit rester compatible avec les deux versions pendant la phase. Appliquez expand/contract ; ne déployez pas une canary qui casse l'ancienne version silencieusement.
Une canary mature se termine par des chiffres — pas par un « on n'a pas vu d'avis sur Slack ».