Runbook

É um documento com procedimentos passo a passo para situações operacionais previstas: o que fazer quando o fornecedor de modelo cai, quando a taxa de alucinação sobe, quando o custo dispara, como fazer rollback de um prompt, como reindexar a base. É escrito antes do incidente, com calma, para ser seguido sob pressão, quando não há tempo de pensar. Toda capacidade em produção deveria ter um runbook para seus cenários de falha mais prováveis.

Em Produto, vale garantir que cada capacidade tenha runbook para os 3 a 5 cenários mais prováveis, incluindo quem decide desligar (kill switch) e como comunicar aos usuários. O time de Produto contribui com o critério de negócio: quando é aceitável degradar para um fallback e quando é melhor ficar indisponível. Essa decisão não pode ser tomada às 3 da manhã por quem está de plantão. Por exemplo, o runbook “fornecedor indisponível”: o circuit breaker ativa o fallback em 30 segundos; se durar mais de 2 horas, mensagem ao usuário e aviso ao time de atendimento.

Use runbook para cenários previstos, com procedimento definido. Use post-mortem para os imprevistos, que geram novos runbooks. Use kill switch como o procedimento de emergência que todo runbook deve referenciar. Uma forma simples de diferenciar: runbook é o plano para o que se sabe que pode acontecer; post-mortem é o aprendizado com o que aconteceu sem plano.

Operações de TI e SRE; documentação de procedimentos operacionais padrão.

Google SRE Book, Managing Incidents; Google SRE Workbook, On-Call