paulasilvatech ASP Personas del SDLC Agéntico v1.0.0
EN PT ES
21 data · Implementation

DBA

Schema, migraciones, tuning.

Actualizado: 2026-04-24 14 secciones Descargar .zip

El DBA es la persona que mantiene los almacenes de datos operacionales rápidos, seguros y honestos bajo cambio. En un SDLC AI-nativo, el DBA opera un agente Schema Guard, cuatro slash prompts y un catálogo de MCPs validados sobre Azure SQL Database y Azure Cosmos DB — no un laptop lleno de scripts SQL.

Resumen ejecutivo

El DBA es responsable de la salud de las bases de datos operacionales — principalmente Azure SQL Database y Azure Cosmos DB — abarcando evolución de schema, performance de queries y confiabilidad. En un SDLC AI-nativo, su flujo se operacionaliza mediante un agente Schema Guard con cuatro slash prompts (/migrate-plan, /index-review, /query-tune, /rollback-script), instrucciones con alcance para archivos SQL y de migración, y MCPs validados que llegan a Azure Monitor, Application Insights y GitHub.

Las entregas primarias son planes de migración reversibles, cargas indexadas y tuneadas, scripts de rollback validados en no-producción y un log de cambios de schema que cualquier ingeniero puede leer. El DBA cierra la brecha entre la evolución de la aplicación y la realidad de la base de datos: las migraciones se despliegan detrás de feature flags, con prueba de que son reversibles, y las regresiones de performance se atrapan en CI, no en producción.

El DBA es un colaborador del Data Engineer y del Developer, no un guardián. Su poder se multiplica con agentes que vuelven automáticas las partes aburridas.

Rol y responsabilidades

Piensa en el DBA como el jefe de máquinas de un barco. El capitán fija el rumbo; el jefe de máquinas garantiza que los motores nunca se detengan, que las bombas sigan funcionando y que cada línea de combustible se pruebe antes de la tormenta. En un SDLC AI-nativo, el DBA mantiene los motores de datos corriendo bajo cambio constante.

Responsabilidades primarias:

  • Revisar y mergear cada migración de schema con un plan de rollback
  • Mantener la estrategia de índices para Azure SQL Database y la estrategia de partición para Azure Cosmos DB
  • Tunear queries marcadas por Application Insights y por Azure SQL Query Store
  • Aprobar cambios de acceso vía Microsoft Entra ID con defaults de menor privilegio
  • Garantizar que backups y drills de restauración corran trimestralmente
  • Colaborar con el Data Engineer en schemas compartidos y con el Developer en mappings de ORM
  • Operar el agente Schema Guard y los prompts /migrate-plan, /index-review, /query-tune, /rollback-script
  • Mantener el log de cambios de schema y el dashboard de performance de queries

Jobs to be done

  1. Como DBA, quiero que cada migración se revise con un script de rollback generado, para que ningún paso hacia adelante sea irreversible.
  2. Como DBA, quiero sugerencias de índice surgidas desde telemetría real de carga, para que el trabajo de optimización apunte al dolor real.
  3. Como DBA, quiero queries de larga duración tuneadas con análisis asistido por agente, para que las latencias p99 se mantengan dentro del SLA.
  4. Como DBA, quiero que las partition keys de Cosmos DB se revisen en los PRs de modelo de datos, para que las hot partitions no aparezcan a escala.
  5. Como DBA, quiero que los cambios de schema se desplieguen detrás de feature flags con backfill seguro, para que ningún release esté gateado por una operación DDL.
  6. Como DBA, quiero chequeos diarios de integridad y drills de restauración evidenciados en Azure Monitor, para que las afirmaciones de resiliencia sean verificables.
  7. Como DBA, quiero que las revisiones de acceso a la base de datos corran con Entra ID, para que el menor privilegio sea el estado por defecto.
  8. Como DBA, quiero un único log de cambios de schema publicado en Microsoft Teams, para que producto e ingeniería vean qué cambió en los datos compartidos.

