Header Ads Widget

Ticker

6/recent/ticker-posts

Éxito o fracaso: la importancia de las métricas de API


El éxito y el fracaso son términos relativamente subjetivos: lo que define el éxito de una empresa puede considerarse un fracaso de otra, y el relativo al éxito en determinadas áreas de desempeño puede cambiar de una industria a otra, de un departamento a otro e incluso de un caso a otro. base . Esta volatilidad en las expectativas, los resultados y los impactos puede hacer que la documentación, la implementación y el soporte de la API sea una tarea difícil.

Afortunadamente, quienes trabajan con API tienen una herramienta secreta que puede dar sentido al agitado mundo de la evaluación del desempeño: el análisis métrico . El uso adecuado del análisis de métricas puede permitir a las empresas comprender a sus consumidores y ayudar en el desarrollo y la implementación de API efectivas y fáciles de usar.

Banner básico-01

En este artículo, echaremos un vistazo a las métricas de API para demostrar cómo se pueden usar para amplificar el éxito dentro del espacio de API. Sugeriremos tipos de métricas de API para analizar, demostraremos una aplicación teórica del análisis de métricas y discutiremos dos ejemplos de la vida real de éxito y fracaso que surgen de diferentes metodologías de análisis de métricas. Al final de este artículo, debe tener una comprensión firme de la definición, la aplicación y el impacto del análisis de métricas API adecuado.

éxito-fracaso-importancia-del-análisis-métrico-API
¿Qué es el análisis métrico?

Según el Diccionario de Oxford, las métricas son "métodos para medir algo, o los resultados obtenidos de esto" . Las métricas son la forma en que medimos los valores de una parte específica de un sistema, midiendo un evento desde el inicio hasta su finalización, incluidos los efectos causados ​​por su implementación.

Entonces, ahora que sabemos qué es una métrica, ¿por qué es tan importante para las API? Las métricas y, por extensión, API Metric Analysis , son herramientas invaluables para las empresas modernas. Las métricas se pueden utilizar para desarrollar nuevos procesos, crear una comprensión fundamental del producto y el consumidor objetivo, impulsar una comprensión holística de su proceso de fabricación y metodología de entrega, y crear oportunidades para monetizar y optimizar su API . El uso de métricas de API puede llevarlo a una vista panorámica de todo un proceso de API, siguiendo el antiguo dicho: "no se puede ver el bosque desde los árboles".

Herramientas y servicios de análisis métrico

Hay muchos tipos de métricas que se pueden capturar, analizar y usar para desarrollar sistemas API más efectivos. Las métricas de API se pueden agrupar en gran medida en dos categorías: métricas internas y métricas externas .

Métricas internas

Las métricas internas son aquellas que se derivan de los datos capturados por los servidores web internos, los formularios de comentarios de los usuarios y las tendencias observables a través de los sistemas internos. Éstos incluyen:

  • Tipo de usuario : ¿El consumidor es un usuario habitual o un usuario nuevo?
  • Días desde la última sesión : ¿Cuánto tiempo hace que los usuarios habituales utilizaron la API por última vez?
  • Fuentes de tráfico : ¿Se llaman a las funciones dentro de la API a través de su propia aplicación web o una aplicación de terceros?
  • Agrupación de funciones : la frecuencia con la que un usuario llama a una determinada función junto con otras funciones.
  • Tipos de datos solicitados : ¿Su servidor atiende solicitudes de medios, solicitudes de texto sin formato u otros tipos de solicitudes con más frecuencia que otros?
  • Velocidades de acceso : ¿Qué tan rápido responde su sistema a las solicitudes? ¿Dónde está el cuello de botella?
  • Solicitudes de servicio : ¿Con qué frecuencia se solicitan algunos servicios? ¿Hay algún servicio que nunca se solicite?
  • El informe de errores : ¿Con qué frecuencia informar a un usuario de un error en el sistema, y lo que es el error específico?

Métricas externas

Estas métricas se derivan del uso de procesos y aplicaciones que se originan fuera del desarrollador de API. Si bien las métricas internas se preocupan más por el funcionamiento de la API real y el sistema en general, las métricas externas se centran más en la comunidad y las bases de usuarios potenciales. Estas métricas pueden involucrar sistemas de terceros:

  • Tasas de adopción de API y servicios - WebTrends
  • Redirección y datos de cara al público - Google Analytics
  • Tendencias y comportamientos del mercado - Adobe

