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

DBA

Schema, migrações, tuning.

Atualizado: 2026-04-24 14 seções Baixar .zip

O DBA é a persona que mantém os stores de dados operacionais rápidos, seguros e honestos sob mudança. Em um SDLC AI-nativo, o DBA opera um agente Schema Guard, quatro slash prompts e um catálogo validado de MCPs abrangendo Azure SQL Database e Azure Cosmos DB — não um laptop cheio de scripts SQL.

Resumo executivo

O DBA é dono da saúde dos bancos de dados operacionais — principalmente Azure SQL Database e Azure Cosmos DB — em evolução de schema, performance de queries e confiabilidade. Em um SDLC AI-nativo, o workflow é operacionalizado através de um agente Schema Guard com quatro slash prompts (/migrate-plan, /index-review, /query-tune, /rollback-script), instruções com escopo para SQL e arquivos de migração, e MCPs validados alcançando Azure Monitor, Application Insights e GitHub.

As entregas primárias são planos de migração reversíveis, workloads indexados e tunados, scripts de rollback validados em não-produção e um log de mudanças de schema que qualquer engenheiro pode ler. O DBA fecha a lacuna entre a evolução da aplicação e a realidade do banco de dados: migrações são entregues atrás de feature flags, com prova de que são reversíveis, e regressões de performance são capturadas no CI, não em produção.

O DBA é um colaborador com o Data Engineer e o Developer, não um gatekeeper. Seu poder é multiplicado por agentes que automatizam as partes chatas.

Papel e responsabilidades

Pense no DBA como o engenheiro-chefe de um navio. O capitão define o curso; o engenheiro-chefe garante que os motores nunca parem, as bombas continuem funcionando e cada linha de combustível seja testada antes da tempestade. Em um SDLC AI-nativo, o DBA mantém os motores de dados funcionando sob mudança constante.

Responsabilidades primárias:

  • Revisar e fazer merge de cada migração de schema com um plano de rollback
  • Manter a estratégia de índices para Azure SQL Database e a estratégia de partição para Azure Cosmos DB
  • Tunar queries sinalizadas pelo Application Insights e Azure SQL Query Store
  • Aprovar mudanças de acesso através do Microsoft Entra ID com padrões de mínimo privilégio
  • Garantir que backups e simulações de restauração rodem trimestralmente
  • Colaborar com o Data Engineer em schemas compartilhados e com o Developer em mapeamentos de ORM
  • Operar o agente Schema Guard e os prompts /migrate-plan, /index-review, /query-tune, /rollback-script
  • Manter o log de mudanças de schema e o dashboard de performance de queries

Jobs to be done

  1. Como DBA, eu quero cada migração revisada com um script de rollback gerado, para que nenhum passo adiante seja irreversível.
  2. Como DBA, eu quero sugestões de índices surfaceadas a partir de telemetria de workload real, para que o trabalho de otimização mire na dor real.
  3. Como DBA, eu quero queries de longa duração tunadas com análise assistida por agente, para que latências p99 fiquem dentro do SLA.
  4. Como DBA, eu quero partition keys do Cosmos DB revisadas em PRs de modelo de dados, para que hot partitions não apareçam em escala.
  5. Como DBA, eu quero mudanças de schema deployadas atrás de feature flags com backfill seguro, para que nenhum release seja bloqueado por uma operação DDL.
  6. Como DBA, eu quero verificações diárias de integridade e simulações de restauração evidenciadas no Azure Monitor, para que alegações de resiliência sejam verificáveis.
  7. Como DBA, eu quero revisões de acesso ao banco rodadas com Entra ID, para que mínimo privilégio seja o estado padrão.
  8. Como DBA, eu quero um log de mudanças de schema único publicado no Microsoft Teams, para que produto e engenharia vejam o que mudou em dados compartilhados.

Dores antes do AI-nativo

  • Migrações somente para frente. Uma migração ruim em produção significa restaurar de backup, não reverter.
  • Índices por adivinhação. Índices adicionados baseados em intuição do developer, não em evidência do Query Store.
  • ORMs donos do schema. Schemas inferidos de anotações de código, se afastando do design pretendido.
  • Hot partitions do Cosmos. Partition keys escolhidas para minimizar esforço; throttling de produção é o primeiro feedback.
  • Concessões de acesso ad hoc. Permissões concedidas durante incidentes, nunca revogadas, se tornando o novo normal.
  • Simulações de restauração puladas. “Temos backups” é acreditado até o dia em que precisamos usá-los.
  • Silêncio de mudança de schema. Engenharia fica sabendo da nova coluna por erros de produção, não por revisões de PR.

