Melhores Práticas de Equipe e Onboarding
Um resumo condensado das 25 práticas mais importantes de equipe e onboarding para organizações PostgreSQL 18.4 - conteúdo portátil compartilhado; sem DDL de produção solo.
//
Busque em todas as páginas da documentação
Um resumo condensado das 25 práticas mais importantes de equipe e onboarding para organizações PostgreSQL 18.4 - conteúdo portátil compartilhado; sem DDL de produção solo.
Atribua um buddy de banco de dados no primeiro dia: DBA da mesma squad ou backend sênior por no mínimo duas semanas (Noções Básicas de Onboarding).
Postgres 18.4 local antes de ambientes compartilhados: Docker compose corresponde à versão principal de produção.
Fluência em psql antes de ferramentas GUI: Scripts \d+, \conninfo, ON_ERROR_STOP.
Hábito de EXPLAIN desde a primeira PR: Nenhuma revisão de consulta sem (ANALYZE, BUFFERS) em evidências de staging.
Produção somente leitura na segunda semana, não no primeiro dia: Reduz o risco de acidentes; buddy nas primeiras cinco sessões.
Sem DDL de produção solo nos primeiros 90 dias: Migrações mescladas com revisor DBA; emergência em pares.
CONTRIBUTING.md lista caminhos de migração e on-call: Fonte única para escalonamentos.
Shadow no on-call antes de ser principal: Pelo menos duas sombras não-SEV1 com debrief.
Parear nas três primeiras PRs de consulta ORM: Pareamento em PRs de Consulta previne cultura N+1.
Matriz de habilidades trimestral com links de evidências: PRs, drills, post-mortems - não apenas autoavaliação (Matriz de Habilidades).
Caminho de desenvolvimento de aplicativo → DBA documentado: Fases evitam pular HA antes da profundidade de EXPLAIN (Caminho de Desenvolvimento de App → DBA).
Horário de atendimento semanal para perguntas de schema: Reduz DMs no Slack e DDL não autorizados.
Conselho de banco de dados para schema entre equipes: Presidente de staff; ADR para alterações de tabelas compartilhadas.
Sem migrações heroicas em deploys de sexta-feira: Política de janela de alteração no acordo da equipe.
Atualizações de post-mortem de incidentes na lista de verificação de onboarding: SEV1 se torna leitura do dia três do próximo contratado.
Rotacione o dever de revisão de forma justa: Espalhe a carga de revisão de migração entre os níveis intermediários, não um gargalo de DBA.
Celebre as detecções seguras: O revisor que bloqueou a perda de CONCURRENTLY recebe reconhecimento - constrói cultura.
Documente quem é o proprietário de cada schema: Mapa de serviço para schema no repositório; sem tabelas órfãs.
Novo contratado executa o script de bundle de incidentes em staging na primeira semana: Prova que os scripts CLI funcionam.
Habilidades de agente introduzidas na segunda semana com salvaguardas: Noções Básicas de Habilidades de Agente antes de ChatGPT SQL de forma livre.
Caminho de onboarding de análise separado: Leitura somente de réplica; SLA de EXPLAIN diferente de OLTP.
Remoção de credenciais de banco de dados no mesmo dia no offboarding: Auditoria de revogação de função no ticket.
Contratados recebem acesso de escrita com tempo limitado: Data de expiração em funções de staging.
Loop de contratação inclui exercício de EXPLAIN ao vivo: Scorecard alinhado à matriz.
Retrospectiva anual da equipe sobre incidentes de banco de dados: Tendências impulsionam o orçamento de treinamento.
Frequentemente um proprietário de banco de dados sênior para 8-12 engenheiros de backend; governança de staff em frotas multi-squad. A matriz mostra quando contratar.
Mesma lista de verificação; adicione sessões de pareamento gravadas, revisão assíncrona de EXPLAIN em PRs, fuso horário explícito para horário de atendimento.
Sim, com revisão. Eles não devem ser o único aprovador ou aplicador em produção até o nível intermediário da matriz.
Versões da Stack: Esta página foi escrita para equipes de plataforma e aplicativos PostgreSQL 18.4 usando Flyway e políticas de acesso de produção somente leitura.
Revisado por Chris St. John·Última atualização: 16 de jul. de 2026