Cloud/rollback/canary
O gate de CI aprovou um artefato, mas a produção apresenta carga, dependências e usuários que o teste não cobre completamente. Deploy controlado limita exposição, observa sinais e mantém um caminho de retorno. A mudança precisa preservar a identidade do artefato e a compatibilidade dos dados, ou o rollback pode restaurar código antigo que não consegue ler o estado novo.
Nesta aula conectaremos deploy, canary, rollback, autoscaling e monitoramento a uma política verificável. Kubernetes e Cloud Run fornecem mecanismos concretos de operação, mas não assumiremos que qualquer plataforma tem as mesmas garantias. O exemplo executa duas versões HTTP locais e um teste de regressão; a etapa de cloud é um procedimento de laboratório com credenciais, projeto e orçamento próprios.
JavaScriptInfraestruturaAo terminar esta aula
- Deploy controlado preserva identidade e evidencia qualidade.
- Rollback exige compatibilidade e verificação posterior.
- Escala respeita dependências, quotas e orçamento.
Antes de continuar: Laboratório: CI/CD + eval gates
Deploy é uma mudança de estado do sistema
FundamentosUm deploy coloca uma versão de aplicação em um ambiente. Essa versão inclui imagem, configurações, segredos referenciados, modelo, prompt e dependências de dados. Preserve o manifesto da semana 44 e use identificadores imutáveis quando possível. Uma tag latest facilita atualização, mas dificulta saber qual conteúdo foi executado. Registre a versão em respostas diagnósticas e traces para associar incidentes à mudança.
↗ Deployments↗ Rollbacks, gradual rollouts, and traffic migration
Kubernetes Deployment controla substituição de réplicas de aplicação conforme sua estratégia; Cloud Run trabalha com revisões e distribuição de tráfego. Nenhum desses mecanismos valida automaticamente qualidade de um agente. Readiness pode impedir tráfego para processo não pronto, mas um agente pronto para receber HTTP ainda pode inventar uma política. A decisão de promoção precisa combinar saúde técnica com evals e sinais funcionais. Configuração externa também deve ser versionada para que a identidade do deploy não dependa só da imagem.
↗ Deployments↗ Rollbacks, gradual rollouts, and traffic migration
Canary: exposição limitada com critérios prévios
FundamentosCanary direciona uma parte do tráfego para a candidata enquanto a baseline permanece em serviço. Defina antes quais sinais bloqueiam expansão: erro crítico, aumento de falhas, latência excessiva ou queda de conclusão. Não use apenas status HTTP, porque uma resposta 200 pode conter ação errada. O conjunto de avaliação pode ser executado contra uma revisão sem tráfego de usuários antes da primeira exposição.
↗ Rollbacks, gradual rollouts, and traffic migration↗ Deployments
Uma fração pequena de tráfego não garante uma amostra representativa. Poucos tenants podem dominar os pedidos, e classes raras podem não aparecer. Preferir atribuição estável por usuário ou tenant ajuda a evitar experiências inconsistentes, mas ainda exige analisar segmentos. Um canary com dez requisições sem erro não comprova equivalência. Defina janela, número mínimo de casos e regra para evidência insuficiente. Para ações de escrita, evite duplicar efeitos ao fazer shadow traffic; uma cópia de teste não deve executar o mesmo estorno.
↗ Rollbacks, gradual rollouts, and traffic migration↗ Deployments
Rollback e compatibilidade de dados
FundamentosRollback restaura uma versão ou distribuição de tráfego anterior. Ele não desfaz automaticamente efeitos de ferramentas, migrações de banco ou mensagens já publicadas. Se a versão nova escreve um formato que a antiga não entende, voltar a imagem pode ampliar o incidente. Planeje evolução compatível: adicionar campo antes de exigir seu uso, manter leitura dos formatos antigos e adiar remoções até que não haja versões dependentes.
↗ Deployments↗ Rollbacks, gradual rollouts, and traffic migration
Separe rollback de aplicação de recuperação de dados e compensação de efeitos. Um ticket criado indevidamente precisa de ação própria, mesmo que o código anterior volte. Preserve revisões anteriores e conheça o comando de retorno, com permissão disponível ao operador. Teste o rollback em um ambiente de laboratório antes de precisar dele. Registre ponto de decisão, operador, versão e resultado dos probes posteriores. Um retorno executado sem confirmar saúde e qualidade é apenas uma troca, não uma recuperação demonstrada.
↗ Deployments↗ Rollbacks, gradual rollouts, and traffic migration
Autoscaling: sinal, gargalo e limites
FundamentosAutoscaling ajusta capacidade conforme métricas e políticas. Kubernetes HPA pode usar métricas de recursos ou outras métricas conforme a instalação. Para agentes assíncronos, idade da fila e jobs pendentes podem ser mais relevantes que CPU, porque um worker esperando API externa consome pouca CPU e ainda pode ter muitos usuários aguardando. Escolha o sinal que representa o gargalo, e teste a capacidade da dependência que receberá a carga adicional.
Mais réplicas podem aumentar concorrência no provedor, no banco e na ferramenta de escrita. Combine mínimo, máximo, limites de concorrência e quotas. Se cada réplica possuir contador próprio, escalar pode multiplicar indevidamente o orçamento permitido. Defina estabilização para evitar oscilações e considere tempo de partida. O autoscaler não produz capacidade infinita nem reduz magicamente latência quando o gargalo é um rate limit externo. A operação precisa de degradação ou rejeição explícita quando o sistema atinge seus limites.
Monitoring e serviços de cloud com escopo claro
InfraestruturaMonitore erro técnico, conclusão funcional, uso, latência e filas por versão e classe. Traces ajudam a atribuir uma piora à etapa certa, como retrieval ou ferramenta. Alertas devem ter ação definida: pausar promoção, reduzir tráfego ou iniciar diagnóstico. Um alerta baseado em média global pode esconder falha de um tenant ou categoria. Preserve contagens e denominadores, e estabeleça retenção e acesso para a telemetria.
↗ Traces↗ Logs↗ MLflow Tracing for LLM and Agent Observability↗ Rollbacks, gradual rollouts, and traffic migration
Na cloud, escolha região, projeto, identidade de serviço, rede, secrets e limites antes de publicar. Uma revisão de teste deve usar dados sintéticos e permissões restritas. Cloud Run documenta revisão sem tráfego e migração de tráfego; confira a configuração atual da conta e comandos do CLI antes de executar. O laboratório local abaixo testa resposta e retorno de versão, mas não demonstra provisionamento de cloud, disponibilidade ou custo real. Uma entrega honesta mantém essas evidências separadas.
↗ Traces↗ Logs↗ MLflow Tracing for LLM and Agent Observability↗ Rollbacks, gradual rollouts, and traffic migration
Duas versões HTTP e uma decisão de rollback
FundamentosExecute node rollout.cjs com Node que ofereça fetch. Cada versão inicia em uma porta livre e o teste consulta de fato o serviço HTTP local. A candidata retorna um prazo incompatível com a política de referência. O roteador de teste volta a apontar para a baseline e confirma a resposta após a troca.
const http=require('node:http');
const assert=require('node:assert/strict');
async function start(version,days){
const server=http.createServer((req,res)=>{
res.setHeader('Content-Type','application/json');
res.end(JSON.stringify({version,days}));
});
await new Promise(resolve=>server.listen(0,'127.0.0.1',resolve));
return {server,url:'http://127.0.0.1:'+server.address().port};
}
(async()=>{
const baseline=await start('v1',14),candidate=await start('v2',30);
try{
let active=candidate;
const probe=await fetch(active.url).then(r=>r.json());
const passed=probe.days===14;
if(!passed)active=baseline;
const after=await fetch(active.url).then(r=>r.json());
assert.equal(passed,false);assert.equal(after.version,'v1');
assert.equal(after.days,14);console.log({probe,after,rolledBack:!passed});
}finally{
await Promise.all([baseline,candidate].map(x=>new Promise(r=>x.server.close(r))));
}
})();O HTTP da candidata funciona, mas a verificação de negócio falha. O retorno para v1 recupera a resposta de 14 dias, mostrando a diferença entre health técnico e qualidade. O exemplo não divide tráfego, não muda banco e não escala processos. Ele fornece uma prova pequena da política; os testes seguintes expandem a fronteira operacional.
Exercício aplicado
A candidata passa health, mas devolve prazo incorreto. Ela também escreveu um campo novo que v1 ignora. Decida rollback e descreva o que ainda precisa ser verificado.
- Compare resposta com a política, não apenas HTTP.
- Volte tráfego para a revisão conhecida.
- Teste leitura dos dados produzidos pela candidata.
- Verifique efeitos e jobs já iniciados.
Abrir resolução comentada
O probe funcional bloqueia expansão e justifica rollback. O teste local confirma resposta correta após voltar a v1. Se o novo campo é realmente opcional e ignorável, a leitura antiga pode continuar, mas isso deve ser testado, não inferido pelo nome do campo.
A mudança de tráfego não cancela trabalhos nem reverte efeitos. Inspecione jobs, migrações e ações realizadas. Só declare recuperação após probes técnicos e funcionais, com a versão efetiva registrada.
const http=require('node:http');
const assert=require('node:assert/strict');
async function start(version,days){
const server=http.createServer((req,res)=>{
res.setHeader('Content-Type','application/json');
res.end(JSON.stringify({version,days}));
});
await new Promise(resolve=>server.listen(0,'127.0.0.1',resolve));
return {server,url:'http://127.0.0.1:'+server.address().port};
}
(async()=>{
const baseline=await start('v1',14),candidate=await start('v2',30);
try{
let active=candidate;
const probe=await fetch(active.url).then(r=>r.json());
const passed=probe.days===14;
if(!passed)active=baseline;
const after=await fetch(active.url).then(r=>r.json());
assert.equal(passed,false);assert.equal(after.version,'v1');
assert.equal(after.days,14);console.log({probe,after,rolledBack:!passed});
}finally{
await Promise.all([baseline,candidate].map(x=>new Promise(r=>x.server.close(r))));
}
})();Como conferir seu resultado
- HTTP real local confirma versões antes e depois.
- Falha funcional bloqueia mesmo com 200.
- Runbook identifica revisão anterior e critério de retorno.
- Compatibilidade de dados e efeitos são avaliados separadamente.
Aplique em um problema novo
Primeiro resolva sem consultar a resposta. Explique suas decisões e guarde a evidência. A conclusão de leitura é independente desta autoavaliação.
Confira seus pré-requisitos
- Separar health e qualidade funcional.
- Entender rollout/rollback e compatibilidade.
Canary 5% temhealth ok, mas prazo errado; escreveu campo obrigatório que v1 não conhece. Decida rollback.
Conferir raciocínio e critérios de domínio
Limitar exposição/pausar promoção segundo critérios definidos antes.
Health operacional não compensa erro de prazo; comparar casos e sinais do produto.
Rollback de código depende de compatibilidade dos dados; planejar adaptação/reversão sem apagar evidência.
Evidências para autoavaliação ou revisão por pares
- Exposição: Limitar exposição/pausar promoção segundo critérios definidos antes.
- Qualidade: Health operacional não compensa erro de prazo; comparar casos e sinais do produto.
- Reversão: Rollback de código depende de compatibilidade dos dados; planejar adaptação/reversão sem apagar evidência.
Um erro frequente
Trocar imagem sempre desfaz deploy.
Rollback depende da compatibilidade dos dados e efeitos.
Teste sua compreensão
Responda com suas palavras antes de abrir o comentário. Saber explicar uma decisão é parte do domínio.
1. Rollback desfaz estornos executados?
Não.
Efeitos externos precisam de reconciliação ou compensação própria.
2. CPU sempre é o melhor sinal de escala?
3. Canary pequeno prova equivalência?
Não.
Amostra e segmentos podem ser insuficientes para a conclusão.
Seu progresso fica salvo neste navegador. Concluir a leitura não substitui demonstrar o domínio nos exercícios.
Referências e aprofundamento
Documentação oficial e trabalhos originais. As referências registram o escopo e as limitações para você conferir o que sustentam.
- Deployments
Kubernetes • consulta: 2026-10-06
FundamentosRevisões, rollout, rollback, atualização gradual e estratégias de deployment.
Limites: Rollback de deployment não desfaz migrações de dados ou efeitos já executados.
- Rollbacks, gradual rollouts, and traffic migration
Google Cloud • consulta: 2026-10-06
InfraestruturaRevisões, divisão percentual de tráfego, rollout gradual e rollback em serviço cloud gerenciado.
Limites: Mudança de tráfego não é instantânea; requests em andamento podem concluir em revisões anteriores.
- Horizontal Pod Autoscaling
Kubernetes • consulta: 2026-10-06
FundamentosEscalonamento por métricas de recursos e métricas customizadas.
Limites: Autoscaling exige métricas e limites; não remove quotas do provedor nem gargalos de estado.
- Traces
OpenTelemetry • consulta: 2026-10-06
FundamentosTrace, span, contexto, relações pai-filho, eventos e status de execução.
Limites: Instrumentação mostra operações registradas; não revela raciocínio privado do modelo.
- Logs
OpenTelemetry • consulta: 2026-10-06
FundamentosLogs estruturados e correlação com contexto de traces.
Limites: Coleta e retenção dependem da implementação; evitar registrar segredos e conteúdo sensível desnecessário.
- MLflow Tracing for LLM and Agent Observability
MLflow • consulta: 2026-10-06
AgentesIA & MLAvaliaçãoEntradas, saídas, metadados, latência e uso de tokens por etapa; integração OpenTelemetry.
Limites: Custo financeiro exige cálculo adicional com tarifas vigentes; traces só cobrem etapas instrumentadas.