Resumo

Este simulador de rollout de código gerado por IA mostra quanto do seu error budget de 30 dias uma mudança ruim escrita por IA consome antes de ser revertida. Informe tráfego, SLO, escada de rollout, tempo de soak e velocidade de detecção. Ele compara um deploy único em 100%, um rollout em estágios acompanhado por uma pessoa e um gate automático de SLO, com aritmética simples que você pode conferir à mão.

Simulador gratuito de rollout

Simulador de rollout de código gerado por IA: veja até onde uma mudança ruim se espalha

Informe tráfego, SLO e escada de rollout. A ferramenta mostra quanto do error budget de 30 dias uma mudança ruim, escrita por um gerador de código com IA, consome em um deploy único, com uma pessoa olhando o dashboard e com um gate automático.

Rodar o simulador Como funciona a conta

Simulador de rollout de código por IA

Cada campo altera o resultado em tempo real. Os valores padrão descrevem um serviço com 200 requisições por segundo, SLO de 99.9% e uma mudança que falha em 20% das requisições.

Seu plano de rollout
EstágioTráfegoComeça emRequisições atendidas pelo código novo
Como funciona

Três linhas de aritmética, nenhum modelo escondido

Error budget

Budget = (1 menos SLO) vezes a média de requisições por segundo vezes 2,592,000 segundos em 30 dias. Com 200 req/s e 99.9%, são 518,400 requisições com falha permitidas por mês.

Exposição ao longo do tempo

A escada indica a fração do tráfego no código novo a cada minuto. O simulador integra essa fração desde a primeira requisição até o tempo de detecção somado ao tempo de revert, então uma detecção lenta empurra a mudança para estágios posteriores, maiores.

Requisições com falha

Falhas = requisições por segundo vezes a sua taxa de falha vezes a integral de exposição. Dividindo pelo budget, obtém-se a porcentagem do mês que uma mudança ruim custa. Três modos de detecção são comparados na mesma escada.

Use em uma mudança real

Do diff gerado por IA ao plano de rollout

  1. 1

    Escolha entradas pessimistas

    Para uma mudança escrita por um gerador de código com IA e revisada às pressas, assuma uma taxa de falha alta caso ela esteja errada, e um tempo de detecção humano igual ao seu incidente recente mais lento, não ao melhor.

  2. 2

    Compare os três cenários

    O deploy único mostra o pior caso. O caso em estágios com humano mostra o que sua escada entrega hoje. O gate automático mostra o que um gate sobre a sua métrica de SLO mudaria.

  3. 3

    Copie o plano para o runbook

    O botão de cópia exporta os estágios e o consumo de budget no pior caso como texto simples, pronto para colar em um ticket de mudança ou na descrição de um pull request.

Por que a escada importa

O primeiro estágio é onde a maior parte do budget é preservada

Uma mudança que falha em 20% das requisições com 1% do tráfego produz falhas em 0.2% das requisições. A mesma mudança com 100% do tráfego falha uma requisição em cada cinco. A diferença entre esses dois números é todo o argumento para um rollout progressivo. Quando o código vem de um gerador capaz de produzir centenas de linhas em segundos, o tempo de revisão por linha cai, e o primeiro estágio passa a ser o lugar onde você descobre o problema.

  • Um primeiro estágio de 1% limita o raio de explosão em 99% antes de qualquer outra coisa ser medida.
  • O tempo de soak só ajuda se o seu sinal conseguir mostrar uma regressão dentro dessa janela.
  • Reverter mais rápido vale tanto quanto detectar mais rápido: ambos aumentam a integral de exposição.
Rack de servidores com uma luz de status âmbar entre várias verdes
Leia o resultado

O que fazer com os três números

Deploy único

Se este número ficar acima de 5% do budget mensal para uma falha plausível, um deploy de uma vez só é a decisão de gastar seu budget em uma única mudança. Poucas equipes fazem essa escolha de propósito.

Em estágios, humano

É a sua realidade atual se o plantão acompanha gráficos. Se a exposição de pico mostrar 100%, sua escada é cosmética: a mudança ruim alcança todo mundo antes que alguém reaja.

Em estágios, gate automático

É o caso de um gate que lê sua métrica de SLO e reverte sem pedir permissão. O valor só é real se o gate disparar com o mesmo sinal que o seu SLO usa, então teste com uma mudança deliberadamente ruim.

Perguntas frequentes

Este simulador de rollout de código gerado por IA é gratuito?
Sim. Ele roda inteiramente no seu navegador, não exige cadastro e não envia nada para um servidor além de um beacon anônimo de uso. Não é um gerador de código com IA: ele simula até onde uma mudança ruim se espalha quando o código de um gerador chega ao seu pipeline.
De onde vêm os números?
De uma aritmética que você pode conferir à mão. O error budget é (1 menos o seu SLO) vezes as requisições em 30 dias. As requisições com falha são o seu tráfego vezes a taxa de falha vezes a fração de tráfego que o código novo recebe, integrada até o fim do revert. Nenhum benchmark está embutido; cada premissa é uma entrada.
Por que modelar código gerado por IA de forma diferente do código escrito por humanos?
A matemática é a mesma. O que muda é a premissa: um diff grande produzido em minutos recebeu menos revisão humana por linha, então a taxa de falha e o tempo para perceber merecem valores pessimistas. Defina os dois a partir do seu próprio histórico de incidentes, não desta página.
O que o simulador assume que o tráfego real não faz?
Ele assume tráfego estável, uma regressão que falha a mesma fração de requisições desde a primeira requisição, e um revert que para o dano assim que termina. Incidentes reais têm rampa de subida, falhas parciais e rollbacks lentos, então trate o resultado como um piso de dano, não como uma previsão.
Qual é um bom tempo para perceber em um gate automático de SLO?
Depende da resolução da sua métrica e da janela de alerta. Um gate que avalia a taxa de erro de um minuto contra um limite pode disparar em dois a cinco minutos. Se o seu alerta só aciona depois de uma janela de burn rate de 30 minutos, informe esse valor, e o simulador mostrará o custo.
Um soak mais longo sempre ajuda?
Não. Um soak mais longo dá mais dados ao gate em cada estágio, mas também mantém uma mudança ruim em uma determinada fração de tráfego por mais tempo. Se o gate percebe em dois minutos, um soak de dez minutos sobretudo acrescenta espera. Se ele precisa de quinze, um soak de cinco minutos deixa a mudança chegar a 25% ou mais antes.
Posso usar isto para rollouts de feature flag, e não só para deploys?
Sim. Um rollout percentual de uma flag se comporta como um deploy canary neste cálculo: uma fração de tráfego, um tempo de soak, um atraso de detecção e um tempo de revert. Substitua o tempo de revert pela latência do seu kill switch de flag.

Quer que o gate faça o revert por você?

A upstreamapi executa rollouts progressivos com gates de SLO e auto-rollback, então a terceira coluna é a que você usa em produção.

Conheça a upstreamapi