Melhores Práticas de Resposta a Incidentes
Runbooks no repositório; post-mortem para todo sev-1. Use esta lista durante revisões de incidentes e ao integrar DBAs ao plantão.
Como Usar Esta Lista
- Mantenha runbooks junto ao código da aplicação no git; versionados como a configuração de produção.
- Marque os itens após cada incidente Sev-1/2 para aumentar a memória organizacional.
- Converta falhas repetidas em alertas, timeouts ou guardas de CI dentro de duas sprints.
- Ensaie os cinco cenários principais trimestralmente em um cluster de staging.
A - Preparação
- Runbooks residem no repositório com comandos testados. Copie e cole SQL e bash que funcionaram em staging.
- O plantonista tem função de triagem somente leitura. Nenhuma senha de superusuário compartilhada no Slack.
- Matriz de severidade acordada com produto e SRE. Todos usam as mesmas definições de Sev.
- Árvore de escalonamento documentada. Backups nomeados quando o DBA principal está indisponível.
- Pager roteia para humanos que podem executar psql. Não apenas o plantonista genérico de infra sem acesso ao banco de dados.
B - Detecção e Triagem
- Alertas vinculados a SLOs visíveis ao usuário. Bytes de disco sozinhos são insuficientes sem o contexto da taxa WAL.
- Primeira consulta é pg_stat_activity. Antes de otimizar consultas, saiba quem está conectado e esperando.
- Capture o lag em bytes e tempo.
pg_wal_lsn_diffdetecta atrasos na replicação de commit. - Verifique os slots de replicação em cada alerta de disco. Slots inativos são um dos principais causadores de falha do primário.
- Registre cada pg_terminate_backend com o ID do ticket. Política de terminação auditável.
C - Comunicação
- Atualizações de status a cada 15 minutos durante Sev-1/2. Mesmo que o status seja "ainda investigando".
- Um único comandante de incidente. Evita mudanças conflitantes em produção.
- Comunicação com o cliente separada da thread técnica. Sem PII ou texto de consulta em posts públicos.
- Declare "tudo liberado" somente após a taxa de erro normalizar. Não quando a primeira correção for aplicada.
D - Recuperação e Aprendizado
- Post-mortem de todo Sev-1 em até cinco dias úteis. Sem culpas, com itens de ação e responsáveis.
- Atualize o runbook no mesmo PR do post-mortem. O conhecimento não vive em slides.
- Simulação de restauração PITR pelo menos anualmente. Backups não testados são suposições.
- Revise a política de lock_timeout e idle_in_transaction após incidentes de bloqueio. Padrões não são política.
FAQs
Quantos runbooks precisamos?
Comece com cinco: disco cheio, tempestade de bloqueios, lag de replicação, esgotamento de conexões e migração falha.
Desenvolvedores devem estar de plantão para Postgres?
Combine o plantonista de aplicação com o DBA para Sev-1; os proprietários da aplicação são responsáveis pelo pool de conexões e limites de transação.
Quais ferramentas pertencem a todo runbook?
Strings de conexão psql (padrão redigido), Patroni/patronictl, consultas de disco e WAL, contatos de escalonamento.
Precisamos de uma sala de guerra para todo incidente?
Sev-1 sim; Sev-3 pode usar ticket assíncrono, a menos que o impacto se espalhe.
Como praticamos sem risco de produção?
Dias de jogo em staging com bloqueadores injetados e discos temporários cheios.
Quais métricas nunca devem faltar?
Contagem de conexões, lag de bytes de replicação, bytes de retenção de slot, % de disco livre, transações por segundo, latência de consulta p95.
Quando o failover é o runbook correto?
Primário irrecuperável ou corrupção confirmada no primário, não meras consultas lentas.
Por quanto tempo manter artefatos de incidentes?
Pelo menos um ano no git para indústrias com forte conformidade; redigir PII.
Devemos terminar automaticamente transações ociosas?
Sim, com idle_in_transaction_session_timeout após revisão da aplicação; documentar no runbook.
O que devo ler em seguida?
Siga os links Relacionados para aprofundamento específico do cenário.
Relacionados
- Noções Básicas de Incidentes - severidade e checklist dos primeiros 15 minutos
- Triagem de Tempestade de Bloqueios - identificação de bloqueadores
- Emergência de Lag de Replicação - decisões de slot e reconstrução
- Disco Cheio em PGDATA - runbook de explosão WAL
- Runbook de Simulação PITR - prática de restauração
Versões de 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+.