Um plano de rollback precisa sobreviver à primeira gravação

Um plano de rollback só é confiável se o sistema antigo conseguir receber as gravações do novo sem perder, duplicar ou alterar a ordem delas. Voltar o balanceador de carga é a parte fácil. A parte difícil começa com o primeiro pedido, pagamento, processo, lançamento contábil ou mudança de status confirmado depois da virada.

Isso faz do rollback um problema de dados e autoridade, não um recurso de implantação. Antes da virada, a equipe precisa saber qual sistema controla as gravações em cada instante, como as gravações posteriores voltarão ao modelo antigo, quais efeitos externos não podem ser desfeitos e quem pode ordenar o retorno. Se essas respostas estão apenas na cabeça de alguém ou dependem de um código que nunca rodou, não existe plano de rollback. Existe apenas a esperança de que o sistema novo falhe antes que algo importante aconteça.

A virada transfere a autoridade de gravação

Uma virada segura dá a autoridade de gravação a exatamente um sistema por vez. Os dois sistemas podem atender leituras, comparar resultados, consumir eventos copiados ou fazer cálculos em modo sombra. Eles não podem aceitar de forma independente mudanças oficiais no mesmo registro de negócio. Dois escritores criam conflitos que uma troca de rota não resolve.

A autoridade de gravação abrange mais do que a conexão principal com o banco de dados. Um ambiente legado costuma receber mudanças por arquivos em lote, filas de mensagens, telas de operador, tarefas agendadas, transferências de parceiros, procedimentos armazenados e atualizações diretas do suporte. Já vi equipes congelarem a aplicação web enquanto uma rotina noturna lançava ajustes discretamente com outra conta. A migração parecia estável até os dois livros contábeis divergirem na manhã seguinte.

Monte o inventário de gravações em torno das operações de negócio, não das tabelas. Para cada operação, registre ponto de entrada, identidade, limite da transação, identificador gerado, fonte do horário, efeitos posteriores e sistema responsável antes e depois da virada. “Atualizar cliente” é amplo demais. “Mudar endereço postal, emitir aviso de conformidade e colocar a impressão na fila” é específico o bastante para mostrar o que o rollback precisa preservar.

O controle de roteamento também precisa de um único responsável. O DNS sozinho é um controle ruim para emergências, pois resolvedores e clientes mantêm cache além do momento em que os operadores acreditam que a mudança terminou. Prefira um controle no gateway, proxy, consumidor de fila, intermediário de conexões ou outro ponto em que a equipe possa observar a rota ativa. Registre o valor atual do controle e o comando que o altera. Uma captura de tela do console não dá ao comandante do incidente uma ação repetível.

Defina os estados de autoridade em termos simples: OLD_WRITES, DRAINING, NEW_WRITES e ROLLING_BACK bastam para muitos sistemas. Cada estado deve permitir um conjunto conhecido de escritores. A transição precisa rejeitar um escritor inesperado, não apenas registrá-lo, pois um alerta descoberto depois do rollback não consegue apagar uma transação.

As condições prévias exigem aprovação ou reprovação

A virada só deve começar quando cada condição prévia do rollback tiver um teste nomeado, um resultado atual e um responsável capaz de interromper a mudança. Um documento que diga “replicação saudável” abre espaço para discussão durante o incidente. Um teste que diga que a posição reproduzida é igual ou posterior à posição capturada, com a consulta e a saída exatas anexadas, dá um fato à equipe.

Use um contrato curto de prontidão. Ele é uma barreira, não uma intenção:

• A versão antiga consegue ler todas as mudanças de esquema introduzidas para a virada.
• O sistema antigo está implantado, acessível, corrigido e capaz de se autenticar com suas dependências.
• O caminho de captura ou replicação processou uma carga semelhante à de produção sem ultrapassar o limite de atraso combinado.
• Todos os escritores do inventário obedecem ao controle de autoridade, inclusive rotinas em lote e caminhos de operador.
• A equipe restaurou um backup recente em um ambiente isolado e comprovou que ele inicia.

