Runbooks de Incidentes: Como Documentar Respostas para Downtime, Banco e Segurança

Na crise, ninguém quer procurar comando em conversa antiga

Incidentes exigem clareza. Quando o site cai, o banco trava ou um alerta de segurança dispara, a equipe precisa saber o que verificar, quem acionar e como reduzir impacto. Runbooks são documentos práticos com passos de resposta para cenários conhecidos.

Empresas que usam VPS, dedicados, bancos e múltiplos serviços ganham muito com runbooks simples. Eles reduzem dependência de uma pessoa e evitam improviso durante pressão.

O que incluir

• Sintoma e alerta relacionado.
• Impacto esperado no negócio.
• Primeiros comandos de diagnóstico.
• Critérios para escalar.
• Procedimento de mitigação.
• Links para dashboards e logs.
• Como comunicar clientes ou equipe.

Exemplos de runbooks

Disco cheio, certificado vencendo, DNS errado, erro 500, banco sem conexão, fila acumulada, ataque de força bruta e backup falhando são bons primeiros temas. Cada runbook deve ser curto, testável e atualizado depois de incidentes reais.

Pós-incidente

Depois da crise, revise o runbook. O que faltou? Qual comando estava errado? Qual alerta chegou tarde? A melhoria contínua transforma incidente em aprendizado.

Como escrever sem burocracia

Um bom runbook não é manual genérico. Ele precisa responder uma situação concreta. Use frases diretas, comandos testados, links atuais e critérios claros de parada. Se o procedimento depende de senha, acesso VPN ou painel específico, diga isso antes dos passos de mitigação. Durante incidente, descobrir falta de permissão no meio do processo custa tempo.

Inclua também sinais de perigo. Por exemplo: se o banco está com replicação atrasada, não promover réplica sem confirmar último binlog; se o disco encheu, não apagar logs de auditoria sem preservar evidência; se há suspeita de invasão, não reiniciar tudo antes de coletar dados mínimos. Runbook bom evita ações impulsivas.

Treinamento e dono

Cada runbook deve ter responsável. Sem dono, ele envelhece. Faça simulações curtas, especialmente para backup, restauração, troca de certificado e falha de banco. O objetivo não é criar teatro, mas revelar dependências escondidas antes que elas apareçam em produção.

Referência

O SRE Book é referência neutra para práticas de confiabilidade e resposta a incidentes.

Conclusão

Runbooks não precisam ser longos. Eles precisam funcionar. Comece pelos incidentes mais prováveis e mantenha o material vivo. Em operação real, documentação prática vale mais que memória.