Conceito e mecanismo
Uma mitigação reduz impacto sem necessariamente eliminar a causa. Escolhe uma ação compatível com evidência, runbook e autoridade, identificando pré-condições, âmbito, riscos, critérios de interrupção e recuperação. Não mistures várias mudanças sem conseguir atribuir resultados. Reiniciar um processo pode libertar recursos mas também perder evidência ou interromper trabalho; a decisão precisa de contexto. Um timeout numa operação com efeitos não prova que a operação falhou antes de produzir resultado. Antes de repetir, correlaciona identidade e estado, confirma garantias de idempotência e limita tentativas. O restabelecimento técnico deve ser acompanhado de validação do trabalho pendente.
Aplicação guiada
Num exercício, chegam 120 tarefas por minuto e concluem-se 150 depois de uma mitigação. Com 900 tarefas pendentes e taxas constantes, sem retries nem outras entradas, a fila demora 30 minutos a escoar: a redução líquida é 30 por minuto. Este cálculo não prova cumprimento de prazo se a carga mudar. Verifica erros, latência, frescura dos dados e resultados do consumidor. Em PostgreSQL 18, uma sessão active com wait_event preenchido pode estar bloqueada numa espera; não concluas que consome CPU continuamente. A observação de locks pode justificar escalada à equipa de bases, sem terminar sessões por iniciativa não autorizada.
900÷(150−120)=30 minutos, sob as hipóteses declaradas.
Armadilhas comuns
Timeout como ausência de efeito; fila vazia como todos os resultados corretos; várias mudanças simultâneas.
Tópicos relacionados: Triagem orientada ao impacto · Hipóteses e evidências úteis · Diagnóstico por camada
Valida a recuperação técnica e o resultado de negócio separadamente.
Referência: Timeouts retries and backoff with jitter · Operational support; PostgreSQL 18, OpenSSL 3.5 and BIND 9.20.29 examples; reviewed 2026-09-30