Mean time to detect

A maioria dos times de engenharia não sabe quanto tempo leva para encontrar um incidente em produção até estar fundo em um postmortem. O mean time to detect (MTTD) mede exatamente isso: o tempo médio entre uma falha ocorrer e o time perceber que ela existe. Quanto menor o MTTD, menos dano se acumula antes de alguém começar a trabalhar em uma correção. Esta página cobre a definição, como calcular, benchmarks publicados, formas concretas de reduzir o MTTD e como o DevStats traz os dados que você precisa para agir.

TL;DR: Mean time to detect = tempo total de detecção de todos os incidentes / número de incidentes. Menor é melhor. Times elite detectam falhas em menos de uma hora.

Principais conclusões

• O mean time to detect mede o tempo médio entre uma falha ocorrer em produção e o time perceber. Importa porque cada minuto de falha não detectada é um minuto de impacto ao usuário, risco de receita e dano técnico que o squad ainda não pode começar a resolver.
• O MTTD é calculado dividindo o tempo total de detecção de todos os incidentes pelo número de incidentes em um período. A pesquisa DORA mostra consistentemente que times de engenharia elite detectam falhas em menos de uma hora, enquanto times de baixo desempenho podem levar dias.
• O erro mais comum dos times com MTTD é confundir tempo de detecção com tempo de resposta. Se o alerta dispara cinco minutos após o início de um incidente, mas ninguém o reconhece por duas horas, o MTTD efetivo é duas horas, não cinco minutos. Cobertura de alertas sem disciplina de on-call não move o número.
• O DevStats expõe DORA metrics, incluindo sinais de tempo de detecção, conectando ao seu provedor Git, pipeline de CI/CD e issue tracker, com benchmarks comparados a mais de 1.000 times de engenharia. Comece um teste gratuito e veja os números do seu time em menos de dois minutos.

Definição de mean time to detect

O mean time to detect (MTTD) é o tempo médio que um time de engenharia leva para perceber uma falha depois que ela ocorre em produção. Ele mede o intervalo entre algo quebrar e alguém no time saber disso.

Tecnicamente, o MTTD é calculado assim: MTTD = soma de todos os tempos de detecção / número de incidentes. O tempo de detecção de um único incidente começa no momento em que a falha ocorre e termina quando o time recebe um alerta confirmado ou toma conhecimento do problema de outra forma. Analisado junto ao conjunto completo de DORA metrics, o MTTD dá aos líderes de engenharia uma visão clara da saúde de observabilidade do sistema e da capacidade do squad de conter o raio de impacto de qualquer incidente.

Por que o mean time to detect importa para times de engenharia

Quando o MTTD é alto, as falhas se acumulam em silêncio. Usuários encontram erros, transações falham e inconsistências de dados se acumulam antes de qualquer pessoa no squad saber que há um problema. Quando um alerta dispara ou uma reclamação de usuário aparece, o incidente já está pior do que precisava estar. Falhas não detectadas também criam dados de sprint enganosos: seus números de throughput podem parecer saudáveis enquanto a produção está degradada.

O MTTD se conecta diretamente aos KPIs do líder de engenharia. Detecção lenta estende a duração do incidente, o que infla o mean time to recover (MTTR), o que prejudica a conformidade com SLA e a confiança dos stakeholders. Times com MTTD ruim tendem a gastar mais tempo apagando incêndios de forma reativa e menos tempo em trabalho planejado, o que corrói a precisão de planejamento ao longo do tempo. O MTTD é uma das quatro DORA metrics principais, ao lado de deployment frequency, lead time for changes e MTTR, como medida de estabilidade na entrega de software.

Medir o MTTD é o primeiro passo. Os dados mostram onde estão as lacunas de observabilidade. O que você faz com elas é decisão sua como líder de engenharia.

Como medir o mean time to detect

Para calcular o MTTD, você precisa de um timestamp confiável de quando cada incidente começou e de um segundo timestamp de quando o time foi notificado pela primeira vez. A diferença entre esses dois pontos é o tempo de detecção daquele incidente. Calcule a média dessas diferenças em uma janela contínua, normalmente de 30 ou 90 dias, e você tem seu MTTD.

