APRENDER. PRATICAR. EVOLUIR.Começar pela operação e pelo denominador
Um dashboard responde a uma pergunta definida pela consulta, não a todas as perguntas do incidente. Antes de citar uma taxa, identifica a operação, o ponto de medição, a janela e a unidade: tentativa, pedido aceite, intenção ou resultado consumido. No conjunto original desta oficina, east tem 100 pedidos e 40 erros; west tem 900 pedidos e nove erros. O total é 49 em 1000, ou 4,9%. A média simples de 40% e 1% daria 20,5%, porque atribui o mesmo peso a grupos com volumes diferentes. Mantém o total correto e a divisão por grupo. Se east serve o relatório do cut-off, uma pequena proporção do volume pode concentrar grande consequência operacional.
Filtros e ausência alteram a leitura
O p95 também depende da população. O guião calcula nearest rank sobre valores sintéticos: em east, o p95 apenas dos sucessos é 120 ms; incluindo as falhas lentas, é 6000 ms. Não há contradição entre os cálculos, mas seria incorreto usar o primeiro para declarar que todas as tentativas são rápidas. Depois do desvio, east deixa de ter pedidos. A consulta devolve contagem zero e percentagem NULL; não observou zero por cento de falhas numa população positiva. Regista sem amostra e procura uma verificação representativa da operação. Uma sonda online positiva não demonstra que o arquivo de fecho é produzido e consumido. A cobertura deve acompanhar a consequência que motivou a resposta.
Enriquecimento não cria novos pedidos
A oficina associa etiquetas aos pedidos: east recebe duas e west recebe uma. A junção devolve 1100 linhas para 1000 pedidos; somar os erros dessas linhas produz 89 em vez de 49. O erro surge porque uma linha deixou de representar um pedido. COUNT(DISTINCT r.id) corrige o denominador, mas não corrige automaticamente um numerador que ainda soma linhas repetidas. Conta também identificadores distintos que falharam ou agrega os pedidos antes de enriquecer. Mantém um teste com resultado conhecido para detetar regressões na consulta. Em trabalho APS, esta inspeção é útil quando logs, inventário, equipas e etiquetas são combinados num relatório. Mais contexto deve melhorar a interpretação sem alterar silenciosamente a unidade da medição.
Preservar o que se sabia em cada decisão
O evento B da oficina ocorre aos 120 segundos e chega ao coletor aos 420. Aos 300 segundos, a equipa conhece A e C; aos 600, sabe que B também pertence à primeira janela. Guarda ocorrência, chegada e instante do relatório. Atualiza a contagem com uma revisão explícita, preservando o que estava disponível para a decisão anterior. Para janelas adjacentes, o predicado início incluído e fim excluído coloca o evento aos 300 segundos apenas na segunda janela. A consulta por tempo de chegada responde a outra pergunta. O guião executa estas consultas em SQLite em memória sobre dados inventados; não reproduz relógios de produção nem prova sincronização real. Usa os resultados para preparar uma investigação e assinalar limites da cronologia.
python3 content/labs/incident-analysis/run.py --output /tmp/dr-incident-analysis.json
# SQL used in the synthetic in-memory dataset:
# SELECT region, COUNT(*) n, SUM(1-ok) errors
# FROM requests WHERE phase='incident' GROUP BY region;O conjunto fictício tem 49 erros em 1000 pedidos, mas 40 dos 100 pedidos east falham perto do cut-off.
Armadilhas comuns
Fazer médias de percentagens, confundir ausência com saúde, contar linhas enriquecidas como pedidos e apagar revisões.
Tópicos relacionados: Monitorização e observabilidade · Mitigação e passagem para RUN
Uma taxa só é útil quando se conhece o que conta, quem ficou de fora e quando a observação estava disponível.
Referência: Monitoring · Incident management practices 2026-09; scoped Google SRE, PagerDuty and Atlassian examples