Fluxo diário AI-nativo

O DBA trabalha a partir do Visual Studio Code com GitHub Copilot e do terminal com Claude Code, operando o agente Schema Guard ao longo do dia.

Setup da manhã

  1. Abra o Azure Monitor e o Azure SQL Query Store; revise queries de longa duração e alertas noturnos.
  2. Rode /index-review --since=yesterday; o Schema Guard surfa recomendações de índice a partir de telemetria real.
  3. Revise PRs de migração pendentes; confirme que cada um tem um /rollback-script.
  4. Verifique métricas do Cosmos DB para hot partitions e throttling; triar.
  5. Sincronize com o Data Engineer sobre quaisquer dependências cross-store em movimento hoje.

Execução no meio do dia

  1. Para cada PR de migração, rode /migrate-plan; o Schema Guard verifica a reversibilidade e produz um plano de execução passo a passo com gating por feature flag.
  2. Invoque /query-tune para as principais regressões identificadas pelo Application Insights.
  3. Valide scripts de rollback em um banco de staging; anexe a evidência ao PR.
  4. Pareie com Developers em desalinhamentos ORM-para-schema.

Revisão no fim da tarde

  1. Publique o log diário de mudanças de schema no Microsoft Teams.
  2. Revise acesso ao banco mediado pelo Entra ID; feche concessões obsoletas.
  3. Verifique o status de simulação de restauração; se não está verde neste trimestre, agende e execute.

Primitivas recomendadas

Agente

AgenteArquivoPropósito
schema-guard.github/agents/schema-guard.agent.mdRevisa migrações, planeja índices, tuna queries, escreve scripts de rollback

Slash prompts

ComandoArquivoPropósito
/migrate-plan.github/prompts/migrate-plan.prompt.mdGerar um plano de migração reversível com gating e estratégia de backfill
/index-review.github/prompts/index-review.prompt.mdSurfar recomendações de índice a partir de telemetria do Azure SQL Query Store
/query-tune.github/prompts/query-tune.prompt.mdTunar uma query lenta com análise de plano de execução e sugestões de reescrita
/rollback-script.github/prompts/rollback-script.prompt.mdProduzir e validar um script de rollback para uma migração

Instruções com escopo

Escopo (applyTo)ArquivoPropósito
migrations/**/*.sql.github/instructions/migrations.instructions.mdPassos up e down obrigatórios, sem DDL destrutivo sem gate
src/**/entities/**.github/instructions/ormschema.instructions.mdRegras de alinhamento ORM-para-schema para Azure SQL
cosmos/**/*.ts.github/instructions/cosmos-dba.instructions.mdRevisões de partition key e política de índice para Azure Cosmos DB
queries/**/*.sql.github/instructions/queries.instructions.mdSARGabilidade, parametrização, política de query hints

Hooks

  • pre-commit: lint de SQL, detector de DDL destrutivo
  • pre-push: dry-run de migração contra um shadow database
  • post-merge: agendar execução de migração com gating por feature flag
  • nightly: rodar /index-review contra o Query Store e abrir issues
  • on-deploy: publicar log de mudanças de schema no Microsoft Teams

MCPs validados

MCPPropósitoDono
GitHub MCP ServerPRs, execuções do Actions, logs de mudança de schemaGitHub
Azure MCP ServerConsultar Azure SQL, Cosmos DB, Azure Monitor, Application Insights, Entra IDMicrosoft
Microsoft Learn Docs MCPReferenciar orientação atualizada de Azure SQL e Cosmos DBMicrosoft
Azure DevOps MCP ServerRastrear work items do DBA quando o time usa Azure DevOpsMicrosoft
Playwright MCPValidar fluxos de UX data-driven após migraçãoMicrosoft

Exemplos reais

Exemplo 1: migração segura atrás de feature flag