O último item revela uma troca comum: backup bem-sucedido não é restauração bem-sucedida. Uma tarefa de backup verde prova que bytes foram copiados para algum lugar. Não prova que a chave de criptografia está disponível, o arquivo está completo, o mecanismo consegue lê-lo ou a aplicação inicia com ele. Guarde comando de restauração, duração, soma de verificação e resultado do teste da aplicação junto ao registro da virada.

Capture um ponto de controle dos dados imediatamente antes da transferência de autoridade. No PostgreSQL, uma equipe que use replicação física por streaming pode comparar a posição WAL atual do primário com a posição reproduzida pelo secundário. O manual do PostgreSQL define LSN como uma posição no log de gravação e diz que pg_last_wal_replay_lsn() retorna a última posição reproduzida durante a recuperação. Uma captura mínima de evidência tem este formato:

/* On the primary */
SELECT pg_current_wal_lsn();
 pg_current_wal_lsn

 7A3/91F2C6D0
(1 row)

/* On the standby */
SELECT pg_last_wal_replay_lsn();
 pg_last_wal_replay_lsn

 7A3/91F2C6D0
(1 row)

Trate o valor como exemplo do formato da saída, não como um limite mágico. A igualdade em um instante não prova que toda gravação de negócio possa ser revertida, e uma diferença em bytes não se converte diretamente em tempo. A verificação prova um fato restrito: o secundário reproduziu até a posição capturada do log. A evidência também precisa de contagens da aplicação, invariantes e amostras de registros que façam sentido no domínio.

Mantenha o sistema antigo aquecido até os dados poderem voltar

O sistema antigo deve continuar aquecido até a equipe provar que ele consegue incorporar toda mudança posterior à virada ou abandonar formalmente o rollback e passar à correção adiante. Um número fixo de dias parece objetivo, mas ignora volume de transações, tarefas atrasadas, ciclos de liquidação e mudanças de esquema. Defina o período por condições observáveis de saída e acrescente um limite de calendário para controlar equipe e custo.

“Aquecido” significa executável sob a pressão de um incidente. A aplicação antiga tem capacidade computacional, configuração atual, segredos válidos, acesso à rede, contratos ativos com dependências, espaço de armazenamento, monitoramento e operadores que ainda sabem usá-la. Uma máquina virtual desligada com certificado vencido é um arquivo. Não é um destino de rollback.

Mantenha o sistema aquecido durante pelo menos um ciclo completo do negócio capaz de revelar comportamento atrasado. Esse ciclo pode incluir um processamento noturno, uma data de faturamento, um arquivo de parceiro, uma programação de fim de semana ou um fechamento de período. Não copie uma regra genérica de sete ou trinta dias. Um sistema de sinistros que recebe documentos atrasados e um serviço de ponto de venda que liquida todas as noites precisam de janelas de prova diferentes.

As condições de saída devem cobrir comportamento e capacidade de recuperação. Exija que o sistema novo conclua tarefas atrasadas, concilie confirmações externas, mantenha limites de erro e latência sob tráfego real e produza um fluxo de mudanças que o sistema antigo consiga consumir. Exija também um ensaio de rollback bem-sucedido com dados capturados depois de uma virada simulada. Se a equipe remover o caminho inverso, aplicar uma mudança destrutiva no esquema ou deixar expirar o contrato de uma dependência antiga, registre o instante exato em que o rollback deixa de existir.

Manter o sistema antigo aquecido tem custo e risco. Serviços sem correções, agendadores duplicados e credenciais ativas ampliam a superfície de falha. Reduza essa superfície de propósito: bloqueie o tráfego de usuários, desative todos os agendadores exceto o necessário para o rollback testado, restrinja o acesso dos operadores e monitore cada tentativa de conexão. Aquecido não significa deixado em execução sem controle.

As gravações posteriores definem a estratégia

Cada gravação posterior à virada precisa de um entre quatro tratamentos: reproduzi-la no sistema antigo, preservá-la para reprodução posterior, compensar seu efeito ou aceitar que ela torna o rollback impossível. Chamar os quatro de “sincronização de dados” esconde as decisões importantes. O tratamento certo acompanha a semântica do negócio, sobretudo a ordem e os efeitos externos.

