Toda operação de tecnologia já teve a mesma experiência frustrante: um incidente acontece às três da manhã, alguém lembra que existe um runbook para aquela situação, abre o documento e descobre que está desatualizado, incompleto ou escrito de forma tão vaga que não ajuda em nada no momento em que mais precisava ajudar. Rolando Bonaccorsi, diretor de operações da Vert Analytics, considera esse cenário um dos desperdícios mais comuns em operações de tecnologia: tempo investido em documentação que ninguém confia o suficiente para seguir sob pressão real.
A boa notícia é que construir um runbook que efetivamente funciona não exige ferramenta sofisticada, apenas disciplina em seguir alguns passos simples, na ordem certa, sem pular etapas que parecem menos urgentes no início do processo.
Passo 1: escolha os incidentes que realmente consomem tempo da equipe
Tentar documentar cada cenário possível de falha é receita para nunca terminar nada. O ponto de partida mais eficaz é identificar os poucos tipos de incidente que, juntos, consomem a maior parte do tempo da equipe ao longo de um trimestre, geralmente uma fração pequena do total de problemas possíveis.
Rolando Bonaccorsi recomenda revisar o histórico de chamados dos últimos meses antes de escrever qualquer runbook, priorizando os cenários que se repetem com mais frequência. Documentar esses casos primeiro entrega retorno imediato, enquanto tentar cobrir cada possibilidade rara desde o início consome tempo desproporcional ao benefício real que aquele documento específico vai gerar.
Essa priorização também evita um erro comum: começar por um cenário raro e complexo, gastar semanas documentando cada detalhe, e nunca chegar aos incidentes simples e frequentes que efetivamente consomem a maior parte do tempo operacional da equipe no dia a dia.
Passo 2: escreva comandos exatos, não descrições vagas
A diferença entre um runbook útil e um inútil geralmente está no nível de precisão das instruções. “Verificar se o serviço está saudável” não ajuda ninguém às três da manhã; o comando exato a ser executado, com o resultado esperado descrito ao lado, ajuda imediatamente qualquer pessoa de plantão.
Rolando Bonaccorsi observa que essa precisão exige um esforço adicional na hora de escrever, testando cada comando antes de documentá-lo, mas esse esforço inicial se paga muitas vezes, ao longo da vida útil do documento, cada vez que alguém consegue resolver um incidente sem precisar adivinhar o que um passo vago realmente significava na prática.
Passo 3: teste com alguém que nunca viu aquele sistema
O autor de um runbook carrega conhecimento implícito que frequentemente esquece de documentar, porque parece óbvio demais para escrever. Esse é o motivo pelo qual testar o documento com alguém de fora daquele contexto específico revela lacunas que o próprio autor jamais perceberia sozinho.
Rolando Bonaccorsi considera esse teste, conhecido informalmente como maldição do conhecimento, etapa obrigatória antes de considerar qualquer runbook pronto para uso real. Pedir que um colega siga o documento do início ao fim, sem qualquer ajuda verbal complementar, expõe rapidamente cada ponto em que a instrução escrita não é clara o suficiente para alguém sem contexto prévio.
Esse exercício custa pouco tempo comparado ao benefício que gera: uma hora de teste simulado revela lacunas que, sem essa validação, só apareceriam durante um incidente real, exatamente o pior momento possível para descobrir que uma instrução importante ficou subentendida em vez de escrita com clareza suficiente.
Passo 4: revise depois de cada incidente real que o utilizou
Um runbook nunca está definitivamente pronto. Sistemas mudam, dependências evoluem, e um documento que funcionava perfeitamente há seis meses pode já estar parcialmente desatualizado sem que ninguém tenha percebido essa deriva silenciosa ao longo do tempo.
Rolando Bonaccorsi recomenda tratar cada uso real de um runbook durante um incidente como oportunidade de revisão: o que funcionou, o que precisou de improviso, o que já não correspondia à realidade atual do sistema. Incorporar esse aprendizado imediatamente, enquanto ainda está fresco na memória de quem executou o procedimento, mantém o documento genuinamente confiável para a próxima vez que alguém precisar dele sob pressão.
