A mentira do ambiente de staging

Todo time tem um ambiente de staging, e todo time acredita nele mais do que ele merece. 'Passou no staging' é oferecido como evidência de que uma release é segura. O que isso prova de verdade é que o código sobe, o caminho feliz funciona e nada óbvio quebra quando uma pessoa clica pelas telas. São fatos úteis. Não são os fatos que evitam quedas.

A mentira não é que staging é inútil. A mentira é que staging parece com produção. Nos sistemas que audito, quase nunca parece, nas coisas que importam.

Os jeitos que staging é diferente

Dado é a primeira e maior lacuna. Staging tem mil usuários e produção tem um milhão. A query que roda em dez milissegundos no staging leva onze segundos em produção porque o planner escolheu outra estratégia em escala. A migration que levou dois segundos no staging trava a tabela por três minutos em produção. Nenhuma quantidade de clique no staging encontra nenhum dos dois problemas.

Tráfego é a segunda. Staging atende um testador por vez. Produção atende centenas ao mesmo tempo, e concorrência é onde moram as race conditions, a contenção de lock, o esgotamento do pool de conexões e as estouradas de cache. Código que nunca rodou sob carga concorrente nunca foi testado para o modo de falha mais comum de produção.

Configuração é a terceira. Staging compartilha instância de banco para economizar, usa cache menor, aponta para versões sandbox de APIs de terceiros que se comportam diferente das reais, tem outros timeouts, outras feature flags, outra política de CDN ou nenhuma. Cada uma dessas diferenças é um bug que staging não consegue pegar por construção.

E tem o drift. Staging era idêntico a produção no dia em que foi criado. Desde então, alguém testou uma mudança de config no staging e nunca reverteu. Outra pessoa mudou produção na mão durante um incidente. Os dois ambientes vêm divergindo em silêncio há meses, e ninguém tem um diff.

Para que staging serve de verdade

Staging é bom em três coisas. Pegar problemas de integração entre serviços desenvolvidos separadamente. Deixar alguém que não é engenheiro ver a feature antes de sair. Rodar os testes end-to-end automatizados contra um sistema publicado em vez de um mockado. São benefícios reais, e um time deveria manter o staging por eles.

Para o que staging não serve é responder 'isso vai sobreviver em produção'. Essa pergunta tem outras respostas, e elas são mais baratas do que uma segunda produção.

As alternativas que funcionam

• Teste migrations contra uma cópia recente do banco de produção, restaurada numa instância descartável, e cronometre. Isso acha os problemas de lock que as tabelas pequenas do staging escondem.
• Faça load test do endpoint específico que mudou, na concorrência de produção, antes do merge. Não o sistema inteiro, só o caminho que é novo.
• Publique em produção atrás de uma feature flag e ligue primeiro para usuários internos. Isso é staging com dados reais, tráfego real e configuração real.
• Faça canary da release para uma fração pequena do tráfego real e observe taxa de erro e latência por versão durante quinze minutos.
• Mantenha infraestrutura como código para os dois ambientes a partir da mesma fonte, e rode um diff com frequência para pegar drift.

Cada uma dessas testa o código contra a coisa que vai rodar ele de verdade. Staging testa o código contra uma imitação menor, mais velha e mais quieta.

Onde gastar o dinheiro

Times costumam gastar mais deixando o staging maior do que gastariam nas alternativas acima. Um staging que é cópia fiel de produção, com dados do tamanho de produção, replay de tráfego de produção e configuração idêntica, é uma segunda produção, e custa como uma. Pouquíssimos times precisam disso. O que precisam é da disciplina de testar mudanças de dados contra tamanhos reais, mudanças de código sob concorrência real e releases contra tráfego real em doses pequenas.

Mantenha o staging. Só pare de fazer para ele perguntas que ele não consegue responder, e pare de tratar 'passou no staging' como motivo para pular as perguntas que importam.