MTBF e MTTR: a matemática da disponibilidade e qual métrica atacar primeiro

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado ago/2015Atualizado ago/2026

Todo relatório mensal de operação traz os dois números lado a lado. O MTBF subiu de 240 para 280 horas. O MTTR caiu de 4 horas para 3 horas e meia. Em seguida, o gráfico fica verde na apresentação.

Mesmo assim, a pergunta que o diretor faz na reunião seguinte continua sem resposta: onde colocar o orçamento do próximo trimestre? Nenhuma das duas métricas responde isso sozinha. Quem responde é a conta que liga as duas à disponibilidade. Além disso, essa conta tem uma propriedade que quase nunca aparece nos guias do assunto: ela é simétrica.

Este artigo assume que você já reporta os dois números. Adiante vêm a fórmula que os conecta e o critério para escolher qual atacar primeiro. Por fim, chegam as quatro situações em que o número do seu relatório descreve uma operação diferente da sua.

MTBF e MTTR: o que cada um mede

O MTBF (Mean Time Between Failures) mede o intervalo médio que um sistema opera entre uma falha e a seguinte. O MTTR (Mean Time to Restore) mede quanto tempo, em média, a operação leva para devolver o serviço depois que ele cai. Ou seja, um descreve a frequência da interrupção e o outro descreve a duração dela.

Antes de tudo, as fórmulas são diretas:

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

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

Por exemplo: um serviço operou 720 horas no mês, caiu 3 vezes e somou 12 horas fora do ar. O MTBF é 720 ÷ 3 = 240 horas. O MTTR é 12 ÷ 3 = 4 horas. Repare que o denominador é o mesmo nas duas contas, o que já antecipa uma armadilha tratada adiante.

Cada indicador tem post próprio aqui, com o passo a passo do cálculo e os limites de uso: como o MTBF se comporta em ativo reparável e em ficha técnica de fabricante.

Por outro lado, as quatro leituras possíveis do R em MTTR mostram como o mesmo incidente vira números diferentes. Neste texto, contudo, o interesse é o que acontece quando você olha para os dois ao mesmo tempo.

A conta que liga as duas: disponibilidade

A disponibilidade sai diretamente das duas métricas, sem nenhum parâmetro adicional:

Disponibilidade = MTBF ÷ (MTBF + MTTR)

No exemplo acima, 240 ÷ (240 + 4) = 98,36%. Considere agora uma operação que falha uma vez por mês e leva 4 horas para restaurar. Assim, a conta fica 720 ÷ (720 + 4) = 99,45%, que é o número que vai para o SLA acordado com o cliente.

O que essa fórmula revela é o custo de cada nove adicional. Com o MTBF parado em 720 horas, portanto, o teto de MTTR despenca por um fator de dez a cada casa decimal conquistada.

Por isso, os cinco noves não são uma meta de processo. São uma meta de arquitetura: nenhum ser humano lê um alerta, decide e age em 26 segundos. Quem promete esse número em contrato está prometendo redundância com chaveamento automático, não empenho de equipe.

Qual atacar primeiro: a regra de decisão

Volte à operação do exemplo anterior, com falha mensal e 4 horas de recuperação. Para chegar aos três noves existem exatamente dois caminhos. O primeiro corta o MTTR de 4 horas para 43 minutos. Por outro lado, o segundo espaça as falhas para uma a cada cinco meses e meio, elevando o MTBF de 720 para 3.996 horas.

Os dois movimentos entregam o mesmo resultado. O primeiro pede uma redução de 5,6 vezes, o segundo pede um aumento de 5,5 vezes. Ou seja, a matemática é simétrica e não escolhe por você. Quem escolhe é o custo de cada alavanca no seu ambiente.

Quando o MTTR é a alavanca mais barata

Ataque o tempo de recuperação quando as causas das falhas forem dispersas, sem nenhuma dominante. Ataque também quando boa parte do relógio for consumida por diagnóstico, não por reparo. O mesmo vale quando a origem estiver fora do seu controle, em provedor externo ou dependência de terceiro.

Nesses três casos, prevenir sai caro e restaurar rápido sai barato. A evidência de mercado empurra na mesma direção.

