Guía de rol · Bases de datos
¿Qué es un DBA?
Qué hace un administrador de bases de datos en el día a día, qué tipos hay y cómo se llega al rol desde administración de sistemas o desde desarrollo.
DBA son las siglas de Database Administrator: la persona que se ocupa de que las bases de datos de una empresa estén disponibles y rindan bien, sin perder datos por el camino, y de que solo las toque quien debe. Es un rol de infraestructura, no de análisis: un DBA no explota los datos, hace que otros puedan hacerlo con garantías.
Qué hace un DBA en el día a día
- Disponibilidad. Que la base de datos esté arriba y responda. Alta disponibilidad, réplicas, failover, ventanas de mantenimiento.
- Rendimiento. Índices, planes de ejecución, consultas lentas, bloqueos. Buena parte del trabajo es encontrar por qué algo va lento y arreglarlo sin tocar la aplicación.
- Copias y recuperación. Política de backups y pruebas de restauración, incluida la recuperación a un punto en el tiempo. Es lo que separa un incidente de un desastre.
- Seguridad y accesos. Usuarios, roles, cifrado, auditoría, cumplimiento.
- Cambios y despliegues. Migraciones de esquema, actualizaciones de versión, paso a nube, capacidad.
- Soporte a desarrollo. Revisar modelos y consultas, aconsejar sobre índices, ayudar cuando algo se rompe.
Tipos de DBA
La etiqueta cubre perfiles bastante distintos, y conviene saber cuál te describe antes de aplicar:
- DBA de producción u operaciones. El clásico: entornos críticos, guardias, muchos servidores. Suele venir de administración de sistemas.
- DBA de desarrollo. Más cerca del código: modelado, procedimientos almacenados, optimización de consultas. Suele venir de desarrollo backend.
- DBRE o DBA en la nube. Bases de datos gestionadas (Azure SQL, RDS, Cloud SQL), infraestructura como código, automatización. Cada vez más habitual en las ofertas.
Cómo se llega a DBA
Casi nadie empieza como DBA. Los dos caminos habituales son desde administración de sistemas (ya gestionas servidores y backups y te especializas en el motor) y desde desarrollo backend (ya escribes SQL y te vas hacia el rendimiento y la operación). En los dos casos lo que marca la diferencia en una entrevista es poder contar un incidente real: qué falló y qué cambiaste para que no volviera a pasar.