Métricas de disponibilidade: MTTR e MTBF

Dando continuidade ao nosso assunto de métricas de engenharia, hoje vamos tratar de métricas de disponibilidade: MTTR e MTBF. Vamos entender sua origem, como são medidas, como usá-las e também como a forma em que você escreveu seus softwares pode influenciar esses números.

Qual o significado de MTBF?

MTBF é uma sigla para “Mean Time Between Failures” (tempo médio entre falhas). Esta métrica se preocupa em extrair uma média do tempo entre falhas de um componente, dado um determinado ciclo de tempo. Desta forma, você poderia prever o comportamento de falhas de um componente, já que sabe que – em média – ele funciona sem falhar por um determinado período.

Qual o significado de MTTR?

MTTR, por sua vez, significa “Mean Time To Recovery”, ou em bom português “Tempo médio para recuperação”. Sendo assim, dado um sistema que ficou off-line, esta métrica diz, em média, quanto tempo ele leva para ficar online novamente.

A letra “R” do acrônimo pode ter outros tantos significados. Podemos considerar, por exemplo, o tempo médio para resolução da causa raiz da falha, ou o tempo médio de reparos ou ainda o tempo médio de resposta ao incidente. Essa diversidade de indicadores se deve, especialmente, a origem dessas métricas.

De onde vem essas métricas?

Se você já trabalhou na indústria, especialmente nas áreas relativas à performance e manutenção, já deve ter ouvido falar dessas métricas. Sim, MTTR e MTBF tem uma forte relação com o hardware da indústria. Como você pode deduzir, esses KPIs podem ajudar a entender (e até “prever”) quanto tempo um equipamento ficará em funcionamento; quando encaixar melhor as rotinas de overhaul; tendo em vista otimizar a performance e a produção da linha.

Com base nessas métricas, eu posso definir qual equipamento adquirir. Talvez um equipamento que tenha um alto tempo de funcionamento pareça o mais adequado para minha linha de produção. Mas se esse equipamento, quando fica indisponível, levar uma semana para ser reparado, talvez não seja a melhor escolha para a minha operação. Neste caso, apesar do MTBF ser ótimo (porque é alto), o MTTR inviabiliza a aquisição (porque também é alto).

Mas onde entra o software nessa conversa toda?

MTTR e MTBF aplicados ao desenvolvimento de software.

É possível traçar um paralelo entre os equipamentos de uma fábrica e o software em produção, no que diz respeito a extração de MTTR e MTBF. Um desses paralelos é que, em ambos os casos, quanto melhores esses indicadores, mais alto é o custo do equipamento/software. Por isso é muito importante considerar essas métrica na razão disponibilidade x criticidade, a fim de otimizar recursos e tempo.

Por exemplo: Consideremos duas soluções. A “Solução A” é responsável por executar processos de baixa criticidade. Por outro lado, a “Solução B” é responsável por processos importantes e é altamente requisitada. Se a “Solução A” ficar indisponível, qualquer dado é reversível. Se a “Solução B” ficar indisponível, você pode corromper dados e inviabilizar processos. Em qual delas você investiria mais?

O entendimento de criticidade é relativo, e deve ser a síntese entre os interesses de negócio e de tecnologia.

Do ponto de vista de negócio, a análise de criticidade pode considerar desde a queda da satisfação do cliente até a perda de dinheiro (ou gastos com processos jurídicos), que uma indisponibilidade pode gerar.

Já do ponto de vista tecnológico, a criticidade pode variar do throughput da aplicação até a cadeia de integrações da qual a aplicação faz parte. Afinal, um serviço de SMS pode ser pouco importante, mas se as vendas param por uma indisponibilidade dele, esse serviço tornou-se crítico.

Como calcular o MTTR?

Essa é a parte mais simples. O primeiro ponto é estabelecer o período que você deseja considerar. Quer saber a disponibilidade por dia, semana, mês ou ano? Dentro desse período, some o total de tempo indisponível (TI) e divida pela quantidade de ocorrências (QO) de indisponibilidade. Assim temos a fórmula:

MTTR = TI / QO

Se em um ano, tivemos 2 falhas de 10 minutos, 3 falhas de 30 minutos e 1 falha de sessenta minutos, o nosso MTTR é:

MTTR = (10 + 10 + 30 + 30 + 30 + 60) / (2 + 3 + 1)

MTTR = 170 / 6

MTTR = 28,3 minutos

Isso quer dizer que, quando falhamos, levamos (em média) pouco mais de 28 minutos para restaurar o sistema. Como você pode perceber, o período levado em consideração influencia diretamente no indicador. Apesar de você poder considerar períodos curtos para análise, como um dia, por exemplo, o resultado pode ser pouco construtivo. Que tal considerar períodos maiores, como um ano?

Como calcular o MTBF?

De igual maneira, vamos considerar um determinado período “P”. Também conte a quantidade de ocorrências de indisponibilidade (QO) e o tempo total de indisponibilidade (TTI). O que nos dá a seguinte fórmula:

MTBF = (P – TTI) / QO

Apesar do nosso dado de referência ser o tempo entre falhas, subtrair o total de indisponibilidade do período considerado, nos dá exatamente o tempo de disponibilidade real da aplicação. Vamos a um exemplo de aplicação: Considere um período de 525.600 minutos (aproximadamente um ano) e o mesmo quadro de falhas que apresentamos no exercício do MTTR. Assim temos:

MTBF = (525.600 – 170) / 6

MTBF = 87571,6 minutos ou pouco mais de 60 dias.

Com isso, estamos dizendo que, em média, a cada 60 dias temos uma falha no sistema.

Como conseguir bons indicadores de MTTR e MTBF?

E nesse momento você deve estar se perguntando: Como conseguir bons indicadores de MTTR e MTBF? A resposta não é simples. Você precisa considerar os valores de resiliência e redundância, aplicados aos caminhos do software e a infraestrutura.

Como escrever software resilientes?

Resiliente é o software que sabe reagir aos cenários de exceção, sem levar ao caos completo.

A primeira e fundamental dica para escrever softwares resilientes é ter em mente que os seus recursos não são infinitos. O disco pode ficar cheio; a rede pode cair ou aumentar a latência; um banco de dados pode falhar; os serviços dos quais sua aplicação depende podem ficar indisponíveis. E em todos esses casos, a sua aplicação não pode propagar – ou aumentar – o caos.

Um software resiliente sabe como reagir em todos esses cenários. Existem muitas técnicas para superar o caos. Você poderia, por exemplo, implementar um circuit breaker, redirecionando os comandos da sua aplicação para outro lugar (uma fila, por exemplo) para processamento posterior. Esse é apenas um dos exemplos (e nem é o melhor) de como solucionar um caso de indisponibilidade. Existem tantos outros, que detalhá-los fugiria ao escopo deste artigo.

Mas prosseguindo com o exemplo dado: Filas são ótimas, mas também complicadas. Você precisa se preocupar com a própria indisponibilidade do broker, a incompatibilidade de contratos, como tratar as mensagens que estão inválidas… E quando você percebe, o custo desta aplicação já está nas nuvens (com o perdão do trocadilho).

Como escrever software redundante?

Não se trata de escrever o software duas vezes, ou o dobro de linhas de código. Se pensarmos ao pé da letra, não existe software redundante. Na realidade, o que existe é um software que se permite redundante. Explico:

Já trabalhei com sistemas em que levantar uma segunda instância era problemático. Sistemas stateful, que mesmo com as opções de session affinity habilitadas, não permitiam a execução de uma segunda instância. Quer seja por uma limitação de licença, quer seja porque a aplicação não foi pensada para trabalhar num cenário de concorrência. E como fruto dessa limitação, você sobre com deadlocks no banco de dados, por exemplo.