O levantamento anual de interrupções registra a quinta queda anual seguida na taxa de eventos por site. Ainda assim, 57% dizem que a última interrupção grave custou mais de US$ 100 mil. Um em cada cinco passou de US$ 1 milhão.

Ou seja, o setor vem ganhando no MTBF e continua perdendo no custo por evento. Quando a falha fica mais rara sem ficar mais barata, o dinheiro rende mais na duração do que na frequência.

Quando o MTBF é a alavanca mais barata

Inverta a prioridade em três situações. A primeira é a concentração de causa: se duas ou três origens respondem pela maioria dos incidentes, eliminar essas origens custa menos que acelerar a resposta a todas.

A segunda é o custo por evento independente da duração, como perda de transação financeira ou corrupção de dados. A terceira é o piso físico de recuperação.

Restaurar um banco grande, reprovisionar hardware ou aguardar janela de fornecedor tem um tempo mínimo que nenhum runbook vence. Portanto, onde esse piso já é o seu MTTR, só sobra espaçar as falhas.

Existe ainda um terceiro veredito, o mais comum de todos. Se a soma de MTTD e MTTA passar de metade do MTTR, nenhuma das duas alavancas é o primeiro movimento certo. O gargalo, então, está na detecção. É lá que o orçamento começa.

Onde os dois números mentem

Antes de comparar o seu número com qualquer benchmark, confira se ele descreve mesmo a sua operação. Três defeitos aparecem com frequência.

A média não é o incidente que o usuário sentiu

MTTR é média aritmética sobre uma distribuição de cauda longa. Ou seja, o número é fácil de mover sem querer. Vinte incidentes resolvidos em 15 minutos e um que durou 12 horas produzem um MTTR de 48 minutos.

Nenhum incidente durou 48 minutos: metade durou 15 e um durou 720. Portanto, a correção é barata. Reporte a mediana ao lado da média e acrescente o p90, que é o tempo dentro do qual nove em cada dez incidentes fecharam.

Em resumo, a média mostra o volume de esforço e o p90 mostra o que o cliente lembra.

Três falhas no trimestre não são uma amostra

Um trimestre com 3 falhas em 2.160 horas de operação dá MTBF de 720 horas. A quarta falha, sozinha, derruba o indicador para 540 horas. É uma queda de um quarto sem que nada tenha mudado no ambiente.

Com denominador de um dígito, o número oscila mais por sorte do que por engenharia. Por isso, trate MTBF trimestral de serviço estável como tendência, nunca como medida. Compare janelas longas ou agregue por família de ativo.

MTBF de ficha técnica não descreve o seu ambiente

O MTBF que o fabricante publica sai de uma população grande de unidades observada por um período curto, dentro da vida útil projetada. Isto é, ele é uma taxa de falha estatística, não a expectativa de vida da unidade que está no seu rack.

Somar esses valores para estimar a confiabilidade de um serviço composto produz um número sem relação com o que a operação vai medir.

De onde sai o número na prática

Duas equipes podem medir o mesmo incidente e reportar MTTR diferente sem que nenhuma esteja errada. A diferença mora em duas escolhas silenciosas.

A fronteira do relógio

O relógio de um incidente tem pelo menos seis marcos: a falha começa, o monitoramento detecta, alguém reconhece o alerta, o chamado abre, o serviço volta e o time confirma a normalização. Além disso, cada equipe escolhe onde começa a contar.

Quem começa na abertura do chamado exclui do MTTR toda a fase de detecção e reconhecimento. O número fica menor e o usuário continua com o mesmo prejuízo.

Portanto, meça o tempo até a detecção em separado. Declare a fronteira do relógio no relatório e mantenha a mesma fronteira entre trimestres.

O ruído que entra no denominador

O segundo problema mora no denominador, compartilhado pelas duas fórmulas. Dez incidentes reais de 3 horas somam 1.800 minutos, o que dá MTTR de 180 minutos.

Acrescente 90 alertas falsos fechados em 2 minutos. O total vai para 1.980 minutos sobre 100 ocorrências. Como resultado, o MTTR cai para 19,8 minutos. A operação piorou o MTBF, melhorou o MTTR em nove vezes e não mudou nada.

