Mean time to recovery

Quando um incidente de produção acontece, cada minuto de downtime tem um custo: receita perdida, confiança dos usuários abalada e squads de engenharia tirados do trabalho planejado para apagar incêndios. O mean time to recovery (MTTR) mede quanto tempo o seu time leva para restaurar o serviço após uma falha. É uma das quatro DORA metrics e um dos sinais mais claros de quão resiliente é o seu processo de entrega. Esta página cobre a definição, como calcular, benchmarks publicados, formas práticas de melhorar e como o DevStats exibe esse dado para o seu squad.

Key takeaways

• O mean time to recovery mede o tempo médio entre uma falha de serviço e a restauração completa. Isso importa porque janelas de recuperação longas se traduzem diretamente em downtime para o usuário, SLAs perdidos e trabalho não planejado que empurra o roadmap para o lado.
• O MTTR é calculado dividindo o tempo total de recuperação de todos os incidentes pelo número de incidentes em um período. Segundo o DORA State of DevOps Report de 2023, times de alta performance alcançam um mean time to recovery abaixo de uma hora.
• O erro mais comum dos times é tratar o MTTR como uma medida de performance individual do engenheiro. É uma métrica de processo. Um MTTR alto geralmente aponta para lacunas em ferramentas de observabilidade, runbooks de incidente confusos ou deployment pipelines que tornam os rollbacks lentos, não para a capacidade individual de cada player.
• O DevStats exibe as DORA metrics, incluindo o mean time to recovery, por meio do seu recurso de DORA metrics, com benchmark baseado em dados de mais de 1.000 times de engenharia. Inicie um trial gratuito e veja seus números em menos de dois minutos em app.devstats.com/register.

Definição de mean time to recovery

O mean time to recovery é o tempo médio que um time de engenharia leva para restaurar um sistema à operação normal após uma falha ou incidente. O cálculo começa no momento em que a falha é detectada e termina quando a restauração completa do serviço é confirmada.

A fórmula é: MTTR = Tempo total de recuperação de todos os incidentes / Número de incidentes. Normalmente é expresso em horas ou minutos e medido em uma janela contínua, como 30 ou 90 dias. O MTTR é uma das quatro DORA metrics principais, ao lado de deployment frequency, lead time for changes e change failure rate. Um MTTR baixo indica que o seu squad detecta problemas rápido, responde com segurança e restaura o serviço antes que a maioria dos usuários perceba.

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

Squads que não acompanham o MTTR costumam descobrir o problema da pior forma: um post-mortem revela que o time gastou seis horas se recuperando de um incidente que deveria ter levado trinta minutos. Essa diferença não aparece nas métricas de velocidade nem nas taxas de conclusão de sprint. Ela aparece na confiança dos stakeholders e no trabalho não planejado que silenciosamente desloca os compromissos do roadmap nos próximos dois sprints.

Para líderes de engenharia, o MTTR se conecta diretamente à conformidade com SLA, à carga de on-call e à retenção de desenvolvedores. Um MTTR alto significa que os seus players passam mais tempo no modo reativo de apagar incêndios. Isso corrói tanto a produtividade do squad quanto o moral ao longo do tempo. Quando a recuperação leva horas em vez de minutos, o custo não é só o downtime. É o efeito acumulado do foco interrompido e do trabalho planejado adiado.

O MTTR é uma das DORA metrics do lado de estabilidade, junto com o change failure rate, e oferece uma visão de resiliência na entrega, não apenas de velocidade. A medição é o ponto de partida. O líder de engenharia é quem decide o que os dados significam e o que mudar.

Times que combinam os dados de MTTR com visibilidade do seu deployment pipeline conseguem identificar se a recuperação lenta se correlaciona com padrões específicos de deployment, como releases em grandes lotes ou deploys pouco frequentes que tornam os rollbacks mais difíceis de executar de forma limpa.

Como medir o mean time to recovery

Para calcular o MTTR, você precisa de um log de incidentes com dois timestamps por incidente: quando a falha foi detectada (ou quando o serviço caiu abaixo do limite aceitável) e quando a restauração completa do serviço foi confirmada. A maioria dos squads extrai isso da ferramenta de gestão de incidentes, como PagerDuty, Opsgenie ou Statuspage. O cálculo é direto: some todas as durações de recuperação de um período e divida pelo número total de incidentes.

