O Que é MTTR e MTBF em Suporte de TI

11 de maio de 2026

Quando um sistema cai, duas perguntas surgem quase ao mesmo tempo: quanto tempo vamos levar para resolver, e por que isso está acontecendo de novo. Por trás dessas perguntas cotidianas existem duas métricas que traduzem em números a saúde do suporte de TI: o MTTR, que mede a velocidade de recuperação, e o MTBF, que mede a confiabilidade. Juntas, elas contam a história de quão resiliente é a sua operação. Empresas que medem essas métricas conseguem enxergar padrões, cobrar fornecedores com base em dados e melhorar de forma contínua. Empresas que não medem ficam reféns da sensação. Este artigo explica o que é MTTR e MTBF, como calcular, como interpretar e como usar essas métricas para elevar a qualidade do suporte.

O que é MTTR

MTTR é a sigla em inglês para Mean Time To Repair, ou tempo médio de reparo. É o tempo médio que a equipe leva para restaurar um sistema, serviço ou equipamento ao funcionamento normal depois que uma falha ocorre. Em outras palavras, o MTTR mede a velocidade de recuperação: quando algo quebra, quanto tempo em média até estar de pé de novo.

A fórmula básica é simples:

MTTR = tempo total de indisponibilidade / número de falhas

Se em um mês houve cinco incidentes que somaram dez horas de reparo, o MTTR é de duas horas por incidente. Quanto menor o MTTR, mais rápida é a recuperação e menor o impacto de cada falha no negócio.

Vale um alerta importante: a sigla MTTR é usada, na prática, para significados diferentes, e confundi-los distorce a análise. As quatro variações mais comuns são:

Mean Time To Repair (reparo): só o tempo de conserto propriamente dito.
Mean Time To Recovery (recuperação): o tempo desde a falha até a restauração completa do serviço, incluindo detecção, diagnóstico e reparo.
Mean Time To Respond (resposta): o tempo até a equipe começar a agir após o alerta.
Mean Time To Resolve (resolução): o tempo total até resolver de forma definitiva, incluindo ações para evitar reincidência.

O que muda entre elas é o que se conta no cronômetro. Por isso, ao comparar números ou negociar com fornecedores, é essencial deixar explícito qual MTTR está em jogo. Neste artigo, quando não especificado, tratamos do tempo de recuperação, que é o mais relevante para o negócio.

O que é MTBF

MTBF é a sigla em inglês para Mean Time Between Failures, ou tempo médio entre falhas. Mede o intervalo médio de funcionamento de um sistema entre uma falha e a próxima. Enquanto o MTTR olha para a velocidade de conserto, o MTBF olha para a confiabilidade: quanto tempo, em média, o sistema opera sem quebrar.

A fórmula básica é:

MTBF = tempo total de operação / número de falhas

Se um servidor operou por 1.000 horas e apresentou duas falhas nesse período, o MTBF é de 500 horas. Quanto maior o MTBF, mais confiável é o sistema, porque falha com menos frequência.

Uma observação conceitual: o MTBF se aplica a itens reparáveis, aqueles que voltam a operar após o conserto, como servidores e sistemas. Para componentes que não se consertam e são simplesmente substituídos, usa-se o MTTF (Mean Time To Failure). A diferença é sutil, mas relevante em ambientes de infraestrutura.

MTTR e MTBF: a diferença que importa

As duas métricas respondem a perguntas diferentes e complementares. Confundi-las leva a decisões erradas. A tabela abaixo resume o contraste.

O que mede Velocidade de recuperação Confiabilidade / frequência de falhas Pergunta que responde Quanto tempo até voltar? Quanto tempo até quebrar de novo? Direção desejada Quanto menor, melhor Quanto maior, melhor Foco de melhoria Processo de resposta e reparo Qualidade e prevenção Quando atua Depois da falha Antes da falha

A analogia do carro ajuda a fixar. O MTBF é quanto tempo o carro roda sem apresentar problema; o MTTR é quanto tempo a oficina leva para consertar quando ele quebra. Um carro ideal roda muito sem quebrar (MTBF alto) e, nas raras vezes que quebra, é consertado rápido (MTTR baixo). O mesmo vale para a TI: você quer sistemas que falham pouco e, quando falham, se recuperam depressa.

O ponto crucial é que essas métricas se sustentam mutuamente. De nada adianta recuperar rápido de falhas que acontecem toda hora, porque o acúmulo de interrupções corrói a produtividade mesmo com MTTR baixo. E de nada adianta um sistema confiável se, na hora rara em que ele cai, a recuperação demora um dia inteiro. A operação saudável cuida das duas frentes.

