Responder a um incidente

Objetivo: responder a uma falha de forma consistente, sem improviso — cada tipo de incidente tem um runbook (passo a passo) próprio.

O padrão

1. Identificar — qual entrega falhou? Para qual atleta/assessoria? (geralmente já vem de um alerta de pipeline).
2. Abrir o runbook do tipo de incidente.
3. Diagnosticar antes de agir — confirmar o estado real (o dado existe? foi enviado? o canal está certo?) antes de reenviar.
4. Corrigir e confirmar — executar a correção e validar que a entrega aconteceu de fato (não basta “rodou”).

Runbooks que existem

Situação	Resposta, em resumo
Análise não chegou ao aluno	Conferir se a análise existe e se foi enviada; validar o canal correto; reenviar respeitando a assessoria.
Falha no provedor de IA	Conferir os registros; o sistema já tem fallback automático; se persistir, escalar.
Webhook do canal falhando	Validar o segredo/configuração e reenviar.
Veredito semanal sem resposta	É o atleta que responde (até domingo); o fallback é automático. O ops não responde pelo atleta.
Canary de periodização	Abrir/monitorar/reverter com os scripts controlados e a janela definida.

Regra de ouro

Diagnóstico antes de opinião. Não reenvie no escuro: confirme o estado real primeiro. E valide o artefato final (a mensagem chegou?), não só “o script rodou”.

Os runbooks completos ficam na pasta runbooks/ do repositório — cada um com o passo a passo detalhado.