As empresas estão cada vez mais preocupadas com o desempenho dos seus servidores e a disponibilidade dos recursos de tecnologia utilizados em seus negócios. Com a ampliação do uso de dispositivos móveis, a expansão da conectividade e aumento das tensões mundiais, as empresas precisam garantir que estão preparadas para o que vier.
Ou seja, seus hardwares, softwares e planos de disaster recovery devem estar preparados para atender às demandas do mercado por uma infraestrutura de TI complexa e dinâmica. Como isso é possível? Através do stress test.
Temos muitos fatores para considerar quando falamos de stress test de TI. Por isso, produzimos este artigo para que você possa tomar uma decisão mais informada sobre qual a melhor forma de analisar sua infraestrutura. Compilamos as seguintes respostas para as perguntas mais frequentes que recebemos sobre stress test. Vamos lá!
1. O que é stress test?
O stress test na tecnologia é um método usado para determinar o limite da infraestrutura de TI. Esse método de melhoria procura estabelecer até que ponto sua infraestrutura, hardware, softwares entre outros podem ser estressados e, a partir daí, fornecer um caderno de recomendações e melhorias.
Em outras palavras, o stress test na TI ajuda as empresas a saberem quais servidores, software e outras tecnologias precisam de manutenção para aguentar picos de requisições, bem como definir as tecnologias que devem ser alocadas para garantir o melhor desempenho da sua TI.
O teste de estresse na área de TI pode ser usado para uma série de finalidades, tais como:
- aumentar a confiabilidade de um ambiente de TI;
- determinar a estabilidade de um ambiente de TI;
- encontrar problemas potenciais antes que eles aconteçam;
- determinar se uma falha será a causa da indisponibilidade da infraestrutura.
Mas via de regra, o principal objetivo do stress test é encontrar falhas e/ou vulnerabilidades em potencial (por exemplo, em um sistema de rede ou em um software) que pode afetar qualquer uma das partes que a compõem. Um teste de stress pode ser realizado com qualquer sistema de TI, desde uma rede local a um ambiente de nuvem; pode ser feito com uma parte do sistema ou com a infra inteira.
Por exemplo: sua empresa está prestes a lançar uma atualização importante no sistema de faturamentos. Antes de chegar ao destino final, o time de desenvolvimento precisa verificar se está seguindo o caminho certo. A única maneira de ter certeza de que está indo na direção certa é testando a tecnologia que você está planejando mudar ou adicionar. Como ela se comporta durante um pico de acessos, como em semanas de fechamento? Essas respostas sua empresa obterá com o stress test.
1.1. Stress test de infraestrutura
Stress tests de infra de TI são usados para garantir a estabilidade e a confiabilidade do sistema. Os testes simulam uma alta taxa de dados e de tráfego e registram como o sistema responde nessas condições. É um dos testes mais importantes para garantir o sucesso das vendas, especialmente em datas comerciais, como black friday e festas de fim de ano. Mas esse não é o único cenário possível: imagine se seu blog é citado por um jornal de ampla relevância? Ou se uma campanha de inscrição e matrícula com data limite gere um alto volume de requisições simultâneas? É muito possível que seu site saia do ar por conta disso.
A falha em garantir a estabilidade pode resultar em perda de vendas e de reputação. Portanto, é vital verificar se os sistemas responderão adequadamente em circunstâncias anormais, bem como se, em caso de sobrecarga, apresentará mensagens de erro adequadas aos usuários, evitando acionamentos excessivos dos serviços de suporte técnico.
Por isso, o stress test de infraestrutura protegerá sua empresa contra esse tipo de prejuízo. Além disso, permite melhorar o dimensionamento de infra, detectar scripts muito pesados e ter mais eficácia no gerenciamento de erros sob condições extremas. Ele pode ter foco em:
Sistemas distribuídos
Em sistemas distribuídos cliente-servidor, os testes devem ser realizados em todos os clientes. O papel do teste é distribuir um volume de estresse para todos e acompanhar como cada cliente reage. Em geral, quando os clientes contatam o servidor, ele começa o envio de dados para teste. No meio tempo, as máquinas dos clientes enviam sinais para o servidor. Se o servidor não receber nenhum sinal da máquina do cliente, é necessário investigar e depurar.
Aplicações
Este teste tem como foco detectar defeitos relacionados com bloqueios de dados, problemas de conexão e gargalos de performance.
Estresse transacional
Testa uma ou mais transições entre dois ou mais aplicativos. É utilizado para otimizar e refinar o sistema.
Sistemas
Teste integrado que considera vários sistemas rodando no mesmo servidor. É usado para encontrar situações em que um aplicativo bloqueia os dados de outro aplicativo.
Explorar cenários incomuns
Explora a infraestrutura e sistemas a partir de parâmetros incomuns ou condições difíceis de acontecer em cenários reais, como:
- grande número de usuários logados ao mesmo tempo;
- se seu banco de dados ficar offline durante o acesso a uma aplicação web;
- se um volume massivo de dados for inserido de uma vez só no banco de dados.
1.2. Stress test de hardware
O teste de estresse de hardware geralmente é voltado para a análise da CPU e consiste em executá-la na capacidade máxima por um período prolongado para avaliar a estabilidade de seu desempenho sob situações extremas. O stress test de hardware mapeia situações, como:
- superaquecimento;
- poeira;
- componentes mostrando sinais de envelhecimento;
- overclock;
- drivers ou versões do BIOS desatualizadas.
1.3. Stress test de software
O stress test de software é realizado para submeter uma aplicação ou feature a situações extremas. Basicamente, avalia-se quanto determinado software a ser implementado na sua empresa aguenta, o que pode ser exigido, se existem falhas decorrentes dessas demandas e quais são elas. Por isso, os testes de stress são fundamentais em aplicações em que a eficiência seja uma característica importante, como:
- files servers e servidores web que devem atender solicitações de um grande número de requisições;
- aplicações em escala industrial;
- sistemas de gestão empresarial;
- games, que precisam de alto desempenho para serem viáveis no mercado.
1.4. Stress test de disaster recovery
Stressar um plano de disaster recovery é crucial para validar o plano de continuidade de negócios e recuperação de desastres da sua empresa. Você pode conferir mais sobre o que é o plano de recuperação de desastres (DR) aqui, mas basicamente, ele consiste no conjunto de processos e ações para garantir que uma empresa possa recuperar seus dados, aplicativos críticos para o negócio e continuar suas operações no caso de uma interrupção grave.
Logo, o stress test de disaster recovery consiste em simular situações de desastre e mapear possibilidades de falha que, porventura, não tenham sido contempladas pela versão anterior do plano. O teste de DR é projetado para ajudar uma empresa a ficar à frente de problemas que podem resultar em perda de dados no futuro.
As etapas para realizar esse tipo de teste diferem um pouco do processo de stress test de infra, hardware e software. Podemos resumir nos seguintes passos.
Categorizar tipos diferentes de desastre:
- desastres naturais, como incêndios florestais, inundações e deslizamentos de terra podem quebrar a cadeia de suprimentos, impedir que os colaboradores cheguem até a empresa e destruir a instalação ou equipamentos da empresa;
- biológicos, como em caso de pandemias, que também interferem na cadeia de suprimentos, continuidade dos negócios e operações;
- operacionais, por exemplo quando uma empresa perde um chefe de departamento muito renomado;
- tecnológicos, causados por falhas de conexão, perda de dados, ciberataques, etc, que geralmente têm como causa raiz erros humanos e negligência.
Sistemas de TI raramente são estáticos, então cada vez que seu time implementa uma nova tecnologia ou instala uma atualização de sistema, é preciso realizar os testes novamente. Outro fator é a cloud computing: cada vez mais organizações estão migrando para a nuvem, provocando grandes mudanças no cenário de TI. Um stress test de recuperação de desastres ajuda a garantir que o plano de DR da sua empresa permaneça atualizado em um mercado que se atualiza constantemente.
2. Como funciona um stress test?
Etapa 1: realizar uma auditoria dos recursos de TI
Primeiro, é preciso identificar todos os ativos que existem na infraestrutura de rede e de negócios. Ao criar um inventário de todos os recursos de TI na rede e identificar o que eles contêm, uma empresa pode realizar o stress test.
Etapa 2: entender os níveis de criticidade dos ativos da infraestrutura
Durante a auditoria de ativos, a empresa pode descobrir que muitos dos dados armazenados ou aplicações são desnecessárias e até mesmo prejudiciais para manter o sistema funcionando em alta performance. Isso porque a transferência de todos os dados desnecessários na rede para um servidor de backup pode usar uma enorme quantidade de poder de processamento, por exemplo.
Por isso, a classificação dos níveis de criticidade dos ativos da infraestrutura pode ajudar a reduzir custos, otimizar o desempenho dos sistemas e aumentar a disponibilidade do ambiente.
Etapa 3: criar funções e responsabilidades específicas para todos os envolvidos
Boa prática pela LGPD, essa etapa tem como premissa que cada funcionário em uma organização deve ter um papel a desempenhar. Observe que aqui não estamos falando de um teste automatizado que, embora tenha um propósito importante para as organizações, ele testa apenas os componentes técnicos.
Então, se ocorrer um desastre real e o objetivo for fazer o teste de DR, são as pessoas dentro de uma organização que precisarão saber o que fazer para restaurar rapidamente o tempo de atividade. Ah, e não se esqueça de documentar tudo.
Etapa 4: determinar as métricas de validação
As métricas ajudam a mensurar a performance de um sistema e geralmente são definidas no início e estudadas no fim do teste de estresse. Todo stress test deve ser realizado com base em métricas, sendo as mais comuns:
Escalabilidade e performance:
- páginas por segundo: quantas páginas foram requisitadas;
- taxa de transferência: tamanho dos dados de resposta;
- execução: número de vezes que os cenários de testes foram planejados versus o número de vezes que o cliente foi executado.
Resposta do aplicativo:
- tempo de carregamento;
- tempo para o primeiro byte;
- tempo da página: tempo para o carregamento de todas as informações em uma página.
Falhas:
- falhas de conexão;
- quantidade de falhas;
- tentativas falhas: número de links quebrados.
Trazendo para uma realidade mais reconhecível para quem está entrando agora no universo da TI, o principal é conseguir medir:
- se o sistema, aplicação ou plano de recuperação consegue atingir o objetivo;
- qual o número máximo de transações sem provocar falhas;
- como o sistema vai se comportar caso haja degradação parcial da plataforma de execução;
- se condições de operação difíceis, como registrar operações incorretas, podem gerar falhas.
Etapa 5: estressar o ambiente e acompanhar a evolução dos resultados
Com tudo pronto, seu time está pronto para estressar o ambiente. Para isso, o mercado disponibiliza diversas ferramentas (open source e enterprise) que poderão te ajudar a fazer isso de maneira assertiva.
Aqui vão alguns exemplos de ferramentas para executar o stress test:
- DBMonster: para estressar aplicações SQL;
- DieselTest da Source Forge: simula um número altíssimo de usuários em um site;
- OpenSTA: mede o desempenho de aplicações web e executa testes de carga pesada com script e HTTP e HTTPS;
- tsung: ferramenta open source para simular cenários complexos usando modelagem estocástica de usuários e gerar cargas pesadas a partir de vários nodes;
- HeavyLoad: para testar suas CPUs, escrever arquivos de teste e alocar memória, permitindo que você descubra quão os dispositivos da sua empresa funcionam sobre uso contínuo e pesado;
3. Teste de estresse para sua empresa: quando um serviço de Consultoria de TI focado em stress test é a melhor escolha?
Uma empresa que é focada em atender bem seus clientes e criar oportunidades de negócio tem que ser capaz de se adaptar a uma grande variedade de desafios que são impostos por atores de mercado cada vez mais exigentes. Esses desafios podem ser de natureza técnica, negócios, pessoas ou qualquer outro departamento.
Em cenários de desastres, como ataques cibernéticos e ataques de ransomware, a principal solução de armazenamento de dados de uma organização pode ser destruída, resultando na perda permanente desses dados. Na “melhor” das hipóteses, a empresa pode passar por lentidões e períodos de indisponibilidade provocados por ataques DDoS.
Já em cenários de implementação de novas tecnologias, é muito comum que a nova aplicação ou feature apresente algum problema ou incompatibilidade no ambiente de produção caso não tenha sido devidamente testada. Isso pode gerar desde um desgaste pontual para o time de desenvolvimento, até provocar prejuízos para a organização e expôr o ambiente a ameaças de segurança.
Outro exemplo é um cenário em que os ativos físicos que armazenam os dados da empresa são danificados: por incêndio, inundação ou adulteração humana. Como você pode ver, as possibilidades são muitas e frequentemente estão longe da nossa percepção, seja porque estamos mais preocupados com a parte técnica da testagem ou porque a equipe de TI está culturalmente adaptada a ter uma atitude reativa mediante a infraestrutura.
Afinal, por quê ter uma equipe para executar o stress test junto com o seu time? Bem, já ficou claro que um bom teste de estresse de TI é capaz de detectar quais são os pontos fortes e fracos da empresa e o que ela precisa melhorar para se tornar mais eficiente e mais capaz de atender a clientes cada vez mais exigentes. Porém, ao contar com um time de especialistas para apoiar todo o processo de execução do stress test, a corporação terá acesso a profissionais multidisciplinares, garantindo que seu teste ocorra sem pontos cegos.
Além disso, a grande dificuldade de realizar um stress test por conta própria é configurar adequadamente a ferramenta de execução para que seja possível estudar as métricas estipuladas. Por exemplo: se o avaliador da infraestrutura quer saber qual o mínimo de memória alocada possível para viabilizar o funcionamento de um programa, ele terá de retirar fisicamente chips de RAM, o que é muito trabalhoso. Também terá que pensar em outros parâmetros, como disco, CPU e rede.
Bom, se você chegou até aqui, talvez tenha descoberto que sua empresa precisa rodar um stress test, mas não sabe como justificar para sua diretoria o investimento em ferramentas ou até mesmo em um serviço de consultoria especializada. Então, que tal conferir este artigo do head of sales da Binario Cloud? Neste texto o Gabriel Adorno ensina pra gente como construir argumentos sólidos para justificar o investimento em TI e ferramentas na sua empresa. Confira agora!
