Escreva primeiro o rollback: um modelo para upgrades de rotina

As plataformas ficam para trás por uma razão simples: cada upgrade parece arriscado, por isso é adiado, e cada adiamento torna o upgrade seguinte maior e ainda mais arriscado. A saída é tornar os upgrades aborrecidos. Isso significa um modelo que se segue sempre, e a linha mais importante dele é a que a maioria das equipas escreve em último lugar: como voltar atrás.

Saiba que existe uma versão antes de precisar dela

Publicamos cada novo build, com o seu changelog, no nosso chat de operações no dia em que sai.

Um refinamento merece ser copiado. Muitos projetos publicam correções para ramos mais antigos ao lado do atual. Um watcher que anuncia cegamente «nova versão» pode tentar alguém a instalar um back-port mais antigo do que o que já está a correr. Nós etiquetamo-los automaticamente como «não fazer deploy», para que ninguém dê um passo atrás por acidente.

Prepare a alteração

Leia o changelog como um contrato

Nas notas de versão, as migrações são o que mais conta: tudo o que corre uma vez e não se desfaz facilmente, como uma alteração de esquema, decide o que o seu rollback tem de incluir.

Verifique cada servidor

Depois verifique cada servidor em que vai tocar, não a frota em geral, e liste os seus plugins, extensões e integrações face à nova versão.

Um plugin de que ninguém se lembrava é a razão mais comum para um upgrade, de resto limpo, falhar. Listá-los por servidor demora minutos e elimina a surpresa.

Faça um backup que tenha realmente verificado

«O job de backup correu» não é o mesmo que «temos um backup». Antes da alteração, faça um dump consistente e teste-o:

mysqldump --single-transaction --routines --triggers --events <db> \
  | gzip > <db>-pre-upgrade-$(date +%F-%H%M).sql.gz
gzip -t <db>-pre-upgrade-*.sql.gz && ls -lh <db>-pre-upgrade-*.sql.gz

Escreva o rollback antes da alteração

Este é o passo que transforma um upgrade arriscado numa rotina. Antes de começar, escreva, por ordem, os passos exatos que devolveriam o sistema ao ponto em que está agora. Em sistemas baseados em RPM, o lado dos pacotes costuma ser curto:

dnf history list | head
dnf history undo <transaction-id>

E para impedir que um pacote conhecido como bom se mova enquanto testa, o plugin versionlock fixa-o:

dnf versionlock add <package>

Mas os pacotes raramente são a história toda. Se a versão corre uma migração de esquema, reverter apenas os pacotes deixa-o com código antigo sobre um esquema novo. O seu rollback tem então de incluir o restore do dump que acabou de fazer, e precisa de saber quanto tempo esse restore demora. Escreva tudo, e sempre que puder, ensaie-o primeiro numa cópia. Um rollback que só existe na sua cabeça no momento em que as coisas correm mal não é um rollback.

Altere uma máquina de cada vez

Em plataformas redundantes, um nó de cada vez. As versões major vão primeiro para as nossas próprias instâncias e correm lá antes de qualquer instância de cliente as receber.

Meça e verifique

Meça o downtime em vez de o estimar

«Cerca de um minuto» é um palpite. Um probe a correr durante toda a alteração dá-lhe o número real. Arranque-o antes de começar e pare-o quando terminar:

while true; do
  printf '%s %s\n' "$(date +%T.%3N)" \
    "$(curl -s -o /dev/null -m 2 -w '%{http_code}' https://<service>/health)"
  sleep 0.5
done | tee upgrade-probe-$(date +%F).log

Depois, a primeira e a última linha que não sejam 200 no log delimitam a interrupção com precisão de meio segundo. É esse o número que reporta às pessoas que dependem do serviço, e é o número com que compara da próxima vez. Ao longo de um trimestre, estas medições são a melhor prova que tem de que os upgrades estão a ficar mais seguros em vez de mais arriscados.

Verifique de fora, depois traga o sistema operativo

Quando o upgrade terminar, dispare um alarme de teste para saber que a monitorização continua a ver o serviço. Depois use a mesma janela para atualizar também os pacotes do sistema operativo. Aplicação e fundação mantêm-se a par, e o upgrade seguinte não começa com uma pilha de atualizações sem relação.

O modelo

1. Versão detetada e anunciada, back-ports etiquetados.
2. Changelog lido à procura de correções de segurança, breaking changes e migrações.
3. Cada servidor verificado, incluindo todos os plugins.
4. Backup recente feito e inspecionado.
5. Rollback escrito, passo a passo, antes da alteração.
6. Um nó de cada vez, as versões major primeiro nos seus próprios sistemas.
7. Downtime medido por um probe, reportado em segundos.
8. Verificado de fora, sistema operativo atualizado na mesma janela.

Se as suas plataformas ficaram para trás e o próximo upgrade parece um projeto, podemos ajudar a voltar à rotina. Fale com um engenheiro

Related (rows[1])

Relacionados: Plataformas atuais e disciplina de atualizações · Resposta de emergência a vulnerabilidades no mesmo dia · Monitorização da frota e encaminhamento de alarmes