Auditoría EDB Postgres: cómo auditar tu plataforma cuando empieza a dar problemas

Cuando EDB/Postgres empieza a ir lento, el comportamiento del cluster se vuelve extraño
y aparecen procesos “raros”, muchas organizaciones se dan cuenta de que necesitan una
revisión a fondo. En otros casos, el problema es más silencioso: nadie sabe con certeza si
los backups sirven para algo más que ocupar disco.

La palabra “auditoría” suena muy formal, pero en la práctica puede aplicarse un proceso
muy útil y directo: ver cómo está realmente tu plataforma EDB Postgres, sin maquillaje,
y aterrizar:

• Qué te puede “tronar” hoy.
• Qué puedes arreglar rápido.
• Qué hay que replantear con más calma.

En Hopla lo planteamos en tres niveles (y es importante cubrirlos todos). No tiene sentido
revisar solo una capa: si el cluster está mal diseñado, el mejor tuning no te salva. Y si nadie
sabe quién puede hacer qué en la base, da igual que el servidor sea un avión.

1) Analizar el cluster y la alta disponibilidad

El objetivo es que el entorno no juegue en tu contra. En esta fase se revisa la arquitectura y
la disponibilidad:

• Cómo está armado el cluster EDB (EPAS, Postgres, etc.).
• Si realmente hay primario y réplicas bien configuradas.
• Si se usa EFM, Pgpool u otro componente para alta disponibilidad y balanceo de carga.
• Si existe una dirección VIP (o un mecanismo claro) para que las aplicaciones sepan a dónde conectarse cuando algo falla.

La pregunta clave es: cuando el nodo principal se cae, ¿hay failover automático, manual o
“rezar”?

Problemas típicos que suelen aparecer

• Cluster “en teoría” de alta disponibilidad, pero solo hay un nodo que de verdad se usa; la réplica está atrasadísima o nunca se ha probado el failover.
• EFM o Pgpool configurados a medias, con timeouts peligrosos o sin una ruta clara de retorno a la normalidad.
• Cambios de red / IPs / VLAN realizados después, pero nadie actualizó la configuración de la plataforma.

Cómo se aborda en una auditoría

• Primero se construye un mapa simple del entorno: servidores, IPs, roles, quién manda y cómo entran las aplicaciones.
• Después se revisan escenarios de fallo:
  -¿Qué pasa si se cae el primario?
  -¿Qué pasa si se cae la red de un nodo?
  -¿Qué pasa si el almacenamiento empieza a llenarse o fallar?

De aquí salen quick wins (ajustar parámetros de EFM, limpiar configuraciones viejas,
documentar el flujo de failover) y una lista de acciones más de fondo: rediseño de topología,
añadir un witness, cambiar cómo se conectan las aplicaciones, etc.

Objetivo: dejar de tener un cluster que “medio aguanta” y pasar a una plataforma cuyo
comportamiento ante fallos es predecible y conocido.

2) Motor, recursos y performance: ¿realmente tu cluster está optimizado?

En esta fase se entra en el motor (EPAS/Postgres) y en el uso real de recursos:

• Configuración general de la base: memoria, conexiones, autovacuum, WAL, etc.
• Uso real de CPU, RAM y disco cuando la carga es alta.
• Tablas e índices que se llevan la mayor parte del trabajo.
• Bloqueos y esperas que frenan a las aplicaciones.
• Crecimiento de la base y si hay bloat o elementos que ya no deberían estar ahí.

Situaciones habituales

• Servidor potente, pero la base configurada como si fuera un entorno pequeño de pruebas.
• Autovacuum casi sin poder respirar, o al revés: tan agresivo que compite con la carga real.
• Índices mal definidos (faltan, sobran o no se están usando).
• Picos de CPU y disco en ciertas horas que nadie tiene identificadas.
• Procesos batch que corren a la misma hora “de toda la vida” y cada año duran más.