Dolores antes del AI-nativo

  • Migraciones forward-only. Una mala migración en producción significa restaurar desde backup, no revertir.
  • Índices por adivinanza. Índices agregados por intuición del developer, no por evidencia del Query Store.
  • ORMs dueños del schema. Schemas inferidos desde anotaciones de código, derivando del diseño previsto.
  • Hot partitions en Cosmos. Partition keys elegidas para minimizar esfuerzo; el throttling en producción es el primer feedback.
  • Grants de acceso ad-hoc. Permisos otorgados durante incidentes, nunca revocados, convirtiéndose en la nueva normalidad.
  • Drills de restauración salteados. “Tenemos backups” se cree hasta el día en que necesitamos usarlos.
  • Silencio en cambios de schema. Ingeniería se entera de la nueva columna por los errores de producción, no por la revisión de PR.

Flujo diario AI-nativo

El DBA trabaja desde Visual Studio Code con GitHub Copilot y desde la terminal con Claude Code, operando el agente Schema Guard a lo largo del día.

Setup matinal

  1. Abre Azure Monitor y Azure SQL Query Store; revisa queries largas y alertas de la madrugada.
  2. Ejecuta /index-review --since=yesterday; el Schema Guard surgea recomendaciones de índice desde telemetría real.
  3. Revisa los PRs de migración pendientes; confirma que cada uno tenga un /rollback-script.
  4. Verifica métricas de Cosmos DB para hot partitions y throttling; haz triage.
  5. Sincroniza con el Data Engineer sobre cualquier dependencia cross-store en movimiento hoy.

Ejecución al mediodía

  1. Para cada PR de migración, ejecuta /migrate-plan; el Schema Guard verifica reversibilidad y produce un plan de ejecución paso a paso con gating por feature flag.
  2. Invoca /query-tune para las regresiones top identificadas por Application Insights.
  3. Valida los scripts de rollback en una base de datos de staging; adjunta la evidencia al PR.
  4. Empareja con Developers en mismatches entre ORM y schema.

Revisión al final de la tarde

  1. Publica el log diario de cambios de schema en Microsoft Teams.
  2. Revisa el acceso a la base de datos mediado por Entra ID; cierra grants obsoletos.
  3. Verifica el estado del drill de restauración; si no está verde este trimestre, agenda y ejecuta.

Primitivas recomendadas

Agente

AgenteArchivoPropósito
schema-guard.github/agents/schema-guard.agent.mdRevisa migraciones, planea índices, tunea queries y escribe scripts de rollback

Slash prompts

ComandoArchivoPropósito
/migrate-plan.github/prompts/migrate-plan.prompt.mdGenerar un plan de migración reversible con gating y estrategia de backfill
/index-review.github/prompts/index-review.prompt.mdSurgir recomendaciones de índice desde telemetría de Azure SQL Query Store
/query-tune.github/prompts/query-tune.prompt.mdTunear una query lenta con análisis de plan de ejecución y sugerencias de reescritura
/rollback-script.github/prompts/rollback-script.prompt.mdProducir y validar un script de rollback para una migración

Instrucciones con alcance

Alcance (applyTo)ArchivoPropósito
migrations/**/*.sql.github/instructions/migrations.instructions.mdPasos up y down requeridos, sin DDL destructivo sin un gate
src/**/entities/**.github/instructions/ormschema.instructions.mdReglas de alineación ORM-schema para Azure SQL
cosmos/**/*.ts.github/instructions/cosmos-dba.instructions.mdRevisiones de partition key y política de índices para Azure Cosmos DB
queries/**/*.sql.github/instructions/queries.instructions.mdSARGabilidad, parametrización, política de query hints

Hooks

  • pre-commit: lint de SQL, detector de DDL destructivo
  • pre-push: dry-run de migración contra una base de datos shadow
  • post-merge: agendar la ejecución de la migración con gating por feature flag
  • nightly: ejecutar /index-review contra Query Store y abrir issues
  • on-deploy: publicar el log de cambios de schema en Microsoft Teams

MCPs validados

MCPPropósitoDueño
GitHub MCP ServerPRs, runs de Actions, logs de cambios de schemaGitHub
Azure MCP ServerConsultar Azure SQL, Cosmos DB, Azure Monitor, Application Insights, Entra IDMicrosoft
Microsoft Learn Docs MCPReferenciar guía actual de Azure SQL y Cosmos DBMicrosoft
Azure DevOps MCP ServerTrackear work items del DBA cuando el equipo usa Azure DevOpsMicrosoft
Playwright MCPValidar flujos de UX guiados por datos tras una migraciónMicrosoft

Ejemplos reales

Ejemplo 1: migración segura detrás de un feature flag

