Mejores prácticas de respuesta a incidentes
Runbooks en el repositorio; post-mortem para cada sev-1. Usa esta lista durante las revisiones de incidentes y al incorporar a los DBA a la guardia.
Cómo usar esta lista
- Mantén los runbooks junto al código de la aplicación en git; versiona como la configuración de producción.
- Marca los elementos después de cada incidente Sev-1/2 para aumentar la memoria organizacional.
- Convierte los fallos repetidos en alertas, tiempos de espera o guardas de CI dentro de dos sprints.
- Ensaya los cinco escenarios principales trimestralmente en un clúster de staging.
A - Preparación
- Los runbooks viven en el repositorio con comandos probados. Copia y pega SQL y bash que funcionaron en staging.
- La guardia tiene rol de triaje de solo lectura. Sin contraseñas de superusuario compartidas en Slack.
- Matriz de severidad acordada con producto y SRE. Todos usan las mismas definiciones de Sev.
- Árbol de escalada documentado. Nombres de respaldo cuando el DBA principal no está disponible.
- Pager enruta a humanos que pueden ejecutar psql. No solo a la guardia de infraestructura genérica sin acceso a la base de datos.
B - Detección y Triaje
- Las alertas se vinculan a SLOs visibles para el usuario. Los bytes de disco por sí solos son insuficientes sin el contexto de la tasa de WAL.
- La primera consulta es pg_stat_activity. Antes de optimizar consultas, sabe quién está conectado y esperando.
- Captura el lag en bytes y tiempo.
pg_wal_lsn_diffdetecta retrasos en la repetición de commits. - Verifica las ranuras de replicación en cada alerta de disco. Las ranuras inactivas son un asesino principal de primarias.
- Registra cada pg_terminate_backend con el ID del ticket. Política de terminación auditable.
C - Comunicación
- Actualizaciones de estado cada 15 minutos durante Sev-1/2. Incluso si el estado es "todavía investigando".
- Un único comandante de incidente. Previene cambios conflictivos en producción.
- Comunicaciones al cliente separadas del hilo técnico. Sin PII ni texto de consulta en publicaciones públicas.
- Declara "todo despejado" solo después de que la tasa de error se normalice. No cuando se aplica la primera solución.
D - Recuperación y Aprendizaje
- Post-mortem de cada Sev-1 dentro de los cinco días hábiles. Sin culpas, elementos de acción con responsables.
- Actualiza el runbook en el mismo PR que el post-mortem. El conocimiento no vive en diapositivas.
- Simulacro de restauración PITR al menos anualmente. Las copias de seguridad no probadas son suposiciones.
- Revisa la política de lock_timeout e idle_in_transaction después de incidentes de bloqueo. Los valores predeterminados no son una política.
Preguntas frecuentes
¿Cuántos runbooks necesitamos?
Empieza con cinco: disco lleno, tormenta de bloqueos, lag de replicación, agotamiento de conexiones y migración fallida.
¿Deberían los desarrolladores estar de guardia para Postgres?
Empareja la guardia de aplicaciones con un DBA para Sev-1; los propietarios de aplicaciones se encargan del pool de conexiones y los límites de transacciones.
¿Qué herramientas pertenecen a cada runbook?
Cadenas de conexión psql (patrón redactado), Patroni/patronictl, consultas de disco y WAL, contactos de escalada.
¿Necesitamos una sala de guerra para cada incidente?
Sev-1 sí; Sev-3 puede usar un ticket asíncrono a menos que el impacto se extienda.
¿Cómo practicamos sin riesgo de producción?
Días de juego en staging con bloqueadores inyectados y discos temporales llenos.
¿Qué métricas nunca deberían faltar?
Número de conexiones, lag de bytes de replicación, bytes de retención de ranuras, % de disco libre, transacciones por segundo, latencia de consulta p95.
¿Cuándo es la conmutación por error el runbook correcto?
Primaria irrecuperable o corrupción confirmada en la primaria, no meras consultas lentas.
¿Cuánto tiempo mantener los artefactos del incidente?
Al menos un año en git para industrias con alta conformidad; redactar PII.
¿Deberíamos terminar automáticamente las transacciones inactivas?
Sí con idle_in_transaction_session_timeout después de la revisión de la aplicación; documentar en el runbook.
¿Qué debo leer a continuación?
Sigue los enlaces Relacionados para profundizar en escenarios específicos.
Relacionados
- Conceptos básicos de incidentes - severidad y lista de verificación de los primeros 15 minutos
- Triaje de tormenta de bloqueos - identificación de bloqueadores
- Emergencia de lag de replicación - decisiones de ranuras y reconstrucción
- Disco lleno en PGDATA - runbook de explosión de WAL
- Runbook de simulacro PITR - práctica de restauración
Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, y PostGIS 3.5+.