En una auditoría no se trata de soltar 200 parámetros y salir corriendo. Lo importante es
medir cómo se comporta la base con la carga real, no en laboratorio, y localizar 3 o 4
cuellos de botella que se puedan explicar de forma clara, por ejemplo:

• “Aquí estamos leyendo mucho en disco cuando podríamos usar RAM.”
• “Esta tabla se consulta todo el día y no tiene el índice correcto.”
• “Autovacuum no llega nunca a ciertas tablas grandes.”

Con eso, se proponen cambios que tengan sentido aplicar de forma escalonada, no un
“tuning mágico” que nadie entiende y luego nadie mantiene.

Resultado esperado de esta fase

Un plan accionable con:

• Cambios rápidos (parámetros clave, 1–2 índices, ajustes menores).
• Cambios que requieren ventana o pruebas (reorganizar tablas grandes, separar cargas, reprogramar procesos nocturnos).
• Acciones ligadas a capacidad/crecimiento (más nodos, más recursos, cambios de arquitectura).

3) Operación, seguridad y backups: quién hace qué y qué pasa si
algo se rompe

Es la parte menos vistosa, pero suele ser la que más duele cuando ocurre un incidente.
Aquí se revisa:

• Quién se conecta a la base y con qué rol.
• Si hay separación entre cuentas de aplicación, administración y reporting.
• Si todo el mundo entra con el mismo usuario “de siempre” o incluso como superusuario.
• Qué se está auditando / logueando de verdad (accesos, cambios críticos, errores).

Backups

Se analiza:

• Qué se respalda y cada cuánto.
• Dónde se guarda.
• Quién verifica.

Y la pregunta clave: ¿se ha probado recuperar algo recientemente?

Patrones comunes de riesgo

• Usuario postgres o un usuario “admin” compartido entre todo el mundo, sin trazabilidad real.
• Roles heredados de instalaciones viejas y que nadie se atreve a tocar.
• Backups que “ahí están”, pero sin pruebas de restore, sin documentación y a veces ni siquiera fuera del mismo servidor.
• Falta de políticas simples: quién puede crear bases, quién puede truncar tablas, quién puede cambiar configuraciones.

Qué se busca dejar establecido

• Un esquema mínimo de roles entendible separando cuentas para aplicaciones, admin, solo lectura, replicación, etc.
• Una política básica de backups y pruebas (muy importante):
  -Con qué herramienta se automatizan backups.
  -Qué nivel de protección tienen (PITR o no).
  -Cada cuánto se hace una prueba de restore.
• Señalar riesgos serios: permisos excesivos, backups en el mismo disco, falta de logs para investigar incidentes, etc.

No se trata de volverlo un entorno militar en un día, sino de pasar de “nadie sabe bien cómo
está” a un mínimo razonable de seguridad y operación.

¿Qué te llevas con una auditoría EDB Postgres?

Más allá del detalle técnico, el resultado final debería ser:

1. Una foto clara de cómo está tu plataforma EDB hoy (cluster, motor, operación).
2. Una lista priorizada de riesgos y mejoras, en lenguaje que puedas explicar a tu equipo y a tu responsable.
3. Un plan de acción dividido en:
   1) Cosas que puedes hacer casi de inmediato.
   2) Cosas que requieren algo de planificación.
   3) Cosas que apuntan a un rediseño más grande.

La meta no es que la base quede “perfecta para siempre”, sino que dejes de operar a ciegas
y tengas claro qué puede fallar mañana, qué puedes mejorar con poco esfuerzo y qué
decisiones tendrás que tomar para que EDB/Postgres aguante lo que viene.

Si ya tienes EDB Postgres en producción y te hace ruido cualquiera de estas áreas (cluster,
performance, seguridad o backups), merece la pena revisarlo con honestidad para saber
dónde estás y qué harías a partir de ahí.

📌​ Solicitar una auditoría para mi empresa aquí.

Preguntas frecuentes (FAQ) sobre la auditoría EDB Postgres

Autoría: Carlos Ponce de León Sámano