DBA autônomo:
RCA e correção guiada para incidentes de banco

O custo de não ter DBA

DBA dedicado é raridade fora de empresa grande. Na prática, o banco de dados do seu SaaS é responsabilidade difusa: do backend, do DevOps, de quem respondeu o alerta primeiro. E incidente de banco tem duas propriedades cruéis. Primeira: ele derruba tudo ao mesmo tempo — não existe "só um serviço afetado" quando o banco trava. Segunda: o diagnóstico exige um conhecimento que o time não exercita no dia a dia — locks, planos de execução, comportamento de pool, limites de conexão.

O resultado típico é mitigação às cegas. Reinicia a aplicação, sobe o tier da instância, torce. Às vezes o sintoma some. Quase nunca a causa é entendida — e o incidente volta, porque a causa continua lá. Cada rodada dessas custa duas vezes: o downtime em si e as horas de engenharia queimadas em diagnóstico sob pressão.

Contratar não resolve na escala típica de um SaaS: um DBA sênior custa mais do que a infraestrutura inteira que ele cuidaria, e o volume de trabalho não fecha uma vaga. O meio-termo real em que a maioria vive é este: ninguém é DBA — até o banco cair, quando todo mundo é.

O que o DBA autônomo monitora

O DBA autônomo do Catcher Data acompanha continuamente os sinais operacionais da sua instância do Database: conexões ativas e sua tendência, latência de queries, locks e esperas, uso de disco e memória, taxa de erros. O objetivo não é gerar mais um dashboard para você ignorar — é correlacionar sinais e transformá-los em algo acionável quando o padrão indica problema real.

Quando isso acontece, ele abre um incidente no console. Não um alerta cru de threshold, mas um registro estruturado: o sinal que disparou, o RCA — a análise de causa raiz, em texto legível — e a correção sugerida.

O comportamento é configurável por instância. O banco de produção que atende cliente final pode operar com sensibilidade alta; a instância de staging, com tolerância maior — ou com o monitoramento desligado. Sensibilidade é decisão de operação, não constante universal, e instâncias diferentes carregam perfis de risco diferentes.

Anatomia de um incidente

Todo incidente carrega os mesmos campos, sempre na mesma estrutura. É um contrato de formato: você aprende a ler uma vez e lê todos.

Campo	O que contém	Exemplo
Sinal	A métrica que disparou e a trajetória dela	"Conexões ativas em 92% do limite, crescendo de forma sustentada há 40 minutos"
RCA	A causa raiz em texto legível, com o encadeamento entre causa e sintoma	"Pool dimensionado acima do limite da instância quando somado entre réplicas; um endpoint segura conexões com padrão N+1"
Evidência	Os dados que sustentam o RCA	Amostra de queries do intervalo, conexões por origem, série temporal do sinal
Correção sugerida	A ação proposta, com escopo e reversibilidade explícitos	"Redimensionar o limite de conexões e o pool; colapsar o N+1 em uma única query"
Estado	Onde o incidente está no fluxo de decisão	Aberto, reconhecido, resolvido ou dispensado

O campo que muda o dia de quem opera é o RCA. Alerta tradicional entrega o sintoma e para por aí; o incidente entrega a interpretação — o que está causando o quê, em qual ordem, com a evidência anexada. A distância entre "CPU alta" e "a query do endpoint de relatórios passou a fazer full scan depois que a tabela cruzou dez milhões de linhas" é a distância entre começar uma investigação e terminá-la.

Quatro ações, uma regra

Todo incidente segue o mesmo fluxo: sinal → RCA → correção sugerida → decisão sua. A decisão é o centro do desenho. Para cada incidente aberto, o console oferece quatro ações:

Ação	O que faz	Quando usar
Aplicar fix	Executa a correção sugerida na instância	O RCA bate com o que você observa e a correção proposta é a certa
Reconhecer	Marca que alguém está investigando, sem executar nada	Você quer validar o diagnóstico antes de mexer em produção
Resolver	Fecha o incidente como tratado	Você corrigiu por outro caminho, ou a causa foi eliminada
Dispensar	Descarta o incidente	Falso positivo, ou um risco que você aceita de forma consciente

Uma regra atravessa as quatro: nada é aplicado sem comando seu. O DBA autônomo nunca executa uma correção por conta própria.

Explica antes de agir

Automação de infraestrutura costuma falhar em um de dois extremos. Ou é um alerta burro — "CPU alta" — que joga todo o diagnóstico no seu colo às três da manhã. Ou é uma caixa-preta que corrige coisas sozinha e você descobre a mudança depois, lendo log de auditoria.

O DBA autônomo foi desenhado para o meio-termo que funciona: ele faz o trabalho de diagnóstico — correlaciona sinais, identifica a causa raiz, formula a correção — e apresenta o raciocínio completo antes de qualquer ação. Você lê o RCA, confere contra o que está vendo e decide. É essa transparência que constrói confiança com o tempo: você aprende como ele raciocina porque ele mostra o raciocínio, incidente após incidente. Automação que não explica só é tolerada enquanto acerta.

Um incidente narrado: conexões no limite

O primeiro exemplo do fluxo completo, do tipo que aparece em produção.