A replicação inversa funciona quando o modelo de destino consegue representar a nova mudança e a ferramenta preserva os limites necessários da transação. Ela fica perigosa quando o sistema moderno divide uma linha legada em vários registros, substitui um status mutável por eventos, muda a geração de identificadores ou torna a validação mais rígida. Um copiador de linhas pode entregar dados sintaticamente válidos que a aplicação antiga interpreta de forma errada.

Um diário de mudanças que só permite acréscimos costuma ser mais fácil de entender. Dê a cada comando aceito um ID de operação imutável, chave de negócio, sequência da origem, versão do esquema, ator, horário de aceitação, dados e resultado. O importador de rollback registra o ID aplicado, para que tentativas repetidas não repitam a ação de negócio. A idempotência pertence ao limite de negócio: “definir o endereço como X” pode ser repetido, enquanto “somar 10 ao saldo” exige identidade única da operação e rejeição de duplicatas.

A gravação dupla no código da aplicação é popular porque parece imediata. Eu a desaconselho na maioria das viradas. A solicitação pode ser confirmada no banco novo e atingir o tempo limite antes da confirmação no antigo, deixando o chamador sem certeza e os sistemas separados. Inverter a ordem só muda qual sistema vence a falha. Uma caixa de saída transacional ou um fluxo de mudanças do banco liga a captura à confirmação oficial e permite que um consumidor separado repita a entrega.

Algumas gravações não devem voltar automaticamente. Se o sistema novo aceita um estado que o esquema antigo não consegue representar, coloque a operação em quarentena e mostre a contagem antes da virada. O mesmo vale quando as regras de validação são diferentes. Não force o valor, elimine um campo nem esconda um significado novo em um campo antigo de texto livre apenas para levar um contador de conciliação a zero.

O runbook precisa mover dados e tráfego

Um runbook executável de rollback congela novas gravações, estabelece um limite final, descarrega as mudanças capturadas no modelo antigo, verifica o estado de negócio e só então devolve o tráfego. Devolver o tráfego primeiro permite que usuários criem mais mudanças enquanto o importador ainda elimina o atraso. O limite passa a se mover durante o incidente.

Uma sequência prática tem interrupções e evidências explícitas:

1. Declare ROLLING_BACK, rejeite novas solicitações de alteração, pause os consumidores e registre o horário e o último ID de operação aceito. As leituras só podem continuar se não causarem gravações escondidas.
2. Espere as transações em andamento terminarem ou interrompa-as conforme uma regra documentada. Capture a posição do log de origem, os offsets das filas e a quantidade de entradas do diário ainda não processadas.
3. Aplique o fluxo inverso até o limite registrado. Pare se uma operação não tiver mapeamento, violar um invariante antigo ou produzir uma referência externa diferente.
4. Execute consultas de conciliação e leituras de negócio por amostragem no sistema antigo. Passe uma transação sintética por cada ponto de entrada essencial, mas mantenha notificações externas em um receptor controlado.
5. Restaure a autoridade antiga de gravação, libere o tráfego gradualmente, retome apenas os agendadores antigos e acompanhe contadores de duplicatas, rejeições e atrasos.

Escreva as saídas esperadas ao lado de cada comando. 0 rows pode significar sucesso em uma consulta de órfãos e desastre em uma contagem de pedidos. Diga qual significado se aplica. Mantenha os procedimentos de credenciais e aprovação perto dos comandos sem colocar segredos no runbook. Se a pessoa que executa precisar procurar um caminho no cofre de senhas, identifique a entrada e teste o acesso durante o ensaio.

Cronometre cada etapa separadamente. O tempo total de recuperação não basta. A equipe precisa saber por quanto tempo as gravações ficam congeladas, com que velocidade o consumidor inverso esvazia o volume de pico e qual validação domina a pausa. Se um acúmulo de 500.000 operações demorar mais para ser reproduzido do que a empresa tolera, o plano falha mesmo que um ensaio pequeno funcione. Teste no nível máximo esperado e com margem.

A compatibilidade preserva o caminho de volta

O rollback depende de compatibilidade retroativa em bancos, mensagens, APIs, arquivos e autenticação. O binário antigo precisa funcionar com o estado da virada. Se uma migração remover uma coluna, reutilizar um valor de enumeração, mudar o significado de uma mensagem ou trocar uma credencial além do que o cliente antigo suporta, o caminho de volta pode desaparecer antes que alguém perceba.