Como essas métricas se conectam à disponibilidade

MTTR e MTBF não são números soltos: eles determinam matematicamente a disponibilidade do sistema, aquele indicador de "quantos noves" que aparece em contratos de SLA. A relação é direta:

Disponibilidade = MTBF / (MTBF + MTTR)

Ou seja, a disponibilidade sobe quando o MTBF cresce (o sistema falha menos) ou quando o MTTR cai (a recuperação é mais rápida). Essa fórmula deixa claro por que investir só em uma das pontas tem retorno limitado. Para chegar aos famosos 99,9% ou mais de disponibilidade, é preciso atuar nas duas: reduzir a frequência das falhas e acelerar a recuperação.

Para dar dimensão, veja quanto tempo de indisponibilidade cada nível de disponibilidade permite por ano:

99% (dois noves) cerca de 3 dias e 15 horas 99,9% (três noves) cerca de 8 horas e 45 minutos 99,99% (quatro noves) cerca de 52 minutos 99,999% (cinco noves) cerca de 5 minutos

Esses números mostram por que cada minuto de MTTR importa. Em um serviço que almeja quatro noves, você tem menos de uma hora de folga no ano inteiro. Não dá para alcançar isso sem medir e melhorar continuamente MTTR e MTBF.

Como calcular na prática

Medir bem começa com dados confiáveis. Sem registrar cada incidente, com hora de início, hora de detecção, hora de resolução e causa, qualquer cálculo vira chute. É aqui que uma ferramenta de service desk ou de monitoração se torna indispensável, porque ela captura esses tempos automaticamente.

Um exemplo prático. Suponha que, em 30 dias, um sistema teve os seguintes incidentes: um de 1 hora, um de 2 horas e um de 3 horas de indisponibilidade. O tempo total parado foi de 6 horas, em 3 falhas. Logo, o MTTR foi de 2 horas. Se o sistema deveria operar 24 horas por dia durante os 30 dias, seriam 720 horas de operação prevista, das quais 6 foram de parada, restando 714 horas de operação real. Com 3 falhas, o MTBF fica em 238 horas. A disponibilidade, aplicando a fórmula, seria de 238 / (238 + 2), aproximadamente 99,2%.

O valor dos números não está no cálculo em si, mas no acompanhamento ao longo do tempo. Um MTTR que sobe mês a mês sinaliza que o processo de resposta está se degradando. Um MTBF que cai indica que algo na infraestrutura ou na qualidade está piorando. As métricas viram um termômetro que antecipa problemas antes que eles virem crise.

Como melhorar MTTR e MTBF

Reduzir o MTTR, ou seja, recuperar mais rápido, passa por atuar em cada etapa do ciclo de resposta. Detecção rápida com monitoração proativa encurta o tempo até saber que algo falhou. Alertas bem configurados evitam que a equipe descubra o problema pelo cliente. Processos claros de escalonamento e runbooks documentados aceleram o diagnóstico e o reparo. Automação de tarefas repetitivas, como reinício de serviços ou failover, corta minutos preciosos. E uma base de conhecimento bem mantida evita que a equipe reinvente a solução a cada incidente.

Aumentar o MTBF, ou seja, fazer o sistema falhar menos, é um trabalho de prevenção e qualidade. Manutenção preventiva, atualizações em dia, hardware e software de qualidade, redundância nos pontos críticos e, sobretudo, análise de causa raiz dos incidentes recorrentes. Cada falha resolvida em definitivo, atacando a causa e não só o sintoma, empurra o MTBF para cima. A análise de causa raiz é o elo que transforma o MTTR de hoje em MTBF melhor amanhã, porque impede que o mesmo problema volte.

Esse ciclo de medir, analisar e melhorar é contínuo e exige disciplina, ferramentas e, muitas vezes, uma equipe dedicada. É exatamente o tipo de operação que um parceiro de suporte e monitoração entrega de forma estruturada, com service desk que registra tudo e monitoração que detecta cedo.

Cuidados ao interpretar essas métricas

Métrica mal interpretada engana mais do que ajuda. Alguns cuidados evitam conclusões erradas. O primeiro é não olhar apenas para a média. A palavra "médio" no MTTR e no MTBF esconde a variação. Um MTTR médio de duas horas pode ser a soma de muitos incidentes de dez minutos com um único de oito horas, e esse incidente longo talvez seja justamente o que mais dói no negócio. Complementar a média com a mediana e com o pior caso dá um retrato mais honesto.

O segundo cuidado é considerar o contexto de cada sistema. Comparar o MTTR de um serviço crítico com o de uma ferramenta secundária sem levar em conta a diferença de prioridade produz comparações injustas. As metas precisam ser proporcionais à criticidade.

