Déploiement progressif : ce que le canary ne voit pas

Soit un service à 20 requêtes par seconde. On envoie 5 % du trafic sur la nouvelle version pendant dix minutes, elle reçoit donc 600 requêtes. La version stable a un taux d'erreur de fond de 0,2 %, et la nouvelle contient un bug qui fait échouer 0,5 % des requêtes en plus. Sur 600 requêtes, on attend 1,2 erreur d'un côté et 4,2 de l'autre. Aucune analyse automatique sérieuse ne tranche entre « une erreur » et « quatre erreurs » sur dix minutes ; le canary passe au vert, et le bug part chez tout le monde avec un tampon « validé en production ».

Le canary reste une bonne pratique, à condition de le traiter comme ce qu'il est, un test statistique, avec une puissance limitée. Il voit ce qui est fréquent, immédiat et sans état. Le reste lui échappe par construction, et c'est souvent là que se logent les pannes qui coûtent cher.

Ce que le canary mesure vraiment

Le mécanisme tient en trois éléments : deux populations de requêtes, une métrique par population, une règle de comparaison. Chez nous, la répartition se fait dans Traefik, avec un service pondéré.

http:
  services:
    api:
      weighted:
        services:
          - name: api-stable
            weight: 95
          - name: api-canary
            weight: 5

Ce fichier repose sur des hypothèses implicites.

Les deux populations sont comparables. La répartition tire au sort des requêtes et non des usages. Si le chemin cassé n'est emprunté que par un type de client, il peut ne jamais tomber du côté du canary pendant la fenêtre.

La métrique capte la défaillance. Un taux de 5xx ne voit pas une réponse 200 qui contient un montant faux, et une latence médiane ne voit pas un p99 qui double.

L'effet est immédiat. La comparaison porte sur la fenêtre d'observation, si bien que ce qui casse dans une heure ou à la fin du mois n'existe pas pour elle.