Há um padrão que se repete em empresas de porte médio. O banco de dados foi instalado por um desenvolvedor há alguns anos, funciona, e ninguém tem como responsabilidade formal cuidar dele. A pessoa que mais entende de banco é a que mais reclama quando algo fica lento — e ela é desenvolvedora, não administradora de banco.
O sistema funciona assim por um tempo surpreendentemente longo. Até não funcionar: uma consulta que passa a demorar oito segundos, um disco que enche por log de transação acumulado, uma réplica atrasada há três semanas que ninguém viu, ou — o pior caso — um backup que nunca foi restaurado e não presta.
Nesse ponto, aparece a decisão: contratar um DBA, treinar alguém interno, ou terceirizar.
O trabalho que existe, quer alguém faça ou não
Vale listar, porque a conversa costuma ser vaga. Um banco de produção demanda:
Rotina contínua
- Monitorar conexões, esperas, replicação, espaço e desempenho.
- Verificar que o backup rodou — e que ele é restaurável.
- Acompanhar a limpeza automática e a idade das transações.
- Revisar as consultas mais custosas e os índices.
- Aplicar correções de segurança.
Periódica
- Testar restauração, cronometrando.
- Revisar índices não utilizados e redundantes.
- Ajustar parâmetros conforme a carga muda.
- Planejar capacidade.
- Atualizar versão dentro do ciclo suportado.
Eventual, mas crítico
- Diagnosticar incidente de desempenho.
- Executar failover, planejado ou não.
- Migrar servidor, versão ou provedor.
- Recuperar de corrupção ou de erro humano.
A maior parte disso é rotina de baixa intensidade que exige conhecimento específico. É justamente o perfil de trabalho que se acumula quando não tem dono — e que, quando cobra, cobra caro.
Os três caminhos, com a conta honesta
Contratar um DBA interno
Ganha: conhecimento profundo do seu ambiente, disponibilidade integral, integração com o time.
Custa: salário, encargos, e — o item mais subestimado — o problema de dedicação parcial. Em empresa de porte médio, o trabalho de banco raramente ocupa uma pessoa em tempo integral. O DBA acaba absorvendo outras funções, e a especialização se dilui.
O risco real: pessoa única. Ela tira férias, adoece, sai. E quando sai, leva o conhecimento — porque quem opera sozinho raramente documenta.
Faz sentido quando: há vários bancos, volume alto, complexidade real, e trabalho suficiente para ocupar alguém em tempo integral.
Treinar alguém interno
Ganha: custo menor, conhecimento do negócio, e o desenvolvimento de uma pessoa que já está na casa.
Custa: tempo até a competência existir, e o custo de oportunidade — a pessoa deixa de fazer o que já sabe fazer bem.
O risco real: competência de banco é profunda, e aprende-se boa parte dela em incidente. Treinar alguém e esperar que ela resolva sozinha a primeira corrupção grave é transferir risco para quem não tem repertório para absorvê-lo.
Faz sentido quando: há apetite genuíno da pessoa, prazo para desenvolver, e alguém experiente acompanhando enquanto a competência se forma. Raramente funciona como solução isolada e imediata.
Terceirizar a sustentação
Ganha: competência disponível imediatamente, custo proporcional ao escopo, escala com mais de uma pessoa, e exposição a muitos ambientes — o que significa repertório de problemas que uma pessoa sozinha levaria anos para acumular.
Custa: valor mensal, e a necessidade de escopar bem o que está incluído.
O risco real: dependência externa e perda de conhecimento interno, se o contrato não prever transferência.
Faz sentido quando: o volume de trabalho não justifica alguém em tempo integral, a competência não existe internamente, ou o risco de pessoa única é inaceitável.
O que não se terceiriza
Importante ser claro, porque terceirizar demais é tão problemático quanto de menos. Estas decisões ficam com você:
- Qual dado é crítico. Só o negócio define isso.
- RPO e RTO. São decisões de negócio, com custo associado, tomadas por quem responde pelo resultado.
- Modelagem de dados. Depende do domínio, e é do time de produto.
- Prioridade de investimento. O que corrigir primeiro.
- Acesso aos dados. Quem pode ver o quê continua sendo decisão sua.
O parceiro opera, diagnostica, ajusta e recomenda. Quem decide o que é crítico e quanto risco aceitar é você.
Como escopar um contrato que funciona
A diferença entre um serviço que resolve e um que gera atrito está no escopo escrito. O que precisa estar definido:
O que é monitorado, com a lista de métricas e os limiares de cada alerta.
O que dispara ação, e qual ação. Alerta sem ação definida é ruído.
Tempo de resposta por severidade. Banco fora do ar, degradação, dúvida — cada um com o seu prazo.
Cobertura. Horário comercial ou 24 por 7? Sobreaviso está incluído ou é adicional?
O que está incluído e o que é projeto à parte. Rotina, ajuste e diagnóstico costumam estar; migração, upgrade de versão maior e projeto de alta disponibilidade costumam ser escopo separado. Deixar isso ambíguo gera a discussão mais desagradável possível.
Acesso. Quais credenciais, com qual privilégio, com qual registro de auditoria. Acesso a dado de produção precisa de base definida — inclusive por LGPD.
Relatório periódico. O que foi feito, o que foi encontrado, o que é recomendado. É o que torna visível um serviço cujo sucesso é a ausência de problema.
Transferência de conhecimento. Documentação, runbooks e reuniões de repasse. Sem isso, você fica dependente — e um bom parceiro não tem interesse nisso, porque cliente dependente é cliente ressentido.
Condições de saída. O que você leva se encerrar: documentação, acessos, procedimentos. Pergunte isso antes de assinar; a resposta revela o caráter do fornecedor.
O primeiro trabalho: o diagnóstico
Independentemente do caminho escolhido, o ponto de partida é o mesmo — saber em que estado o banco está. Um diagnóstico sério cobre:
- Backup e restauração. Existe? Roda? Já foi restaurado? Quanto tempo leva? É quase sempre aqui que está o achado mais grave.
- Alta disponibilidade. Existe? O failover já foi testado? A aplicação sabe encontrar o novo primário?
- Desempenho. Quais consultas consomem a maior parte do tempo, quais índices faltam, quais sobram.
- Configuração. Parâmetros contra o hardware e a carga real.
- Manutenção. Limpeza automática acompanhando, inchaço, idade de transações.
- Segurança. Acesso por rede e por usuário, cifragem, privilégio mínimo.
- Versão. Dentro do ciclo suportado? Qual o plano de atualização?
- Monitoramento. O que é observado, o que dispara alerta, quem recebe.
O resultado é uma lista priorizada por risco. E, na nossa experiência, os dois primeiros itens quase sempre concentram os achados mais sérios — e são os mais rápidos de corrigir.
O sinal de que chegou a hora
Se três ou mais destes são verdade, a sustentação já deveria ter dono:
- Ninguém sabe dizer quando o backup foi restaurado pela última vez.
- Lentidão é resolvida reiniciando o banco.
- Nunca se testou o failover.
- A versão está fora do ciclo de suporte.
- Uma única pessoa sabe operar o banco.
- Não há monitoramento além de CPU e disco.
- O último ajuste de parâmetros foi na instalação.
- Existem índices que ninguém sabe se podem ser removidos.
- Um incidente de banco no ano passado levou mais tempo do que deveria.
Erros comuns
- Deixar o banco sem dono formal até o primeiro incidente grave.
- Contratar DBA em tempo integral para trabalho de meio período, e diluir a especialização.
- Treinar alguém e esperar que resolva sozinha a primeira crise.
- Terceirizar sem escopo escrito.
- Contratar sem definir tempo de resposta por severidade.
- Não definir se o sobreaviso está incluído.
- Terceirizar as decisões de negócio junto com a operação.
- Não exigir transferência de conhecimento no contrato.
- Não perguntar as condições de saída antes de assinar.
- Não começar por um diagnóstico do estado atual.
- Aceitar relatório que não mostra o que foi encontrado e recomendado.
Onde a Solvefy/Cloud entra
Nossa consultoria de bancos de dados opera nos dois formatos. Sob demanda, por hora, com escopo definido — diagnóstico, tuning, revisão de índices, implantação de alta disponibilidade, migração, upgrade de versão. E sustentação contínua, com monitoramento das métricas que antecipam problema, backup com restauração testada e cronometrada, manutenção preventiva, atendimento de incidente e relatório periódico do que foi feito e do que recomendamos.
Em ambos, a transferência de conhecimento está no escopo: documentação, runbooks e repasse ao seu time. Trabalhamos com PostgreSQL, MariaDB, MongoDB, Redis e Elasticsearch, em infraestrutura própria ou em nuvem.
Quer saber em que estado o seu banco está antes de decidir? Fazemos um diagnóstico gratuito, sem compromisso, em solvefy.cloud.
Solvefy/Cloud — Infraestrutura que cresce com você.