Quand votre pipeline décide : automatiser les décisions de déploiement progressif

Imaginez : il est 2h du matin un samedi. Votre équipe vient de déclencher une release avant de rentrer chez elle. La nouvelle version commence à recevoir 5% du trafic de production. Cinq minutes plus tard, les taux d'erreur grimpent. Personne ne surveille le tableau de bord. Au matin, quand quelqu'un vérifie son téléphone, les utilisateurs subissent des erreurs depuis des heures.

Ce scénario est plus courant que la plupart des équipes ne l'admettent. Les releases n'ont pas toujours lieu pendant les heures de bureau. Les équipes ont une vie en dehors du travail. Et attendre qu'un humain remarque un problème avant d'agir crée des temps d'arrêt inutiles.

La solution n'est pas de garder des gens d'astreinte en permanence. C'est de donner à votre pipeline la capacité de prendre des décisions par lui-même.

Comment fonctionne le gating automatisé

L'idée centrale est simple. Un pipeline de déploiement progressif comporte plusieurs étapes, chacune exposant la nouvelle version à davantage de trafic. Entre chaque étape se trouve une porte (gate). Cette porte vérifie les métriques en temps réel par rapport à des seuils prédéfinis avant de décider de la suite.

Voici un exemple concret. Votre pipeline commence par router 5% du trafic vers la nouvelle version. Il attend cinq minutes pour que les données s'accumulent. Ensuite, il vérifie trois choses :

  • Le taux d'erreur de la nouvelle version est-il inférieur à 0,1% ?
  • La latence est-elle dans une marge de 10% par rapport à la référence de l'ancienne version ?
  • N'y a-t-il pas d'augmentation significative des réponses 5xx ?

Si toutes les métriques passent, le pipeline passe à l'étape suivante, par exemple en augmentant le trafic à 20%. Si les métriques échouent, le pipeline doit décider quoi faire.

Le diagramme suivant illustre la logique de décision à chaque porte du pipeline :

flowchart TD A([Début : 5% trafic]) --> B[Attendre 5 min pour les données] B --> C{Vérifier métriques} C -->|Tout OK| D[Continuer vers 20%] C -->|Seuil d'alerte| E[Bloquer - notifier équipe] C -->|Seuil critique| F[Revenir à l'ancienne version] D --> G[Attendre 5 min] G --> H{Vérifier métriques} H -->|Tout OK| I[Continuer vers 50%] H -->|Alerte| J[Bloquer - notifier équipe] H -->|Critique| K[Revenir] I --> L[Attendre 5 min] L --> M{Vérifier métriques} M -->|Tout OK| N[Continuer vers 100%] M -->|Alerte| O[Bloquer - notifier équipe] M -->|Critique| P[Revenir]

Voici à quoi pourrait ressembler cette configuration de porte dans un pipeline basé sur YAML :

gates:
  - name: canary-5pct
    traffic: 5%
    wait: 5m
    checks:
      - metric: error_rate
        query: "sum(rate(http_requests_total{version='new', status=~'5..'}[5m])) / sum(rate(http_requests_total{version='new'}[5m]))"
        warning: 0.005
        critical: 0.02
        action_warning: hold
        action_critical: rollback
      - metric: latency_p99
        query: "histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{version='new'}[5m])) by (le))"
        baseline: "histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{version='old'}[5m])) by (le))"
        warning: 1.10
        critical: 1.25
        action_warning: hold
        action_critical: rollback

Cette configuration vérifie deux métriques après cinq minutes à 5% de trafic. Si le taux d'erreur dépasse 0,5% (alerte), le pipeline bloque. S'il dépasse 2% (critique), il revient en arrière. La latence est comparée à la référence de l'ancienne version, avec des seuils similaires.

Trois actions possibles : Continuer, Bloquer ou Revenir

Lorsqu'une métrique dépasse un seuil, le pipeline a trois options.

Continuer signifie que tout va bien. La nouvelle version passe au palier de trafic suivant. C'est le chemin heureux qui ne nécessite aucune intervention humaine.

Bloquer signifie que le pipeline arrête la progression de la release, mais la nouvelle version continue de fonctionner à son pourcentage de trafic actuel. L'équipe est notifiée et peut enquêter sans pression. C'est utile quand le problème n'est pas encore critique. Peut-être que les taux d'erreur ont légèrement augmenté mais ne sont pas alarmants. L'équipe peut vérifier les logs, examiner les traces et décider de continuer ou de revenir en arrière.