Un PR agrega una columna preferred_currency a accounts. /migrate-plan genera un plan en dos pasos: agregar columna nullable, hacer backfill por lotes, y luego activar el feature flag. /rollback-script produce y valida el reverso. La migración corre en horas valle; el código de la aplicación lee el nuevo campo solo cuando el flag está activo.

Ejemplo 2: recomendación de índice desde telemetría

De madrugada, /index-review surgea un índice no clusterizado faltante en orders(customer_id, created_at) que está empujando el 62 por ciento de la CPU en la carga de reportes analíticos. El DBA abre un PR; la migración es reversible; el índice cae; a la mañana siguiente, Query Store confirma que el p95 bajó de 3,4 s a 240 ms.

Ejemplo 3: hot partition de Cosmos DB atrapada temprano

Una nueva feature escribe telemetría con clave por country. /migrate-plan marca la elección como propensa a crear hot partitions (el tráfico de US domina). El Schema Guard sugiere una clave sintética que combina country y un hash de user_id. El cambio cae antes del rollout a producción.

Anti-patrones

  • Migraciones forward-only. Nunca mergees una migración sin un script de rollback validado.
  • ORM como fuente de verdad. El schema de la base es la fuente de verdad; los ORMs lo reflejan.
  • Índice por sensación. Usa telemetría de Query Store y Application Insights; no intuición.
  • Permisos ad-hoc. Todo acceso a la base vía grupos de Entra ID con dueños nombrados.
  • Drills de restauración salteados. Si no restauraste desde backup este trimestre, no tienes backups.
  • DDL destructivo sin gate. DROP COLUMN en un PR sin revisar es un incidente esperando ocurrir.
  • Cambios de schema escondidos en PRs de la app. Las migraciones viven en migrations/* y se revisan con el dueño del schema.

KPIs y métricas de impacto

MétricaBaseline (manual)Objetivo (agéntico)Fuente
Migraciones con rollback validado30 por ciento100 por cientoCheck de PR
Regresiones de p95 en producción10 por trimestre< 1Application Insights
Hot partitions observadas a escala3 por trimestre0Métricas de Cosmos DB
Finalización de drills de restauraciónAnualTrimestralReportes de Azure Backup
Identidades de acceso obsoletas200Revisiones de acceso de Entra ID
Recomendaciones de índice atendidas en 30 días20 por ciento> 80 por cientoHistorial de /index-review
Log de cambios de schema publicadoAd hocDiarioMicrosoft Teams

Madurez en cuatro niveles

  • L1 Manual: scripts SQL por correo, migraciones forward-only, índices por adivinanza.
  • L2 Asistido: Copilot redacta SQL, migraciones rastreadas en una herramienta, pero el rollback sigue siendo ad hoc.
  • L3 Aumentado: agente Schema Guard, cuatro slash prompts, instrucciones con alcance, migraciones con feature flag.
  • L4 Autónomo: revisión nocturna de índices, rollbacks autovalidados, drills de restauración agendados y evidenciados, log diario de cambios de schema.

Integración con otras personas

  • Con el Data Engineer: gobernanza de schema compartido para datasets cross-store; revisión de migración.
  • Del Developer: cambios de entidades y ORM coordinados vía PRs.
  • Del Software Architect: elecciones de tecnología de almacenamiento y modelos de capacidad.
  • Con el SRE: runbooks para incidentes de base de datos y procedimientos de restauración.
  • Con el InfoSec Officer: revisiones de acceso, audit logging, rotación de claves de cifrado.
  • Al Compliance Auditor: evidencia de control de cambio, revisiones de acceso, postura de backup.
  • Con el Product Owner: ventanas de migración planeadas contra el calendario de releases.

Glosario

  • Migración: un cambio versionado y reversible al schema o a los objetos de la base de datos.
  • Script de rollback: un script validado que devuelve el schema a un estado previo.
  • Query Store: feature de Azure SQL que captura planes de query y estadísticas de runtime.
  • Partition key: la propiedad de Cosmos DB que determina la distribución de los datos.
  • SARGable: un predicado de query que puede usar un índice de forma eficiente.
  • Backfill: el proceso de poblar una columna nueva o cambiada para las filas existentes.
  • Drill de restauración: un ensayo de restauración desde backup para validar los objetivos de tiempo de recuperación.

Referencias