Melhores Práticas de Liderança Técnica
Conselho de banco de dados para alterações de esquema entre equipes. Use esta lista ao estabelecer ou auditar a liderança da plataforma de dados.
Como Usar Esta Lista
- Adote a cadência do conselho antes que a segunda equipe compartilhe um banco de dados.
- Pontue cada serviço trimestralmente em relação aos itens de conexão, migração e revisão.
- Publique decisões como ADRs no git, não apenas em notas de reunião.
- Combine a lista com o orçamento de erros e ações de pós-mortem de incidentes.
A - Governança
- O conselho de banco de dados se reúne semanalmente com a fila de migração. Conflitos entre equipes surgem cedo.
- Guia de estilo de esquema único aplicado em CI. Nomenclatura, política de FK, padrões de RLS documentados.
- Alterações de esquema tratadas como semver de API. Alterações disruptivas usam expandir/contrair.
- ADR exigido para disputas de propriedade de tabelas compartilhadas. Quem escreve, quem migra.
B - Barra de Qualidade
- Padrões de revisão de consulta obrigatórios acima do limite de QPS. Evidência EXPLAIN no PR.
- Solicitações de índice fluem através de aprovação medida. Sem
CREATE INDEXad hoc em produção. - pg_stat_statements revisado semanalmente. Os dez primeiros por tempo total têm um proprietário.
- Treinamento MVCC para cada nova equipe de serviço. Dentro de 30 dias após o primeiro deploy.
C - Parceria de Confiabilidade
- Líder técnico co-possui o SLO do datastore com SRE. RPO/RTO explícito nos documentos de status.
- Runbooks de plantão vinculados ao README do serviço. Cenários de disco, locks, lag.
- Ações pós-incidente rastreadas até a conclusão. Mesmo sprint do post-mortem.
- Janelas de manutenção coordenadas com o calendário do produto. Datas de blackout compartilhadas.
D - Custo e Crescimento
- Previsão de crescimento de armazenamento compartilhada com finanças mensalmente. Vincule à retenção e índices.
- Contagem de réplicas justificada pelo SLO de leitura. Não "padrão 2" sem prova de carga.
- Revisão de dimensionamento trimestral. Geração de instância e IOPS correspondem ao conjunto de trabalho.
- Desativar índices e esquemas não utilizados. Monitoramento de idx_scan com política de exclusão.
FAQs
Qual o tamanho ideal do conselho de banco de dados?
Um delegado por serviço consumidor mais o presidente do DBA; mantenha abaixo de 10 pessoas para decisões.
E se as equipes resistirem ao conselho?
O líder técnico escala via custo de incidente e perdas de SLO; comece consultivo e depois mandatório após Sev-2.
O conselho bloqueia a entrega?
O objetivo é a ordenação de migração paralela segura, não poder de veto para velocidade.
Como lidar com o esquema de uma empresa adquirida?
O conselho adiciona uma trilha de integração; ADR separado para bancos de dados mesclados vs. federados.
O líder técnico deve escrever SQL?
Sim, para padrões e revisões; delegue o ajuste fino para o DBA sênior.
Como medir o impacto da liderança?
Frequência de incidentes, taxa de falha de migração, tempo médio para aprovar alteração segura de esquema.
E sobre persistência poliglota?
O escopo do conselho esclarece Postgres vs. outras lojas por contexto delimitado.
Esquema gerado por IA no conselho?
Mesma barra de revisão; DDL gerado não é aprovado automaticamente.
Dicas para conselho remoto?
Documento de migração assíncrono 24h antes; ao vivo apenas para conflitos e incidentes.
O que devo ler a seguir?
Relacionados
- Noções Básicas de Liderança Técnica em Postgres - correção/uptime/custo
- Padrões de Revisão de Consulta - barra de PR
- Noções Básicas de Governança - padrões da organização
- Práticas Recomendadas de Trabalho com Colaboração de Engenharia - alinhamento de stakeholders
- Práticas Recomendadas de Gerenciamento de Mudanças - segurança de DDL
Versões do 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+.