Un ejemplo de métricas externas:

texto alternativo

Ejemplo: el problema del tráfico de Tokio

ejemplo-análisis-métrico-API-tokio-japan-downtown-API

Una forma de entender la importancia del análisis métrico es mostrar una situación en la que se aplica correctamente frente a una situación en la que no lo es, comparando los resultados de ambos enfoques. Imaginemos que somos ingenieros para las carreteras de Tokio, Japón, una de las ciudades más grandes del mundo. Tenemos la tarea de resolver un problema de congestión en una de las intersecciones más congestionadas de toda la ciudad.

En primer lugar, abordemos este problema sin utilizar el análisis métrico. Usaremos un enfoque observacional. Al pararnos en un paso elevado que se extiende a ambos lados del área más congestionada de la carretera, anotamos nuestras observaciones en nuestro cuaderno, anotando tanto la cantidad de autos como la cantidad de carriles provistos. Usando estas observaciones, se diseña una solución para expandir la calzada en dos carriles adicionales. El tiempo presupuestado para la construcción se establece en un horario de 24 horas. Usted asume que la congestión se aliviará debido a su solución y se aleja. Unos meses más tarde, la congestión que observó solo se ha extendido a las nuevas carreteras, agravando el problema. El enfoque observacional ha dado lugar a más problemas de los que solucionó y se considera un fracaso abyecto.

Ahora abordemos el problema utilizando un enfoque basado en métricasDespués de que se le asigne el proyecto, primero mira los mapas de carreteras de la ciudad. Observa que la carretera congestionada probablemente enfrenta problemas que surgen de una intersección de semáforo algunas millas adelante del área congestionada; Debido a que la carretera desemboca en una vía de la ciudad antes de continuar hacia otra carretera, esta área funciona como un "cuello de botella", aumentando la congestión al restringir el rendimiento del sistema en su conjunto. Con estos datos, decide agregar una carretera de tres carriles que pasa por alto la vía de la ciudad, lo que permite que el tráfico fluya hacia la intersección y alrededor de ella, dependiendo de las necesidades del conductor. También decide implementar una rotonda en lugar de un semáforo, pensando que el flujo de tráfico debería aliviarse de esta manera. Este plan se coloca en un cronograma de construcción durante un puñado de semanas, evitando trabajar durante las horas pico. Después de implementar esta solución, recopila datos durante toda una semana, tomando notas de los puntos de falla o problemas en ciertos momentos del día. La congestión se ha reducido considerablemente y la solución basada en métricas se considera un éxito.

La solución al problema del tráfico

¿Cuál fue la diferencia entre los dos enfoques? Ambos tenían como objetivo aliviar la congestión y, si bien el primer enfoque era diferente al segundo, en el papel ambos deberían haber funcionado. La diferencia es el uso fundamental de los datos en la implementación.

  • En el enfoque observacional, el problema global de la congestión fue atacado con una solución específica . En el enfoque basado en métricas, el problema global de la congestión se atacó con una solución global .
  • Los problemas surgieron dentro del primer enfoque debido a la falta de comprensión del consumidor final (expandiendo la vía interurbana y usando un programa de construcción de 24 horas que interfiere con las horas pico). El segundo enfoque comprendió los requisitos del consumidor final, creando una carretera de circunvalación y evitando la construcción durante los períodos más congestionados del día.
  • El enfoque observacional evitó el análisis de datos, asumiendo que una solución localizada solucionaría el problema, mientras que la solución basada en métricas observó los resultados medibles de la solución, modificando y ajustándose a cualquier nuevo requisito que surgiera durante la construcción.

El problema del tráfico y las API

