O método que quase ninguém executa direito
A maioria das pessoas ouve a expressão entra na água e não se molha e pensa em golpear o problema de um jeito diferente. Não é isso. É sobre mapear exatamente onde está o risco e criar uma passagem lateral sem precisar pular de cabeça. No meu trabalho com automação e infraestrutura, eu vi muita gente tentar automatizar deploy e acabar derrubando o ambiente de produção porque ignorou um detalhe de rollback. Eu também fiz isso. A primeira vez custou 4 horas de outage e uma ligacao ruim pra diretoria.
entra na água e não se molha: a técnica prática
Funciona assim. Você identifica três coisas antes de qualquer execução: o que pode quebrar, quanto tempo leva pra recuperar, e qual é o custo de simplesmente não fazer aquilo. A parte que as pessoas pulam é o step três. Nao adianta ter um rollback bonito se o problema é irreversivel sem restaurar backup de 3 dias atras. Nesse caso a resposta correta é cancelar a execucao antes mesmo de começar.
Eu usei esse criterio num migration de banco onde o vendor garantia downtime zero. Eu calculei o tempo de restore, comprei um ambiente paralelo, rodei a migracao contra ele e só quando os dados estavam sincronizados eu troquei o ponto de conexao. Downtime real: 47 segundos. O vendor tinha prometido zero e entregueou algo perto de 20 minutos se tudo desse errado.
Como montar seu plano sem romantismo
Escreva o passo a passo real, nao o passo a passo ideal. A diferenca é que no plano ideal voce nao considera latencia de rede, timeout de conexão, ou o fato de que o terceiro sistema tem um limite de 100 requisicoes por segundo que voce nao controla. Se voce esta falando de automacao de infraestrutura, comece com um playbook que rode em ambiente isolado. Nada de executar contra production antes que o teste tenha passado em staging pelo menos tres vezes em dias diferentes, em horarios diferentes. Eu perdi conta de quantas vezees scripts funcionavam so as 2 da manha e falhavam as 14h porque havia um job batch rolando ao mesmo tempo.
Use feature flags quando possible. Se algo quebrar, voce desliga a funcionaliade em segundos sem precisar de deploy reverso. Isso e mais rapido do que tentar desfazer mudancas estruturais no meio de uma operacao.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O que eu vi dar errado na pratica
O erro mais comum é confundir velocidade com ausencia de risco. Voce pode ser rápido e ainda assim destruir algo. A diferença é que quando voce planeja a saída, o dano fica contido. No meu caso recente com api de pagamentos, eu configurei um canal de fallback automatico para um provedor alternativo. Quando o provedor principal caiu num viernes à tarde, o sistema já desviava as transações em menos de 8 segundos. Ninguém percebeu. Mas isso só funcionou porque eu tinha testado o fallback especificamente na quinta-feira anterior, sabendo que sexta à tarde sempre tem pico de transações.
O erro que eu cometi foi assumir que o provedor alternativo teria a mesma taxa de sucesso. Ele não tinha. Era 94 por cento contra 99,7 por cento do principal. No fim das contas, o sistema funcionou, mas eu tive que justificar pro controller porque o custo por transação subiu 0,03 reais. Um valor pequeno, mas que existe.
Quando a tecnica nao serve
Se o seu sistema nao permite ambiente paralelo, se voce nao tem visibility do que esta acontecendo em tempo real, ou se o time de suporte do provedor responde em media 6 horas depois, entra na água e não se molha vira entra na água e torce pra nao se molhar. Nesses casos a alternativa mais honesta é reduzir o escopo. Em vez de migrar tudo de uma vez, migre 10 por cento dos usuarios. Se der ruim, voce reverte 10 por cento. Nao e tão elegante quanto um switch, mas funciona.
Tambem nao adianta aplicar isso em coisas que dependem exclusivamente de fatores humanos. Treinamento de equipe, mudanças culturais, processos que exigem Aprovacao de tres niveis. Voce pode eliminar o risco tecnico, mas o risco humano continua la.
Um exemplo concreto de execucao
Recentemente precisei atualizar certificados TLS em um cluster com 40 microsservicos. A tentacao era rodar um script e torcer. Eu fiz o contrario. Criei um job que rotacionava os certificados apenas nos nodes de teste durante a madrugada, por uma semana. Monitorou erros, latencia, conectividade. Na sexta, rodei o mesmo job em todos os nodes de production, mas mantendo o antigo certificado ativo por mais 48 horas como fallback. Se algo aparecesse, eu revertia removendo a referencia ao novo certificado e o sistema voltava a usar o antigo automaticamente.
O processo levou 3 dias de preparacao e 12 minutos de execucao efetiva. Zero incidentes. Sem estrés desnecessario. A lição que ficou foi simples: o tempo que voce gasta planejando a escape route é sempre menor do que o tempo que voce gastaria resolvendo o problema sem planejamento. E essa matematica vale tanto pra infrastrutura quanto pra decisoes de negocio que envolvem risco controlado.
