Josimar JMV
Blog · Carreira em produção · 04·09·2026

Medo de subir em produção: como eu perdi o meu (e o método que funcionou)

Eu fui pro Paraguai com dinheiro escondido na cueca. Eu queimei a placa-mãe do primeiro servidor que desmontei. Eu já tive medo, muito medo, muitas vezes — e é por isso que este texto não vem de quem nunca sentiu.

Resposta rápida: o medo de botar sistema em produção só passa enfrentando — mas enfrentar sem método é só apanhar. O que funciona: observabilidade (log em tudo: quem fez o quê, onde, quando), plano de rollback pronto, investigar antes de voltar o serviço e subir primeiro uma versão beta gratuita, avisada como beta, pra deixar quebrar enquanto ninguém está pagando. Você não precisa dominar rede, DNS, SSL, Docker e cluster antes de começar — isso vem por camada, conforme a necessidade.

Este texto é pra quem é do bem: gente que está desenvolvendo, que quer o melhor pra si e pra família, mas trava na hora de colocar um IP público no ar e dizer "agora é minha vez de vender". Um aluno da imersão de sites escreveu isso no chat — tem boas ideias, faz as coisas, mas tem medo de subir em produção. Este artigo é pra ele também.

O método, em cinco pontos:

Este artigo é a versão escrita do vídeo publicado no canal em 3 de setembro de 2026 — sem corte, gravado por quem cuida de datacenter e paga a conta quando o trem cai. Assista e leia junto:

18 minutos, sem edição — do canal @josimarjmv. Se preferir o texto, ele está todo aqui embaixo.

O medo é legítimo — e eu também tive

Antes de qualquer dica, o principal: ter medo não é sinal de que você é ruim. É sinal de que você entendeu o tamanho da coisa. Você sabe a dor que é o negócio cair, ser invadido, e sabe quem depende daquilo funcionar.

Eu sou dono de empresa e virei hands-on de novo justamente por medo — pra entender como funcionava e não ficar refém de ninguém. Já fiquei. Já quase quebrei a empresa por confiar em quem era tecnicamente capacitado mas não queria fazer, e em quem queria muito mas não tinha capacidade técnica. Isso não é sobre ser júnior ou sênior; é sobre segurança — a sua e a de quem depende de você.

A lista dos meus medos é longa e específica:

Desmontar servidor dedicado. Equipamento de milhares de reais, na mão, sem rede de proteção.

Ter meu próprio GitLab. Medo de ficar refém de uma peça que eu não dominava.

Subir cluster de banco de dados. Sem entender direito como funcionava split brain.

Trocar de proxy. Porque a performance não estava boa e mexer ali dói.

Fazer anúncio. E aqui não estou falando de tráfego pago — falando de me expor mesmo.

Some a isso o cenário de hoje: na era da IA, qualquer concorrente que não vai com a sua cara consegue direcionar um ataque com muito mais facilidade. Derrubar uma máquina virtual mal configurada é trivial pra quem entende. Pra quem não entende, é desespero puro — e é aí que o medo trava tudo.

A primeira lição não veio de um servidor. Veio do Paraguai.

Eu tinha uns 20 e poucos anos e uma loja de informática. Comprava da Zona Franca de Manaus, até me falarem que no Paraguai era bem mais barato. Fui. E fui morrendo de medo: coloquei dinheiro na cueca e dentro dos dois tênis, porque pensei "não é possível que, se me assaltarem, levem tudo de uma vez". Pelo menos o dinheiro de voltar pra casa eu tinha que garantir.

A travessia era a Ponte da Amizade, na aduana antiga, sem segurança nenhuma — gente correndo, pegando coisa e fugindo. Eu passei com frio na barriga, entrei nas lojas com medo, e voltei. Na segunda vez foi menos. Na terceira eu já ia tranquilo. Eu sabia como funcionava, sabia as peças que comprava, sabia onde ia e a que horas voltar.

É exatamente a mesma mecânica de um deploy. O que mudou entre a primeira e a terceira viagem não foi coragem: foi informação coletada em campo.

Queimei a placa-mãe do primeiro servidor que desmontei