Entonces, ¿qué tienen que ver los problemas de congestión de Tokio con el desarrollo de API? Los dos enfoques anteriores son analogías perfectas para el ciclo de desarrollo e implementación de API, y muestran la necesidad medible de análisis métrico. Al desarrollar una API, uno debe monitorear las métricas de API internas y externas para garantizar que su producto sea efectivo a largo plazo. Cuando se desarrolla e implementa una API, se deben considerar los siguientes factores vitales:

  • Las necesidades del consumidor final , es decir, el usuario que interactuará con la API y sus sistemas frontales.
  • El método y la escala de tiempo de implementación , es decir, si la API se implementará inmediatamente o con el tiempo.
  • El tipo de implementación, es decir, si la API es específica (definiendo un uso o propósito único) o global (revisando completamente las estructuras y sistemas ya existentes)
  • La solución medible o los efectos causados ​​por la implementación de su API en su consumidor final

Ejemplo de ciclo de API

ciclo de vida de la api

El ciclo de vida de la API es un proceso ágil para administrar la vida de una API. El ciclo de vida de la API común se compone de cuatro fases distintas: análisis, desarrollo, operaciones y retiro.

Para comprender mejor este concepto, analicemos el ciclo de vida de la API punto por punto, examinando el papel del análisis de métricas en cada etapa.

En la primera etapa del ciclo de vida de la API, la etapa de análisis , el análisis de métricas se utiliza quizás de manera más eficaz y extensa. Al determinar la utilidad de una API, la demanda para su implementación y las decisiones entre las API privadas, las API de socios y las API públicas ( un tema que se trata con más detalle en nuestro libro electrónico Desarrollando la mentalidad de API ), el uso del análisis de métricas está diseñado específicamente. para ayudarlo a comprender su base de clientes, sus necesidades y la importancia relativa de la facilidad de accesibilidad y extensibilidad. Al analizar las tendencias del mercado, revisar los datos del servidor web y sondear a los posibles clientes y usuarios, las métricas de API pueden ayudar a reducir y definir de manera efectiva el objetivo de un sistema de API.

Durante la segunda etapa del ciclo de vida de la API, la etapa de desarrollo , el análisis de métricas cambia de un rol externo a uno interno. Mediante el análisis de los sistemas disponibles para sus desarrolladores, el seguimiento de la gestión y la implementación de funciones y el uso de métodos variados de pruebas rigurosas y seguimiento de errores, se respalda la calidad y el producto se refina en su mejor estado inicial posible. Si no se realiza un análisis adecuado de las diversas métricas de API en esta etapa, se pueden producir fallas ocultas masivas, conjuntos de funciones faltantes y una base general de usuarios disgustada.

Casi al final del ciclo de vida de la API, la etapa de operaciones es casi tan pesada en análisis de métricas como la primera, ya que se ocupa del uso público, la recepción y la respuesta interna a través de la iteración y la aplicación de parches. El seguimiento de las estadísticas de los usuarios, incluidos los métodos y la duración del uso, los comentarios generales sobre la usabilidad y la extensibilidad, y la impresión general del sistema API no solo pueden ayudarlo a refinar aún más su producto, crear una base de usuarios sólida y segura y responder rápidamente a los errores. y problemas, también puede ayudarlo a prepararse para futuros proyectos de desarrollo y hacer que la primera etapa de su próximo esfuerzo sea mucho más sencilla.

Finalmente, la cuarta etapa del ciclo de vida de la API es la etapa de retiro . Esta etapa es a menudo el resultado directo de un análisis efectivo a lo largo de las cuatro etapas anteriores. Al retirar y desaprobar las API, las métricas relacionadas con las tasas de uso, el sistema operativo y el soporte del navegador, la respuesta financiera y la confianza de la base de usuarios pueden informar la decisión de retirar, continuar o reiterar una API.

Si no se lleva a cabo un análisis de métricas de API, el producto podría pasar por un ciclo de desarrollo largo y costoso solo para encontrar poca demanda en el momento del lanzamiento, lo que haría que la API no fuera viable desde el punto de vista financiero. Sin embargo, un análisis métrico efectivo puede ayudar a crear un producto estelar, producido rápidamente y con menos gastos, lo que resulta en una mayor demanda con una vida útil más larga. Este es el poder bruto del análisis métrico.

Recorrido por la publicación del blog CTA 5-01

Un fracaso del mundo real: Heartbleed