A descrição de Parallel Change de Danilo Sato divide uma mudança incompatível nas fases de expansão, migração e contração. O modelo ajuda porque o rollback pertence à fase expandida, enquanto consumidores antigos e novos ainda funcionam. As equipes entram em dificuldade quando tratam a contração como limpeza e removem o campo ou endpoint antigo assim que o novo tráfego parece saudável. A contração encerra deliberadamente o rollback e merece seu próprio registro de mudança.

Mudanças aditivas de esquema são necessárias, mas não suficientes. Até uma coluna que aceite nulo pode quebrar código antigo se um gatilho mudar, uma consulta usar inserções posicionais ou um procedimento armazenado devolver um novo formato de resultado. Teste a versão antiga real com um clone do esquema da virada. Exercite leituras e gravações, incluindo valores raros, lotes vazios, tamanhos máximos de campo e caminhos de erro.

As mensagens também precisam de uma regra de compatibilidade. Os consumidores devem ignorar campos desconhecidos, mas precisam rejeitar um significado alterado escondido sob um nome antigo. Mantenha tipos antigos de evento durante o período aquecido ou forneça um conversor descendente testado. Versione o conversor e armazene os dados originais para que um operador possa reproduzir um mapeamento contestado.

Falhas de autenticação são particularmente constrangedoras porque podem ser evitadas. Preserve as identidades antigas de serviço, cadeias de certificados, compatibilidade de cifras e rotas de rede enquanto o rollback continuar sendo uma opção. Teste a partir do ambiente de execução antigo, não da estação de um administrador.

Efeitos externos precisam de compensação

Um rollback não consegue recolher um e-mail já entregue, um arquivo bancário aceito, uma etiqueta impressa nem uma instrução de parceiro que já foi executada. Esses são efeitos externos, e o plano precisa de uma política para cada um antes da virada. A paridade no banco de dados não resolve esses efeitos.

Atribua uma chave de idempotência a toda ação de saída e guarde com ela a confirmação do destinatário. Durante o rollback, o sistema antigo precisa saber quais ações já aconteceram para não enviá-las de novo. Se o receptor aceita solicitações idempotentes, reutilize a mesma chave. Caso contrário, coloque a ação atrás de um registro interno que rejeite um segundo envio.

A compensação é uma nova ação de negócio, não uma exclusão. Um pagamento lançado pode exigir um lançamento de estorno. Uma instrução de armazém já enviada pode exigir um cancelamento que também pode falhar. Uma notificação ao cliente pode precisar de uma correção escrita por uma pessoa. Registre quem autoriza cada compensação, o prazo e o que acontece quando a parte externa não consegue desfazer o efeito.

O trabalho agendado cria um risco de duplicação mais discreto. Quando os dois ambientes ficam aquecidos, dois agendadores podem selecionar as mesmas linhas vencidas e emitir a mesma ação. O controle de autoridade precisa abranger as tarefas com a mesma firmeza que as solicitações HTTP. Durante a operação normal, o agendador inativo não deve conseguir adquirir seu lease nem a credencial de produção. Durante o rollback, os operadores transferem o lease somente depois que o novo worker para e seu último item concluído é conhecido.

Concilie os efeitos pelo identificador de negócio e pela confirmação, não pela profundidade da fila local. Uma fila vazia pode significar que todos os itens tiveram sucesso, que todos falharam em um armazenamento de mensagens descartadas sem monitoramento ou que um filtro não selecionou nada. Um relatório útil reúne ações pretendidas, tentativas, respostas do destinatário e compensações em uma linha por evento de negócio.

Um ensaio precisa forçar a falha incômoda

Um ensaio só prova o rollback quando usa gravações posteriores à virada, quebra algo de propósito e devolve o serviço pelos mesmos controles que a equipe de produção usará. Uma reunião em que as pessoas leem o runbook em voz alta testa o texto. Uma virada em homologação sem dados representativos testa o roteamento. Nenhuma das duas demonstra recuperação.

