My Geocode

Migração

Planejando um rollback antes de migrar qualquer coisa

· 3 min de leitura · My Geocode · #plano-de-rollback#planejamento-de-migração#geocodificação#gestão-de-riscos#implantação

Um plano de rollback é a parte de uma migração que, bem feita, ninguém nunca precisa usar, e é exatamente por isso que costuma ser deixada de lado quando o tempo está apertado. Pular essa etapa é um erro justamente porque o custo de precisar de um rollback e não ter um é muito maior do que o custo de preparar um que acaba não sendo usado.

A premissa inicial de um bom plano de rollback é que o novo provedor vai se comportar de forma diferente do antigo em pelo menos um aspecto que você não previu, por mais minuciosos que tenham sido os seus testes. Isso não é pessimismo, é apenas uma descrição honesta de como as integrações com sistemas externos costumam acontecer. Planejar com base nessa premissa, e não na esperança de que os testes pegaram tudo, produz um plano melhor.

Um plano de rollback para a troca de provedor de dados de localização deve incluir:

  • Um mecanismo de troca rápida. Seja uma feature flag, uma variável de ambiente ou um valor de configuração lido no momento da requisição em vez de embutido em um build implantado, as credenciais e o endpoint do provedor antigo devem continuar válidos e prontos para uso novamente sem uma nova implantação de código, durante uma janela definida após a transição
  • Uma condição de acionamento clara. Decida com antecedência o que exatamente justificaria o rollback: uma taxa de erros acima de determinado limite, uma categoria específica de requisição falhando ou um certo volume de reclamações de usuários, em vez de deixar a decisão para ser tomada sob pressão sem um critério acordado
  • Um responsável pelo rollback. Uma pessoa ou um pequeno grupo explicitamente responsável por decidir o rollback, para que a decisão não fique travada enquanto várias pessoas esperam que outra tome a iniciativa
  • Um prazo definido para a janela de rollback. Manter as credenciais dos dois provedores ativas indefinidamente anula o propósito da migração; defina uma data específica a partir da qual o acesso ao provedor antigo será encerrado de vez

Como os hosts de compatibilidade do My Geocode reproduzem exatamente o formato de requisição e resposta de um provedor, um rollback em uma migração baseada em compatibilidade muitas vezes é apenas uma mudança de configuração de volta para o host e a chave antigos, sem precisar reimplantar outro código de análise, o que reduz o tempo que um rollback realmente leva para ser executado se for necessário. Dito isso, isso vale para os dois lados: também significa que vale a pena testar deliberadamente, uma vez durante a fase de planejamento, se o rollback funciona, em vez de simplesmente presumir que funciona, já que um caminho de rollback não testado não é muito diferente de não ter plano de rollback algum.

Também vale a pena decidir o que acontece com os dados ou as requisições processados durante o período do qual você está revertendo. Se uma tarefa em lote rodou durante a noite no novo provedor antes de um problema ser detectado na manhã seguinte, esse lote precisa ser reprocessado ou a discrepância é aceitável? Decidir isso com antecedência, e não durante um incidente real, tira mais uma decisão de um momento já estressante.

Um plano de migração que só descreve o avanço é, em um sentido real, um plano incompleto. A metade do rollback é o que transforma uma migração de uma aposta sem volta em uma decisão ponderada que pode ser revertida de forma limpa se as evidências pedirem.

Mais em Migração