Um PR adiciona uma coluna preferred_currency a accounts. /migrate-plan gera um plano de dois passos: adicionar coluna nullable, backfill em lotes, depois flipar a feature flag. /rollback-script produz e valida o reverso. A migração roda em horário de baixa demanda; código da aplicação lê o novo campo somente quando a flag está ligada.

Exemplo 2: recomendação de índice a partir de telemetria

Durante a noite, /index-review surfa um índice não-clustered ausente em orders(customer_id, created_at) que direciona 62 por cento de CPU no workload de relatórios analytics. O DBA abre um PR; a migração é reversível; o índice aterrissa; na manhã seguinte, o Query Store confirma que p95 caiu de 3,4 s para 240 ms.

Exemplo 3: hot partition do Cosmos DB capturada cedo

Uma nova feature escreve telemetria com chave por country. /migrate-plan sinaliza a escolha como provável criadora de hot partitions (tráfego dos EUA domina). O Schema Guard sugere uma chave sintética combinando country e um hash de user_id. A mudança aterrissa antes do rollout para produção.

Anti-padrões

  • Migrações somente para frente. Nunca faça merge de uma migração sem um script de rollback validado.
  • ORM como fonte da verdade. O schema do banco de dados é a fonte da verdade; ORMs o refletem.
  • Índice por feeling. Use telemetria do Query Store e Application Insights; não intuição.
  • Permissões ad hoc. Todo acesso ao banco via grupos do Entra ID com donos nomeados.
  • Simulações de restauração puladas. Se você não restaurou de backup neste trimestre, você não tem backups.
  • DDL destrutivo sem gate. DROP COLUMN em um PR sem revisão é um incidente esperando acontecer.
  • Mudanças de schema escondidas em PRs de app. Migrações vivem em migrations/* e são revisadas com o dono do schema.

KPIs e métricas de impacto

MétricaLinha base (manual)Meta (agêntico)Fonte
Migrações com rollback validado30 por cento100 por centoVerificação no PR
Regressão de query p95 em produção10 por trimestre< 1Application Insights
Hot partitions observadas em escala3 por trimestre0Métricas do Cosmos DB
Conclusão de simulação de restauraçãoAnualTrimestralRelatórios do Azure Backup
Identidades de acesso ao banco obsoletas200Revisões de acesso do Entra ID
Recomendações de índice atendidas em 30 dias20 por cento> 80 por centoHistórico de /index-review
Log de mudanças de schema publicadoAd hocDiariamenteMicrosoft Teams

Maturidade em quatro níveis

  • L1 Manual: Scripts SQL por email, migrações somente para frente, índices por adivinhação.
  • L2 Assistido: Copilot redige SQL, migrações rastreadas em ferramenta, mas rollback ainda é ad hoc.
  • L3 Aumentado: Agente Schema Guard, quatro slash prompts, instruções com escopo, migrações com feature flag.
  • L4 Autônomo: Revisão noturna de índices, rollbacks auto-validados, simulações de restauração agendadas e evidenciadas, log diário de mudanças de schema.

Integração com outras personas

  • Com o Data Engineer: governança de schema compartilhada para datasets cross-store; revisão de migração.
  • Do Developer: mudanças de entidade e ORM coordenadas através de PRs.
  • Do Software Architect: escolhas de tecnologia de armazenamento e modelos de capacidade.
  • Com o SRE: runbooks para incidentes de banco de dados e procedimentos de restauração.
  • Com o InfoSec Officer: revisões de acesso, logging de auditoria, rotação de chaves de encriptação.
  • Para o Compliance Auditor: evidência de controle de mudanças, revisões de acesso, postura de backup.
  • Com o Product Owner: janelas de migração planejadas contra o calendário de releases.

Glossário

  • Migração: uma mudança versionada e reversível no schema ou objetos do banco de dados.
  • Script de rollback: um script validado que retorna o schema a um estado anterior.
  • Query Store: feature do Azure SQL que captura planos de consulta e estatísticas de runtime.
  • Partition key: a propriedade do Cosmos DB que determina a distribuição de dados.
  • SARGable: um predicado de query que pode usar um índice eficientemente.
  • Backfill: o processo de popular uma coluna nova ou alterada para linhas existentes.
  • Simulação de restauração: um ensaio restaurando de backup para validar objetivos de tempo de recuperação.

Referências