A lentidão é o novo vilão

Ouvimos de nossos clientes que "Devagar é a nova desaceleração". Ter um desempenho ruim nos aplicativos é tão ruim quanto depender da maioria dos proprietários e operadores de aplicativos modernos. FAANG as empresas acostumaram os consumidores a um desempenho excelente e consistente, e os consumidores que são clientes de outros softwares começam a ter as mesmas expectativas, especialmente quando os concorrentes em um mercado concorrido oferecem uma boa experiência ao usuário.

Alguns clientes até nos disseram que um desempenho lento pode ser pior do que uma inatividade total. Ter algo que parece quase funcionar e depois tentar novamente várias vezes é mais irritante do que simplesmente não funcionar. Por exemplo, a qualidade da voz sobre IP é ruim, com ambas as partes tendo que repetir o que disseram várias vezes, em vez de estar indisponível, o que faz com que as pessoas usem um telefone celular ou fixo.

A importância de atender às expectativas de experiência do cliente é reconhecida como alta em todos os setores. Uma pesquisa de 2020 do setor varejista descobriu que melhorar a experiência do cliente era uma das principais prioridades digitais para quase um terço (32%) dos entrevistados. Mais de 71% citaram a melhoria da experiência do cliente como o principal resultado comercial de curto prazo que buscavam com os esforços de transformação digital.

Agora, certamente é o caso de que tanto os operadores quanto as partes interessadas nos negócios se preocupam com seus usuários. Uma das razões pelas quais o baixo desempenho não é resolvido é a falta de visibilidade sobre o que causa a "lentidão" ou o que "lentidão" significa para um aplicativo como o deles. Às vezes, essa falta de visibilidade é o resultado direto de uma falha na medição de alguma coisa.

Uma pesquisa da Turbonomic expõe esse fenômeno (ênfase adicionada): "Quando perguntamos aos entrevistados como suas organizações estão medindo o desempenho dos aplicativos, foi promissor ver que mais de 60% o medem de alguma forma. Mas a abordagem mais comum era medir a disponibilidade, em vez de gerenciar os Objetivos de Nível de Serviço (SLOs), que normalmente assumem a forma de tempo de resposta ou rendimento de transações. 13% não medem o desempenho do aplicativo.

Mas antes de elogiar aqueles que medem , observe o que eles estão medindo. A abordagem mais comum para medir o desempenho era medir a disponibilidade. Disponibilidade é uma medida de aumento ou redução. Não é uma medida de lentidão ou rapidez, embora pudéssemos passar um blog inteiro (ou mais) argumentando que deveria ser assim.

Mas isso não acontece, e uma das razões pode ser encontrada na mensurabilidade dos custos do negócio. O impacto financeiro do tempo de inatividade é bem documentado. Podemos encontrar diversas fontes que fornecem detalhamentos dos custos em toda a organização. Mas e quanto ao desempenho? Temos algumas pesquisas que destacam as respostas dos usuários na forma de abandono ou mídias sociais negativas. Mas os custos reais para o negócio? Quase inexistente.

Em geral, podemos resumir o problema de medir o desempenho hoje como "Não medimos o custo da lentidão. Medimos o custo do tempo de inatividade." Os seres humanos tendem a trabalhar para atingir aquilo pelo qual são avaliados. Este não é um conceito novo e, na verdade, é um dos princípios do DevOps e a razão pela qual a metodologia inclui uma mudança nas medições em direção ao que é mais importante. Na F5, planejamos ajudar você não apenas a medir em uma escala absoluta, mas também em relação a dados de aplicativos de outras pessoas, para ver como seus usuários finais estão experimentando seus aplicativos em comparação com a experiência deles com outros aplicativos semelhantes.

O que mais importa é atender às expectativas dos usuários finais e hoje isso significa mais do que apenas disponibilidade; significa rapidez e confiabilidade também. Planejamos ajudar os proprietários de aplicativos não apenas com dados e visualizações sobre a experiência do usuário final, mas com insights, declarados em linguagem natural, como "As mudanças que você enviou para a produção no fim de semana melhoraram a experiência típica de segunda-feira de manhã para seus usuários finais, ótimo trabalho!" ou "Sua experiência para usuários do Chrome em Nova York deve piorar do que a média para aplicativos bancários como o seu em quatro dias. Aqui está a alteração na política de balanceamento de carga que recomendamos que você faça nos seus balanceadores de carga NGINX na AWS US East. Sinta-se à vontade para fazer a alteração você mesmo ou clique aqui para que façamos a alteração para você.”

Se você quer respostas para perguntas como:

• “Meus usuários finais estão tendo uma boa experiência no geral? 
• Como é a experiência deles em comparação com aplicativos semelhantes ao meu? 
• Posso expor um indicador de saúde simples para meu aplicativo que incorpore uma experiência adaptável do usuário final para minhas equipes de suporte monitorarem? 
• Que medidas posso tomar para melhorar a experiência do usuário final? 
• O que posso fazer para manter a mesma experiência do usuário final, mas com custos mais baixos? 
• Os usuários finais que têm uma experiência ruim vão embora ou voltam?” 

...então fique ligado nos próximos artigos onde entraremos em mais detalhes.