No projeto com a Klabin, o defeito não estava na fórmula: estava no que entrava nela. A operação recebia alerta demais e parte relevante não correspondia a incidente real.

Implantamos o OpMon com console centralizado, capacity planning e robôs que simulam o acesso de usuários reais. Em seguida, a notificação passou a sair apenas para incidente verdadeiro, em uma operação distribuída com mais de 700 dispositivos monitorados.

Enquanto a fadiga de alertas não for tratada, qualquer meta de MTTR é uma meta sobre ruído.

Por que o SRE moderno desconfia das duas

Disponibilidade baseada em tempo pressupõe um sistema com dois estados: no ar ou fora do ar. No entanto, serviço distribuído raramente se comporta assim. Ele degrada em fatias, falha para uma região e responde para outra, ou perde parte das requisições sem sair do ar em lugar nenhum.

O capítulo sobre risco do livro de engenharia de confiabilidade do Google é explícito quanto a isso. Uma métrica de disponibilidade baseada em tempo costuma não ser significativa em serviços distribuídos globalmente.

A razão é simples: quase sempre existe algum tráfego sendo atendido em algum lugar. Por isso, a alternativa adotada lá é a taxa de sucesso de requisição, medida em janelas móveis.

O que o DORA mudou em 2023

A definição de MTTR também não resistiu ao escrutínio. Naquele ano, o programa renomeou a métrica para failed deployment recovery time.

O motivo: a definição anterior não distinguia falha originada por mudança de software de falha causada por fator externo, como uma queda de data center. O histórico oficial das métricas do programa registra a mudança.

Vale destacar esse ponto antes de comparar o seu número com qualquer estudo que use a sigla sem qualificar.

No corte Quais métricas realmente importam, o time da OpServices trata a escolha do indicador. Nesse sentido, a lista de métricas de uma operação costuma ser maior do que a lista das que alguém usa para decidir.

Nada disso aposenta as duas métricas. Apesar de tudo, elas continuam descrevendo bem infraestrutura com falha discreta: link, nobreak, cluster de banco, appliance.

Para serviço que degrada em fatias, contudo, o par que responde melhor é SLO com error budget. Ele troca a pergunta sobre quanto tempo ficou fora pela pergunta sobre quanto de erro a janela ainda comporta. As métricas DORA seguem a mesma lógica no ciclo de entrega.

Da manutenção industrial para a TI

Uma busca por esses dois indicadores em português devolve, quase inteira, a literatura de manutenção industrial. Não é acaso: os conceitos nasceram na engenharia de confiabilidade de equipamento reparável.

Nesse contexto, a peça se desgasta de forma previsível e o reparo devolve o ativo ao estado anterior. Software, por outro lado, não se desgasta.

A falha vem de mudança, de carga, de dependência externa ou de configuração. O incidente de ontem não torna o de amanhã mais provável pelo simples passar do tempo.

Por isso, manutenção preventiva por calendário tem pouco efeito sobre a maior parte dos incidentes de TI. No mundo industrial, ela é a resposta natural ao MTBF baixo.

Ainda assim, a herança é útil onde o objeto é físico. Nobreak, gerador, climatização, disco e enlace de rádio envelhecem. A confusão só aparece quando alguém aplica a mesma matemática a um serviço formado por trinta componentes com modos de falha independentes.

O que levar para o relatório da segunda-feira

Três mudanças pequenas melhoram mais o relatório do que qualquer meta nova. A primeira é publicar a fronteira do relógio junto com o MTTR: de que marco até que marco o tempo foi contado. Sem isso, comparar trimestres é comparar definições.

A segunda é reportar mediana e p90 ao lado da média, porque a média sozinha esconde justamente o incidente que gerou a reunião. A terceira é separar alerta de incidente antes de calcular qualquer coisa.

O ruído entra no denominador das duas fórmulas e move os dois números na direção errada. Com essas três correções, em resumo, a conta de disponibilidade passa a apontar para uma decisão de verdade: cortar duração ou espaçar frequência, conforme o que for mais barato no seu ambiente.

Se você quer chegar a essa decisão com números que aguentam auditoria, fale com nossos especialistas.