Um software redundante, para começo de conversa, é stateless. Só com isso, já não demanda de “bruxarias” de infra para possibilitar o seu funcionamento, além de possibilitar que “N” instâncias da mesma versão sejam disponibilizadas. Com tantas instâncias no ar, um software redundante também se preocupa com cenários de concorrência. Isto se traduz em um software que extrai o melhor do processador, fazendo uso de tantas threads quantas o processador suporta (considerando a performance). E também se traduz nas operações no banco de dados, que não devem gerar deadlocks quando num cenário de alta concorrência.

Como ter uma infraestrutura resiliente?

Aqui confesso que infraestrutura ainda não é a minha área principal. Estou cercado de ótimos profissionais, que são especialistas no assunto, e me ajudam cotidianamente. Mesmo assim, gostaria de deixar os meus “20 centavos” sobre o assunto.

Ainda que redundância seja uma característica que permite a resiliência, quero tratar as duas de forma distinta.

Parte da resiliência em uma infraestrutura, está na habilidade de ser facilmente reconstruída. Agora imagine você reconfigurar manualmente toda a estrutura de uma aplicação ou de toda a empresa “NA MÃO”? Por isso, a resiliência EXIGE que a infraestrutura se apresente, também, na forma de código. Sem o famoso Infra as Code, o MTTR pode vir a ser muito alto.

Empresas tem turn over, e mesmo que não tivessem, pessoas se esquecem. Por isso, a resiliência de uma infraestrutura também reside nas automações.  Um exemplo claro de tarefas que podem ser automatizadas são as renovações de certificados e tokens de autenticação. Ter essas tarefas básicas automatizadas, previnem indisponibilidades triviais – e muito comuns. Sem contar que, nesse caso específico, também aumentam a segurança.

Por fim, uma infra resiliente é aquela que, à luz do que acontece com o software, também sabe reagir em cenários de exceção e caos. Quando algo errado acontece com a infra, ou com o software, ela sabe a quem deve notificar – e não apenas mostrar em dashboards confusos e cheios de cores. E não o bastante, ela também sabe o que fazer automaticamente. Um bom exemplo é o Kubernetes que, quando um pod deixa de responder, o k8s simplesmente levanta um outro no lugar. Sem a necessidade de intervenção humana.

Como ter uma infraestrutura redundante?

O tema redundância é vasto.  Podemos falar de redundância local ou redundância geográfica e outros tantos modelos. Mas o fato é que o conselho do meu avô resume bem o tema:

Quem tem dois, tem um. Quem tem um, tem nenhum.

AVÔ, Meu

Para os serviços mais críticos, é importante ter uma infraestrutura de backup, pronta para substituir aquela que apresenta defeito. Seja a possibilidade de levantar todo um novo cluster e só redirecionar um Application Gateway, seja ter uma VM com a solução configurada e esperando apenas se ligada.

Em tempo, também é preciso considerar a redundância de banco de dados, de armazenamento, e de recursos em geral. A depender do caso, pode valer muito a pena considerar soluções PaaS, especialmente aquelas que oferecem geo-redundância.  Assim, se um caminhão cair no datacenter, você não perde os dados da sua empresa.

É óbvio que toda essa redundância pode aumentar – e muito – o custo de uma solução. No entanto, lembre-se que é preciso equalizar o MTTR e o MTBF das aplicações de acordo com a sua criticidade. E acredite: A sua solução não é totalmente crítica. Apenas parte dela que é.

Indicadores são altamente empoderadores. Especialmente quando os utilizamos como diagnóstico de um cenário dado. Aqui mostramos que o MTTR e o MTBF podem ajudar até mesmo na tomada de decisão a respeito da infra ou complexidade arquitetural da aplicação. Mas se observados sozinhos, podem enviesar a leitura. Por isso, vamos continuar falando de outros indicadores de engenharia nos próximos post. Até lá!