O terceiro é desconfiar de melhorias que vêm da subnotificação. Se o MTBF "melhorou", vale checar se as falhas realmente diminuíram ou se apenas pararam de ser registradas. Métricas só valem quando a base de dados é honesta e completa. Por isso o registro disciplinado de todos os incidentes, com horários e causas, é o alicerce de qualquer análise confiável.

Por fim, MTTR e MTBF devem alimentar decisões, não virar troféu. O objetivo não é exibir um número bonito no relatório, e sim identificar onde investir: se o MTTR está alto, o foco é o processo de resposta; se o MTBF está baixo, o foco é prevenção e qualidade. As métricas são bússola, não medalha.

Perguntas frequentes

MTTR quanto menor melhor, e MTBF quanto maior melhor, certo? Sim. MTTR baixo significa recuperação rápida das falhas. MTBF alto significa que o sistema opera por muito tempo entre uma falha e outra. O cenário ideal combina os dois: falhar pouco e recuperar depressa.

Qual é um bom valor de MTTR? Não existe número universal, porque depende da criticidade do sistema e do SLA acordado. Um serviço crítico pode exigir MTTR de minutos, enquanto um sistema secundário tolera horas. O importante é definir metas coerentes com o impacto no negócio e acompanhar a evolução ao longo do tempo.

MTTR e SLA são a mesma coisa? Não. O SLA é o acordo de nível de serviço, que estabelece metas, por exemplo, de tempo de resposta e de disponibilidade. O MTTR é uma métrica que ajuda a medir se o SLA está sendo cumprido. O SLA define a promessa; o MTTR e o MTBF mostram se ela está sendo entregue.

Preciso de uma ferramenta para medir essas métricas? Na prática, sim. É possível calcular manualmente, mas isso não escala e é sujeito a erro. Um sistema de service desk e de monitoração registra automaticamente os tempos de cada incidente e gera os indicadores, o que torna a medição confiável e contínua.

Conclusão

MTTR e MTBF são as duas métricas que traduzem a saúde do suporte de TI em números. O MTTR mede a velocidade de recuperação depois da falha, e queremos ele o menor possível. O MTBF mede a confiabilidade, o tempo que o sistema opera entre falhas, e queremos ele o maior possível. Juntas, elas determinam a disponibilidade do serviço, aquele indicador de "quantos noves" que os contratos exigem. Medir essas métricas de forma contínua permite enxergar padrões, cobrar com base em dados e melhorar de maneira estruturada, atacando tanto a velocidade de resposta quanto a prevenção de falhas.

A Ródio Tech está no mercado desde 2004, é certificada Great Place to Work, tem nota 9.4 no oHub e atende clientes como C&A, Fleury, CERC e SoftwareOne. Nosso service desk registra cada incidente e nossa monitoração detecta problemas cedo, o que mantém MTTR baixo e MTBF alto na sua operação. Conheça o nosso service desk e a nossa monitoração.

Referências

Atlassian. "MTBF, MTTR, MTTF, MTTA: A guide to incident management metrics". https://www.atlassian.com/incident-management/kpis/common-metrics
IBM. "What is mean time to repair (MTTR)?". https://www.ibm.com/topics/mttr
ISO/IEC 20000-1. "Service management system requirements". https://www.iso.org/standard/70636.html
NIST. "Computer Security Incident Handling Guide" (SP 800-61). https://csrc.nist.gov/pubs/sp/800/61/r2/final
Google SRE. "Site Reliability Engineering: Measuring Reliability". https://sre.google/sre-book/service-level-objectives/

Principais pontos

MTTR (Mean Time To Repair): tempo médio que a equipe leva para restaurar um sistema após uma falha, calculado como tempo total de indisponibilidade dividido pelo número de falhas; quanto menor, melhor.
MTBF (Mean Time Between Failures): tempo médio de operação entre uma falha e a próxima, calculado como tempo total de operação dividido pelo número de falhas; quanto maior, melhor.
Fórmula da disponibilidade: Disponibilidade = MTBF / (MTBF + MTTR), o que explica por que reduzir a frequência das falhas e acelerar a recuperação são igualmente necessários.
Referência de "noves": 99,9% de disponibilidade permite cerca de 8 horas e 45 minutos de indisponibilidade por ano, enquanto 99,99% permite cerca de 52 minutos.
MTTR não é sinônimo de SLA: o SLA define a meta acordada de nível de serviço, enquanto MTTR e MTBF são métricas que mostram se essa meta está sendo cumprida na prática.