Em redes de computadores e sistemas, monitorar o funcionamento faz parte da rotina dos administradores de redes, ou DevOps. Em ambos os ambientes, existem métricas que ajudam no entendimento da saúde da operação. Hoje, quero explicar um pouco sobre alguns KPIs de falha e as diferenças entre eles. Quando pensamos em falha, é estranho pensar em medição, mas sim, é importante observar essa variável, pois com ela conseguimos saber o que fazer, onde fazer e por que fazer. Dessa forma, melhorar a eficiência e qualidade se torna algo objetivo e orientado à falha.
Comecemos com a falha. Imagine que uma falha, ou interrupção, acabou de acontecer. Vamos chamar essa referência temporal de instante zero, ou t_0. Desse momento até o responsável pela garantia de funcionamento do sistema ou rede receber essa informação, chamamos de MTTA, ou Mean Time To Acknowledge. Esse tempo representa a média de quão ágil você é em reconhecer que uma falha ocorreu. Em algumas situações, isso parece óbvio, pois esse tempo pode estar relacionado, dependendo do que a falha afeta, à experiência de outros recursos utilizados por outras pessoas. O que quero dizer com isso? Vamos entrar no ambiente de redes de computadores e infraestrutura de redes externas FTTx. Rompimentos de cabos ópticos são muito comuns em redes ópticas e isso gera um efeito de falha na transmissão de sinal de uma operadora para os seus assinantes. Comumente, essa falha é chamada de "falha massiva de rede". Nessas falhas, o MTTA pode ser verificado por diversas "personas" da operadora. É importante saber qual persona é responsável por dar uma tratativa adequada ao problema para saber quando ela recebe um alerta de que algo precisa ser feito. Exatamente o tempo entre a falha e essa persona receber o alerta se torna o MTTA. Desse momento do alerta até o reestabelecimento do sistema, temos outro KPI, o primeiro MTTR que falaremos: o Mean Time To Respond.
Notem que disse o primeiro MTTR. Isso acontece porque esse acrônimo pode ser utilizado para representar pelo menos 4 KPIs: Mean Time To Respond, Mean Time To Repair, Mean Time To Recover e Mean Time To Resolve. Exatamente, são muitos MTTRs e toda vez que estiver conversando com alguém sobre MTTR, é de suma importância entender o que ela está considerando como MTTR. Pode existir conflitos nos entendimentos de cada um, mas é importante saber o que marca o início e fim do parâmetro que está sendo medido. Ao menos esse nível de entendimento precisa estar claro entre as pessoas quando esse for o assunto.
Conforme expliquei anteriormente, o Mean Time To Respond possui características bem definidas de início e fim, sendo o início o instante que o responsável por atuar na falha recebe um alerta para atuação, podendo ser um alerta automatizado e sistêmico, ou até uma notificação por pessoas, como por exemplo um call center com ligações sendo utilizado como "termômetro" e que direciona uma tratativa para a falha. Já o instante final do Mean Time To Respond é caracterizado pelo reestabelecimento do sistema. Note que dentro desse KPI podem existir diversas atividades até se iniciar efetivamente o reparo. O que quero dizer com isso? Se eu já recebi o alerta, por que ainda não comecei o reparo? Pois é, saber que existe um problema é a primeira etapa para tratá-lo. A segunda pode ser descobrir qual é o problema. Até iniciar o reparo, pode ser necessário fazer um troubleshooting no sistema ou rede para descobrir o que está causando a falha. Só depois de descoberto o problema é possível criar um plano de ação, podendo esse plano de ação já ser pré-definido para situações de falhas mapeadas, ou seja, processos mapeados para determinadas causas das falhas. Às vezes, os planos de ação envolvem outras equipes e pessoas, logo, há a necessidade de acionar os devidos responsáveis que, por sua vez, podem iniciar o reparo.
Chegamos ao início do reparo na nossa falha "simulada". Esse instante representa o início de um outro KPI com acrônimo de MTTR: o Mean Time To Repair. Exatamente, esse instante inicial é quando o reparo se iniciou, mas a falha ainda não foi reparada por completo. O instante final para esse KPI também se dá no momento em que o sistema é reestabelecido, o mesmo instante final do Mean Time To Respond. Apesar de possuírem momentos finais semelhantes e tempos sobrepostos na linha do tempo, são parâmetros que medem a performance em momentos diferentes. O Mean Time To Respond pode apontar que é necessário melhorar o processo de análise da causa da falha para ser mais ágil no início do reparo. Ser assertivo nas atividades anteriores ao instante de início do reparo ajuda na melhora do Mean Time To Respond, mas não necessariamente no Mean Time To Repair. Por quê? Caso a etapa de análise da falha não tenha sido assertiva para direcionar a equipe ou responsável ideal para realizar o reparo e, ao chegar no local, verificar que a tratativa inicialmente mapeada não é a adequada, o reparo não se inicia, ou seja, o Mean Time To Repair não tem seu início definido. Já o KPI do Mean Time To Repair pode mostrar a eficiência profissional do responsável pelo reparo, a complexidade do reparo versus tipo de falha, etc. Note que entre a falha e o reestabelecimento, apresentei três KPIs com instantes de início e fim bem definidos. Existe um outro KPI que contém esses três KPIs dentro dele, mas que por natureza perde a granularidade de informação: é o MTTR Mean Time To Recover.
Mean Time To Recover tem seu início no mesmo instante inicial do Mean Time To Acknowledge, ou seja, o instante t_0 da falha. Já o instante final é o mesmo momento compartilhado com o Mean Time To Respond e Mean Time To Repair: o reestabelecimento do sistema. Em um nível "macro" e dependendo do que se deseja observar na saúde da operação, esse parâmetro pode ser suficiente. Mas como comentei anteriormente, perde-se a "granularidade" da informação e isso está diretamente ligado à efetividade das ações necessárias para melhorar a saúde da operação.
Como última definição do acrônimo MTTR, ao menos para esse artigo e que tenho conhecimento, existe o Mean Time To Resolve. Esse KPI mede algo que, por muitas vezes, é desconsiderado nas operações: a resolução do problema. Aqui, o tempo inicial também se dá no instante da falha, porém, o instante final é apenas quando o problema é resolvido, podendo esse momento ser igual ao dos demais MTTRs apresentados até agora, ou até mesmo maior. Isso acontece porque a definição de resolvido nesse KPI indica que foi realizado algo para o problema que causou a falha não voltar a acontecer. Logo, ainda que a recuperação do sistema ou serviço tenha ocorrido, se o sistema ou serviço ainda estiverem sujeitos às falhas pelos mesmos motivos, o instante final do Mean Time To Resolve ainda não aconteceu.
A recorrência de falhas também é importante de se medir e, quanto maior for o MTBF, ou Mean Time Between Failures, melhor a condição de saúde da operação do sistema. Até então, falamos de KPIs que queríamos que fossem o menor possível. Esse não é o caso. MTBF indica que sua rede demora para falhar depois da recuperação. Aqui, temos o instante inicial no momento de recuperação do sistema e o instante final na próxima falha. Quanto maior esse indicador, maior o período de tempo que o sistema está operando conforme o esperado. Diferente dos KPIs anteriores, MTTA e MTTRs, que ajudam na visualização de ações corretivas, o MTBF pode indicar o quão efetivas são as suas ações de prevenção de falhas.
Além da recorrência das falhas reparáveis, existe a ocorrência de falhas não reparáveis. Para isso, existe o Mean Time To Failure, ou MTTF. Com esse KPI observa-se a durabilidade do sistema. Para sistemas de longa durabilidade, o uso desse parâmetro para análises é menos recomendado, pois pode simplesmente dizer "nada com nada".
Como comentei anteriormente, cada indicador tem a capacidade de indicar algo. Mais do que medir esses parâmetros, é importante ter em mente que os KPIs não fazem milagres. Saber interpretá-los e tirar deles os insights necessários para tomadas de decisões estratégicas que impactam é o "game changing" para os negócios.
