Uma migração é um projeto, não um ticket.

São sites de notícias e lifestyle em que o pico de tráfego é o próprio negócio. Uma migração que os deita abaixo, ou os levanta mais lentos, é visível para cada leitor a meio de uma notícia de última hora. Isto nunca iria ser um ticket. Foi um projeto com uma noite de cutover.

Porquê uma só equipa para todo o trabalho

O trabalho precisava de duas coisas ao mesmo tempo, de uma só equipa: a engenharia para redesenhar as camadas de caching e de base de dados, e a infraestrutura própria (all-flash SAN enterprise, um verdadeiro fabric de rede) onde a assentar. Juntámos os engenheiros e o metal, e a noite do cutover foi responsabilidade nossa.

A plataforma, tal como foi desenhada

A intenção do desenho era três coisas ao mesmo tempo: redesenhar para escala na cache e na base de dados, fazer o cutover com uma janela mínima e delimitada, e levar cada peça do novo desenho intacta através do cutover. Eis no que se tornou.

O determinístico vence o elegante

A base de dados foi movida com um hot backup recente em vez de um catch-up de replicação em direto. Foi uma decisão de desenho com uma justificação declarada: um backup é determinístico, por isso o que está no backup é o que o novo cluster tem, sem estado de replicação para desenredar no pior momento possível. O caminho mais elegante existe, e recusámo-lo de propósito. Na noite do cutover quer-se a mudança cujo resultado já se conhece.

Mover os dados depressa significou retransmiti-los em dois saltos: pela internet pública até um relay de staging, e depois pela LAN interna a line rate, transformando uma cópia limitada pela encriptação em poucos minutos. No destino, o cluster foi reconstruído a partir do backup e ressincronizado nó a nó.

E uma sincronização do filesystem levou uma lista de exclusões cirúrgica para que a migração não pudesse esmagar a configuração da nova casa: a configuração do apontador da base de dados, o drop-in da object cache e a instalação da cache de dois níveis foram todos explicitamente preservados. A única peça de estado que um restore de base de dados apaga silenciosamente, a ativação do plugin de cache-purge, foi mapeada de antemão com a sua reativação pronta a disparar. É isso que significa desenhar o cutover duas vezes: uma vez para a frente, e outra para tudo o que poderia morder pelo caminho.

“Não movemos os seus servidores. Reconstruímos a sua plataforma e assentámo-la na nossa, numa janela de cerca de cinco minutos, planeada de antemão.”

No que se tornou a relação

A migração foi o ponto de entrada, não o fim. Os sites irmãos seguiram o mesmo padrão, e a disciplina operacional veio como parte da construção e não como um upsell posterior: hot backups frequentes da base de dados e snapshots do filesystem retidos, edge caches afinadas, uma camada de monitorização de desempenho para toda a frota, e validação por teste de carga antes do lançamento. A relação assentou em «operamos e evoluímos a plataforma», não em «alojamo-la».