Já expliquei neste artigo que um bug pode sair bem caro. Neste, exemplifiquei em como simples erros de código podem afetar inúmeras pessoas em situações da vida real. Imagina só a porta do metrô não fechar ou você não receber seu pagamento porque o sistema da prefeitura foi invadido e todos os dados foram perdidos? Pois é.

Agora, no entanto, converso especificamente com você, que administra sistemas e servidores principalmente o meio digital. Sabemos que software é imperfeito e os bugs vão aparecer inevitavelmente. Mas quanto eles vão prejudicar seu sistema? E seria tão difícil assim testar algum recurso específico antes de tomar alguma ação? São essas questões que vou analisar neste artigo.

Microsoft: Azure fica fora do ar

Como lembra Vinay Patankar no Process.st, existem vários exemplos do que dá errado se você não segue todos os passos para assegurar que o seu software seja protegido de desastres digitais. E pode apostar que esses erros vão te custar bem mais que uma simples checagem antes de lançar um serviço ou atualização, por exemplo.

Veja este exemplo que Patankar dá no começo do artigo: em 18 de novembro de 2014, o Microsoft Azure, plataforma de computação em nuvem, simplesmente parou de funcionar, deixando milhares de clientes na mão.

Ele voltou logo depois de oito horas e a Microsoft explicou o erro: uma atualização do sistema foi enviada sem antes ser propriamente testada. Os funcionários assumiram que não havia bug algum e apenas enviaram a atualização. Não é brincadeira: essa falta de checagem custou oito horas de servidor fora do ar aos consumidores.

Microsoft Azure

O que poderia ter sido feito?

Tá, nesse caso parece óbvio. Não custaria nada (literalmente!) seguir os padrões já existentes na empresa e certificar que a atualização seguiria sem problemas ― é pra isso que protocolos servem, não? Pois é. Ainda assim, o DatacenterDynamics explica que, em vez disso, eles preferiram confiar no “chutômetro” de funcionários.

Se até a Microsoft passou por isso, imagina quem tem engenheiros menos experientes ou poucos protocolos para colocar em ação em grandes modificações.

Zurich Insurance: perda total de dados

A Zurich Insurance é, como o nome sugere, uma empresa suíça de seguro digital. Mas talvez ela se esqueceu dessa origem quando perdeu dados de 46 mil clientes quando eles apagaram sem querer seus dados em uma transferência de rotina. Haviam diretrizes a serem seguidas… Mas adivinha? Pois é. Elas não foram.

Por conta disso, a empresa foi multada em £ 2,28 milhões, o equivalente a cerca de R$ 8,7 milhões hoje em dia. Provavelmente teria sido bem mais barato investir no teste dessa transferência ― que era feita todos os dias e era crucial para o ramo da empresa.

Target: servidor caiu depois de campanha enorme

Em uma parceria com a designer italiana Margherita Maccapini Missoni, a loja norte-americana de varejo Target lançou uma nova coleção de edição limitada com roupas da marca e que eram desejadas por uma grande quantidade de usuários. Tão grande que, mesmo dispostos a pagar até US$ 4 mil nas peças, fizeram o site cair.

Foi um dos piores momentos para o servidor deixá-los na mão: imagine os meses que foram levados para construir e idealizar toda a campanha e o tanto de consumidores que a loja perdeu por não oferecer o que eles queriam no momento tão esperado.

Target To Lay Off Employees

O que poderia ter sido feito?

Um dos testes mais comuns quando falamos em teste de software é o stress test, que testa o nível máximo de stress que uma aplicação ou servidor consegue resistir até não cair. Dava para ter preparado um teste como esse para ajustar os servidores e o código a se comportar direitinho mesmo com um número volumoso de acessos.

Leia também: 5 perguntas para se fazer antes de testar

Inclusive, segundo Patankar, o site da Target já aguentou muito mais. Eles só não acharam que precisaria testar o servidor antes deste evento, como eles fazem normalmente para a Cyber Monday ou Black Friday, em que consumidores conseguem comprar produtos com um desconto enorme.

Seria melhor ter prevenido, hein?

Buffer: dados não criptografados são roubados

Muitas empresas confiam ao Buffer o acesso às suas redes sociais para ele organizar posts no Twitter, Facebook e várias outras redes sociais, como lembra o Process.st. Acontece que o serviço não deu bons sinais de se comprometer a guardar os dados de usuários de forma segura no final de 2013.

Eles armazenavam as informações sensíveis dos usuários sem criptografia, ou seja, sem embaralhar as informações de uma forma segura de forma que ninguém consiga saber o que significa (nem eles mesmos). Em 26 de outubro, eles foram hackeados e invasores conseguiram acessar várias contas dos usuários, postando o que bem queriam.

O que poderia ter sido feito?

Você também deve imaginar a solução: criptografar os dados! Sim, tanto que, desde o começo do vazamento, a empresa foi super transparente e dias depois já havia criptografado os dados. Meio tarde demais, né?

Safe Lock

Especialmente neste último caso, podemos ver como a negligência afeta muito o mundo digital e como isso pode custar bem caro a uma empresa. A comparação de Pantakar é muito boa (tradução livre):

É o clássico “o que os olhos não veem o coração não sente”, do mesmo jeito que você acha que não precisa de plano de saúde até ser diagnosticado com uma doença rara de pele. Se você está planejando ser hackeado, não vale o esforço de criptografar os dados. Mas novamente: quem se planeja para um ataque hacker ou para contrair uma doença rara de pele?

Já falei aqui no post de senhas sobre o benefício da criptografia. Gerenciadores de senhas como o LastPass já foram hackeados, mas dados sensíveis como as senhas dos usuários continuaram inacessíveis, graças à criptografia.

Ou seja, o LastPass já estava prevenido para um ataque como este. No caso do Buffer, eles só foram ligar para o assunto depois que o ataque e os dados dos usuários foram obtidos por invasores.

“É melhor previnir do que remediar”

Pode parecer clichê, mas esse ditado popular nunca esteve mais certo. Em todos os casos que vimos por aqui, mais atenção do time técnico poderiam ter ajudado a diminuir o impacto de cada falha citada. No entanto, a negligência faz com que claras violações de protocolos sejam vistas como algo normal.

Dessa forma, o recomendado é encomendar testes com agentes externos, já que eles têm o olhar menos viciado e não estão sujeitos à visão parcial de certos problemas que ocorrem dentro da empresa. Como já falamos, teste de software é gestão de risco: você previne que algo aconteça, em vez de tratar o erro logo depois que ele já aconteceu.

Posso garantir que a One Day Testing faz dezenas de testes para assegurar que o seu software não vai te deixar na mão em situações críticas como as citadas acima. Ficou interessado? Basta enviar um e-mail para bruno.abreu@sofist.com.br ou ligue em (19) 3291-5321 para conversarmos. Será um prazer ajudá-lo! =)