«Se correr mal, desfazemos»
É a frase que tranquiliza antes de uma mudança importante, e a que menos se cumpre. Desfazer uma mudança de código de aplicação costuma ser fácil. Desfazer uma mudança de infraestrutura não o é sempre: uma base de dados migrada, uma rede reconfigurada ou um certificado substituído não voltam atrás com um clique.
Por isso, em infraestrutura, a reversão desenha-se antes da mudança, não se improvisa depois.
Manter o anterior vivo
A técnica mais segura é não modificar o que funciona, mas levantar ao lado a versão nova:
- A versão atual continua a dar serviço.
- Cria-se a versão nova, completa, em paralelo.
- Testa-se sem tráfego real ou com uma pequena parte.
- Muda-se o tráfego para a nova.
- Se algo falhar, o tráfego volta à anterior em segundos, porque continua lá.
- Só quando a nova está confirmada se retira a anterior.
Custa mais durante algumas horas (há duas versões ao mesmo tempo) e poupa muitíssimo quando algo corre mal.
Quando não se podem ter duas versões
Há mudanças que não admitem paralelo, sobretudo em dados. Para essas:
- Cópia verificada imediatamente antes, restaurável e testada (não um pressuposto).
- Mudanças em dois tempos: primeiro acrescenta-se o novo sem retirar o velho (uma coluna, um campo) e só depois, quando tudo usa o novo, se retira o antigo.
- Janela e plano escritos: o que se faz, quanto tempo leva, em que ponto já não há reversão e quem decide prosseguir.
A regra
Nenhuma mudança importante se aprova sem uma resposta escrita a «como voltamos atrás, e quanto tempo leva?». Se a resposta for «não se pode», a mudança precisa de outra forma.
Voltar atrás protege dos erros que já ocorreram. Melhor ainda é impedir que certos erros cheguem a ser aplicados.
Como o aplicamos: Automação e IaC.