Use um clone semelhante à produção ou um ambiente isolado de reprodução com registros limpos e tráfego gravado. Inicie as versões antiga e nova, ative o controle real de autoridade e carregue histórico suficiente para migrações e índices se comportarem de forma crível. A CodeHero usa um mecanismo de paridade com tráfego de produção gravado ao reescrever sistemas legados. O mesmo conjunto de tráfego pode revelar diferenças de comportamento antes de um ensaio de rollback.

Depois force uma falha quando o sistema novo já tiver aceitado um conjunto misto de operações. Inclua uma atualização que chegue duas vezes, dois comandos na mesma conta em ordem, um limite de lote, um valor rejeitado, uma operação com efeito externo capturado em um receptor e uma tarefa em execução durante o congelamento. Interrompa o consumidor inverso no meio e reinicie-o. Os IDs de operação devem impedir duplicatas, e o limite deve permanecer estável.

Uma falha conhecida merece atenção especial. O importador inverso informa que não há acúmulo, o tráfego volta ao sistema antigo e as contagens básicas coincidem. Horas depois, um parceiro rejeita o arquivo do dia porque o sistema moderno gerou identificadores em um formato que a exportação antiga corta. O rollback moveu as linhas corretamente, mas perdeu comportamento no limite do arquivo. Um ensaio adequado executa a exportação, analisa o arquivo segundo o contrato do receptor e compara os identificadores de ponta a ponta.

Reúna evidências que alguém além do autor da migração consiga avaliar: IDs de operação aceitos, posições de origem e aplicação, resultados das consultas de invariantes, contagens de duplicatas, mapeamentos em quarentena, entradas do registro de efeitos externos, duração das etapas e estado final de autoridade. Guarde também o ensaio que falhou. Um plano que só passa depois que um engenheiro edita dados manualmente precisa registrar esse reparo como passo controlado ou eliminá-lo por uma mudança no código.

A observação deve mostrar a correção do negócio

Os sinais de rollback precisam informar a correção do negócio, não apenas se os processos estão em execução. Um serviço novo pode responder rápido enquanto atribui números duplicados de fatura, ignora uma regra de lançamento ou deixa uma exportação presa na fila para sempre. Gráficos de infraestrutura ajudam a localizar uma falha, mas raramente dizem ao responsável pela decisão se continuar gravando é seguro.

Defina invariantes a partir do comportamento legado antes da virada. Um invariante pode dizer que todo pagamento aceito tem um lançamento, toda remessa referencia um pedido aceito, todo processo encerrado tem um motivo de encerramento ou todo arquivo de saída tem o total de controle correspondente. Expresse cada um como consulta ou relatório que os dois sistemas consigam produzir. Quando os esquemas forem diferentes, compare uma projeção canônica do negócio em vez de forçar igualdade de tabelas.

A projeção deve normalizar diferenças que não mudam o comportamento e preservar as que mudam. Converter horários para um único fuso antes da comparação faz sentido. Ignorar centavos porque um sistema armazena valores decimais e o outro unidades menores inteiras não faz. Decida as regras com quem responde pelo registro de negócio e versione-as junto com o código da migração. Caso contrário, um engenheiro pode transformar uma comparação vermelha em verde ampliando um filtro durante o incidente.

As contagens precisam de denominadores e limites. “Doze divergências” diz pouco sem o número examinado, os tipos de operação e o intervalo de aceitação. Uma contagem zero também pode mentir se a comparação parou na partição de ontem. Todo resultado deve informar limite de origem, limite de destino, número selecionado, número comparado, divergências, operação sem correspondência mais antiga e horário de conclusão.

Use sinais de atualização que acompanhem o caminho real de reprodução. A profundidade da fila não mostra uma partição presa quando as demais continuam esvaziando. A atividade do consumidor não mostra uma mensagem defeituosa que tenta para sempre. Informe a operação não aplicada mais antiga e sua idade, a última sequência de origem vista, a última sequência de destino confirmada, a contagem de quarentena, as tentativas por operação e a taxa de esvaziamento. Um acúmulo estável sob tráfego constante pode ser aceitável no uso normal, mas fatal para um rollback que precisa chegar a zero durante o congelamento.

