Você está implantando uma nova versão de um serviço de pagamentos crítico. Me explique passo a passo como você configuraria um canary release para ele.

Question

Accepted Answer

Primeiro, eu implantaria a nova versão junto com a atual, mas direcionando apenas uma pequena fatia do tráfego para ela, digamos 2-5%. O canary recebe tráfego real de produção enquanto a versão estável cuida do resto. Eu configuraria uma análise automatizada em métricas-chave: taxa de erro, latência p99 e métricas de negócio como taxa de sucesso de pagamentos. Essas métricas seriam comparadas entre o canary e a versão estável. Se a taxa de erro do canary for mais de 0,5% maior ou sua latência p99 for mais de 50ms pior, o rollout para automaticamente e o tráfego volta para a versão estável. Se as métricas estiverem saudáveis após 15-30 minutos, eu avançaria para 10%, depois 25%, 50% e finalmente 100%, com as mesmas verificações automatizadas em cada etapa. Para um serviço de pagamentos especificamente, eu também observaria efeitos downstream, como aumento de disputas de cobrança ou falhas na entrega de webhooks. Todo o processo pode levar de 2 a 4 horas para uma mudança de baixo risco ou um dia inteiro para algo mais significativo. Ferramentas como Flagger ou Argo Rollouts podem automatizar o deslocamento de tráfego e a análise de métricas para que você não precise ficar observando dashboards manualmente.

Canary Releases em Progressive Delivery

Resposta de exemplo

Por que isso importa

Exemplos de código

Erros comuns a evitar

Prováveis perguntas de acompanhamento

Mais perguntas de entrevista de CI/CD

Also worth your time on this topic

Fundamentos de Progressive Delivery

Como Implementar Progressive Delivery com Feature Flags

GitOps com ArgoCD - Deployments Automatizados no Kubernetes