Medindo Duração: o que exatamente você precisa rastrear
O conceito de "quanto tempo durou" não é uma ferramenta. É uma pergunta fundamental que aparece em dezenas de contextos diferentes. Se você está tentando medir duração de algum processo, seja ele técnico ou do dia a dia, o problema real é bem mais simples e chato do que muitos blogs tentam vender.A primeira coisa que todo mundo erra é não definir onde começa e onde termina o que está sendo medido. Eu perdi duas semanas num projeto de infraestrutura tentando entender por que os números de downtime não batiam entre o monitoramento e os logs da aplicação. O problema? O sistema de monitoramento considerava a falha a partir do primeiro erro no log, mas a aplicação continuava respondendo requisições em cache por mais uns 4 minutos. Tecnicamente estava "no ar". Tecnicamente estava "fora". A métrica de quanto tempo durou mudou completamente dependendo de qual definição você usava. A solução foi parar de confiar em uma única fonte e criar um painel que cruzava timestamps de rede com timestamps de aplicação.
Como calcular quanto tempo durou de forma prática
O método básico depende inteiramente do que você está medindo. Para processos técnicos, a abordagem padrão é usar timestamps Unix ou ISO 8601. Você registra o momento inicial, o momento final, e subtrai. Parece óbvio, mas a parte que as pessoas pulam é lidar com fusos horários e turnos de trabalho. Vou dar um exemplo concreto do meu dia a dia. Trabalho com janelas de manutenção e SLAs. Quando um incidente acontece, o tempo de resolução effectivo precisa considerar apenas horas úteis. Um ticket aberto sexta às 15h e fechado segunda às 9h parece ter durado 42 horas em wall-clock time, mas em negócios reais durou 4 horas úteis. Usei durante meses uma biblioteca Python chamada workalendar que resolve isso de forma confiável. Ela já tem calendars prontos para Brasil, EUA, Europa. Custo zero de configuração depois de entendida.
Para medições mais simples, sem SLA, o comando `time` no Linux ou o built-in `Measure-Command` do PowerShell já resolvem. Em Python, o módulo `datetime` com `timedelta` faz o cálculo em uma linha. O detalhe importante é que `datetime.now()` tem precisão limitada pelo sistema operacional. Em ambientes Windows, a granularidade pode ser de 15ms. Para medições de milissegundos, use `time.perf_counter()` em vez de `datetime`.
Pegadinhas comuns que ninguém conta
A maior armadilha é o que eu chamo de gap de medição. Quando você usa polling — verificar o status a cada X segundos —, o tempo que o evento levou para acontecer está sempre entre o último check e o primeiro check após o evento. Se você faz polling a cada 30 segundos, seu erro máximo é de 30 segundos. Isso parece pequeno até você estar lidando com sistemas que precisam de precisão sub-second. Outro problema sério é o garbage collector. Se você está benchmarkando código Python e o GC decide rodar no meio da sua medição, os números ficam inconsistentes. A workaround que eu uso é desativar o GC durante medições críticas com `gc.disable()` e reativar depois. Não é perfeito, mas elimina uma variável que causa flutuação de até 15% em benchmarks scripts.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Em infraestrutura, há também o problema dos restarts. Um serviço que cai e reinicia automaticamente pode ter durado 2 segundos de indisponibilidade, mas se o reinício levou 45 segundos, o tempo efetivo de degradação é de 45 segundos. A pergunta "quanto tempo durou" exige que você decida qual versão do tempo quer saber. indisponibilidade pura, tempo até recuperação, ou tempo até operação completa.
Ferramentas que realmente funcionam
Para medições simples de linha de comando, o hyperfine é excelente. Ele roda comandos múltiplas vezes, descarta outliers, e dá estatísticas confiáveis. Leva cerca de 30 segundos para instalar via package manager e 1 minuto para começar a usar. Para monitoramento contínuo de duração de incidents, o Prometheus com o Alertmanager resolve bem. A função `increase()` do PromQL calcula automaticamente variações em counters, o que evita erros manuais de subtração. A curva de aprendizado é de umas 3 a 4 horas para quem já conhece SQL, mas depois disso você nunca mais precisa calcular manualmente a duração de nada.
Se o contexto é mais empresarial e menos técnico, planilhas com funções de data/hora resolvem 80% dos casos. A função `=B2-A2` no Excel, formatada como "[h]:mm", mostra horas totais mesmo quando ultrapassa 24. A maioria das pessoas não sabe que os colchetes forçam o display de horas acumuladas em vez de resetar a cada dia.
Quando medir duração simplesmente não funciona
Há cenários onde a medição de tempo é inútil ou enganosa. Processos assíncronos com filas de espera distorcem completamente a métrica. Um job que leva 2 segundos para executar mas ficou 3 horas na fila não tem "duração" significativa de processamento — tem duração de espera. Separar esses dois conceitos é essencial. Sem essa separação, você fica otimizando o tempo errado. Outro caso onde a métrica quebra é em sistemas distribuídos sem clock sincronizado. Se os servidores não têm NTP rodando e com drift aceitável, comparação de timestamps entre nós perde o sentido. Já vi equipes tentando correlacionar logs de três datacenters diferentes e gastar horas porque um deles estava 2 minutos atrasado. Configurar NTP com pelo menos 3 fontes distintas resolve isso em 5 minutos. Não pule esse passo.
O ponto final é que a pergunta quanto tempo durou tem uma resposta simples, mas obter essa resposta de forma confiável exige decidir com antecedência o que você está medindo, onde cortam os limites, e quais ferramentas vão capturar isso sem adicionar ruído. Defina os limites antes de ligar o cronômetro. O resto é configuração.
