APRENDER. PRATICAR. EVOLUIR.Conservar a incerteza sobre o início
O fixture estabelece explicitamente que o impacto começou entre 08:57 e 09:00 UTC. A recuperação foi validada às 09:35, pelo que a duração está entre 35 e 38 minutos. A deteção às 09:07 ocorreu sete a dez minutos após o início; o acknowledgement às 09:10 demorou três minutos desde a deteção. São medidas diferentes. Não transformes um único incidente numa média nem uses MTTR sem definir as fronteiras. Estes limites foram dados pelo exercício: dois resultados isolados de uma probe não garantem automaticamente que todo o impacto ficou entre eles. Num relatório real, indica como conheces o início, quais operações foram observadas e que lacunas permanecem.
Atualizar a previsão quando a taxa muda
O backlog começa em 600 trabalhos. Entram quarenta por minuto e terminam cem trabalhos distintos por minuto, dando redução líquida de sessenta e projeção inicial de dez minutos. Após quatro minutos restam 360. Se as conclusões descem para setenta e as entradas se mantêm, a redução passa a trinta: são necessários mais doze minutos, ou dezasseis desde o início. Ao minuto oito ainda restam 240. O script reproduz estas duas fases com aritmética exata. Não é um benchmark nem um modelo completo de filas. Usa a projeção como condição para decidir e volta a medi-la quando carga, mistura ou capacidade mudarem. Uma estimativa antiga não se torna compromisso técnico por ter sido comunicada.
Avaliar o impacto deslocado pela admissão
Num cenário alternativo desde o início, admitir dez dos quarenta trabalhos por minuto deixa noventa conclusões líquidas por minuto, se a capacidade de cem se mantiver. Os 600 trabalhos escoam em 20/3 minutos, cerca de 6.67. Porém, trinta trabalhos por minuto foram adiados ou rejeitados. O gráfico da fila melhora porque parte da procura deixou de entrar; não demonstra serviço totalmente restabelecido. Define o que acontece a essa procura, quem acompanha o resultado e quando a admissão normal pode regressar. Se o prazo exige 115 conclusões por minuto e o destino só foi ensaiado até 110, aumentar workers não prova capacidade adicional. A decisão deve mostrar limites e consequências.
Contar o custo das tentativas adicionais
Quarenta pedidos de negócio com três tentativas cada oferecem 120 tentativas por minuto. Num destino que suporta cem tentativas por minuto, a carga oferecida excede a capacidade do fixture. Não confundas tentativas, conclusões válidas e pedidos distintos. Retentar imediatamente durante saturação pode consumir os recursos necessários para recuperar. Além disso, um timeout não prova que o destino deixou de executar a operação. Avalia limites, intervalos, comportamento dos clientes e segurança da repetição antes de alterar a política. Num fluxo fictício de instruções financeiras, resultados incertos precisam de reconciliação e identidade estável apropriada ao contrato. O exercício calcula amplificação; não implementa retries nem recomenda valores universais de backoff.
Verificar a atualidade do sinal verde
Às 09:20, o painel conserva healthy com observação das 09:15. A idade é trezentos segundos e ultrapassa o limite fictício de sessenta. A evidência não confirma o estado atual, mas também não prova por si uma indisponibilidade: serviço e observabilidade podem falhar de formas diferentes. Pede uma observação atual e uma validação funcional adequada. Não interpretes ausência de novos alarmes como ausência de impacto quando a recolha pode ter parado. Regista o instante do acontecimento medido e o da consulta do painel, para distinguir dado antigo de apresentação atual. O limite de sessenta segundos pertence ao exercício e não é um SLA de qualquer banco ou fornecedor.
Preparar uma atualização que permita decidir
Escreve uma atualização curta com operação afetada, backlog relevante, taxa observada, hipótese da projeção, ação em curso e próximo ponto de informação. No minuto quatro do fixture, a projeção é mais doze minutos se setenta conclusões e quarenta entradas se mantiverem; o cut-off ao minuto oito não será cumprido por esse caminho. Esta informação permite ao negócio avaliar alternativas. Não confundas o horário da próxima atualização com uma promessa de recuperação. Se prometeste atualizar às 09:25, podes cumprir esse compromisso mesmo com ETA ainda indeterminado. Usa linguagem adequada ao destinatário e mantém evidência técnica detalhada no registo de acesso apropriado, sem copiar dados de clientes para a comunicação geral.
python3 content/labs/incident-evidence/run.py
# Initial backlog: 600; arrivals: 40/min; completions: 100/min
# Minute 4: 360 remain; completions fall to 70/min
# Minute 8: 240 remain; revised total projection: 16 minutes
# All values are synthetic assumptions, not measured production capacity.Um serviço fictício de fundos volta a receber instruções, mas as entregas continuam atrasadas. A equipa recalcula a projeção e distingue receção recuperada, escoamento em curso e risco do cut-off.
Armadilhas comuns
Usar a previsão antiga após queda de capacidade, esconder procura rejeitada, contar retries como trabalho útil e confiar numa etiqueta saudável com observação antiga.
Tópicos relacionados: Monitoring and Observability · Production Support L3 · Problem Management
Uma mitigação pode melhorar uma métrica e manter impacto noutro ponto. Comunica resultados por operação, com população, atualidade e hipóteses visíveis.
Referência: Handling overload · Incident management practices 2026-09; scoped Google SRE, PagerDuty and Atlassian examples