Melhores Práticas de Gerenciamento de Mudanças
DDL de alto risco requer salvaguardas automatizadas de timeout de bloqueio. Use esta lista na revisão de PRs de migração e pacotes do CAB.
Como Usar Esta Lista
- Anexe a conclusão do checklist a cada ticket de mudança de alto risco.
- Aplique timeouts de bloqueio em callbacks do Flyway ou pre-sql do Liquibase, não por memória.
- Ensaie o rollback em staging com contagens de linhas em escala de produção.
- Revise migrações falhas mensalmente; transforme padrões em regras de lint.
A - Classificação
- Todo script tem um nível de risco (baixo/médio/alto/digno de severidade). Nenhum DDL sem tag no main.
- Mudanças de alto risco exigem um revisor DBA nomeado. Não apenas aprovação genérica da plataforma.
- Raio de impacto documentado. Tabelas, serviços e contagens aproximadas de linhas listadas.
- Expanda/reduza o padrão para mudanças que quebram compatibilidade. Evite reescritas em uma única etapa em tabelas grandes.
B - Salvaguardas de Segurança
-
lock_timeoutdefinido em cada sessão de migração. Cinco segundos é um padrão comum para OLTP. -
statement_timeoutdefinido para DDL em lote. Evite migrações travadas durante a noite. -
CREATE INDEXusaCONCURRENTLYem tabelas de produção. Envolto fora de transações. - Chaves estrangeiras adicionadas como
NOT VALIDprimeiro. Valide em uma janela separada após a limpeza dos dados. - Alerta de índice inválido conectado.
pg_index.indisvalid = falsealerta o plantonista.
C - Janelas e Comunicação
- DDL de alto risco apenas em janelas de manutenção. Com página de status e responsável pelo rollback.
- Congele implantações concorrentes durante a janela. Um objetivo por janela.
- Latência de replicação monitorada durante o backfill. SLO de latência em bytes no primário.
- Linguagem voltada ao cliente declara o impacto visível ao usuário. Não "manutenção breve".
D - Rollback e Aprendizado
- Seção de rollback no ticket: reversão do app + contrato de schema. Somente para frente explicitamente indicado.
- Caminho PITR documentado para DML catastrófico. Alvo de tempo e responsável nomeados.
- Consultas de verificação pós-mudança no runbook. Não
psqlad hoc depois. - Análise post-mortem de migração falha em até cinco dias. Atualize callbacks e templates.
FAQs
Qual valor de `lock_timeout` é padrão?
3-10s para OLTP; mais longo apenas para tabelas de lote com aprovação explícita de janela.
O Liquibase deve rodar em uma transação?
Desabilite para CREATE INDEX CONCURRENTLY e alguns padrões de ALTER de acordo com a documentação do fornecedor.
Como aplicamos os níveis em CI?
Faça lint nos cabeçalhos de migração, exija CODEOWNERS em db/migrate, bloqueie implantações de alto risco às sextas-feiras por política.
Views e funções têm risco menor?
CREATE OR REPLACE pode quebrar dependentes; classifique como médio, a menos que seja puramente aditivo.
Quem é o responsável pelo calendário de mudanças?
Equipe de DBA ou plataforma com visibilidade do produto sobre datas de blackout.
Extensões precisam de CAB?
Sim, ao instalar em produção ou atualizar versões principais do pgvector/PostGIS.
Como lidar com migrações de hotfix?
Mesmas salvaguardas; aprovação acelerada não pula lock_timeout.
E schemas multi-tenant?
Rollout por tenant ou janelas cientes do shard; documente o raio de impacto do tenant.
SQL gerado por IA pode pular a revisão?
Nunca. DDL gerado ainda precisa de classificação humana de nível e teste de bloqueio em staging.
O que devo ler a seguir?
Veja Noções Básicas de Gerenciamento de Mudanças para exemplos de níveis.
Relacionados
- Noções Básicas de Gerenciamento de Mudanças - matriz de níveis e exemplos
- Janelas de Manutenção - agendamento e comunicação
- Rollback para Migrações Falhas - caminhos de reversão
- Regras de Segurança de Migração - política da equipe
- DDL de Zero Downtime - técnicas online
Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, e PostGIS 3.5+.