Runbook de incidentes para DBA em produção.
Uma réplica atrasada durante o fechamento financeiro, um pico de conexões que esgota o pool ou uma corrupção detectada em uma tabela crítica não são eventos para serem resolvidos por memória, tentativa e erro ou mensagens dispersas em um grupo de chat. Um runbook de incidentes para DBA transforma pressão operacional em uma sequência controlada de decisões: detectar, classificar, conter, recuperar, validar e registrar.
Em ambientes transacionais, cada minuto de indisponibilidade pode interromper vendas, pagamentos, atendimento e processos internos. Mas o custo real não está apenas no downtime. Uma ação mal executada durante a crise pode ampliar a perda de dados, comprometer evidências, violar requisitos de conformidade ou criar uma falha recorrente que voltará no próximo pico. O runbook existe para eliminar improviso quando o ambiente mais exige senioridade.
O que um runbook precisa resolver na prática
Um runbook não é uma coleção de comandos SQL nem um documento genérico de continuidade de negócios. Ele é um procedimento operacional acionável, construído para um banco, uma arquitetura e uma criticidade específicos. Deve indicar quem atua, quais sinais confirmam o incidente, que riscos precisam ser evitados e qual é o critério objetivo para encerrar a ocorrência.
O objetivo não é engessar o DBA sênior. Incidentes complexos exigem diagnóstico e julgamento técnico. O documento reduz o tempo gasto com perguntas básicas e protege a operação contra decisões perigosas tomadas sem contexto, como reiniciar um serviço antes de preservar logs, promover uma réplica desatualizada ou restaurar um backup sem validar o ponto de recuperação.
Para uma operação crítica, o runbook precisa conversar com o monitoramento, a matriz de escalonamento, a política de backup, o plano de disaster recovery e a documentação da arquitetura. Se esses elementos vivem em lugares diferentes e nunca foram testados juntos, a empresa tem documentação, mas não tem prontidão.
Estrutura de um runbook de incidentes para DBA
O formato deve ser padronizado, mas o conteúdo muda conforme o motor de banco, a topologia, os objetivos de RPO e RTO e as dependências do aplicativo. PostgreSQL, MySQL, SQL Server, Oracle e bancos gerenciados em cloud têm procedimentos, limitações e mecanismos de recuperação distintos. Copiar um modelo pronto sem adaptá-lo ao ambiente é apenas uma forma organizada de falhar.
1. Identificação e criticidade do incidente
Todo runbook começa com o nome do cenário e sua condição de disparo. “Banco lento” não é uma definição operacional. “Latência de consultas acima de 2 segundos por cinco minutos, com saturação de CPU e aumento de conexões ativas” já oferece um ponto de partida verificável.
A classificação de severidade deve refletir impacto de negócio e não apenas métricas técnicas. Uma degradação em uma base analítica pode ser relevante, mas uma falha de escrita na base de pagamentos exige resposta imediata. Defina, no mínimo, quatro níveis:
- Sev 1: indisponibilidade total, risco de perda de dados ou interrupção de processo crítico.
- Sev 2: degradação severa com impacto relevante em clientes ou receita.
- Sev 3: falha parcial, sem interrupção ampla, mas com risco de evolução.
- Sev 4: alerta operacional ou anomalia sem impacto imediato.
O runbook deve apontar o dono técnico, o responsável pela comunicação e os contatos para escalonamento. Durante um Sev 1, o DBA não deve dividir atenção entre investigar bloqueios e responder repetidamente a solicitações de status. Funções claras preservam velocidade e qualidade técnica.
2. Triagem antes de qualquer mudança
A primeira fase deve responder a três perguntas: o que falhou, qual é o escopo e o que mudou antes do evento. O DBA verifica disponibilidade do host ou serviço gerenciado, erros nos logs, consumo de CPU, memória, I/O, espaço em disco, conexões, locks, replicação, latência de rede e comportamento das consultas mais caras.
A correlação com mudanças recentes é obrigatória. Um deploy, uma migração, uma alteração de índice, uma política de autoscaling ou uma rotação de credenciais pode explicar o incidente em minutos. Sem essa checagem, a equipe corre o risco de tratar sintoma e manter a causa ativa.
O runbook precisa determinar quais evidências são coletadas antes de intervenções destrutivas. Planos de execução, sessões bloqueadoras, métricas de disco, logs do banco, logs do sistema e posição de replicação são exemplos frequentes. A regra é simples: preserve dados diagnósticos suficientes para investigar a causa raiz depois da estabilização.
3. Contenção com menor risco possível
Conter não significa necessariamente reiniciar. Em muitos incidentes, a melhor primeira ação é reduzir a pressão sobre a camada de dados: limitar uma funcionalidade do aplicativo, pausar um job pesado, cancelar consultas específicas, bloquear uma origem de conexões anômalas ou direcionar leituras para réplicas saudáveis.
Cada ação deve trazer pré-requisitos, comando ou procedimento aprovado, impacto esperado, limite de tempo e condição de reversão. Também precisa informar o que não fazer. Em um cenário de replicação atrasada, por exemplo, promover uma réplica sem confirmar o atraso pode trocar indisponibilidade por inconsistência de dados.
Há trade-offs reais. Cancelar uma consulta pode liberar recursos rapidamente, mas interromper uma transação de negócio. Aumentar temporariamente a capacidade pode sustentar o pico, mas mascarar uma regressão de consulta. O DBA sênior avalia essas escolhas, enquanto o runbook torna os limites e riscos explícitos para toda a equipe.
4. Recuperação orientada por RPO e RTO
Quando a contenção não resolve, o runbook entra na etapa de recuperação. Aqui não existe espaço para promessas vagas como “restaurar o backup se necessário”. O procedimento deve indicar qual backup usar, onde ele está, como validar integridade, como restaurar em ambiente isolado e quem aprova a troca para produção.
Também é preciso documentar o RPO e o RTO aceitos para cada serviço. Se o RPO é próximo de zero, uma restauração para o último backup pode ser inaceitável, exigindo recuperação por logs de transação ou binlogs. Se o RTO é de minutos, um restore completo em uma base de vários terabytes talvez não seja uma estratégia viável. A arquitetura precisa sustentar o compromisso assumido.
Para failover, o runbook deve incluir validação de saúde da instância candidata, atraso de replicação, integridade de escrita, atualização de endpoints, impacto em conexões persistentes e plano de fallback. Failover não termina quando o novo primário sobe. Termina quando o aplicativo opera normalmente e a proteção de dados foi restabelecida.
Validação e comunicação fazem parte da resolução
Declarar o incidente como resolvido apenas porque o alerta parou é um erro comum. O runbook deve exigir validação técnica e funcional: disponibilidade do banco, taxa de erros, latência, filas, replicação, backups, métricas de capacidade e jornadas críticas do aplicativo. Se a causa foi uma query regressiva, a confirmação deve incluir a estabilidade após a correção, não só a queda momentânea no uso de CPU.
A comunicação precisa ter cadência definida. Em incidentes severos, os decisores precisam saber impacto, ações em andamento, risco de dados e próxima atualização. Não precisam receber hipóteses técnicas sem confirmação. Uma mensagem curta, factual e recorrente reduz ruído e permite que o time de banco continue operando.
Após a normalização, o DBA registra linha do tempo, sintomas, evidências, decisões, comandos executados, impacto, causa raiz e ações preventivas. Esse registro alimenta a revisão pós-incidente e a evolução do próprio runbook. Um procedimento que não muda depois de uma falha real envelhece rápido.
Teste o runbook antes da madrugada crítica
Um runbook não validado é uma hipótese. A empresa deve testar cenários controlados de indisponibilidade, perda de conectividade, exaustão de disco, bloqueios, falha de réplica, restore e failover. O teste mede não apenas se o banco volta, mas se o time encontra o documento, executa as etapas certas, aciona as pessoas corretas e cumpre RPO e RTO.
A frequência depende da criticidade e da velocidade de mudança do ambiente. Fintechs, e-commerces e plataformas transacionais com releases frequentes precisam revisar procedimentos de forma contínua. Ambientes mais estáveis ainda exigem testes periódicos, especialmente após mudanças de versão, topologia, cloud ou estratégia de backup.
A HTI Tecnologia estrutura operações de banco de dados críticas com monitoramento 24/7, documentação operacional e atuação de DBA sênior para que a resposta não dependa de disponibilidade individual ou conhecimento informal. Em produção, continuidade não é uma intenção. É uma capacidade construída, documentada e testada antes do incidente.
O melhor momento para criar ou revisar um runbook é quando o ambiente está saudável e as decisões podem ser tomadas com calma. Quando o alerta crítico disparar, a organização não precisará procurar um especialista, um comando ou um backup. Precisará apenas executar um processo que já provou funcionar.