Um runbook de produção para equipas pequenas

Um runbook ajuda a passar de um sintoma específico para uma decisão segura.

Duas torres de servidores ligadas por um percurso interrompido e uma via contínua de recuperação.

Um runbook ajuda a passar de um sintoma específico para uma decisão segura. Não é uma lista de todos os comandos disponíveis. Escreva para alguém com as capacidades esperadas que pode estar cansado ou conhecer pouco o componente.

Começar por sinal e impacto

Indique alerta, percurso afetado e condições de aplicação. Ligue o painel e explique a observação que distingue causas parecidas. Acrescente responsável, data de revisão e escalamento. O documento deve continuar acessível se a aplicação falhar; a sua localização faz parte do desenho operacional.

Definir pré-requisitos e limites

Explique permissões, seleção do ambiente e aprovações para ações importantes. Estabeleça quando dados inexplicáveis, cópia ausente ou resultados contraditórios exigem parar e escalar. Não inclua segredos. Cada passo deve conter propósito, resultado esperado e próxima decisão, incluindo efeito no trabalho em curso.

Incluir confirmação e manutenção

Para reinício, repetição ou comutação, explique duplicados e reversão. Verifique percurso do cliente e trabalho pendente e registe ações e consequências. Outra pessoa deve experimentar a instrução em segurança. Atualize após mudanças e incidentes relevantes. Uma instrução curta testada é mais fiável que um documento longo abandonado.

Um exemplo para validar

Perante uma fila crescente, distinga ausência de trabalhadores, prestador lento e tarefa isolada que falha repetidamente. Reiniciar tudo pode ocultar causa ou provocar mais repetições. Indique a observação que confirma cada ramo e a próxima ação limitada. Outra pessoa deve escolher o caminho correto e verificar fila e resultado comercial. Registe saídas incompreendidas e permissões ausentes como melhorias documentais. A aceitação não é executar todos os comandos: é tomar uma decisão segura com prova suficiente e saber quando parar antes de aumentar o impacto.

Perguntas frequentes

Deve conter comandos?

Sim, revistos e com pré-requisitos, âmbito e resultados esperados.

Qual o comprimento adequado?

O necessário para o percurso concreto, sem detalhes alheios a esconder ações.

Quem deve testar?

Alguém diferente do autor com acessos e capacidades esperados.

E se a realidade divergir?

Pare no limite definido, preserve provas e escale.

Quando atualizar?

Após mudanças, exercícios e incidentes que alterem os pressupostos.

Da ideia a um âmbito que se consegue executar

Partilhe o percurso do utilizador, integrações e condições de lançamento. Podemos preparar uma estimativa com pressupostos e exclusões.

Consultar o âmbito do serviço →