Trocar a versão do sistema não encerra o trabalho em andamento
Uma empresa mantém duas versões de um agente comercial. A nova versão passou pelos testes e está pronta para receber tráfego. A equipe move todas as novas entradas para ela e conserva a anterior disponível para rollback.
A troca parece segura até alguém perceber que dezenas de oportunidades continuam em filas abertas pela versão antiga. Algumas aguardam aprovação. Outras já criaram tarefas no CRM e esperam confirmação. Voltar o roteamento não desfaz esses efeitos nem informa qual versão deve concluir cada caso.
Estratégias conhecidas de publicação de software precisam de adaptação quando o componente executa trabalho, conserva estado e produz consequências externas. Blue-green facilita uma troca coordenada entre dois ambientes. Canário expõe a candidata a uma parcela delimitada da produção e amplia conforme a evidência.
A escolha depende do tipo de unidade processada, da possibilidade de separar coortes, do custo de manter ambientes equivalentes e da capacidade de reconciliar estado e efeitos durante a reversão.
O que é implantação blue-green
Blue-green mantém dois ambientes de produção equivalentes:
- o ambiente ativo recebe a operação atual;
- o ambiente candidato contém a nova composição;
- a equipe valida a candidata antes da troca;
- o roteador direciona novas entradas para o novo ambiente;
- o ambiente anterior permanece disponível durante a janela de reversão.
A estratégia reduz o tempo de indisponibilidade e permite voltar rapidamente o ponto de entrada. Também oferece um ambiente completo para testes finais de configuração, integração e capacidade.
Para agentes de IA, cada ambiente precisa representar a composição inteira: modelo ou rota, instruções, skills, ferramentas, fontes, políticas, permissões, filas, memória, observabilidade e controles. Trocar apenas o código enquanto ambos compartilham configuração mutável elimina parte da separação que o desenho deveria oferecer.
O que é implantação canário
Na implantação canário, a versão candidata recebe uma parte controlada das unidades reais. A versão vigente continua atendendo o restante durante a comparação.
A exposição pode seguir:
- uma equipe interna;
- uma carteira de clientes;
- uma classe de tarefa;
- um grupo de usuários;
- uma região;
- uma janela acompanhada;
- uma fração estável do volume;
- ações de baixo impacto.
O guia de implantação canário para agentes de IA detalha coortes, afinidade por entidade, critérios de avanço e rollback. Neste artigo, o canário funciona como uma das opções de publicação a comparar com blue-green.
A diferença central está na exposição
| Critério | Blue-green | Canário |
|---|---|---|
| troca inicial | novas entradas migram em conjunto | candidata recebe uma parcela |
| comparação em produção | curta ou indireta | concorrente por coorte ou classe |
| contenção | retorno do roteamento para o ambiente anterior | interrupção da coorte candidata |
| infraestrutura | dois ambientes completos e equivalentes | duas versões operando com roteamento segmentado |
| velocidade de migração | alta depois do gate | gradual por anéis |
| aprendizado | valida troca e reversão | mede comportamento em segmentos reais |
| risco principal | estado e efeitos atravessarem a troca | evidência fraca por coorte enviesada ou pequena |
Blue-green costuma ser mais simples quando a versão pode receber novas unidades sem disputar objetos em andamento e quando a equipe consegue validar bem a candidata antes do corte. Canário ganha força quando a incerteza depende do comportamento real e a empresa consegue segmentar a exposição sem misturar o estado.
Quando blue-green tende a funcionar melhor
Tarefas curtas e delimitadas
Se cada execução começa e termina em poucos minutos, a equipe pode interromper novas entradas, deixar o ambiente atual drenar e mover o roteamento depois. O número de unidades atravessando a troca permanece pequeno.
Estado externo e compatível
Quando o estado oficial vive em sistemas com contratos estáveis, as duas versões conseguem consultar a mesma unidade sem criar memória incompatível. O agente não depende de uma sessão interna difícil de transferir.
Efeitos idempotentes
A repetição de uma tentativa não pode duplicar tarefa, envio, atualização ou pagamento. Chaves estáveis e confirmação no destino reduzem o risco de uma unidade reaparecer depois da troca.
Testes offline representativos
Blue-green transfere muitas entradas de uma vez. A equipe precisa chegar ao corte com regressão, falhas de integração, permissões e desempenho já bem testados. Se a principal incerteza só aparece em produção, o canário oferece contenção melhor.
Reversão rápida de novas entradas
O roteador precisa conseguir devolver o fluxo ao ambiente anterior sem deploy adicional. DNS com propagação longa ou configuração manual em vários pontos enfraquece a promessa de rollback rápido.
Ambientes realmente equivalentes
Segredos, políticas, rede, ferramentas, fontes, modelos e observabilidade precisam corresponder. Uma candidata testada com permissões menores ou base diferente não representa o corte que ocorrerá.
Quando canário tende a ser melhor
A qualidade depende de entradas reais
Novos canais, documentos, idiomas, perfis de cliente e exceções alteram o comportamento do agente. Uma coorte limitada permite observar a candidata antes de ampliar.
O processo admite segmentação estável
A empresa consegue manter todos os eventos de um cliente, chamado, pedido ou oportunidade na mesma versão. Isso evita que duas composições escrevam sobre o mesmo objeto.
A mudança amplia autonomia
Liberar envio, escrita, desconto, atualização cadastral ou outra consequência pede evidência específica. A candidata pode começar em preparação ou em ações reversíveis para uma classe simples.
Existe capacidade de comparar
A equipe possui linha de base, métricas por versão e volume suficiente nas classes relevantes. Sem comparação, o canário vira apenas uma publicação menor.
O erro pode ser contido por faixa
A arquitetura consegue suspender uma carteira, ferramenta, ação ou classe sem derrubar a versão vigente. Feature flags para agentes de IA ajudam a separar capacidade disponível de versão instalada.
Estado é o critério que costuma ser ignorado
Software sem estado pode trocar instâncias e continuar atendendo. Agentes frequentemente mantêm trabalho entre eventos.
Uma unidade pode estar:
- recebida;
- em preparação;
- aguardando ferramenta;
- esperando aprovação humana;
- parcialmente executada;
- aguardando confirmação externa;
- interrompida;
- em retentativa;
- concluída com pendência;
- sob investigação.
Antes de escolher a estratégia, defina quem possui cada estado durante a transição. Uma versão nova consegue continuar uma tarefa iniciada pela anterior? O schema de memória permanece compatível? Uma aprovação concedida para uma composição ainda vale depois da troca? A fila preserva a versão de origem?
Sem resposta, a equipe pode mover o tráfego e deixar a parte mais perigosa operando fora da visão.
Modele a unidade de roteamento
O roteador deve trabalhar com uma unidade que represente o processo.
Por execução
Cada chamada pode seguir para uma versão. Funciona apenas quando as execuções são independentes e não disputam estado.
Por entidade
Todos os eventos de um cliente, contrato, pedido, chamado ou oportunidade permanecem na mesma composição. É a opção mais segura para jornadas longas.
Por classe de tarefa
A versão candidata recebe somente tipos aprovados. Uma nova rotina de classificação pode entrar sem alterar mensagens externas.
Por capacidade
A mesma versão pode usar leitura nova e manter escrita antiga, desde que flags e permissões imponham essa fronteira na camada executável.
Por ambiente completo
Blue-green direciona novas unidades para um conjunto inteiro de serviços. O roteamento ainda precisa reconhecer tarefas que pertencem ao ambiente anterior.
A chave de afinidade deve ser estável, registrada e disponível em reentregas. Sortear novamente a cada evento faz a unidade alternar entre versões e destrói a atribuição do resultado.
O rollback precisa tratar quatro camadas
1. Entrada
Bloqueie novas unidades na candidata e confirme que agendadores, webhooks, filas e chamadas diretas respeitam a mudança.
2. Trabalho em andamento
Decida quais unidades podem terminar na candidata, quais devem congelar e quais podem migrar. Transferência exige contrato explícito de estado entre versões.
3. Efeitos externos
Identifique tarefas criadas, mensagens enviadas, registros alterados, reservas, arquivos e outras consequências. O rollback de código não apaga o que já aconteceu.
4. Reconciliação
Compare fila, memória e sistemas oficiais. Resolva confirmação perdida, duplicidade, versão divergente e objetos parcialmente atualizados antes de retomar o volume normal.
A reconciliação de agentes de IA ajuda a tratar diferenças entre intenção registrada e estado confirmado. A idempotência em agentes reduz repetição de efeitos quando uma unidade volta à fila.
Como executar blue-green com agentes
1. Congele a composição candidata
Registre código, modelo, instruções, fontes, ferramentas, políticas, permissões e schema de estado. Mudanças durante a validação criam outro candidato.
2. Prepare o ambiente verde
Use integrações e configurações equivalentes sem permitir consequências prematuras. Segredos devem vir do cofre e respeitar escopos próprios.
3. Rode testes de integridade
Verifique saúde, conectividade, catálogo de ferramentas, políticas, filas, logs, custo, latência e capacidade de interrupção.
4. Execute regressão e casos de transição
Inclua tarefas sem estado, em andamento, aguardando aprovação, com confirmação perdida e com retentativa. Teste compatibilidade de memória e payloads.
5. Defina a política de drenagem
Pare novas entradas no ambiente azul quando necessário e permita que unidades seguras terminem. Defina prazo e destino para tarefas que não concluem.
6. Faça o corte
Mova novas unidades para o verde por um mecanismo observável. Registre horário, responsável, configuração e primeira unidade recebida.
7. Acompanhe a janela
Monitore qualidade, falhas, filas, correções, custo e desfechos. Preserve o azul sem mudanças enquanto a possibilidade de retorno estiver aberta.
8. Encerre a transição
Depois da decisão, desative recursos antigos de forma controlada, revogue credenciais exclusivas, retenha evidências e atualize o inventário de versões.
Como executar canário com agentes
1. Escolha uma coorte legível
Use classe, carteira, equipe ou entidade que represente a próxima faixa de expansão. Evite selecionar apenas usuários especialistas e casos fáceis.
2. Preserve afinidade
Todos os eventos da unidade permanecem na candidata durante a janela. Registre a chave e a versão atribuída.
3. Limite a consequência
Comece por leitura, preparação ou escrita reversível. A coorte pequena não justifica liberar uma ação crítica sem evidência própria.
4. Defina referência e recortes
Compare a candidata com a versão vigente ou com a linha de base do processo. Abra resultados por classe e risco.
5. Escreva os gates antes da exposição
Defina entrada, avanço, pausa e reversão. Erros impeditivos encerram a janela independentemente da média.
6. Amplie por anéis
Aumente volume, usuários, classes e autonomia separadamente. Cada passagem deve produzir evidência suficiente para a próxima.
7. Reconcile ao sair
Mesmo uma coorte limitada pode deixar unidades abertas. A decisão final precisa resolver estado, fila e efeitos antes de remover a rota.
Uma estratégia híbrida costuma ser necessária
Blue-green e canário podem trabalhar juntos.
A equipe prepara um ambiente verde completo, executa regressão e valida integrações. Em vez de mover toda a operação, o roteador envia uma coorte estável para esse ambiente. A candidata enfrenta produção com alcance limitado. Depois dos gates, novas unidades migram em conjunto e o ambiente azul permanece disponível durante uma janela curta.
Esse desenho combina isolamento de ambiente com exposição gradual. Também custa mais. A empresa precisa manter duas composições, roteamento por coorte, métricas comparáveis e tratamento de estado.
Use a combinação quando o impacto justifica a complexidade. Em um agente interno de resumo sem escrita, um deploy simples com flag pode ser suficiente. Em um agente que altera CRM, atende clientes ou participa de processos financeiros, o custo de contenção e reversão merece peso maior.
Blue-green, canário, modo sombra e feature flag
Essas práticas controlam objetos diferentes.
Blue-green
Controla a troca entre ambientes completos e preserva uma rota de retorno.
Canário
Controla quem recebe a versão candidata e quanto da produção fica exposto.
Modo sombra
Compara comportamento sobre entradas reais sem liberar a consequência externa. É útil antes do canário quando a incerteza está na decisão do agente.
Feature flag
Controla se uma capacidade específica está disponível para um público e condição. Pode interromper escrita sem retirar leitura e preparação.
O controle de mudanças em agentes de IA governa a decisão completa: hipótese, versão, teste, aprovação, publicação, observação e reversão.
Troca de ambiente ou exposição por coorte: condições de escolha
Tarefa curta; estado longo
- Blue-green
- Forte para tarefa curta; estado longo exige drenagem e compatibilidade.
- Canário
- Neutro para tarefa curta; estado longo favorece coorte com afinidade.
Evidência offline; incerteza em produção
- Blue-green
- Offline representativo favorece; incerteza dependente de produção é sinal fraco.
- Canário
- Pode complementar offline; forte quando a incerteza depende de produção.
Segmentação; volume de comparação
- Blue-green
- Separar usuários/classes e ter volume por coorte são dispensáveis.
- Canário
- Segmentação estável e volume para comparar são necessários.
Velocidade; consequência ampliada
- Blue-green
- Forte para troca rápida; aumento de consequência pede gates adicionais.
- Canário
- Fraco para troca rápida; consequência ampliada favorece exposição gradual.
Custo de dois ambientes
- Blue-green
- Dois ambientes completos e equivalentes são necessários.
- Canário
- Necessidade depende da arquitetura.
Rollback de estado
- Blue-green
- Obrigatório testar; roteamento não desfaz efeitos.
- Canário
- Obrigatório para a faixa; preservar afinidade e reconciliar unidades abertas.
Matriz de decisão
| Pergunta | Sinal para blue-green | Sinal para canário |
|---|---|---|
| a tarefa é curta e independente? | forte | neutro |
| existe estado longo por entidade? | exige drenagem e compatibilidade | favorece coorte com afinidade |
| a qualidade offline é representativa? | forte | ainda pode complementar |
| a principal incerteza depende de produção? | fraco | forte |
| é possível separar usuários ou classes? | dispensável | necessário |
| a troca precisa ocorrer rapidamente? | forte | fraco |
| a consequência aumentou? | pede gates adicionais | favorece exposição gradual |
| dois ambientes completos cabem no custo? | necessário | depende da arquitetura |
| há volume para comparar coortes? | dispensável | necessário |
| rollback de estado foi testado? | obrigatório | obrigatório para a faixa |
A matriz orienta a conversa. A decisão final precisa considerar impacto, reversibilidade, volume, ciclo da tarefa e capacidade real de operação.
Exemplo: agente de triagem de atendimento
Uma empresa possui um agente que identifica o cliente, classifica o assunto, define prioridade e encaminha o chamado. A nova versão passa a consultar contrato e histórico recente.
Opção blue-green
A equipe cria um ambiente verde, testa integrações e deixa o azul drenar chamados abertos. Depois, move todos os novos chamados. Funciona se o volume de unidades em andamento for pequeno, o schema permanecer compatível e o rollback puder devolver novas entradas sem perder atribuição.
Opção canário
Uma fila interna de baixo risco recebe a candidata. Todos os eventos desses chamados ficam nela. A equipe compara encaminhamento, reclassificação, prazo e casos sem fonte. Depois, amplia para outra fila.
Opção híbrida
O ambiente verde recebe primeiro a fila interna. Ao cumprir os gates, passa a receber todos os novos chamados, enquanto o azul conclui ou transfere unidades conforme a política de drenagem.
A escolha híbrida oferece evidência melhor, mas pede roteamento, métricas e governança suficientes para não criar dois processos invisíveis.
Erros comuns
Tratar retorno do tráfego como rollback completo
Novas entradas voltam. Filas, aprovações, efeitos e memórias permanecem. O plano precisa reconciliar cada camada.
Compartilhar estado mutável sem contrato
Ambientes separados que leem e escrevem a mesma estrutura podem corromper compatibilidade. Versões precisam declarar quais campos e estados entendem.
Usar percentual sem afinidade
A mesma oportunidade alterna entre versões a cada evento. A comparação perde validade e as duas composições podem produzir ações conflitantes.
Manter o ambiente anterior sem testar retorno
Uma versão parada pode perder credencial, configuração, capacidade ou compatibilidade. O rollback só existe quando foi exercitado.
Escolher canário sem volume suficiente
Poucos casos comuns não sustentam conclusão sobre exceções raras. Testes dirigidos continuam necessários para riscos críticos.
Escolher blue-green para evitar observação
Troca rápida reduz indisponibilidade. Não prova qualidade operacional. A equipe ainda precisa monitorar resultado e possuir critérios de interrupção.
Checklist antes de publicar uma nova versão
- [ ] A composição candidata está congelada e identificável?
- [ ] A unidade de trabalho e a chave de afinidade foram definidas?
- [ ] Estado, memória e filas são compatíveis entre versões?
- [ ] Novas entradas podem ser interrompidas por um ponto conhecido?
- [ ] Unidades em andamento possuem política de drenagem ou migração?
- [ ] Efeitos externos usam idempotência e confirmação?
- [ ] Ambientes possuem políticas e permissões equivalentes?
- [ ] Regressão cobre falhas e transições de estado?
- [ ] A estratégia escolhida corresponde à incerteza principal?
- [ ] Coortes são comparáveis quando houver canário?
- [ ] Critérios de avanço, pausa e reversão foram definidos?
- [ ] Métricas separam versão, classe, risco e resultado?
- [ ] O rollback foi testado com tarefas em vários estados?
- [ ] A reconciliação possui dono e procedimento?
- [ ] O ambiente anterior tem prazo e condição de desativação?
A estratégia precisa proteger o processo inteiro
Blue-green reduz atrito na troca entre ambientes. Canário reduz a exposição inicial e produz evidência sobre comportamento real. Nenhuma das duas resolve sozinha estado incompatível, efeito duplicado, aprovação pendente ou ausência de critério.
A escolha melhora quando a empresa parte da unidade de trabalho e da consequência possível. Depois, define ambiente, coorte, afinidade, gates e reconciliação. Publicar um agente com segurança significa preservar a capacidade operacional durante a mudança, inclusive quando a versão candidata precisa voltar.