As fontes de dados que você precisa são sua ferramenta de gerenciamento de incidentes (PagerDuty, OpsGenie ou equivalente), sua plataforma de monitoramento (Datadog, Grafana, New Relic) e seu pipeline de deployment para correlacionar incidentes com deploys recentes. Você pode ver como a frequência de deploy e os padrões de incidentes se relacionam no recurso de deploy do DevStats. Para benchmarking entre times, o recurso de benchmarks do DevStats permite comparar seu MTTD com times de tamanho e cadência de releases semelhantes.

Não existe um benchmark publicado único e definitivo especificamente para o MTTD isolado, mas a pesquisa State of DevOps da DORA (2023) agrupa times por desempenho geral de estabilidade. A tabela abaixo mapeia esses agrupamentos para faixas qualitativas de MTTD alinhadas com os resultados publicados pela DORA.

Os benchmarks variam conforme a complexidade do sistema, o tamanho do time e o modelo de releases. Use-os como referências direcionais, não como metas absolutas.

Mean time to detect na prática: um exemplo real

Um VP de Engenharia em uma empresa SaaS de 45 pessoas percebeu que os números de MTTR estavam consistentemente altos, mas os postmortems continuavam apontando para a mesma causa raiz: o time ficava sabendo dos incidentes por tickets de suporte ao cliente, não pelos próprios alertas. Eles analisaram três meses de dados de incidentes e descobriram que o MTTD médio era pouco mais de 18 horas. A maioria desses incidentes foi reportada primeiro por usuários.

O VP tomou duas decisões: atribuiu responsabilidade explícita de on-call para cada serviço e adicionou cobertura a três endpoints de API com monitoramento insuficiente que apareciam repetidamente no log de incidentes. Em dois sprints, o MTTD médio caiu para menos de quatro horas. Eles acompanharam a mudança usando a ferramenta de gerenciamento de incidentes junto com os dados de deployment para confirmar que a melhora não era apenas um período mais tranquilo, mas uma mudança real na capacidade de detecção.

Como melhorar o mean time to detect

1. Audite a cobertura de alertas contra o histórico de incidentes. Analise os últimos 20 incidentes e verifique como cada um foi detectado pela primeira vez. Se mais de 30% foram reportados por usuários ou encontrados manualmente, você tem uma lacuna de observabilidade. Mapeie esses incidentes de volta a serviços específicos e adicione monitoramento lá primeiro.
2. Defina e aplique SLAs de reconhecimento de on-call. Um alerta que dispara, mas não é reconhecido por duas horas, é o mesmo que nenhum alerta. Estabeleça um tempo máximo de reconhecimento, monitore-o e revise as violações na próxima retrospectiva. Isso é uma correção de processo, não de ferramental.
3. Reduza o ruído de alertas antes de adicionar mais alertas. Alto volume de alertas cria fadiga, e engenheiros de on-call com fadiga param de responder rapidamente. Audite suas regras de alertas e suprima ou ajuste qualquer alerta que não tenha gerado um incidente real nos últimos 90 dias. Menos alertas com maior sinal reduzem o MTTD efetivo mais rápido do que adicionar mais ruído.
4. Correlacione deploys com o início de incidentes. Muitos incidentes são causados por um deploy recente. Conectar os dados do pipeline de CI/CD ao log de incidentes permite que o squad identifique o deploy causador mais rapidamente, o que reduz tanto o MTTD quanto o MTTR. É aqui que os dados de PR cycle time se tornam um indicador antecipado útil: PRs menores e mais rápidos reduzem o raio de impacto de qualquer deploy.
5. Revise o MTTD nas retrospectivas de sprint, não apenas nos postmortems. Postmortems são reativos. Incorporar o MTTD à cadência regular de revisão de sprint transforma-o em um sinal proativo, não em um indicador defasado.

Mean time to detect vs. mean time to recover

O mean time to detect e o mean time to recover (MTTR) são ambos DORA metrics de estabilidade, mas medem partes diferentes do ciclo de vida de um incidente. O MTTD termina no momento em que o time sabe do problema. O MTTR começa nesse mesmo momento e termina quando o sistema é restaurado.

Use o MTTD para avaliar o quanto seus processos de monitoramento e on-call detectam problemas. Use o MTTR para avaliar o quanto o squad os resolve quando já são conhecidos.