Leonardo Peron4 min de leitura
Todo o trabalho de uma migração — meses de levantamento, de-para, testes, treinamento — converge para um intervalo de poucas horas em que o sistema antigo para de receber dado e o novo começa. É o cutover, e ele tem uma característica que o resto do projeto não tem: acontece uma vez, com a operação parada, e sob relógio.
Projetos bem executados chegam nesse intervalo com um roteiro. Projetos que chegam com boa vontade costumam descobrir, às três da manhã de um domingo, que alguém precisa tomar uma decisão que ninguém previu.
O roteiro é uma lista com hora e dono
Não é documento de arquitetura. É uma lista de tarefas em ordem, cada uma com três coisas: quem faz, quanto tempo leva, e como saber que terminou.
A terceira é a que costuma faltar. "Migrar cadastro de clientes" não é uma tarefa executável — não há como dizer se acabou. "Migrar cadastro de clientes e confirmar que a contagem no destino bate com a origem" é.
A soma dos tempos dá a duração da janela. Quase sempre essa soma assusta na primeira vez que é feita, e é exatamente para isso que ela serve: melhor assustar num planejamento que num domingo.
O ensaio não é opcional
Cutover ensaiado é outro evento. A diferença entre a primeira e a terceira execução do mesmo roteiro costuma ser de horas, não de minutos.
O ensaio é o roteiro inteiro executado sobre uma cópia da base de produção, com as mesmas pessoas e cronômetro rodando. Ele revela o que nenhuma reunião revela: o passo que demora seis horas em vez de uma, o script que precisa de um parâmetro que ninguém documentou, a dependência entre duas tarefas que estavam planejadas em paralelo.
Vale ensaiar até que duas execuções seguidas terminem sem surpresa. Se a última ainda trouxe novidade, ainda não é a última.
O ponto de não retorno precisa ter hora marcada
Esta é a decisão que mais frequentemente falta no roteiro, e a que mais custa quando falta.
Em algum momento da janela existe um instante depois do qual voltar atrás fica caro — normalmente quando o sistema novo começa a receber transação real. Antes dele, desistir custa um fim de semana. Depois, custa reconstruir.
Esse instante precisa estar no roteiro com hora, e com um critério objetivo de decisão: se às tantas horas a tarefa X não terminou, não seguimos. Definido antes, é uma checagem de trinta segundos. Definido na hora, é uma discussão entre pessoas cansadas com a operação parada — e a pressão do que já foi investido empurra para seguir mesmo quando não se deveria.
O plano de voltar atrás existe para não ser usado
A recusa em planejar o retorno costuma vir de otimismo: "vamos fazer dar certo". O problema é que o plano de retorno não é sobre pessimismo — é o que permite tomar a decisão de seguir com tranquilidade.
Ele precisa responder três perguntas, por escrito:
- Como o sistema antigo volta a receber? Se ele foi colocado em modo somente leitura, como se reverte. Se as integrações foram redirecionadas, como voltam.
- O que fazer com o que entrou no sistema novo? Transação registrada durante a janela precisa ser reproduzida no antigo ou descartada conscientemente. As duas respostas servem; nenhuma resposta não serve.
- Quem decide? Um nome. Não um comitê.
Congelamento, e o que fazer com o que chega mesmo assim
Durante a janela, a origem precisa parar de mudar — senão a migração persegue um alvo em movimento. Isso é fácil de combinar e difícil de garantir: sempre há uma integração que ninguém lembrou, um robô agendado, uma pessoa com acesso direto.
Duas providências resolvem quase tudo: colocar o sistema antigo em modo somente leitura de fato, e não por combinação; e listar antes todas as integrações que escrevem nele, desligando cada uma explicitamente.
O que chega por fora — pedido por telefone, nota que precisa sair — vai para uma lista em papel ou planilha, e entra no sistema novo depois. Parece rudimentar e é o que funciona.
O dia seguinte faz parte do cutover
A janela termina, o sistema novo está no ar, e o projeto não acabou. O primeiro dia útil é onde aparecem os casos que nenhum teste cobriu, e onde a confiança do time se forma ou se perde.
Três coisas mudam esse dia:
Gente disponível, não de plantão. Quem conhece o sistema presente e sem outra tarefa, incluindo quem fez a migração.
Um canal único para relatar problema. Se cada pessoa chama alguém diferente, ninguém enxerga o padrão — e o mesmo defeito é investigado três vezes.
Uma reunião curta no fim do dia. Quinze minutos para separar o que é defeito do que é estranhamento com a interface nova. A proporção entre os dois costuma surpreender, e para o melhor lado.
O sinal de que deu certo
Não é a ausência de problema no dia seguinte — sempre há problema. É a ausência de surpresa: todo problema que aparece cai numa categoria que já estava prevista, com dono definido e caminho de correção conhecido.
Cutover que gera surpresa não foi ensaiado o bastante. E ensaio custa dias; surpresa custa a operação.