O runbook de disaster recovery é o documento que alguém vai abrir às 3h da manhã, sob pressão, possivelmente sem ser a pessoa que o escreveu. Isso deveria definir tudo sobre como ele é redigido — e quase nunca define. A maioria dos runbooks é escrita para quem já sabe, e por isso não serve no momento em que é preciso.
O teste que todo runbook deveria passar
Entregue o documento a um técnico competente que não participou da montagem do ambiente e peça para executar sem perguntar nada a ninguém. Se ele travar, você não tem um runbook: tem uma anotação que funciona porque o autor está disponível.
Esse é o problema central. Plano de DR que depende de uma pessoa específica estar acessível tem um ponto único de falha que nenhuma redundância de infraestrutura resolve.
O que precisa estar dentro
Critério de acionamento
O que caracteriza desastre, em termos objetivos. “Indisponibilidade do sistema X por mais de N minutos confirmada por duas fontes” é acionável. “Falha grave” não é — e sob pressão, ambiguidade vira paralisia.
Autoridade de decisão
Nome, cargo, telefone e a cadeia de substituição. Quem decide se o primeiro da lista não responde em quinze minutos, e quem decide se o segundo também não. Sem isso, o failover espera por uma reunião que não vai acontecer de madrugada.
Ordem de retomada
Não a lista de sistemas: a sequência, com as dependências explícitas. Autenticação antes de aplicação, banco antes de serviço, DNS antes de tudo que resolve nome. Subir na ordem errada gera erro que parece falha de infraestrutura e consome horas de diagnóstico.
Credenciais e acesso
Onde estão, como obtê-las, e quem tem acesso de emergência. Runbook que depende de um cofre de senhas hospedado no ambiente que caiu é um problema que só aparece no pior momento possível.
Procedimento de failback
Como voltar, incluindo a sincronização dos dados gerados durante a contingência. É a seção mais frequentemente ausente e a que causa mais perda de dado — muitas equipes recuperam bem e perdem informação na volta.
Comunicação
Quem avisa clientes, quem avisa o time, quem fala com a imprensa se aplicável, e o texto base de cada mensagem. Redigir comunicado durante crise produz comunicado ruim.
Erros que tornam o runbook inútil
- Guardar só no ambiente que pode cair. Precisa existir cópia acessível de fora — inclusive impressa, se o cenário considerado for severo.
- Escrever em prosa contínua. Passo numerado, um comando por linha, resultado esperado indicado. Ninguém lê parágrafo sob pressão.
- Referenciar sem versionar. “Conforme documentação da arquitetura” só funciona se essa documentação estiver atualizada, o que raramente é verdade.
- Não registrar a data da última validação. Runbook sem data é runbook de credibilidade desconhecida.
Manutenção é o que separa documento de ficção
O runbook precisa ser revisado a cada mudança de arquitetura e validado em cada exercício de DR. O exercício, aliás, é o melhor mecanismo de manutenção que existe: todo passo que alguém resolveu de cabeça durante o drill é uma lacuna que precisa entrar no documento antes do próximo.
Um runbook que passou por três exercícios e foi corrigido depois de cada um vale mais que um documento de cem páginas nunca exercitado.
Onde a Adentro entra
Nos ambientes de disaster recovery que operamos, o runbook é entregável do projeto, não anexo opcional — e é atualizado junto com o ambiente. Nosso time técnico participa da definição da ordem de retomada e das dependências, que é a parte que exige conhecer a infraestrutura de verdade.