Escrever um runbook de cutover de migração com um relógio em cada passo

A diferença entre uma migração que custa cinco minutos de downtime visível e uma que consome um fim de semana raramente está no hardware. Está em saber se o cutover foi escrito como uma sequência de passos cronometrados, verificáveis e reversíveis antes da noite, e se foi ensaiado até os tempos serem conhecidos. É assim que escrevemos esse documento.

O problema: a noite é a pior hora para pensar

Cada decisão tomada durante a janela (que sincronização vai primeiro, quanto tempo esperar por uma réplica, quando desistir e fazer rollback) é tomada por pessoas cansadas e sob pressão, normalmente com o dono do website ao telefone. O objetivo de um runbook é que ninguém tenha de decidir durante a janela nada que pudesse ter sido decidido na semana anterior.

Uma lista de tarefas não é um runbook. Um runbook tem cinco colunas.

As cinco colunas

Passo	Orçamento	Responsável	Verificação	Caminho de volta
Congelar as escritas na origem	2 min	app	login de administrador recusado, fila de encomendas vazia	levantar o congelamento
Sincronização final de ficheiros	3 min	ops	o rsync não lista mais alterações	nenhum necessário, origem intocada
Catch-up final e promoção da base de dados	3 min	db	GTID igual dos dois lados, destino em read write	despromover o destino, descongelar a origem
Mudar o DNS e o load balancer	2 min	net	o novo origin responde através do nome público	reverter o registo
Smoke tests	5 min	app	lista de páginas, login, checkout, pesquisa	reverter o DNS

Orçamento é o tempo que o passo demorou no ensaio, mais uma margem. Responsável é uma pessoa, não uma equipa. Verificação é um facto observável, não «parece bem». Caminho de volta é a ação exata que desfaz o passo, e se um passo não tem caminho de volta, é o ponto sem retorno e tem de ser marcado como tal.

Antes da janela: mova quase tudo cedo

O cutover só deve mover o que mudou desde a última sincronização. Tudo o resto acontece dias antes, enquanto a origem continua a servir:

• Construa o destino de raiz segundo especificações medidas, em vez de restaurar imagens dos servidores antigos.
• Semeie a base de dados a partir de um backup físico e mantenha-a atualizada por replicação. Na noite, o catch-up é uma questão de segundos de diferença.
• Pré-sincronize os ficheiros repetidamente, para que a última passagem seja pequena. Faça um dry run no dia anterior para ver o que a passagem final vai mover:

rsync -aHAX --numeric-ids --delete --itemize-changes --dry-run \
      source:/var/www/ /var/www/ | wc -l

• Copie os índices de pesquisa com o reindex remoto do próprio motor, em vez de voltar a percorrer o conteúdo através da aplicação.
• Baixe os TTL do DNS para poucos minutos pelo menos dois TTL antigos antes da janela, para que os resolvers já tenham esquecido o valor longo quando mudar. Verifique o que o mundo realmente vê:

dig +noall +answer www.example.com @<public-resolver-1>
dig +noall +answer www.example.com @<public-resolver-2>

Ensaie numa cópia, com um cronómetro

Corra o cutover inteiro contra uma cópia do destino pelo menos uma vez, com os mesmos comandos, por ordem, cronometrando cada passo. O ensaio produz a coluna do orçamento. Produz também as surpresas: a sincronização de ficheiros que percorre lentamente milhões de ficheiros inalterados por causa de um flag em falta, o utilizador de replicação a quem falta um privilégio, o health check que aponta para o caminho errado.

Acrescente cada lição ao modelo de runbook, não apenas à cópia desta migração. É assim que a décima migração fica mais fácil do que a primeira.

Escreva os critérios de go ou no go com antecedência

Acorde, antes da janela e com o dono do website, o que tem de ser verdade para começar, e o que vai provocar um rollback:

• Go: lag de replicação no destino abaixo de um valor acordado, última sincronização em dry run dentro do orçamento, monitorização no destino a verde, as pessoas nomeadas na coluna do responsável presentes.
• Gatilho de rollback: qualquer passo a exceder o dobro do seu orçamento, ou os smoke tests a não passarem até uma hora fixa depois da mudança.

Escrever o gatilho elimina o instinto mais perigoso de qualquer noite de cutover: «dá-lhe mais dez minutos». Se o relógio diz rollback, faz-se rollback, e tenta-se de novo noutra noite com um runbook melhor.

Torne o caminho de volta barato

Um rollback que exige restaurar a partir de um backup não é um rollback que alguém escolha usar. Desenhe cada passo de modo que desfazê-lo seja rápido:

• A origem fica intocada e em funcionamento até o destino ter dado provas. Os seus dados nunca são apagados durante a janela.
• No destino, tudo o que é substituído é renomeado, nunca removido. Voltar atrás é um rename e uma alteração de DNS.
• A promoção da base de dados só acontece depois de os dois lados reportarem o mesmo GTID, para que uma despromoção o devolva a uma posição conhecida.
• As alterações de configuração aplicam-se como ficheiros que pode trocar, não como edições de que tem de se lembrar.

mv /var/www/site /var/www/site.pre-cutover-$(date +%F)
mv /var/www/site.new /var/www/site

Corra a janela, depois audite

Durante a janela, uma pessoa lê o runbook em voz alta e regista o tempo real contra cada orçamento. Ninguém improvisa. Quando o último smoke test passar, mantenha a origem a correr e observe os dois lados: o tráfego deve escoar do origin antigo à medida que as caches expiram. Tudo o que continuar a chegar à origem depois de passado o TTL antigo é uma dependência que ninguém listou, como um cron job, um cliente de API ou um endereço fixo no código, e tem de ser encontrada antes de a origem ser desligada.

Depois, compare a nova plataforma com a baseline antiga: exposição externa, tempos de resposta, taxa de cache hit, taxas de erro. Só então retire a origem, e guarde os seus dados até o dono dar a aprovação final.

A sua lista de verificação

• Cada passo tem um orçamento, um responsável, uma verificação e um caminho de volta.
• Os dados são semeados e os ficheiros pré-sincronizados dias antes. A janela só move a diferença.
• TTL baixados cedo e verificados de fora.
• Um ensaio cronometrado numa cópia, com as lições incorporadas no modelo.
• Critérios de go e de rollback acordados por escrito antes da noite.
• A origem mantida intacta até a auditoria estar feita e o dono ter aprovado.

Se tem uma mudança no horizonte, teremos todo o gosto em ajudar a escrever o runbook.

Fale com um engenheiro

Related (rows[1])

Relacionados: Migrações de datacenter geridas, ensaiadas · Replicação de bases de dados e réplicas offsite · Live migration e saída de hypervisor