Não me ajude · Escudo

Lembro de estar resolvendo um problema com imagens de forma cuidadosa. Meu chefe chega na minha mesa, observa o que estou fazendo e pergunta: “O que você está fazendo?”. Eu explico. Ele responde: “Chega pra lá, deixa eu fazer isso”, e começa a mexer no meu computador, eu estava mexendo diretamente no servidor da empresa. Ele clica aqui, mexe ali e faz uma merda gigantesca: apaga todas as imagens dos clientes, de forma irreversível.

Eu me seguro para não rir, porque se risse era demissão na certa. Ele olha para mim, eu olho para ele, e nós dois sabemos exatamente o que aconteceu. E claro, não tinha backup. Afinal, pra que backup, né? Justamente o que eu ia fazer antes de mexer nas imagens.

Deu merda. Corre pra cá, corre pra lá tentando recuperar os arquivos. Baixa programa gratuito, nada. Resolve pagar um programa, nada também. No fim, aceita que não tem volta. Agora é esperar os clientes reclamarem e pedir as imagens novamente, dando algum migue, dizendo que precisam atualizar os dados.

Tive vários e vários exemplos de pessoas tentando me ajudar e fazendo merda. É impressionante. Hoje sou totalmente blindado quanto a isso. Só passo algo para alguém já esperando que vai dar merda. Faço backup antes, reviso tudo depois, e não confio em ninguém, ainda mais quando o meu está na reta. Simplesmente não dá pra confiar.

Teve uma vez em que pedi ajuda a uma pessoa que, em teoria, “sabia” o que estava fazendo. Em resumo, pedi para fazer uma alteração no banco de dados, já que era a primeira vez que eu estava lidando com aquele banco. A pessoa conseguiu fazer uma merda tão grande que, se eu não tivesse feito backup antes, teria dado um problema enorme, porque era o banco local de um cliente que deu acesso.

E, ironicamente, no futuro esse mesmo funcionário, por não fazer backup, perdeu os dados de um cliente, gerando um baita problemão entre a empresa e o cliente.

diretamente no servidor da empresa
porque era o banco local de um cliente que deu acesso

Se conectar direto em produção para fazer QUALQUER alteração é sempre um risco que você está assumindo.

Aqui vai uma boa prática para executar em scripts em produção:

Trabalhava em uma empresa que tinha um DBA dedicado, SOMENTE ELE tinha permissão de usar escrita do DB de produção (outras pessoas tinham como fallback caso ele não tivesse, mas tinham muito mais cuidado porque era papo de justa causa)

Todos os outros tinham acesso somente leitura.

Cada script que fosse executado em produção deveria ter a seguinte estrutura:

DO $$
DECLARE
    registros_alterados INTEGER;
BEGIN
    -- Executa o UPDATE
    UPDATE table_name 
    SET col = 'teste' 
    WHERE col IS NULL;
    
    -- Captura o número de registros alterados
    GET DIAGNOSTICS registros_alterados = ROW_COUNT;
    
    -- Verifica se foram alterados exatamente 5 registros
    IF registros_alterados != 5 THEN
        RAISE NOTICE 'Número de registros diferente de 5. Fazendo ROLLBACK.';
        ROLLBACK;
    ELSE
        RAISE NOTICE 'Exatamente 5 registros alterados. Fazendo COMMIT.';
        COMMIT;
    END IF;
    
EXCEPTION
    WHEN OTHERS THEN
        RAISE NOTICE 'Erro: %. Fazendo ROLLBACK.', SQLERRM;
        ROLLBACK;
END $$;

Isso obriga você a saber exatamente qual o impacto do script, pra saber o numero de registros alterados precisa pelo menos fazer um select para validar os dados.

Se tivesse algum script que não podesse ser validado dessa forma ou alguma alteração massiva o processo era bem diferente:

Copiar o DB de produção para base de teste
Executar o script na base de teste
Fazer uma auditoria profunda sobre quais foram os impactos
Executar o script em produção

Esse processo poderia demorar até uma semana, o DB era massivo, e o custo para fazer dessa forma era gigantesco, mas era seguro

Hoje como não tenho uma estrutura tão grande e robusta adoto uma prática parecida:

Todos os script só podem ser executados depois de passar por revisão por outra pessoa, ter testes em uma cópia parcial do banco, validar em um segundo ambiente. Eu sou o único que tenho permissão de escrita direto no banco, então posso garantir esse processo.

Mecher direto em produção é sempre um risco gigantesco, prefira uma estratégia de copy-on-edit precisa alterar uma configuração no servidor? clone ele completamente, altere, teste, mude os apontamentos para esse novo servidor, mantenha um tempo para garantir estabilidade e só depois remova o antigo (isso funciona muito em ambientes cloud, on-premisse é mais difícil ter hardware sobrando)