Beto necesita mirar los tres ‘TAs’

Por febrero 20, 2018

Beto estaba estresado. La noche anterior él y su practicante colocaron en producción aquella API crítica que se supone va a generar una montaña de dinero a la empresa. Tenía todo para salir bien: el desarrollo ágil, nada de XGH (eXtreme Go Horse) o POG, pruebas unitarias o integradas…en fin, el estado del arte en términos de desarrollo de software…¡pero no!

Comenzó el día y la cola explotó con un montón de llamadas de clientes que reclamaban que la aplicación que usaba aquella API no estaba funcionando. Caos total: la empresa perdía dinero, un jefe súper enojado y Beto no sabía ni por dónde empezar. No tenía ninguna información concreta sobre el comportamiento de la API. En medio del problema, voltea y mira a Bia en sus auriculares, probablemente colocando en el aire otro arreglo mal hecho. Beto respira, habla con Bia y le pide ayuda. Ella se retira el auricular de una oreja, mira a Beto y le pregunta: – “¿Y entonces?, ¿ya miraste los 3 TAs?”. Beto casi se pone contento, el día iba a ser largo, pero él ya sabía qué hacer. Esto iba a demorar. Lástima de carecer de alguna herramienta que te muestre los 3 Tas…tendría que hacerlo todo manualmente.

¿Está en el aire?

Para empezar, mira si tu API está en el aire. No siempre es sencillo hacerlo manualmente, pero es el primer paso que necesitamos realizar. Las APIs consumidas en diversas partes del mundo pueden presentar disponibilidad parcial. Los clientes de Brasil consiguen usarlas y los de Japón, no.

¿Está lento?

Estar disponible por sí solo no resuelve mucho si la respuesta demora una eternidad. Las encuestas muestran que las aplicaciones son abandonadas con sólo 3 segundos de retraso. Nadie quiere que su API sea la culpable de esto.

¿Está bien?

El último punto que debemos mirar es si la API responde a lo que debería o si la respuesta está completamente “loca”. Cuando pensamos en una respuesta “loca”,  vamos a imaginar que su contenido o su forma no son lo esperado.

Chequear si está todo en el aire, respondiendo rápido y con el contenido y la forma esperada ayuda a tener una API sana y nos hace ahorrar en pastillas para el dolor de cabeza. Mejor aún, asegura que las empresas no pierdan dinero.

Pero … ¿y si Beto tuviera Runscope de CA? ¿Qué hubiera pasado?

Con pocos clics, Beto hubiera creado una prueba básica que mostraría si la API está en el aire y cuánto tiempo tarda en responder. Con esta prueba muy básica, él ya hubiera  dominado dos TAs y podría decir si el problema era disponibilidad o lentitud. Lo más extraordinario de eso es que sería posible probarlo a partir de 12 lugares diferentes del mundo y hasta dentro de su propia casa.

¡Increíble! Pero ¿quién garantiza que la API está respondiendo cómo debe? La respuesta puede ser rápida, pero en caso suceda el temido error HTTP 500, o bien, como Beto no usó XGH, volver un mensaje cool de error.

Pasar por este tipo de situación con Runscope no es un drama. Beto puede crear otra prueba que valide el contenido y el formato del mensaje devuelto, dominando así el último TA. ¿Verdad?

Configurando las dos pruebas, podría haber identificado el problema antes de que el mundo se derrumbara. Mejor aún, en el momento exacto en que una determinada prueba falla, Runscope puede enviar correos electrónicos, abrir tickets y aun así enviar mensajes en Slack. Solamente no corrige el problema quien no quiera.

Es decir, usando Runscope, Beto y la empresa que trabaja podrían tener grandes ganancias. Primero, identificando un problema de forma rápida y proactiva. Luego, compartiendo la información con el equipo para una corrección rápida.

Menos problemas, correcciones más rápidas. Menos costos, más ingresos. Beto duerme tranquilo y Bia sigue haciendo sus arreglos sin que nadie la moleste.

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