Estimativa de uma migração de banco de dados
Como estimar uma migração de banco de dados: preenchimento retroativo, duração do bloqueio, implementação e reversão. “Adicionar uma coluna” é uma linha de SQL; a estimativa é de cerca de um segundo.
“Adicionar uma coluna” é uma migração de uma linha. A estimativa não se refere à coluna.
As migrações de esquema operam com dois tempos. Um é o do SQL — geralmente rápido, geralmente mecânico. O outro é o tempo operacional: por quanto tempo a tabela fica bloqueada, o que acontece em caso de gravações simultâneas, como reverter o processo se algo der errado e qual é o plano de contingência caso a execução demore mais do que a janela de implantação. A equipe decide sobre o SQL porque é isso que está no ticket. O trabalho, porém, ocorre no segundo tempo.
Em uma mesinha, os dois relógios são iguais e a história é realmente insignificante. Em qualquer mesa que realmente importe, eles não são. A estimativa precisa levar em conta o preenchimento, a estratégia de implementação e a reversão — algo que alguém precisa ter ensaiado antes que a implantação chegue nem que seja perto da produção.
O que se fala na sala
Backend: “É só um ALTER, a migração é concluída em um segundo.”
SRE: “Na tabela de pedidos? Com os bloqueios ativados? Às 15h?”
DBA: “Como estamos preenchendo as linhas existentes?”
SRE: “Qual é o procedimento de reversão caso a implantação falhe no meio do processo?”
Pergunta principal: “O caminho de leitura permite que a coluna permaneça nula por uma hora?”
Perguntas que vale a pena fazer antes de votar
- Qual é o tamanho da tabela — milhares, milhões, centenas de milhões de linhas?
- Ferramenta de migração on-line ou comando ALTER no próprio banco de dados?
- Estratégia de preenchimento: síncrona, tarefa em lote, gravação dupla?
- O que o caminho de leitura faz durante a janela de implementação?
- Reversão: apenas para a frente, ou podemos reverter o esquema?
- Alguém já seguiu o manual de procedimentos de plantão para essa migração?
Se metade da sala está votando em “o SQL” e a outra metade em “a implantação”, você não tem um problema de números; você tem duas histórias que fingem ser uma só. Separe-as: a mudança de esquema é um ticket, e o plano de atualização retroativa e implantação é outro.
Faça uma estimativa para a implementação e a reversão, não para o ALTER. É no segundo relógio que reside o risco.
Consulte como estimar uma migração de dados para a versão válida para todos os sistemas e os outros exemplos práticos de estimativa. Inicie uma sessão gratuita de Planning Poker assim que o plano de implementação estiver esboçado.