La seguridad de la API es un gran problema y se está convirtiendo en una preocupación más importante a medida que más empresas adoptan el concepto de diseño centrado en API . Uno de los ejemplos más conocidos de fallas de seguridad que surgen de un análisis métrico deficiente es el infame error Heartbleed.Este error, que afectó a los usuarios que implementaban OpenSSL, un protocolo de seguridad ampliamente utilizado, tenía una vulnerabilidad en su algoritmo de validación de entrada de datos, que permitía un exceso de datos en su desbordamiento de búfer (un sistema destinado a permitir que los datos que exceden el tamaño máximo de búfer se "desborden"). en un registro de búfer secundario) para que se lea en su totalidad sin ser validado o verificado en busca de código malicioso. Debido a este error, los datos podrían pasar a través del sistema de desbordamiento sin validación, ejecutando comandos que hicieron que los datos internos, los sistemas y los servicios fueran vulnerables a ataques externos y maliciosos.

Este error es directamente el resultado de un análisis métrico incorrecto. Durante la construcción inicial del sistema OpenSSL y la API, las "pruebas negativas", o las pruebas de escenarios de falla, no se realizaron correctamente contra el desbordamiento del búfer; si lo hubiera sido, es probable que el problema se hubiera detectado desde el principio y se hubiera solucionado antes de que se abusara de él. Las necesidades de un sistema seguro para los consumidores finales no se identificaron adecuadamente, ya que las vulnerabilidades del sistema en sí no se probaron adecuadamente frente a fallas de validación comunes y escenarios de ataques maliciosos. Al no reconocer la tasa de incidentes de desbordamiento del búfer y el tipo de datos que fallaron en la validación durante tales escenarios en el proceso de análisis de métricas, se ignoró esencialmente toda una clase de vulnerabilidades hasta que fue demasiado tarde.

Siga leyendo: Cómo proteger adecuadamente sus API

Un éxito en el mundo real: FedEx ShipAPI

Cuando FedEx se propuso desarrollar una API para sus sistemas de envío y carga, tenían un problema en mente: la eficiencia. Al evitar el mantra "establecido es mejor" y centrarse en un modo ágil de API y desarrollo empresarial , la API de FedEx, conocida como ShipAPI, es una historia de éxito tan impresionante como se podría esperar.

En un momento, FedEx se vio inundado con lo que ellos llaman "WISMO" (¿Dónde está mi pedido?): Clientes que enfrentan variaciones extremas en los tiempos de envío, fechas de entrega inexactas y falta de actualizaciones de FedEx al cliente. Para rectificar este problema, FedEx analizó la frecuencia de estas llamadas, las ubicaciones desde las que se hicieron, los tipos de paquetes que se envían y los servicios de envío utilizados. Además, FedEx examinó sus propias prácticas internas, la tasa de adherencia al escaneo electrónico de códigos de barras al recibirlos en una instalación de FedEx y la efectividad de su sistema de seguimiento de paquetes a larga distancia.

Al identificar las debilidades en su propio sistema mediante el uso de métricas internas (utilizando métricas anecdóticas de usuarios y operadores, así como métricas duras derivadas de servidores, sistemas de escaneo e informes de clasificación internos), FedEx pudo identificar sus puntos de falla. , disminuyendo el tiempo necesario para entregar un producto y aumentando la satisfacción y la confianza del cliente. Casi de la noche a la mañana, la marca FedEx se convirtió en sinónimo de envío rápido y eficiente, y eso se debe en gran medida a su desarrollo e implementación efectivos de una API que utiliza un análisis métrico adecuado.

Seguridad, eficacia y comercio

Básicamente, el proceso de análisis de métricas no se centra únicamente en la seguridad. El comercio, la eficacia de las soluciones y más se pueden determinar mediante la derivación, el análisis y la aplicación adecuados de las soluciones derivadas de las métricas de API. Al determinar su consumidor final, sus necesidades, las necesidades de su proceso y el resultado total de la aplicación de una API, puede aumentar drásticamente los ingresos, la seguridad e incluso su base de consumidores.

¿La lección de todo esto? Comprenda su base de consumidores. Comprenda la API que está desarrollando. Y, lo más importante, mida su éxito y aprenda de sus fracasos.

Quiere más-01

Publicar un comentario

0 Comentarios