Beto precisa olhar três ‘TAs’

Por Fevereiro 20, 2018

Beto estava tenso. Na noite anterior ele e o estagiário colocaram em produção aquela API crítica que vai gerar uma montanha de dinheiro para a empresa. Tinha tudo pra dar certo. Desenvolvimento ágil, nada de XGH (eXtreme Go Horse) ou POG, testes unitários, integrados, enfim o estado da arte em termos de desenvolvimento de software. Só que não!

Começou o dia e a fila bombou com um monte de chamados de clientes, que começaram a reclamar que o app que usava aquela API não funcionava mais. Caos total. A empresa perdendo dinheiro, o chefe virado do avesso e o Beto não sabia nem por onde começar. Ele não tinha nenhuma informação concreta sobre o comportamento da API. No meio do sufoco, vira pro lado e vê Bia de fone de ouvido, provavelmente colocando no ar mais uma gambiarra. Beto respira, cutuca Bia e pede ajuda. Ela tira o fone de uma orelha, olha para o Beto e pergunta: – “E aí, já olhou os 3 TAs?”. Beto quase ficou feliz, o dia ia ser longo, mas ele já sabia o que fazer. Ia demorar. Pena não ter nenhuma ferramenta que lhe mostrasse os 3 TAs. Teria de fazer tudo na unha.

Tá no ar?

Para começar, veja se a sua API está no ar. Nem sempre isso é uma coisa simples de se fazer manualmente, mas é o primeiro ponto que precisamos olhar. APIs consumidas em diversas partes do mundo podem apresentar disponibilidade parcial. Clientes do Brasil conseguem usar e clientes do Japão, não (até rima!).

Tá lento?

Estar disponível por si só não resolve muita coisa se a resposta demora uma eterniadade. Pesquisas mostram que aplicativos são abandonados por apenas 3 segundos de demora. Ninguém quer que sua API seja culpada disto.

Tá certo?

O último ponto que devemos olhar é se a API responde o que deveria ou se a resposta está doidona. Quando pensamos em uma resposta doidona, vamos imaginar que o seu conteúdo ou sua forma não estão conforme o esperado.

Conferir se está tudo no ar, respondendo rápido e com o conteúdo e forma esperados, ajuda a ter uma API saudável e nos faz economizar remédios para dor de cabeça. Melhor ainda, garante que as empresas não percam dinheiro.

Mas…e se o Beto tivesse o Runscope da CA? O que teria acontecido?

Com poucos cliques, Beto teria criado um testezinho básico que mostraria se a API está no ar e quanto tempo ela demora para responder. Com esse teste basicão, ele já teria dominado dois TAs e poderia dizer se o problema era disponbilidade ou lentidão. O mais legal disso é que seria possível testar isso a partir de 12 lugares diferentes do mundo e até de dentro de casa.

Show! Mas quem garante que a API está respondendo ao que deveria? A resposta pode ser rápida, mas acontecer o temido erro HTTP 500, ou então, como Beto não usou XGH, voltar uma mensagem de erro legalzinha.

Pegar esse tipo de situação com o Runscope é moleza. Beto pode criar um outro teste que valida o conteúdo e o formato da mensagem retornada, dominando assim o último TA. Certo?

Configurando os dois testes, ele poderia ter identificado o problema antes do mundo desabar. Melhor ainda, no momento exato em que um determinado teste falha, o Runscope pode enviar e-mails, abrir tickets e ainda enviar mensagens no Slack. Só não corrige o problema quem não quiser.

Quer dizer, usando o Runscope, Beto e a empresa que ele trabalha poderiam ganhar muito. Primeiro, identificando um problema de forma rápida e proativa. Depois, compartilhando a informação com o time para uma correção rápida.

Menos problemas, correção rápida, menos custo e mais receita. Beto dorme tranquilo e Bia continua fazendo suas gambiarras sem ser incomodada.

Escrito por Leandro Ferreira
Sr Consultant, Technical Sales, APM at CA Technologies
LinkedIn: @leandroferreira