User Experiência: 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.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