MTTR não significa “tempo médio para reinicializar”

Falhar rápido é o mantra da velocidade hoje em dia. Seja DevOps ou negócios, a premissa de operar em uma economia digital exige um tempo de atividade o mais próximo possível da perfeição.

Embora a teoria dessa filosofia seja boa, na prática o resultado geralmente é apenas mais fracasso. Ao não focar em encontrar a causa raiz (MTTR) e, em vez disso, apenas em garantir a disponibilidade (tempo de atividade), estamos perdendo dados valiosos em taxas sem precedentes. Aceite a realidade: quando o tempo de atividade é tudo o que você se importa, o MTTR se torna Tempo Médio para Reinicialização em vez de Tempo Médio para Resolução . E sem uma resolução — um motivo para o tempo de inatividade — você não pode evitar que isso aconteça novamente.

Essa abordagem é prejudicial para o negócio.

Veja bem, você não está jogando pacotes, você está jogando partes de moedas de um centavo. E como nos ensina o clássico clichê criminoso de desviar frações de centavos de transações para acumular milhões, cada fração de centavo conta. A cada segundo em que um componente, um serviço ou um servidor não responde, você perde valor, tanto experiencial quanto existencial. Os consumidores não toleram desempenho ruim ou tempo de inatividade, e os registros comerciais também não podem tolerar nenhuma das duas coisas.

E se você sabe alguma coisa sobre taxa de transferência e largura de banda, sabe que a base para ambos os cálculos está nos pacotes por segundo que podem ser processados pelo sistema subjacente. Isso não é verdade apenas na rede, mas para cada componente que interage com uma transação. O aplicativo. Os serviços do aplicativo. Roteadores. Interruptores. Bancos de dados. Se tiver uma conexão de rede, ele estará vinculado a esse mesmo cálculo e limitado por sua capacidade de transmitir pacotes.

AVISO: MATEMÁTICA À FRENTE

A velocidade das redes atuais garante que estamos fazendo exatamente isso, a uma taxa de milhões de pacotes por segundo. As transações comerciais, é claro, são conduzidas principalmente por meio de uma rede (literal) de transações HTTP, cada uma delas transmitindo informações cruciais para a condução dos negócios. O número de pacotes necessários para conduzir uma transação depende da quantidade de dados necessária. O pacote médio transporta 1500 bytes de dados (essa é a MTU). Então, se uma mensagem baseada em HTTP contendo uma carga JSON que representa uma transação requer 4500 bytes (após a criptografia, é claro), isso equivale a cerca de três pacotes. Então, sejamos generosos e digamos que uma transação comercial digital típica requer cinco pacotes. Uma rede de 10 Gbps pode processar pouco menos de 15 M de pacotes por segundo. Supondo que haja capacidade de computação suficiente disponível, você poderia dizer que isso equivale a 3 milhões de transações. Vamos supor que cada transação valha uma fração (um terço) de um centavo. Isso é US$ 1 milhão por segundo.

Hoje em dia, ninguém processa transações nessa velocidade ou volume. Até mesmo a Visa — que indiscutivelmente processa dados a taxas que a maioria das empresas não exige — afirma que sua capacidade é de cerca de 24.000 transações por segundo. Supondo o mesmo valor dessas transações — um terço de um centavo — ainda seriam US$ 8.000 por segundo.

O ponto é que a falha na cadeia de transações composta por roteadores, switches, infraestrutura de serviços de rede e aplicativos, infraestrutura de aplicativos e componentes é uma coisa muito ruim™. É caro, porque uma falha significa que os pacotes não estão sendo processados, nem os centavos que eles representam. E não há nenhuma parte da economia digital que não dependa da transmissão de pacotes.

A resposta até agora está no mantra "falhe rápido" - basta criar uma nova instância de X, Y, Z ou qualquer componente que falhou. Mas esse componente falhou *por uma razão* e é de extrema importância que a razão seja descoberta e tratada. Rapidamente. Porque ainda há segundos caros entre a falha e a restauração que custam valor comercial. Se falhou uma vez, é provável que falhe novamente. E de novo.

VISIBILIDADE: A PEDRA FUNDAMENTAL SOBRE A QUAL O MTTR SE APOIA

É por isso que a visibilidade é tão essencial para o sucesso na economia digital. Porque é a visibilidade que permite que todas as operações encontrem e remediem a causa da falha. Infelizmente, a visibilidade é muitas vezes sacrificada pela velocidade. Não é a velocidade literal das transações, mas o tempo de retorno do investimento. Na nossa pressa em lançar aplicativos no mercado com mais rapidez e frequência, não investimos adequadamente para permitir a visibilidade necessária para mitigar falhas.

Na verdade, pode-se argumentar que a filosofia de "falhar rápido" do DevOps é uma resposta a esse fracasso. Sem a capacidade de encontrar e resolver a causa da falha, o DevOps determinou que é melhor restaurar a disponibilidade do que perder tempo. Essa capacidade está se tornando cada vez mais difícil de ser alcançada à medida que as organizações adotam abordagens multinuvem para implantar aplicativos.

Em 2018, o desafio da visibilidade em multinuvem foi citado por menos de um terço (31%). Em 2019 , esse número saltou para mais de um terço (39%), empatando com desempenho e segurança como os principais desafios para multinuvem. A visibilidade é um componente crítico da abrangente "observabilidade" que reúne monitoramento, análise e alertas para fornecer insights valiosos sobre o estado de um sistema a qualquer momento. Isso é particularmente importante durante uma falha, porque o estado do sistema é distribuído entre vários feudos de TI que podem ou não permitir o compartilhamento de informações que podem levar rapidamente a uma resolução em vez de apenas uma reinicialização .

A capacidade de uma malha de serviço de agregar valor por meio de rastreamento distribuído é um excelente exemplo de como habilitar a visibilidade. Mas precisamos estender isso para incluir toda a cadeia de serviços de aplicativos que dimensionam e protegem os aplicativos em execução em um mundo em contêineres. E isso inclui componentes e aplicativos distribuídos em execução na nuvem pública que podem fazer parte da cadeia de execução. A visibilidade em todos os ambientes, infraestrutura e aplicativos é necessária para encontrar e resolver problemas que causam tempo de inatividade ou baixo desempenho.

A visibilidade é fundamental para permitir que as organizações voltem a medir o sucesso na Resolução MTT em vez da Reinicialização MTT.