Performance que garante um IPO tranquilo e robusto
KEEGGO + VASTA
Caso de Sucesso
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.
“O Plurall consegue suportar um alto volume de acessos?”
PROPOSTA INICIAL
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 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.
CASES
Buscamos as soluções que trazem maior impacto para o negócio.
BLOG
Conteúdos exclusivos
JUNTE-SE A NÓS
Faça parte da nossa aventura!
E ai, curtiu? O café
é por nossa conta :D
