O rollback que ninguém tinha testado em quatro sites de teste expirados
A lista de verificação da migração tinha um item ainda sem marcar: “rollback exercitado uma vez de verdade”. O plano prometia que qualquer endereço de cliente que tivéssemos migrado poderia voltar ao lugar de origem. Ninguém nunca tinha tentado.
O que encontramos quando olhamos
Estávamos migrando os endereços web dos clientes de um servidor antigo para uma configuração nova, em fases. Existia um plano de contingência, mas só no papel. A primeira tarefa foi descobrir o que tinha sido realmente testado. Uma rota de recuperação, a de uma peça intermediária, tinha sido executada. Devolver um endereço ao servidor antigo, não. Isso era só um parágrafo.
O plano de contingência só funciona se o servidor antigo ainda guardar uma credencial para aquele endereço. Sem ela, o visitante vê uma página de erro em vez do site.
Procuramos algo seguro para ensaiar. Acreditávamos que três dos nossos sites de teste estavam no estado certo, e acreditamos nisso por tanto tempo que isso nos custou várias rodadas de trabalho antes de conferirmos. Não estavam. Uma limpeza anterior já tinha removido tudo do servidor antigo nos três, então eles não tinham nenhum caminho de volta. Os sites que de fato serviam eram quatro sites de teste expirados que nós mesmos mantemos, cada um ainda com o conjunto completo. Escolhemos um que estava com a migração pela metade.
O ensaio
O ensaio teve quatro etapas, cada uma verificada antes da seguinte:
- Concluir a migração.
- Provar que o caminho de volta ainda existe, sem alterar nada.
- Voltar o endereço e confirmar que tanto os registros do próprio registrador quanto a internet pública concordavam.
- Deixar tudo exatamente como encontramos.
O servidor antigo continuou servindo o site com segurança o tempo todo, e o site de teste terminou o ensaio exatamente como começou. Quando rodamos a mesma verificação da etapa dois em um site que já tinha passado pela limpeza, ela falhou na hora. Esse contraste resolveu a questão: limpo significa sem caminho de volta, preservado significa volta imediata.
O que mudou no plano
O procedimento escrito agora começa pela verificação somente de leitura. Se ela falhar, o caminho de volta não existe mais e o procedimento manda parar. Também abrimos um ticket para criar um período de espera antes de qualquer limpeza, porque a credencial que torna possível voltar atrás é justamente o que a limpeza apaga.
O rótulo que fez a IA desistir
Mais uma coisa deu errado durante o ensaio. O assistente de IA viu um status “desativado” ao lado do navegador e concluiu que não tinha navegador para usar, então desistiu. O rótulo só queria dizer que um recurso específico estava desligado, e o navegador em si funcionava. Renomeamos o status para dizer o que ele realmente desliga.
A IA executou cada etapa, conferiu o resultado depois de cada uma e escreveu o procedimento a partir do que de fato aconteceu. Ela não decidiu qual site era seguro para o ensaio, e a lembrança confiante dela sobre quais sites de teste serviam estava errada até ser conferida. O rótulo de status mostrou como uma única palavra pode convencer uma IA a abrir mão de uma ferramenta de que ela precisa.
Nós escolhemos o assunto e o momento. O site de um cliente real nunca esteve em jogo, e a gente não entregaria essa escolha a uma ferramenta. Decidir se o plano já estava comprovado o bastante para confiarmos nele também foi nosso.
Antes de confiar em um plano de contingência, use-o uma vez em algo seguro e descubra do que ele precisa para funcionar. Depois, garanta que a limpeza que vem mais tarde não o remova.