Primeiro desafio técnico: o que realmente acontece quando você deploya na produção pela primeira vez
O primeiro grande deploy que você faz sozinho é diferente de tudo que você treinou. A documentação diz uma coisa, o ambiente de staging se comporta de outra, e a produção simplesmente decide que não, obrigado. Isso é normal. A maioria dos engenheiros que eu conheço tem um episódio desses no currículo. O conceito de first tech challenge não é um framework ou uma metodologia com nome bonito. É o momento em que seu código deixa de ser teoria e encontra a realidade das infraestruturas que você nunca configurou diretamente. O problema não é o código em si. Geralmente é o que você não pensou.
Primeiro tech challenge: como preparar algo que ainda não quebrou (mas vai)
Eu aprendi isso na unha em 2019, quando precisei colocar no ar um serviço de processamento de arquivos em lote para um cliente pequeno. A API era simples, Docker estava pronto, o banco de dados rodava num container separado. Parecia trivial. Até que o primeiro lote chegou com 4.000 arquivos CSV e o container de processamento simplesmente morreu sem log de erro. Nenhum stack trace. Nada. Só um exit code 137. O problema era memória. O container tinha limite de 512MB configurado por uma decisão que eu não havia tomado, mas que o time de infra local havia colocado como padrão. Nenhum arquivo estava sendo processado individualmente de forma problemática. Eram os buffers internos do Go que acumulavam tudo em memória antes de escrever no banco. A solução foi trocar o processamento stream-based por leitura parcial com paginação e aumentar o limite do container para 1GB. Simples. Mas levaria horas pra descobrir sem monitoramento.
Isso me leva a um ponto que quase ninguém menciona em tutoriais: o primeiro desafio técnico raramente é sobre o seu código. É sobre as suposições que outras pessoas fizeram antes de você chegar lá. Headers de timeout mal configurados no nginx. Variáveis de ambiente com nomes ligeiramente diferentes entre staging e produção. Uma regra de segurança no security group que bloqueia conexões de saída do container. Isso acontece com frequência suficiente para ser esperado.
O que fazer antes do primeiro deploy
Você não precisa de ferramentas caras. Precisa de três coisas que a maioria dos times não faz porque parece obvia demais. Primeiro, tenha logs estruturados antes de qualquer coisa. Não é sobre ter um dashboard bonito no Grafana. É sobre conseguir ler um log de erro às 3h da manhã e entender imediatamente o que aconteceu. Timestamp, nível de severidade, request ID, e o contexto mínimo necessário. Se você precisa consultar três fontes diferentes pra montar a imagem do que ocorreu, seu sistema de logging já falhou no primeiro desafio.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Segundo, configure health checks reais. Health check que só responde 200 OK quando o processo está vivo não te ajuda em nada. O meu health check deve verificar se o banco responde, se o cache está acessível, e se o disco tem espaço livre. Leva dois segundos a mais na resposta, mas evita que seu load balancer envie tráfego para um container que não consegue trabalhar. Terceiro, tenha um rollback imediato. Se o primeiro deploy quebra alguma coisa, você precisa conseguir reverter em menos de cinco minutos. Isso significa que seu pipeline de deploy deve incluir o comando de rollback como opção padrão, não como procedimento de emergência. Eu já vi times que levaram 40 minutos pra reverter porque o script de deploy não era reversível. Quarenta minutos em produção caída. Sem brincadeira.
Erros comuns que todo mundo comete na primeira vez
O erro mais frequente é confiar cegamente no ambiente de teste. Staging não é produção. Os dados são menores, o tráfego é zero, e o banco de dados tem índices que nunca foram usados em consultas reais. Quando eu comecei, eu testava uma consulta de agregação que levava 200ms no staging e surpreendi-me ao ver que na produção ela levava 12 segundos. O plano de execução era completamente diferente porque os estatísticas do banco de dados em staging estavam desatualizadas. Rodar um ANALYZE TABLE antes de validar a performance em produção resolveu. Levei dois dias pra descobrir isso. Outro erro comum é não testar falhas intencionalmente. Você não sabe se seu sistema resiste a algo até forçar esse algo a acontecer. Reinicie um container durante uma transação. Desligue o banco secundário de leitura. Simule latência alta entre serviços. O primeiro deploy bem-sucedido não é aquele que funciona quando tudo dá certo. É aquele que falha de forma controlada.
Também tem o problema de variáveis de ambiente. Eu tenho uma lista de verificação específica: SECRET_KEY, DATABASE_URL, REDIS_URL, LOG_LEVEL, MAX_CONNECTIONS, TIMEOUT_MS. Se qualquer uma dessas estiver ausente ou com valor vazio, o sistema deve falhar explicitamente na inicialização com uma mensagem clara. Nunca passe adiante com um valor default silencioso. Valor default silencioso é a forma mais elegante de criar um bug que aparece três meses depois.
O que esperar depois do primeiro deploy
Depois que você coloca no ar, o ritmo muda. Os primeiros incidents vão acontecer. Não porque você fez algo errado, mas porque existem variáveis que nenhum documento cobre. Um serviço de terceiros que muda sua API sem aviso. Um problema de memória que só aparece com determinado padrão de uso. Um conflito de versões de biblioteca que o package manager resolveu de forma diferente no seu ambiente. Na primeira semana pós-deploy, o ideal é manter alguém on-call efetivamente, não nominalmente. Alguém que possa responder rápido, ter acesso aos logs, e poder fazer deploy de correção sem passar por três aprovações. Isso reduz o tempo médio de resolução de incidents críticos de horas para minutos.
Se o primeiro deploy não tive problemas, considere isso sorte, não habilidade. Registre o que você aprendeu, documente as suposições que fez, e prepare o próximo deploy sabendo que a próxima vez será diferente. O primeiro desafio técnico é menos sobre resolver problemas e mais sobre construir a confiança de que você consegue lidar com problemas quando eles aparecem. E eles vão aparecer.
