A primeira semana depois que uma migração entra no ar é quando costuma aparecer a diferença entre o que os testes cobriram e como o tráfego real de produção de fato se comporta. Os testes, por mais completos que sejam, abrangem um conjunto finito de cenários; uma semana inteira de tráfego real expõe a cauda longa do uso real que um plano de testes quase nunca prevê por completo.
Alguns pontos específicos que vale observar de perto nessa primeira semana, além dos painéis gerais de taxa de erros que a maioria das equipes já verifica:
Padrões de requisição que você não pensou em testar. Usuários reais digitam endereços com erros de digitação, formatação incomum e convenções regionais que seus dados de teste talvez não tenham coberto. Ficar atento a um aumento de respostas "nenhum resultado encontrado", especificamente, em comparação com sua linha de base anterior à migração, pode revelar diferenças de formatação ou de correspondência de endereços entre provedores que dados de teste limpos deixaram passar.
Consumo de cota em relação à sua estimativa real. Se você estimou suas necessidades de cota antes de migrar, a primeira semana é quando essa estimativa encontra a realidade. Comparar os cabeçalhos X-Quota-Used e X-Quota-Free-Remaining, documentados em /docs/rate-limits/, com o seu volume diário projetado mostra rapidamente se sua estimativa estava próxima ou precisa de ajustes antes de você se comprometer com uma faixa de preço específica a longo prazo.
A distribuição dos tempos de resposta, não apenas as médias. Um tempo médio de resposta que parece bom pode esconder uma cauda menor, mas significativa, de requisições lentas que só aparece sob carga concorrente real, algo que um ambiente de testes limitado raramente reproduz com precisão.
Qualquer trecho de código que ainda faça referência silenciosa ao provedor antigo. Migrações às vezes deixam escapar um ponto de chamada, especialmente em um recurso usado com menos frequência ou em um job em segundo plano executado raramente, e a primeira semana costuma ser quando essa lacuna aparece sozinha, geralmente por meio de um chamado de suporte ou de uma entrada de log inesperada, e não por uma busca ativa.
Dados em cache divergindo entre os resultados do provedor antigo e do novo. Se o seu plano de migração envolveu alguma das abordagens de tratamento de cache discutidas em outros artigos, como marcar as entradas pelo provedor de origem ou deixar as entradas antigas expirarem naturalmente, a primeira semana é quando vale a pena verificar de fato se isso está funcionando como planejado, em vez de simplesmente presumir.
Definir uma verificação diária específica e breve durante essa primeira semana, mesmo que sejam apenas quinze minutos revisando os painéis e cabeçalhos relevantes, detecta a maior parte do que uma migração possa ter deixado escapar muito antes do que esperar que um problema apareça como chamado de suporte. Depois da primeira semana sem problemas significativos, a maioria das equipes pode razoavelmente voltar ao ritmo normal de monitoramento, tendo usado essa janela justamente para detectar as diferenças que só o tráfego real, e não os testes, consegue revelar.
Se aparecer algo que os testes não detectaram, ter um plano de reversão pronto desde antes da migração, em vez de improvisar um sob pressão, é o que impede que uma primeira semana difícil se torne uma semana realmente ruim.