Marque um ou mais trabalhadores como canary e atribua uma porcentagem canary ao pool: essa parcela de chamadas, atribuída consistentemente por um hash de identidade em vez de sorteios por solicitação, prefere o trabalhador canary enquanto todos os outros permanecem na versão estável <a href="#ref-1">[1]</a>. Ambos os grupos permanecem como failover um do outro, portanto a mudança é reversível e contida.
Teste novos modelos no tráfego real
Novas versões de modelos, novas quantizações e novas compilações de daemon podem ser testadas em uma fatia controlada do tráfego real antes que a frota se comprometa com elas <a href="#ref-1">[1]</a>. É assim que você executa uma comparação no estilo A/B de um novo modelo contra o atual usando solicitações ao vivo em vez de um benchmark sintético que pode não corresponder à sua carga de trabalho.
Coerente, sem oscilações
A segmentação consistente por chamador significa que um usuário está totalmente no teste ou totalmente fora dele, então o feedback é coerente e as comparações são significativas, sem oscilações no meio da conversa <a href="#ref-1">[1]</a>. Um usuário que está no grupo canary permanece nele durante toda a sessão, o que torna a comparação resultante confiável.
À prova de falhas por construção
Se o servidor canary falhar ou apresentar mau funcionamento, sua fatia é automaticamente transferida para os trabalhadores estáveis <a href="#ref-1">[1]</a>. O raio de impacto é a fatia, e apenas até a transferência de carga. Combine um canário com uma atualização contínua consciente de drenagem, que é a implementação mecânica, e uma mudança de modelo em toda a frota torna-se uma decisão graduada em vez de um salto <a href="#ref-2">[2]</a>.