Revenir signifie que le pipeline redirige immédiatement tout le trafic vers l'ancienne version. Cela se produit lorsque les métriques indiquent un problème grave. Les taux d'erreur grimpent en flèche. Toutes les requêtes commencent à échouer. La latence se dégrade au-delà des limites acceptables. Dans ces cas, attendre l'approbation humaine ne fait qu'aggraver les choses.

Définir les seuils : Alerte vs Critique

La décision entre bloquer et revenir dépend de la sévérité. De nombreuses équipes implémentent deux niveaux de seuils.

Un seuil d'alerte déclenche un blocage. Par exemple, si le taux d'erreur atteint 0,5%, le pipeline arrête la progression et notifie l'équipe. La nouvelle version reste à son niveau de trafic actuel pendant que quelqu'un enquête.

Un seuil critique déclenche un retour automatique. Si le taux d'erreur atteint 2%, le pipeline retire la nouvelle version immédiatement. Sans attendre. Sans question.

Cette approche à deux niveaux donne aux équipes une marge de manœuvre pour les problèmes mineurs tout en protégeant les utilisateurs des défaillances majeures. Les chiffres exacts dépendent de la tolérance aux erreurs de votre application. Un système de paiement aura probablement des seuils beaucoup plus stricts qu'un site de contenu.

Ce dont le pipeline a besoin pour prendre des décisions

La prise de décision automatisée nécessite trois éléments qui fonctionnent ensemble.

Premièrement, votre système d'observabilité doit exposer les métriques en temps réel. Le pipeline doit pouvoir interroger les taux d'erreur, la latence et d'autres signaux immédiatement après avoir déplacé le trafic. Si votre monitoring a un délai de cinq minutes, le pipeline ne peut pas prendre de décisions en temps utile.

Deuxièmement, le pipeline doit comparer les métriques de la nouvelle version avec la référence de l'ancienne version. Cela signifie stocker les données de référence de la dernière release stable. La comparaison doit tenir compte des fluctuations normales. Une augmentation de 5% de la latence pendant les heures de pointe peut être normale, alors que la même augmentation pendant une période de faible trafic pourrait indiquer un problème.

Troisièmement, vous avez besoin de règles claires encodées dans la configuration du pipeline. Ces règles définissent quelles métriques vérifier, quels seuils utiliser et quelle action entreprendre pour chaque niveau de seuil. Gardez ces règles simples et explicites. Une logique complexe avec plusieurs conditions devient difficile à maintenir et à déboguer.

L'automatisation ne remplace pas les humains

Il est tentant de penser que les décisions automatisées vous permettent d'ignorer complètement les releases. Ce n'est pas le cas. L'automatisation gère les scénarios prévisibles. Les humains doivent toujours :

  • Définir des seuils appropriés pour chaque métrique
  • Vérifier que les seuils restent pertinents à mesure que l'application évolue
  • Gérer les cas particuliers que l'automatisation ne couvre pas
  • Enquêter sur les blocages et décider de continuer ou de revenir en arrière
  • Mettre à jour les règles lorsque de nouveaux schémas de défaillance apparaissent

Considérez l'automatisation comme un filet de sécurité pour les cas courants. Elle attrape rapidement les problèmes évidents, donnant aux humains plus de temps pour se concentrer sur des situations complexes qui nécessitent du contexte et du jugement.

Une checklist pratique rapide

Avant d'implémenter des portes de décision automatisées, vérifiez ces bases :

  • Votre pipeline peut-il interroger les métriques de votre système de monitoring en temps réel ?
  • Disposez-vous de métriques de référence de votre version stable actuelle ?
  • Avez-vous défini des seuils d'alerte et critiques pour le taux d'erreur, la latence et les réponses 5xx ?
  • Votre pipeline a-t-il un mécanisme pour bloquer la progression sans revenir en arrière ?
  • Les notifications sont-elles configurées pour atteindre les bonnes personnes en cas de blocage ou de retour ?
  • Avez-vous testé le retour automatique dans un environnement de staging ?

Et ensuite

Une fois que votre pipeline peut décider quand continuer, bloquer ou revenir en arrière, la prochaine étape consiste à choisir comment distribuer le trafic. Deux approches courantes sont les releases canary et les déploiements progressifs par paliers. Chacune a des caractéristiques différentes pour étendre la portée d'une nouvelle version. Le bon choix dépend de l'architecture de votre application et de la façon dont votre infrastructure gère le routage du trafic.

Mais c'est un sujet pour un autre article. Pour l'instant, concentrez-vous sur le fait de donner à votre pipeline la capacité de prendre des décisions quand personne ne regarde. Vos utilisateurs vous remercieront, et votre équipe dormira mieux.