Marquez un ou plusieurs workers comme canari et attribuez un pourcentage canari à la pool : cette part d'appelants, assignée de manière cohérente par un hash d'identité plutôt que par tirages au sort à chaque requête, privilégie le worker canari tandis que tous les autres restent sur la version stable <a href="#ref-1">[1]</a>. Les deux groupes restent chacun le secours de l'autre, ce qui rend le changement réversible et contenu.
Tester de nouveaux modèles sur du trafic réel
Les nouvelles versions de modèles, nouvelles quantifications et nouvelles compilations du démon peuvent être testées sur une portion contrôlée de trafic réel avant que la flotte ne s'y engage <a href="#ref-1">[1]</a>. C'est ainsi que vous réalisez une comparaison de type A/B d'un nouveau modèle face à l'actuel en utilisant des requêtes en direct plutôt qu'un banc d'essai synthétique qui pourrait ne pas correspondre à votre charge de travail.
Cohérent, sans oscillations
Le découpage cohérent par appelant signifie qu'un utilisateur est soit entièrement dans l'essai soit entièrement en dehors, ce qui rend les retours cohérents et les comparaisons significatives sans oscillations en cours de conversation <a href="#ref-1">[1]</a>. Un utilisateur dans le groupe canari y reste pendant toute sa session, ce qui rend la comparaison obtenue fiable.
Sûr par conception
Si la machine canari tombe en panne ou se comporte mal, sa portion bascule automatiquement vers les workers stables <a href="#ref-1">[1]</a>. Le rayon d'impact correspond à la tranche, et ce uniquement jusqu'au basculement. Associez un déploiement canari à une mise à niveau progressive consciente de la vidange, qui est le déploiement mécanique, et un changement de modèle à l'échelle de la flotte devient une décision graduée plutôt qu'un saut <a href="#ref-2">[2]</a>.