Sinal. O número de conexões abertas cresce de forma sustentada e se aproxima do limite da instância. A aplicação começa a receber erros de conexão intermitentes — o pior tipo de erro, porque some no retry e volta no pico.

RCA. O incidente aberto aponta duas causas encadeadas. A primeira: o pool da aplicação está dimensionado para abrir mais conexões do que a instância comporta quando somado entre as réplicas do serviço — cada deploy que escala horizontalmente aperta mais o limite. A segunda: um endpoint específico segura conexões por mais tempo do que deveria. O padrão de queries no intervalo indica N+1 — sequências de consultas curtas e idênticas dentro do mesmo request, cada uma ocupando conexão enquanto a resposta é montada.

Correção em dois níveis. A sugestão separa mitigação de causa raiz. Nível um, imediato: redimensionar o limite de conexões e o pool para estancar os erros — aplicável pelo console. Nível dois, estrutural: colapsar o N+1 em uma única query, com a evidência anexada ao incidente para virar item de backlog com contexto, não com achismo.

Você aplica o nível um com um clique, marca o incidente como reconhecido enquanto o time trata o nível dois, e resolve quando o endpoint for corrigido. O incidente preserva a evidência e as decisões tomadas ao longo do caminho.

Um segundo incidente: disco crescendo em silêncio

Nem todo incidente é um pico. Alguns são retas — e retas são traiçoeiras porque não disparam alerta de threshold até ser tarde demais.

Sinal. O uso de disco da instância cresce a uma taxa constante há semanas. Nenhum limite foi cruzado ainda, mas a projeção da curva encontra a capacidade da instância em poucas semanas. O incidente abre antes do sufoco, com a projeção anexada — tempo de sobra para uma decisão calma, não uma madrugada de emergência.

RCA. O crescimento não é orgânico. Uma única tabela — o log de eventos da aplicação — responde pela maior parte do delta, crescendo gigabytes por dia. Não há rotina de purga nem política de retenção: a tabela só acumula desde o primeiro deploy. E o padrão de acesso mostra que o app consulta apenas os registros recentes; as linhas antigas são peso morto que ainda assim cobra caro — backup mais longo, índices maiores, scans mais lentos.

Correção em dois níveis. Nível um, imediato: purga controlada das linhas antigas, em lotes, com a estimativa de espaço recuperado anexada. Nível dois, estrutural: um índice parcial cobrindo só as linhas recentes que o app de fato consulta, mais uma política de retenção para a tabela parar de acumular. O nível um estanca o problema; o nível dois impede a reincidência.

Compare os dois incidentes narrados. Um é agudo: conexões se esgotando, minutos para decidir. O outro é crônico: disco enchendo, semanas de antecedência. O contrato é o mesmo nos dois — sinal, RCA legível, correção proposta, decisão sua. É isso que torna o formato aprendível: a urgência muda, a estrutura não.

Quando o DBA autônomo não abre incidente

Tão importante quanto abrir o incidente certo é não abrir o errado. Alerta demais é o caminho mais curto para alerta ignorado — um plantonista que grita por tudo é silenciado em uma semana. Três filtros seguram o ruído:

• Limiar. Sinal abaixo do limiar configurado não abre incidente. Conexões em 60% do limite é informação de dashboard, não incidente — vira incidente quando a trajetória aponta esgotamento.
• Sinal transitório. Um pico que sobe e volta sozinho dentro da janela de observação não vira incidente. Deploy que recicla conexões, batch noturno que consome CPU por vinte minutos — padrões que se resolvem sozinhos não merecem sua atenção às três da manhã.
• Janela de observação. O padrão precisa se sustentar por uma janela antes de virar incidente. É a janela que separa tendência real de ruído de amostragem — o crescimento de conexões do primeiro incidente narrado só virou incidente porque persistiu.

Os três filtros são configuráveis por instância, porque o custo de um falso positivo não é o mesmo em todo lugar. O objetivo final é um só: quando um incidente abrir, ele merecer leitura. Confiança em automação se constrói também assim — pelo que ela decide não dizer.

DBA autônomo e self-tuning: papéis diferentes

O Catcher Data tem duas peças de automação de banco, com divisão clara. O self-tuning é otimização contínua: coleta o workload real, gera findings — índice ausente, flag mal dimensionada —, simula o impacto e aplica com rollback. Ele trabalha fora da crise, no ritmo de uma revisão periódica.

O DBA autônomo é o plantonista: entra quando algo foge do padrão agora, com diagnóstico e correção para o problema presente. Um previne incidentes; o outro responde a eles. E os dois seguem a mesma filosofia: evidência primeiro, explicação antes de ação, decisão final sempre sua.

O que muda na prática

Com um plantonista automático que chega com RCA pronto e correção proposta, o custo de um incidente cai para o que deveria ser: ler, conferir, decidir. O conhecimento específico de banco — a parte que seu time não exercita — vem embutido na plataforma, funcionando sobre instâncias MySQL 8 e PostgreSQL 16 hospedadas no Brasil (região southamerica-east1, em São Paulo), com console em português em data.catcher.one. A configuração por instância e a referência do fluxo de incidentes estão na documentação do Database.