User Experience, alta disponibilidade e resiliência

User Experience (UX), experiência do usuário. Ahhh, a experiência do usuário… O termo que hoje guia cada passo das equipes de negócio, que guia definições de companhias inteiras. A experiência deve ser cuidada não só no que diz respeito à usabilidade (aplicação amigável, bonita), mas também ao desempenho; pois dados (existem diversas estatísticas a respeito) mostram que 53% das pessoas abandonam um site mobile quando demora mais de três segundos para carregar.

Além disso, imaginem áreas internas das empresas sendo extremamente produtivas porque os sistemas têm ótimo desempenho e dificilmente ficam indisponíveis?

Dois cenários mais do que desejáveis para as empresas.

Escalabilidade e Resiliência são as palavras-chave nos cenários citados. Sendo escalabilidade a capacidade de suportar um aumento de volume de utilização, sem que o tempo de resposta aumente demais. E resiliência a capacidade de um sistema de suportar problemas, sem ficar indisponível e sem que os usuários sejam muito impactados.

Mas como criar sistemas com alta disponibilidade?

Atualmente com as metodologias Ágeis e cultura DevOps tudo que se refere à criação de novos produtos, melhorias e correções não podem esperar muito, pois pode haver perda do time-to-market. E novamente, vale a pergunta: Como criar e manter os sistemas com alta disponibilidade? Ainda mais em uma arquitetura distribuída de micro serviços?
Primeiro passo é implementar uma cultura de testes shift-left, ou seja, trazer o mais próximo do desenvolvimento os testes e validações que visam minimizar ou eliminar a chegada de bugs em ambiente produtivo. Estabelecido o shift-left, o que deve acontecer em ambiente produtivo são trabalhos proativos.

Isso posto, alguém pode estar se perguntando: Testes de Desempenho/Stress/Carga, são proativos? Sim, podem ser sim, já que estaremos analisando até onde o sistema aguenta, quais os pontos de quebra etc.

Agora imagine se o shift-left não estiver bem implementado e o teste em produção mostre que a aplicação não foi bem construída e que ela não escala? Todo o investimento em horas-extras (já que o teste deve ser feito a noite para não impactar o ambiente e os usuários), investimento na estratégia de rollback de dados e nas horas de planejamento, dentre outros custos, foi perdido. Já que este problema poderia ter sido detectado em momento de homologação.

O teste de Desempenho/Stress/Carga pode ser útil, por exemplo, para identificar e planejar qual é a capacidade de novas funcionalidades, que não possuem histórico para estimar; caso houvesse um histórico o planejamento poderia ser feito com uso de modelos preditivos (Machine Learning).

O teste pode identificar os problemas, mas não possivelmente todos, e além disso como já citado possui os custos de mobilizar um grande time para atuação fora do horário.

Então, é possível concluir que existem caminhos e cuidados para que a experiência do cliente seja percebida em primeiro plano, de forma simples e eficiente.

*Ronaldo Sales é bacharel em Ciências da Computação pela Unesp Rio Claro, na Yaman é gerente da Divisão de SRE & Automation Services.