Cloud/rollback/canary
Você fará um deploy controlado local de duas versões e produzirá um runbook de canary e rollback. A baseline usa prazo de 14 dias e a candidata errada usa 30, permitindo verificar um erro funcional que passa em health HTTP. A entrega inclui a prova de retorno e uma análise de compatibilidade de dados.
Use Node para o teste local e o manifesto aprovado da semana 44 como referência de identidade. A extensão cloud é opcional e requer conta, projeto de laboratório, CLI autenticado, permissão de deploy e orçamento próprio. Não afirme que o script local foi implantado em Cloud Run ou Kubernetes. Registre separadamente toda operação real e encerre recursos de teste conforme seu plano.
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: Leitura: Cloud/rollback/canary
Preparar versões e definir critérios de promoção
FundamentosCrie manifestos v1 e v2 com imagem ou hash de pacote, prompt, modelo e esquema. Declare critérios antes de executar: prazo correto, zero perda de autorização, erro e latência dentro de limites definidos para o ambiente. Inclua regra para dados insuficientes, em vez de promover automaticamente por ausência de alertas. Defina quais usuários ou fixtures recebem a candidata e como sua atribuição permanece estável. Uma decisão por moeda aleatória em cada chamada pode misturar versões dentro da mesma conversa e dificultar interpretar o resultado.
Executar probes e comprovar rollback local
FundamentosRode rollout.cjs e preserve probe com v2/30 e after com v1/14. Altere a candidata para 14 e confirme que não há rollback; ajuste os asserts para esse segundo cenário. Adicione uma falha HTTP 503 e verifique que o probe técnico também pode bloquear. Depois inclua uma resposta 200 com campo obrigatório ausente: o teste de contrato deve falhar mesmo com transporte saudável. Mantenha os serviços fechados ao final para que o teste seja repetível e não dependa de portas fixas livres.
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))));
}
})();Simular canary e segmentar resultados
FundamentosFaça um selecionador determinístico enviar um em cada dez IDs de teste à candidata. Execute pelo menos um caso de cada categoria, em vez de confiar somente na fração. Registre versão, categoria, resultado e duração. Force a candidata a falhar apenas no caso de autorização e confirme pausa de expansão. Teste shadow mode sem executar ferramentas de escrita: somente a proposta pode ser comparada. A tabela precisa separar erros da baseline e da candidata e mostrar contagens, pois uma porcentagem sem denominador esconde uma amostra muito pequena.
Planejar e verificar a extensão de cloud
InfraestruturaEm Cloud Run, use um serviço de laboratório e uma imagem imutável construída por você; configure identidade, secrets, região e máximo de instâncias. Faça deploy de revisão sem tráfego e teste seu endpoint de revisão autorizado antes de mover uma fração de tráfego. Registre os nomes concretos das revisões para retorno, preservando a baseline. Em Kubernetes, confira namespace e contexto antes de aplicar Deployment, readiness e recursos; use rollout status, rollout history e rollout undo apenas no laboratório. Uma evidência real inclui estado anterior, mudança, probes e estado posterior, sem credenciais no relatório.
↗ Rollbacks, gradual rollouts, and traffic migration↗ Deployments
Testar limites e escrever o runbook
FundamentosSimule fila crescendo enquanto CPU permanece baixa e explique por que o sinal escolhido deve refletir idade de jobs. Defina limite de réplicas e concorrência conforme quota do provedor. Faça uma migração aditiva em dados sintéticos e confirme que v1 e v2 conseguem ler o formato durante a transição. Documente que rollback não desfaz ticket nem migração. O runbook precisa dizer quem pausa promoção, quais comandos ou operações retornam o tráfego e quais probes confirmam recuperação. Entregue evidência local e marque qualquer operação cloud não realizada como não executada.
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 v2 recebe 5% e erra prazo no caso crítico enquanto v1 acerta. v2 grava status='novo' obrigatório; v1 só entende 'antigo'. Latência v2 é menor. Decida rollout e rollback.
Conferir raciocínio e critérios de domínio
Promoção de v2 é bloqueada pelo erro crítico, apesar da latência. A exposição deve ser pausada/redirecionada conforme política previamente definida.
Rollback direto a v1 sobre status novo não é comprovadamente seguro; há incompatibilidade de dados e não basta trocar imagem.
É necessária uma adaptação/compatibilidade ou restauração autorizada antes de devolver tráfegoa v1. Semteste dessas linhas, a conclusão é rollback condicionado, não reversão já validada.
Evidências para autoavaliação ou revisão por pares
- Gate da canary: Promoção de v2 é bloqueada pelo erro crítico, apesar da latência. A exposição deve ser pausada/redirecionada conforme política previamente definida.
- Compatibilidade dos dados: Rollback direto a v1 sobre status novo não é comprovadamente seguro; há incompatibilidade de dados e não basta trocar imagem.
- Condição do rollback: É necessária uma adaptação/compatibilidade ou restauração autorizada antes de devolver tráfegoa v1. Semteste dessas linhas, a conclusão é rollback condicionado, não reversão já validada.
Um erro frequente
Autoscaling corrige regra de negócio.
Autoscaling amplia capacidade, não corrige uma regra errada.
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.