APRENDER. PRATICAR. EVOLUIR.Escolher a unidade antes de contar
Uma tentativa HTTP, um pedido de negócio e um incidente são unidades diferentes. O fixture contém oito tentativas para quatro pedidos identificados. Seis tentativas não tiveram sucesso; os resultados finais são dois sucessos, uma falha e um desconhecido. A fração 6/8 descreve tentativas e não permite declarar que 75% dos pedidos falharam. Agrupa por identidade de negócio e define qual a evidência que determina o estado final. Um timeout do cliente pode coexistir com execução no destino. No relatório, conserva o desconhecido: uma falha em três resultados resolvidos, com um dos quatro ainda por reconciliar. Não convertas automaticamente esse pedido em sucesso ou falha para completar o gráfico.
Normalizar tempo sem inventar exatidão
O aviso do pool tem 09:04 UTC; o timeout do cliente tem 10:05+01:00, equivalente a 09:05 UTC. A ordem nominal tem um minuto de diferença. Porém, cada relógio pode desviar-se dois minutos e os intervalos possíveis sobrepõem-se. Converter offsets não sincroniza relógios. Guarda o texto original, a referência temporal, o instante normalizado e a incerteza conhecida. Depois procura IDs de correlação, relações entre chamadas ou sequências locais que acrescentem evidência. Casas decimais adicionais indicam resolução de apresentação, não garantem exatidão. Mesmo uma precedência bem demonstrada precisa de um mecanismo plausível e de observações adicionais para sustentar uma explicação causal, sobretudo quando vários componentes estão saturados.
Distinguir registos de duração de impacto
Dois registos descrevem indisponibilidade total do mesmo serviço nos intervalos 0–12 e 8–20 minutos. Somar dá 24, mas os minutos 8–12 aparecem duas vezes. A união mede 20 minutos de indisponibilidade contínua. Mantém ambos os registos para investigar causas e mede o impacto segundo uma definição explícita. Este cálculo pressupõe o mesmo serviço, a mesma janela e indisponibilidade total em ambos os intervalos. Não permite somar indiscriminadamente falhas de serviços diferentes ou calcular utilizadores afetados sem dados dessa população. Se apenas uma função esteve degradada, define a função e o critério antes de calcular. Numa passagem de turno, entrega a cronologia dos eventos e o indicador de impacto com as respetivas unidades.
Comparar coortes quando a mistura muda
Antes, o conjunto tem 10 falhas em 1000 operações simples e 10 em 100 complexas. Depois, tem zero em 100 simples e 90 em 1000 complexas. As taxas por tipo descem de 1% para 0% e de 10% para 9%; o agregado sobe de cerca de 1.82% para 8.18%. Não existe contradição: aumentou muito o peso do tipo mais sujeito a falhar. O impacto real agregado deve ser comunicado. Para uma comparação adicional, uma população hipotética com metade de cada tipo produz 5.5% antes e 4.5% depois. Identifica estes pesos como escolhidos para análise; não substituem o tráfego real nem isolam o efeito causal da release.
Ver a população escondida pelo percentil
O laboratório ordena 1010 latências: 1000 valores de 10 ms e dez de 1000 ms. Pelo método empírico nearest rank, a posição do p95 é ceil(0.95×1010), ou 960. O valor nessa posição é 10 ms, embora todos os pedidos especializados tenham demorado um segundo. Um painel global rápido não invalida a queixa desse cliente. Examina a população correspondente à função afetada e mantém explícitos o número de observações, a janela e o método. A média dos p95 dos dois grupos, 505 ms, não é o p95 conjunto; a média de todas as latências também não é esse percentil. Diferentes ferramentas podem usar convenções distintas, pelo que o método faz parte do resultado.
Preparar um conjunto de evidência reproduzível
O ficheiro fixtures.json contém dados fictícios; run.py calcula oito grupos e evidence.json guarda resultados e hashes. Executa o script num ambiente local com Python e compara os valores antes de escrever uma conclusão. Não acrescentes uma alegação de significância estatística: estes números foram construídos para demonstrar erros de interpretação. Numa investigação real, identifica origem, janela, filtros, unidades, transformações e limitações de cada extrato, respeitando as regras de acesso e retenção aplicáveis. Mantém os dados originais separados das tabelas derivadas e liga cada afirmação à transformação que a produz. Um colega deve conseguir reproduzir o cálculo e perceber que conclusão continua em aberto, sem depender de uma captura de ecrã isolada.
python3 content/labs/problem-evidence/run.py
# attempts: 8; requests: 4; final outcomes: 2 success, 1 failure, 1 unknown
# same-service unavailability: union 20 minutes, event sum 24
# nearest-rank global p95: 10 ms; specialized p95: 1000 msNum serviço fictício de fundos, retries elevam o número de erros HTTP e o tráfego complexo domina o período seguinte. Prepara dois quadros: resultados por pedido e taxas por tipo, mantendo desconhecidos e volumes.
Armadilhas comuns
Contar tentativas como pedidos, resolver desconhecidos por conveniência, confundir UTC com relógios exatos, somar sobreposições e usar um percentil global para excluir uma coorte afetada.
Tópicos relacionados: Monitoring and Observability · Incident Management · REST APIs
Uma conclusão útil conserva unidade, população, tempo e incerteza. Os cálculos podem estar certos e a interpretação continuar errada se o âmbito mudar.
Referência: Effective troubleshooting · Problem management practices 2026-09; ServiceNow Brazil examples with scoped plugins and properties