O desafio de qualidade dos dados está na consistência de como "recuperação" é definida. Alguns times encerram um incidente quando o sintoma imediato é resolvido. Outros esperam até a causa raiz ser tratada e o monitoramento confirmar a estabilidade. Escolha uma definição e aplique de forma uniforme. Sem essa disciplina, a linha de tendência do seu MTTR vira ruído. Você pode comparar seus números com os de pares do setor usando os benchmarks do DevStats, baseados em dados de mais de 1.000 times de engenharia.

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

Uma VP of Engineering de uma empresa SaaS de 45 pessoas percebeu que o MTTR havia subido de menos de duas horas para quase seis horas ao longo de um trimestre. Os dados mostravam o padrão com clareza: os incidentes eram detectados rapidamente, mas o tempo até a resolução era longo. Ao revisar o log de incidentes, ela identificou que a maior parte do atraso acontecia entre a detecção e a primeira ação concreta, não na correção em si. O squad não tinha um caminho claro de escalação de on-call, e os runbooks para os três modos de falha mais comuns estavam ausentes ou desatualizados.

Ela rodou um sprint de duas semanas dedicado à criação de runbooks e à clareza na rotação de on-call. O squad documentou os passos de rollback para os cinco cenários de deployment de maior risco e adicionou alertas automatizados com links diretos para o runbook correspondente. Quatro semanas depois, o MTTR caiu de volta para menos de duas horas. O indicador antecedente que ela acompanhava era o time-to-acknowledge, que caiu de 28 minutos para menos de 8 minutos antes de o número do MTTR se mover, confirmando que a intervenção estava funcionando antes de a métrica de atraso reagir.

Como melhorar o mean time to recovery

1. Reduza o time-to-detect com melhores thresholds de alerta. A maioria dos problemas de MTTR começa antes mesmo da recuperação. Audite a configuração atual dos seus alertas e identifique lacunas em que a degradação do serviço passa despercebida por mais de cinco minutos. Ajuste os thresholds nos seus endpoints de maior tráfego primeiro.
2. Crie e mantenha runbooks de rollback para cada tipo de deployment. Uma recuperação lenta costuma ser um problema de conhecimento. Documente os passos exatos para fazer rollback de cada tipo de mudança que o seu squad entrega. Revise esses runbooks no início de cada ciclo de sprint para mantê-los atualizados com o seu stack.
3. Reduza o tamanho dos lotes de deployment para tornar os rollbacks mais baratos. Releases grandes e pouco frequentes tornam os rollbacks caros porque reverter uma mudança significa reverter muitas. Deploys menores e mais frequentes reduzem o raio de impacto de qualquer falha. Monitore a sua deployment frequency como indicador antecedente de melhoria do MTTR.
4. Faça post-mortems sem culpa após todo incidente acima de um threshold de severidade. O objetivo é identificar lacunas no processo, não apontar culpados. Registre os itens de ação dos post-mortems no seu issue tracker e feche o ciclo em até dois sprints. O DevStats pode exibir dados de issue cycle time para você verificar se os itens de ação dos post-mortems estão sendo resolvidos de fato.
5. Estabeleça um papel dedicado de incident commander na rotação de on-call. Quando todos são donos da recuperação, ninguém é. Atribua um único incident commander por turno, cuja função é coordenar, não corrigir. Isso elimina a ambiguidade que adiciona de 30 a 60 minutos na maioria das recuperações.

Mean time to recovery vs. mean time to detect

O mean time to recovery e o mean time to detect (MTTD) são relacionados, mas medem fases diferentes da resposta a falhas. O MTTR cobre a janela completa da detecção da falha até a restauração do serviço, enquanto o MTTD mede apenas quanto tempo leva para perceber que uma falha ocorreu. Você pode ter um MTTD rápido e um MTTR lento se o seu squad detecta problemas rapidamente, mas leva horas para resolvê-los.

Acompanhe as duas métricas juntas para entender onde o seu processo de resposta a incidentes perde mais tempo: antes ou depois da detecção.