Tres Coisa Que Nao Volta Atras

O guia prático de operações que realmente não têm volta

Existem coisas no dia a dia técnico que parecem inofensivas até o momento em que você clica no botão errado. A maioria dos tutoriais fala sobre prevenção, mas poucos explicam o que acontece quando a prevenção falha. Vou listar três cenários reais e mostrar como você lida com isso na prática, incluindo um erro que eu cometi e que ainda me incomoda. A primeira e mais evidente é o migração de banco de dados sem backup transacional. Você já viu aqueles scripts que alteram schema em produção às 3 da manhã. Parece simples: adiciona uma coluna, popula com dados, dropa a antiga. O problema é que, se algo der errado no meio do processo, o banco fica num estado parcialmente migrado e as tabelas novas podem ter constraints inconsistentes. Eu já vi um colega rodar um ALTER TABLE em uma base de 4TB sem testar primeiro em staging. O lock ficou ativo por 12 minutos. A aplicação inteira parou. O pior: o rollback não era possível porque o script já tinha commitado metade das operações. A solução que funcionou foi ter um snapshot anterior do banco e reconstruir a partir dele, mas isso custou 6 horas de downtime que não estavam no plano original. A segunda coisa é o deploy com force-push em repositórios compartilhados. Você acha que está resolvendo um merge conflict feio, faz um git push --force, e destrói commits que outros membros da equipe tinham puxado. O Git permite isso, mas isso não significa que é seguro. Eu já perdi três horas apenas tentando reconstruir branches que estavam apontando para commits que eu sobrescrevi. O git reflog existe exatamente para esse caso, mas a maioria dos desenvolvedores não sabe que ele é seu único resgate quando o force-push erra. O workaround mais simples é nunca fazer force-push em branches main ou master, e usar pipelines de merge com proteção de branch ao invés de push direto.

A terceira é o pagamento ou transferência financeira instantânea confirmada. Sistemas de pagamento PIX ou transferências Same Day não têm cancelamento nativo. Se você enviar para o conta errada, o dinheiro some. Não existe botão de desfazer. A única saída é entrar em contato com a operadora e solicitar estorno, o que leva de 5 a 15 dias úteis e nem sempre é bem-sucedido. Eu já fiz isso duas vezes — uma por engano digitando um dígito a mais no CPF do beneficiário, e outra por copiar e colar dados de pagamento de um projeto que já estava encerrado. Em ambos os casos, o dinheiro voltou após insistência administrativa, mas o tempo de espera e a complexidade do processo foram desproporcionais para erros tão simples. O que ninguém te conta é que existe uma classe de operações chamadas "write-once confirmable" que poderiam prevenir dois desses três cenários. Bancos de dados transacionais modernos permitem staged migrations com rollback automático se o teste de integridade falhar. Repositórios Git podem ter hooks de pre-receive que bloqueiam force-push. E sistemas de pagamento têm a funcionalidade de "aguardar confirmação" que não é divulgada porque aumenta o atrito no fluxo de checkout. A questão é que esses salvaguardas precisam ser configuradas proativamente, e a maioria das equipes negligencia isso até que o problema aconteça. Se você quer evitar Doriana, o passo mais importante é criar um checklist de confirmação antes de qualquer operação irreversível. Isso inclui: verificar o ambiente alvo (produção vs staging), ter um snapshot ou backup recente disponível, e ter um plano B documentado caso o rollback não seja automático. O tempo que você gasta configurando isso leva cerca de 30 minutos e pode economizar horas de recuperação de emergência.

Para migrações de banco de dados, recomendo ferramentas como flyway ou liquibase, que gerenciam versionamento de schema com rollbacks automatizados baseados em scripts inversos. Para Git, configure branches protegidos no GitHub ou GitLab com regras de force-push bloqueado. E para transações financeiras, ative o limite diário e a confirmação em dois passos no seu app bancário — isso reduz drasticamente a chance de erro humano. O detalhe mais importante que eu gostaria de destacar é que a maior causa de problemas irreversíveis não é a falta de conhecimento técnico, mas sim a pressa. Quando você está correndo para resolver um incidente ativo, a probabilidade de pular etapas de segurança dispara. Por isso, ter procedimentos documentados e automatizados antes do problema acontecer é o que realmente faz diferença. Não confie na sua memória ou disciplina no momento de crise. Confie em automação.