Anos depois, antes de ter o meu próprio CDN, eu alugava servidor em datacenter dos outros. Comprei uns servidores IBM usados — isso há uns 8 anos, na sede antiga — só pra testar aqui dentro se o que eu tinha aprendido valia também pra esse mundo, porque eu já pretendia ter o meu datacenter.

Eram máquinas de peso: placa-mãe com dois processadores físicos, 16 núcleos cada — 32 núcleos — e 256 GB de memória RAM. Coisa cara. E eu queimei o primeiro. Fiz na placa-mãe algo que não podia e estourei. Ele ainda ligava, mas a performance ficou péssima; tentei reconfigurar, regravar tudo, não teve jeito. E não existia IA pra me ajudar: era documentação e mão.

O que eu fiz com medo? Fui de novo. Comprei outro servidor, deixei os dois lado a lado, estudei o que tinha feito de errado, desmontei, montei e acertei. E o meu "desmontar" não é trocar processador e memória — é entender cada peça: chassi com seis portas SATA e espaço físico pra quatro, placa de rede 10 GB nativa, GBIC de fibra, controle de ventoinha, IPMI pra ligar e desligar o servidor pela internet.

Cada medo enfrentado me devolveu uma lição concreta. No Paraguai, aprendi o caminho. No servidor queimado, aprendi o que não repetir — e na segunda vez não aconteceu.

A dica fundamental: observabilidade

Aqui está o pulo do gato, e ele explica por que "enfrentar o medo" sozinho não basta: como você vai perder o medo se você não sabe o que aconteceu?

Quando fui ao Paraguai, eu observei — as lojas, o trajeto, o horário de ir e de voltar, onde dava pra passar e onde não dava. Anotei e aprendi. Quando queimei o servidor, observei o erro e corrigi. Queda sem observação não ensina nada: você cai dez vezes e aprende o mesmo que caindo uma.

É a briga que eu compro com o time até hoje. Aconteceu um problema, eu pergunto: o log fala o quê? E vem a resposta que me tira do sério: "não botei log". De estagiário eu ainda engulo. De alguém com dois, três, quatro anos de estrada, não dá.

Log de tudo, não só do usuário. O seu próprio sistema também mexe no banco — quem mexeu, onde, quando.

Quatro perguntas bastam. Não precisa dos seis passos do jornalista: quem fez o quê, onde e quando já resolve.

Log é o que deixa a IA te ajudar. Com log bom, você pede pra ela ler e caçar o problema — inclusive depois de uma invasão. Sem log, não há o que ler.

O plano pra subir sem quebrar o seu negócio

Se você tem medo e quer colocar o sistema online, não suba já vendendo. Suba gratuito, com o aviso na cara: versão beta, de graça, pode quebrar. Deixa rodar, deixa o povo usar dentro de um limite aceitável e vai aprendendo com o que aparece. Assim você perde o medo com o custo baixo — e não com o cliente pagante no meio.

Junto com isso, duas coisas que precisam estar prontas antes:

Plano de rollback. O caminho de volta desenhado antes de você precisar dele, não durante o incêndio.

Investigar antes de voltar. Caiu, a vontade é dar restart e deploy na hora. Não faça: muitas vezes isso apaga o rastro — o estado volta e a causa some. Primeiro você olha o que aconteceu, com o log na mão. Depois volta.

Essa mesma disciplina é o que sustenta um pipeline sério quando existe usuário do outro lado — assunto que eu detalhei no artigo sobre a migração de mais de 3 TB de e-mail: staging, QA, pré-produção e liberação parcial existem justamente pra que o "deixa quebrar" aconteça longe de quem paga.

Você não precisa entender tudo de uma vez

Rede, infraestrutura, proxy, DNS, SSL, Docker, banco de dados, cluster, banco em memória: você não precisa ser o cara que entende tudo isso pra começar. Se você tem medo, é porque ainda não entende — e está tudo bem, é assim mesmo.

O domínio chega por camada, conforme a necessidade bate na porta: quando precisar escalar o banco, quando precisar de job assíncrono, de mensageria, de banco em memória, de storage distribuído, de entender o custo desse storage, de decidir se vai ter teste grátis, de escolher gateway de pagamento — e aí pode compensar pagar 0,1% a mais numa API por causa da política de chargeback — e até de fazer SEO do software, que é mais importante do que parece.

