Performance garantindo um IPO tranquilo.

A SOMOS, estava prestes a realizar o IPO na bolsa de NYC, a NASDAQ através do nome VASTA. Com isso, um questionamento foi feito ao presidente da cia. “Já imaginou o que ocorreria se logo após o IPO ou no mesmo dia do IPO, houver um aumento no volume de acessos e a plataforma não suportar e ocorrer incidentes de indisponibilidade?”

Este questionamento mexeu no âmago do Presidente da SOMOS e fez com que ele se inquietasse e chamasse as pessoas de sua confiança (Felipe do Valle, Luiz Nogara, Ricardo Schneider, Reinaldo Mello e Alex Pinheiro) e compartilhasse o desconforto. 

Logo a pergunta que pairava no ar era. “O Plurall (Plataforma de Ensino da SOMOS) consegue suportar um alto volume de acessos?”. 

Estava claro para o cliente que ele precisava de algum tipo de teste para avaliar qual a capacidade suportada por sua plataforma.

Quando o problema reportado pelo cliente chegou até a Keeggo ficou claro que a necessidade deles era um teste de stress, pois somente este tipo de teste responderia a dúvida, “Quanto minha plataforma suporta?”, o que chamamos de ponto de ruptura.
Ou seja, até qual volume de usuários a plataforma consegue responder com um tempo de resposta aceitável para o negócio.

Quando nos reunimos internamente para, de fato, redigir a proposta, sabíamos que o prazo era curto. Poucos dias. Sim DIAS. Mas tínhamos em mente o quão importante era responder essa pergunta. 

Logo a pergunta que pairava no ar era. “O Plurall (Plataforma de Ensino da SOMOS) consegue suportar um alto volume de acessos?”. 

Um dos primeiros questionamentos que fizemos ao cliente foi. Qual o seu fluxo crítico na plataforma? Quais são as funcionalidades mais acessadas e mais significativas para seus clientes? Quais funcionalidades não podem, de maneira nenhuma sofrer com lentidões e ou algum tipo de indisponibilidade?

Confiança mútua e colaboração entre cliente e o nosso time.

Munidos de todas essas informações, pudemos elencar os caminhos mais críticos dentro da plataforma e criar uma proposta de trabalho para a SOMOS.

Quem ficou encarregado de atuar conosco nesta frente foi o Felipe do Valle.

Assim que tivemos um OK verbal da proposta enviada, já partimos para a construção dos robôs de teste. Pois sabíamos que o tempo era muito curto. Tínhamos pouco mais de 3 dias para construir todos os robôs e a execução seria no final de semana que precedia o IPO.

O Resultado precisava sair antes do IPO e isso era primordial para a tranquilidade da SOMOS como um todo. 

Solução e time foram modelados para que o cliente atingisse seu objetivo.

Já pensou como estaria a cabeça do CEO da SOMOS, Mario Ghio, sem dados consistentes que sua plataforma suportaria de forma adequada o volume de acessos de seus clientes durante o IPO?

 O desenrolar do projeto foi um tanto complexo, mas nos revezamos para que pudéssemos atingir o objetivo. Trabalhamos com 3 pessoas na construção dos robôs, pois quando um parava, outro dava continuidade. A ideia era que não parássemos nem por um minuto. Não podíamos perder tempo algum. Cada segundo contava.

Os robôs foram concluídos na sexta-feira às 11h da noite. 

Foram realizadas inúmeras execuções no decorrer de sábado e domingo, vários pontos de ajustes foram listados durante as execuções e já foram implementados ali mesmo.

O resultado foi que a plataforma conseguiu suportar bem mais que o 2x o volume esperado de usuários e isso foi comemorado fortemente por nós e pela equipe da SOMOS ao término do domingo.