A amostragem continua necessária porque invariantes não conseguem codificar toda regra estranha do legado. Selecione registros por critérios determinísticos para que o ensaio e a virada de produção inspecionem casos comparáveis: maiores transações, registros com tamanho máximo de campo, processos reabertos, pagamentos estornados, moedas fora do padrão e operações que cruzam uma data. Inclua o resultado de negócio e o artefato de saída, não apenas a linha armazenada. Uma fatura que fecha no banco mas aparece sem identificador fiscal tem uma divergência de comportamento.

Os alertas devem corresponder diretamente às decisões declaradas. Uma violação de invariante pode congelar as gravações imediatamente. Uma idade crescente de reprodução pode iniciar um cronômetro. Um pico passageiro de latência pode pedir observação sem rollback. Escreva essa relação antes da virada e anexe-a ao alerta. Durante um incidente, um alerta chamado “migração não saudável” apenas inicia uma discussão sobre o significado de não saudável.

Preserve a telemetria depois do fim do período aquecido. Ela explica por que a equipe retirou o caminho de volta e dá uma referência confiável para a correção adiante. O registro final deve mostrar que o trabalho atrasado terminou, os limites de comparação avançaram além do ciclo de negócio combinado, as quarentenas foram resolvidas e nenhum efeito externo sem explicação permaneceu. Essa evidência é melhor do que uma ata que diz que a migração parecia boa.

Torne a tarefa de comparação independente da rota que ela avalia. Se a conexão com o banco, o cache ou o código de serialização da aplicação nova também alimenta o verificador, um defeito pode corromper o resultado e sua suposta verificação ao mesmo tempo. Execute conciliações críticas por um leitor implantado separadamente com permissões restritas e guarde o texto da consulta e a soma do resultado no registro. Independência não exige uma segunda plataforma, mas exige um caminho de falha que não consiga concordar silenciosamente consigo mesmo.

Teste também a ausência de telemetria como uma falha. Pare o consumidor do diário, retenha uma partição de origem e faça o receptor de efeitos externos rejeitar uma confirmação. O painel deve mostrar um limite envelhecendo e uma comparação incompleta, enquanto o controle de autoridade impede a declaração de sucesso. Se um painel vazio parecer igual a zero divergências, corrija-o antes da virada.

A decisão de rollback precisa de um relógio

A decisão de rollback deve seguir gatilhos declarados, um responsável e um orçamento de tempo definidos antes da virada. Sem eles, os engenheiros gastam a janela reversível investigando enquanto novas gravações se acumulam e efeitos externos se espalham. Quando a liderança pede a volta, a reprodução pode demorar mais do que uma correção adiante.

Escolha gatilhos que descrevam dano ao usuário ou à contabilidade: rejeição de operações críticas, violação de invariantes, divergência de conciliação sem explicação, fila sem limite, confirmações externas ausentes ou incapacidade de fechar um lote obrigatório. CPU e latência podem apoiar a decisão, mas sintomas de infraestrutura raramente dizem sozinhos se os dados continuam seguros. Declare o período de observação e a origem de cada sinal.

Dê a uma pessoa autoridade para ordenar o rollback e indique um substituto. Responsáveis por banco, aplicação, operações, negócio e incidente podem aconselhar, mas consenso é lento demais quando as gravações continuam chegando. Indique também quem pode declarar que o rollback não está mais disponível porque um limite destrutivo foi cruzado. Essa declaração deve trocar o plano por correção adiante e compensação, não deixar a equipe discutindo uma opção vencida.

O relógio precisa de dois limites. O prazo da decisão diz por quanto tempo a equipe pode investigar antes de congelar gravações ou assumir a correção adiante. O orçamento de execução diz quanto tempo o negócio tolera a pausa de gravação e a reprodução. Derive os dois da chegada de transações, da taxa de esvaziamento, dos prazos externos e da equipe, e teste essas premissas no ensaio.

Uma equipe pronta para a virada consegue entregar o runbook a um operador que não o escreveu, injetar uma falha depois de gravações reais e recuperar o sistema antigo dentro desse orçamento. Se o exercício exigir uma consulta não registrada, um engenheiro específico ou uma edição manual de dados, adie a virada. A produção não tornará essas dependências mais gentis.