Isso leva tempo. Virar sênior significa que você passou muita raiva ao longo dos anos e absorveu a informação. A diferença de hoje é que a IA acelera isso de forma absurda: nesses últimos dois anos e meio, três, eu aprendi coisa que levaria dez — porque ela testa, prototipa e reproduz a falha comigo. Mas tem um porém que não dá pra pular: você precisa entender o que ela está fazendo. Entender o log, entender o que aconteceu, reproduzir a queda. Aí o aprendizado é infalível.

Vale lembrar também que o medo às vezes não é técnico: é de quem depende de você. Esse é o mesmo pano de fundo que eu tratei em acabou pro dev chinelinho — o mercado não está atrás de quem sabe tudo, está atrás de quem resolve e assume.

Quer pegar o atalho em vez de bater cabeça por dois ou três anos? Vou fazer a Imersão de SaaS — presencial em São Paulo, 3 dias (sexta, sábado e domingo), investimento de R$ 3.700, data a definir, com pré-inscrição pela lista de espera. É o pipeline completo de botar software em produção sem medo: a parte técnica, a venda, a análise de negócio e o atendimento ao cliente — que é o assunto que ninguém trata em vídeo de desenvolvimento, apesar de o cliente ser o principal usuário do seu software. Se o seu caminho é a infraestrutura por baixo, chatbot em produção ou criar e vender sites, tem imersão pra isso também. Veja as quatro imersões →

Perguntas frequentes

Ter medo de subir em produção é sinal de que eu não sou bom o bastante?
Não. O medo aparece em quem entendeu o tamanho da responsabilidade — o sistema pode cair, pode ser invadido, e tem gente dependendo. Quem opera produção há mais de vinte anos também sentiu, e muitas vezes: desmontar servidor caro, subir cluster de banco sem dominar split brain, trocar de proxy, manter o próprio GitLab.
Como se perde o medo de colocar um sistema no ar?
Enfrentando — não tem outro caminho. Você bota no ar, deixa quebrar e aprende com o que quebrou. O que muda o jogo é a segunda parte: só se aprende com uma queda que foi observada. Sem observabilidade, cair dez vezes ensina o mesmo que cair uma.
Qual é a dica fundamental pra subir sem pânico?
Observabilidade. Log em tudo, do usuário e do próprio sistema: quem fez o quê, onde e quando. Não precisa dos seis passos do jornalista — quatro bastam. Sem log você não responde à pergunta que importa depois de uma queda, e sem resposta não há aprendizado.
Preciso dominar rede, DNS, SSL, Docker e cluster antes de subir?
Não inicialmente. Se você tem medo, é porque ainda não domina tudo isso — normal. O domínio vem por camada: escalar banco, job assíncrono, mensageria, banco em memória, storage distribuído, custo de storage, gateway de pagamento, chargeback e até SEO do produto.
Posso começar a vender assim que o sistema estiver no ar?
Enquanto o medo está lá, não. Suba uma versão gratuita, avise claramente que é beta e que pode quebrar, deixe rodar dentro de um limite aceitável de uso e vá aprendendo. Quando o pânico passar, aí você cobra.
O que fazer no momento em que o sistema cai?
Ter o plano de rollback pronto e não voltar no desespero. Restart e deploy imediatos costumam apagar o rastro: o estado volta e a causa some. Primeiro investigue o que aconteceu junto com o log; depois restaure.
A IA ajuda a perder o medo de produção?
Acelera muito — ler log, testar, prototipar, reproduzir a falha que derrubou o sistema. Mas só funciona se você entende o que ela está fazendo. Ela encurta o tempo de aprendizado; não substitui o entendimento.
Botar SaaS em produção é só a parte técnica?
Não. Envolve análise de negócio, marketing e, principalmente, atendimento ao cliente: solicitação, abertura de chamado, postura no suporte. A parte financeira muitas vezes manda mais que a técnica — um estudo de tráfego mal feito inviabiliza produto que funciona tecnicamente.

Baseado no vídeo "Medo de subir em produção? A verdade que ninguém te conta", do canal @josimarjmv, publicado em 03/09/2026 (18min18s), com transcrição própria das legendas do vídeo. Formato da imersão conforme anunciado; data ainda a definir. Toda segunda-feira tem live ao meio-dia no canal.